Re: undo gone in dired buffers
>It used to work in dired buffers. > >That seems incredible. Deleting the whole text of a directory listing >and reading it again is an operation that cannot preserve undo data. Yet, this is easy to reproduce. Invoke emacs 21 with -q, then C-x d /tmp RET M-! touch 00a RET g --> Now yu should see a file named 00a C-x C-q undo --> Now you don't see the file 00a any more it was useful when I updated a dired buffer with 'g' without looking at it first, and wanted to look at its old status. Very handy in some situations. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: undo gone in dired buffers
It used to work in dired buffers. That seems incredible. Deleting the whole text of a directory listing and reading it again is an operation that cannot preserve undo data. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build: some menus in the menu bar stay highlighted
Actually I think I found a safe fix. If there is no negative feedback, I'll add it to HEAD. I'm not sure who decides if it should go to the 22.1 branch. I think it should go in 22.1 as well as in the trunk. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-abbrev-end-of-buffer apparently does nothing
Apparently mail-abbrev-end-of-buffer does nothing special: it jumps to the end of buffer but does not expand the abbreviation. The code tries to expand: (defun mail-abbrev-end-of-buffer (&optional arg) "Expand any mail abbrev, then move point to end of buffer. Leave mark at previous position. With arg N, put point N/10 of the way from the true end. Don't use this command in Lisp programs! \(goto-char (point-max)) is faster and avoids clobbering the mark." (interactive "P") (if (looking-at "[ \t]*\n") (expand-abbrev)) Why doesn't it work for you? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
>> Can you show us which changes to python.el we need to remove? >> Or identify them by which versions they were checked in in? > Not easily in detail. Anything I actually contributed I consider OK, > obviously. I.e., I'd remove anything just taken from the version on > my web site. While I can imagine myself doing it, I don't remember taking anything from the version of your website. Did anybody else do that? Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: undo gone in dired buffers
Glenn Morris <[EMAIL PROTECTED]> writes: > Otherwise, it seems there is something of a trend to disable undo all > over the place, for no real reason, then have to un-disable it when > someone complains. This is true, but using undo in a dired buffer is a pretty dodgy thing to do; it seems almost guaranteed to stop working at some point in the future (if I was adding some feature to dired that made it necessary to disable undo, I wouldn't even think twice about it). -Miles -- My spirit felt washed. With blood. [Eli Shin, on "The Passion of the Christ"] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mac/INSTALL typos
> On Thu, 26 Apr 2007 12:08:54 -0400, Glenn Morris <[EMAIL PROTECTED]> said: >> Thanks. I applied your patch to both the trunk and the >> EMACS_22_BASE branch. > I think you should alter the changelog entry to be under your name, > which seems perfectly acceptable for corrections which are simple > typos (ie purely factual). > Large numbers of tiny changes from authors without assignments are > an issue. I haven't read any of the recent bug reports, but please > don't install any code from the OP. If you're not familiar with the > gory details, see admin/notes/copyright, or this thread: > http://lists.gnu.org/archive/html/emacs-devel/2007-04/msg00257.html Sorry, I should have noticed that, but I didn't recognize him when I read the report. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: filling long html href
Stefan Monnier <[EMAIL PROTECTED]> writes: > > In theory, yes, but IIRC the resulting regexp may be of a size exponential > w.r.t the size of the literals ;-( Yes, at worst. A tree of common prefixes, if you know what I mean (like regexp-opt I suppose). > I believe in practice it's not going to be exponential, but it may still be > fairly big&ugly. Yes, about 1200 chars :(. Richard Stallman <[EMAIL PROTECTED]> writes: > > How would you write paragraph-start to do that? Proof of concept below, eval it then visit a html file. On the sample foo.html below notice the "" lines were previously each an individual paragraph but now are one. The bits are still individual paragraphs, as are the bits (a deliberate unknown tag name). > I think it is very hard, perhaps impossible. Not impossible, but easier if the regex engine could get some perl style non-match lookahead (a regexp special which matches only if the following text isn't a given expression). Otherwise it'd be much easier of course to specify what is a separator rather than what's not. Just for myself I've managed with only and . I suppose it depends what and how much you write. Maybe a judicious (and perhaps customizable) selection among the standard tags would be enough. (Enough for the original motivation of etc not being a new paragraph and hence not hindering filling.) html-para.el Description: application/emacs-lisp hello world this all flows together One paragraph. Two paragraph. A paragraph. Another paragraph. This is some text. pre form world something ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python.el
Richard Stallman <[EMAIL PROTECTED]> writes: > Can you show us which changes to python.el we need to remove? > Or identify them by which versions they were checked in in? Not easily in detail. Anything I actually contributed I consider OK, obviously. I.e., I'd remove anything just taken from the version on my web site. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Gnus: message-mode creates `totally-fudged-out-message-id'
Hello! I use Gnus in Agent-mode, and I followed the Gnus-FAQ ,[ (info "(gnus)[5.12]") ] | People tell me my Message-IDs are not correct, why aren't they and how | to fix it? | | Answer | .. | | The message-ID is an unique identifier for messages you send. To make | it unique, Gnus need to know which machine name to put after the "@". | If the name of the machine where Gnus is running isn't suitable (it | probably isn't at most private machines) you can tell Gnus what to use | by saying: | [ some methods...] | |Finally you can tell Gnus not to generate a Message-ID for News at | all (and letting the server do the job) by saying | | (setq message-required-news-headers |(remove' Message-ID message-required-news-headers)) ` So I have the above two lines in my .gnus.el. This does not work reliably when I use the Agent-mode and am `unplugged': It works when I am `unplugged', compose a message (hit `a' in the Summary buffer) and let the buffer with the message `hang around' until I am `plugged', and send it with C-c C-c. See my posting on gmane.test on 2007-04-25, `Test Gnus offline, message window left open until Gnus online': it has Message-ID: <[EMAIL PROTECTED]>. However, when I am `unplugged', compose a message (hit `a' in the Summary buffer) and queue the message with C-c C-c so that it is queued in the group `nndraft:queue', put Gnus into the `plugged' state and send it with `J S' (`gnus-group-send-queue') in the Group buffer, the Message-ID looks for example like this: Message-ID: <[EMAIL PROTECTED]>. See my posting on gmane.test on 2007-04-25, `Test Gnus offline, article queued'. I will queue this message, too, before sending, so that it will get a bad Message-ID, too. (It got a bad Message-ID -- I accidentally posted it to gmane.test -- I did `a' now on `gmane.emacs.pretest.bugs' and yanked the text into this posting, which I'll queue again. So it will get a bad Message-ID, too.) In GNU Emacs 22.0.98.1 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of 2007-04-18 on whisker Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--prefix=/home/cschl/sw/emacs-22' '--with-gtk'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_GB.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Group Minor modes in effect: gnus-undo-mode: t whitespace-global-mode: t iswitchb-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: identity Recent input: [snipped] Recent messages: [snipped] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
etags: M-. looks for an uncompressed Emacs Lisp source file, but make install installs it gzipped
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. I compiled and installed the 22.0.99.1 pretest from alpha.gnu.org: ./configure --with-png --with-gtk --with-xpm --with-jpeg --with-tiff - --with-sound --prefix=/home/luca/usr && make bootstrap -j 4 && make install Note that the directory /home/luca/usr existed but was *empty*. All environment variables were already correctly setup: [EMAIL PROTECTED] ~]$ env GREEN=\033[0m\033[32m BLACK=\033[0m\033[30m MANPATH=/home/luca/usr/man:/usr/godi/man:/usr/share/man SSH_AGENT_PID=7403 TERM=xterm DESKTOP_STARTUP_ID= SHELL=/bin/bash NOATTR=\033[0m YELLOW=\033[1m\033[33m LIGHTBLUE=\033[1m\033[34m LIBRARY_PATH=/home/luca/usr/lib: GTK_RC_FILES=/etc/gtk/gtkrc:/home/luca/.gtkrc-1.2-gnome2 WINDOWID=86226876 OLDPWD=/home/luca/usr/info LC_ALL=POSIX USER=luca LD_LIBRARY_PATH=/home/luca/usr/lib: ENDTITLE=\007 BEGINTITLE=\033]0 BROWN=\033[0m\033[33m BLUE=\033[0m\033[34m GNOME_KEYRING_SOCKET=/tmp/keyring-3uqBV5/socket SSH_AUTH_SOCK=/tmp/ssh-cIKODt6834/agent.6834 SESSION_MANAGER=local/babaorum:/tmp/.ICE-unix/6834 USERNAME=luca DEFAULTS_PATH=/home/luca/.cache/fileSlbrDA LIGHTGRAY=\033[0m\033[37m XPSERVERLIST=:64 DESKTOP_SESSION=gnome PATH=/home/luca/usr/bin:/home/luca/bin:/usr/godi/bin:/usr/godi/sbin:/usr/local/bin:/usr/bin:/bin:/usr/games CLEAR=\033[2J C_INCLUDE_PATH=/home/luca/usr/include:/usr/include:/usr/X11R6/include GDM_XSERVER_LOCATION=local DARKGRAY=\033[1m\033[30m PWD=/home/luca EDITOR=emacs LANG=en_US.UTF-8 LIGHTGREEN=\033[1m\033[32m GDM_LANG=en_US.UTF-8 MANDATORY_PATH=/home/luca/.cache/file64fHIs ESC=\033 [EMAIL PROTECTED] \w]\\$ \[\033[0m\033[32m\] BLINK=\033[5m GDMSESSION=gnome RED=\033[0m\033[31m HOME=/home/luca SHLVL=1 LANGUAGE=POSIX PURPLE=\033[0m\033[35m GNOME_DESKTOP_SESSION_ID=Default LIGHTRED=\033[1m\033[31m LIGHTCYAN=\033[1m\033[36m REVERSE=\033[7m LIGHTPURPLE=\033[1m\033[35m LOGNAME=luca DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-hPM2e97j3C,guid=6fb9be6b015f87ab38525400462df4d3 TOPLEFT=\033[1;1H INFOPATH=/home/luca/usr/info: DISPLAY=:0.0 CYAN=\033[0m\033[36m WHITE=\033[1m\033[37m COLORTERM=gnome-terminal XAUTHORITY=/home/luca/.Xauthority _=/usr/bin/env Note that the `install' Makefile target installs most Emacs Lisp source files *gzipped*. Ok, then I generated TAGS from /home/luca/usr/share/emacs: etags `find -name \*.el` `find -name \*.el.gz` When looking up a tag referring a compressed ELisp file with M-., Emacs fails to find the correct file, as it tries to open a non-existing *uncompressed* version. For example with M-. goto-line I see this in the minibuffer: File /home/luca/usr/share/emacs/22.0.99/lisp/simple.el not found /home/luca/usr/share/emacs/22.0.99/lisp/simple.el in fact is not there, but /home/luca/usr/share/emacs/22.0.99/lisp/simple.el.gz exists, and its content is correct (it's gzipped, of course). Uncompressing all installed gzipped elisp files and regenerating TAGS is a way to work around the problem (tested). I don't know whether this behavior is consistent with old releases, but it's definitely not what the user expects. Other info: In GNU Emacs 22.0.99.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-04-26 on babaorum Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-png' '--with-gtk' '--with-xpm' '--with-jpeg' '--with-tiff' '--with-sound' '--prefix=/home/luca/usr'' Important settings: value of $LC_ALL: POSIX value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: nil default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: show-paren-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: M-x r e p C-g M-x r e p o r e b Recent messages: Loading /home/luca/usr/share/emacs/site-lisp/w3m/w3m.el (source)... Loading cl-macs...done Loading /home/luca/usr/share/emacs/site-lisp/w3m/w3m.el (source)...done For information about the GNU Project and its goals, type C-h C-p. [2 times] Making completion list... [2 times] Quit Making completion list... Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done Thanks, - -- Luca Saiu Author of GNU epsilon: http://www.gnu.org/software/epsilon http://www-lipn.lipn.univ-paris13.fr/~saiu -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGMHCqvzOavibF0oYRApoMAJ4mzoA5jRNXhMOGoBPVWh3N07a+2gCgrSWy vvnkWkDDz/10Pu1KszJdIFo= =DB4n -END PGP SIGNATURE- ___ emacs-pretest-bug mailin
stat problems
I am running emacs 22.0.95 on AIX 5.3 (the latest levels).
The special feature is IBM has dfs. I guess it is normal but the dfs
file system at IBM starts out with /.../path/to/files
When I open a file, emacs hangs for a long time. I put in some
fprintf's into file-exists-p (dbx told me that is where I was
hanging). The output looks like this:
stat for '/.../austin.ibm.com/fs/projects/aix/aix52Q/{arch}/=tagging-method'
stat for '/.../austin.ibm.com/fs/projects/aix/{arch}/=tagging-method'
stat for '/.../austin.ibm.com/fs/projects/{arch}/=tagging-method'
stat for '/.../austin.ibm.com/fs/{arch}/=tagging-method'
stat for '/.../austin.ibm.com/{arch}/=tagging-method'
stat for '/.../{arch}/=tagging-method'
stat for '/{arch}/=tagging-method'
...snip...
stat for '/.../austin.ibm.com/fs/projects/aix/aix52Q/MCVS/CVS'
stat for '/.../austin.ibm.com/fs/projects/aix/MCVS/CVS'
stat for '/.../austin.ibm.com/fs/projects/MCVS/CVS'
stat for '/.../austin.ibm.com/fs/MCVS/CVS'
stat for '/.../austin.ibm.com/MCVS/CVS'
stat for '/.../MCVS/CVS'
stat for '/MCVS/CVS'
This is for a single open. I removed some (many) lines.
The killer are these two stats:
stat for '/.../MCVS/CVS'
stat for '/.../{arch}/=tagging-method'
With IBM's dfs set up, these each hang for quite some time (minutes).
I discovered vc-ignore-dir-regexp
I changed it to be this:
## this is from my custom-set-variables in my init.el file
(vc-ignore-dir-regexp "\\`\\([\\/][\\/]\\|/\\.\\.\\./\\|/net/\\|/afs/\\)\\'")
As you can see, I added /.../ into the pattern. This seems to be
exactly what I need. Now the stats look like this:
stat for '/.../austin.ibm.com/fs/projects/aix/aix53H/{arch}/=tagging-method'
stat for '/.../austin.ibm.com/fs/projects/aix/{arch}/=tagging-method'
stat for '/.../austin.ibm.com/fs/projects/{arch}/=tagging-method'
stat for '/.../austin.ibm.com/fs/{arch}/=tagging-method'
stat for '/.../austin.ibm.com/{arch}/=tagging-method'
...snip...
stat for '/.../austin.ibm.com/fs/projects/aix/aix53H/MCVS/CVS'
stat for '/.../austin.ibm.com/fs/projects/aix/MCVS/CVS'
stat for '/.../austin.ibm.com/fs/projects/MCVS/CVS'
stat for '/.../austin.ibm.com/fs/MCVS/CVS'
stat for '/.../austin.ibm.com/MCVS/CVS'
I thought this might be a good general change to add in. The pattern
already has afs in the list. I believe this is the dfs equivlalent.
Although I have not been bit by it yet, I might need to add in /gsa/
as well for the gsa file system. It has the same pattern:
/gsa/region/path/to/file
So, probably stat of /gsa/CVS/ is going to hang (although from the
command line it does not seem to).
I hope this makes it to the list. I don't know if I am signed up from
this email address or not.
Take care,
Perry Smith
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
emacs 22.0.99 config/build/install/execute report - Solaris 7, 8, 9 and 10
I have configured, built, installed and executed emacs 22.0.99 on Solaris 7 through Solaris 10 with no unexpected warnings and only one significant error, which I initially reported last December for Solaris 9 in the 22.0.92 test cycle. Since that time, I have worked to further characterize the problem and have recently added Solaris 10 to the mix as well. What I learned on those two platforms caused me to try the process on Solaris 7 and Solaris 8 too. Except for "cc" and "make", I used the bundled Sun tools to configure, build and install emacs. For "cc", I used the SunPro compiler on Solaris 9 and Solaris 10 (Sun Studio 10 and 11, respectively) and GNU cc v3.3.2 on Solaris 7 and 8 (because the people who ran the license server for Sun Studio 6 seem to have turn it off without warning :-( ). For "make" I used the bundled /usr/ccs/bin/make for the configuration and build steps on all platforms but, because I was building out-of-tree, I had to use GNU make (v3.80 on all platforms) for the out-of-tree installation step. The make programs bundled with Solaris support VPATH but support *different* VPATH semantics from those supported by GNU make and this difference causes "make install" to fail badly when doing out-of-tree builds. The VPATH semantics differences are not a problem when installing from the original source tree; they are only a problem when working out-of-tree. I had hoped to report the changes needed for the configuration process to make "make install" work with the bundled make but, given the imminent release of GNU emacs v22.1.0, I've run out of time and am following RMS's proposed solution of documenting the problem and moving on. Below is proposed text for .../etc/PROBLEMS (and, yes, I already have papers on file at the FSF). ---snip---snip--- On Solaris, use GNU Make when installing an out-of-tree build The Emacs configuration process allows you to configure the build environment so that you can build emacs in a directory outside of the distribution tree. When installing emacs from an out-of-tree build directory on Solaris, you may need to use GNU make. The make programs bundled with Solaris support the VPATH macro but use it differently from the way the VPATH macro is used by GNU make. The differences will cause the "make install" step to fail, leaving you with an incomplete emacs installation. GNU make is available in /usr/sfw/bin on Solaris 10 and can be installed as /opt/sfw/bin/gmake from the Solaris 9 Software Companion CDROM. The problems due to the VPATH processing differences affect only out of tree builds so, if you are on a Solaris installation without GNU make, you can install emacs completely by installing from a build environment using the original emacs distribution tree. ---snip---snip--- Please feel free to edit the above for clarity or to ask me to clarify anything unclear in this message. -- David R. Linn |INET: [EMAIL PROTECTED] Vanderbilt University School of Engineering|Phone: [+1] 615-343-6164 VU Station B Box 351826|Disclaimer: I have no authority Nashville, TN, USA 37235-1826 |to speak for anyone but myself. http://web.vuse.vanderbilt.edu/~drl ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (void-function nil) error without backtrace
On Thursday, April 26, 2007 at 23:05:08, Robert Widhopf-Fenk wrote: > On Tuesday, April 24, 2007 at 12:03:44, Richard Stallman wrote: > > Whenever I enable debug-on-error when running VM I get a > > backtrace with the following content: > > > > Please try running under GDB with a breakpoint at call_debugger > > and send the C-level backtrace made by the `backtrace' command. > > It is below. When continuing I get another shorter one ... (gdb) c Continuing. Breakpoint 1, call_debugger (arg=141105341) at eval.c:265 265 int old_max = max_specpdl_size; (gdb) bt #0 call_debugger (arg=141105341) at eval.c:265 #1 0x08152bac in find_handler_clause (handlers=137512761, conditions=, sig=, data=141105389, debugger_value_ptr=0xbfca3f28) at eval.c:1920 #2 0x08153eb2 in Fsignal (error_symbol=137512857, data=141105389) at eval.c:1672 #3 0x08153ff8 in xsignal (error_symbol=137512857, data=141105389) at eval.c:1722 #4 0x081544f0 in xsignal1 (error_symbol=137512857, arg=137468105) at eval.c:1739 #5 0x08152f2c in Feval (form=141009453) at eval.c:2374 #6 0x08152391 in internal_condition_case_1 (bfun=0x8152c80 , arg=141009453, handlers=137512761, hfun=0x80effb0 ) at eval.c:1529 #7 0x080f2f02 in menu_item_eval_property (sexpr=141009453) at keyboard.c:7429 #8 0x080f3124 in process_tool_bar_item (key=139960929, def=141007877, data=137468105, args=0x0) at keyboard.c:8116 #9 0x080fe275 in map_keymap_item (fun=0x80f2f20 , args=137468105, key=0, val=137904840, data=0x0) at keymap.c:677 #10 0x081000ff in map_keymap (map=, fun=0x80f2f20 , args=137468105, data=0x0, autoload=1) at keymap.c:716 #11 0x080f29de in tool_bar_items (reuse=140952324, nitems=0xbfca4218) at keyboard.c:7893 #12 0x08073737 in update_tool_bar (f=0x85bcbf0, save_match_data=0) at xdisp.c:9423 #13 0x0807d61e in prepare_menu_bars () at xdisp.c:9107 #14 0x08086c15 in redisplay_internal (preserve_echo_area=) at xdisp.c:10944 #15 0x080f8902 in read_char (commandflag=1, nmaps=2, maps=0xbfca4fe0, prev_event=137468105, used_mouse_menu=0xbfca5088, end_time=0x0) at keyboard.c:2659 #16 0x080fb0d2 in read_key_sequence (keybuf=0xbfca5134, bufsize=30, prompt=137468105, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9115 #17 0x080fcb85 in command_loop_1 () at keyboard.c:1618 #18 0x081525cb in internal_condition_case (bfun=0x80fc9f0 , handlers=137512761, hfun=0x80f7450 ) at eval.c:1481 #19 0x080f682e in command_loop_2 () at keyboard.c:1329 #20 0x0815268c in internal_catch (tag=137506745, func=0x80f6800 , arg=137468105) at eval.c:1222 #21 0x080f729e in command_loop () at keyboard.c:1308 #22 0x080f7628 in recursive_edit_1 () at keyboard.c:1006 #23 0x080f7716 in Frecursive_edit () at keyboard.c:1067 #24 0x080ed7e2 in main (argc=Cannot access memory at address 0x0 ) at emacs.c:1761 (gdb) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (void-function nil) error without backtrace
On Tuesday, April 24, 2007 at 12:03:44, Richard Stallman wrote: > Whenever I enable debug-on-error when running VM I get a > backtrace with the following content: > > Please try running under GDB with a breakpoint at call_debugger > and send the C-level backtrace made by the `backtrace' command. It is below. > It was caused by a wrong toolbar item spec for the prop :button > and can be reproduced with GNU Emacs 22.0.92.1 and 21.4.1 on > Debian when adding the following to ~/.emacs: > > It may be we don't need to fix this for Emacs 22, but we > will want to fix it sooner or later, and further info will > show us how to do that. Bye Robert ~ > gdb bin/emacs GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) b call_debugger Breakpoint 1 at 0x81527c9: file eval.c, line 265. (gdb) r Starting program: /home/widhopf/bin/emacs Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1214142784 (LWP 2016)] [Switching to Thread -1214142784 (LWP 2016)] Breakpoint 1, call_debugger (arg=139304085) at eval.c:265 265 int old_max = max_specpdl_size; (gdb) bt #0 call_debugger (arg=139304085) at eval.c:265 #1 0x08152bac in find_handler_clause (handlers=137512761, conditions=, sig=, data=139304613, debugger_value_ptr=0xbfac3a88) at eval.c:1920 #2 0x08153eb2 in Fsignal (error_symbol=137512857, data=139304613) at eval.c:1672 #3 0x08153ff8 in xsignal (error_symbol=137512857, data=139304613) at eval.c:1722 #4 0x081544f0 in xsignal1 (error_symbol=137512857, arg=137468105) at eval.c:1739 #5 0x08152f2c in Feval (form=141009453) at eval.c:2374 #6 0x08152391 in internal_condition_case_1 (bfun=0x8152c80 , arg=141009453, handlers=137512761, hfun=0x80effb0 ) at eval.c:1529 #7 0x080f2f02 in menu_item_eval_property (sexpr=141009453) at keyboard.c:7429 #8 0x080f3124 in process_tool_bar_item (key=139960929, def=141007877, data=137468105, args=0x0) at keyboard.c:8116 #9 0x080fe275 in map_keymap_item (fun=0x80f2f20 , args=137468105, key=0, val=137904840, data=0x0) at keymap.c:677 #10 0x081000ff in map_keymap (map=, fun=0x80f2f20 , args=137468105, data=0x0, autoload=1) at keymap.c:716 #11 0x080f29de in tool_bar_items (reuse=137468105, nitems=0xbfac3d78) at keyboard.c:7893 #12 0x08073737 in update_tool_bar (f=0x85bcbf0, save_match_data=0) at xdisp.c:9423 #13 0x0807d61e in prepare_menu_bars () at xdisp.c:9107 #14 0x08086c15 in redisplay_internal (preserve_echo_area=) at xdisp.c:10944 #15 0x080f8902 in read_char (commandflag=1, nmaps=2, maps=0xbfac4b40, prev_event=137468105, used_mouse_menu=0xbfac4be8, end_time=0x0) at keyboard.c:2659 #16 0x080fb0d2 in read_key_sequence (keybuf=0xbfac4c94, bufsize=30, prompt=137468105, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9115 #17 0x080fcb85 in command_loop_1 () at keyboard.c:1618 #18 0x081525cb in internal_condition_case (bfun=0x80fc9f0 , handlers=137512761, hfun=0x80f7450 ) at eval.c:1481 #19 0x080f682e in command_loop_2 () at keyboard.c:1329 #20 0x0815268c in internal_catch (tag=137535305, func=0x80f6800 , arg=137468105) at eval.c:1222 #21 0x080f7247 in command_loop () at keyboard.c:1296 #22 0x080f7628 in recursive_edit_1 () at keyboard.c:1006 #23 0x080f7716 in Frecursive_edit () at keyboard.c:1067 #24 0x08153ae5 in Ffuncall (nargs=1, args=0xbfac4fe0) at eval.c:2994 #25 0x0817e3fa in Fbyte_code (bytestr=136591347, vector=136591372, maxdepth=48) at bytecode.c:679 #26 0x08153048 in Feval (form=136591333) at eval.c:2334 #27 0x0815268c in internal_catch (tag=139712801, func=0x8152c80 , arg=136591333) at eval.c:1222 #28 0x0817d67f in Fbyte_code (bytestr=136590995, vector=136591012, maxdepth=56) at bytecode.c:854 #29 0x08153594 in funcall_lambda (fun=136590948, nargs=1, arg_vector=0xbfac5304) at eval.c:3184 #30 0x081539ab in Ffuncall (nargs=2, args=0xbfac5300) at eval.c:3054 #31 0x0817e3fa in Fbyte_code (bytestr=136593779, vector=136593796, maxdepth=16) at bytecode.c:679 #32 0x08153594 in funcall_lambda (fun=136593732, nargs=1, arg_vector=0xbfac5424) at eval.c:3184 #33 0x081539ab in Ffuncall (nargs=2, args=0xbfac5420) at eval.c:3054 #34 0x0817e3fa in Fbyte_code (bytestr=136594091, vector=136594108, maxdepth=96) at bytecode.c:679 #35 0x08153594 in funcall_lambda (fun=136594060, nargs=1, arg_vector=0xbfac5564) at eval.c:3184 #36 0x081539ab in Ffuncall (nargs=2, args=0xbfac5560) at eval.c:3054 #37 0x0817e3fa in Fbyte_code (bytestr=136585355, vector=136585372, maxdepth=56) at bytecode.c:679 #38 0x08153594 in funcall_lambda
find-dired output isn't fully propertized
1. emacs -Q
2. M-x find-dired RET RET -name "*src"
3. The buffer *Find* contains this:
,
| :
| find . \( -name "*src" \) -exec ls -ld \{\} \;
| drwxr-xr-x 2 steve users 4096 2007-04-26 17:43 lib-src
| drwxr-xr-x 2 steve users 4096 2007-04-26 20:17 src
|
| find finished at Thu Apr 26 20:38:37
`
In this dired listing, moving the mouse over `lib-src' displays
mouse-face highlighting and a tooltip, but moving the mouse over src
does not.
If step 2 above is replaced by the following:
M-x find-dired RET RET -name "Make*"
the output is a dired listing of all the Makefiles in the Emacs source
tree, plus Makefile.c files. In this listing moving the mouse the
last N file names fails to show mouse-face highlighting and a tooltip,
where N can be anywhere from 1 to all but the first dired entry;
repeating this find-dired invocation doesn't always yield the same
number, except that at least the last dired entry is not propertized.
In particular, if the output of find-dired is just a single dired
entry (e.g., with `M-x find-dired RET RET
-name lisp') , then it lacks mouse-face and tooltip.
The following patch fixes this bug, AFAICT:
*** find-dired.el.~1.55.~ 2007-01-21 23:44:41.0 +0100
--- find-dired.el 2007-04-26 21:51:25.0 +0200
***
*** 257,263
(delete-region (point) (- (point) 2)))
;; Find all the complete lines in the unprocessed
;; output and process it to add text properties.
! (goto-char end)
(if (search-backward "\n" (process-mark proc) t)
(progn
(dired-insert-set-properties (process-mark proc)
--- 257,263
(delete-region (point) (- (point) 2)))
;; Find all the complete lines in the unprocessed
;; output and process it to add text properties.
! (goto-char (point-max))
(if (search-backward "\n" (process-mark proc) t)
(progn
(dired-insert-set-properties (process-mark proc)
In GNU Emacs 22.0.98.2 (i686-pc-linux-gnu, GTK+ Version 2.10.6)
of 2007-04-20 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.70199902
configured using `configure '--with-x-toolkit=gtk''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8
default-enable-multibyte-characters: t
Major mode: Emacs-Lisp
Minor modes in effect:
shell-dirtrack-mode: t
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: identity
Recent input:
i r e d - m o d e C-x b
C-h f C-x o
C-x 1
M-x
C-x kC-u C-M-x M-x
SPC SPC SPC SPC
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC
SPC SPC SPC SPC SPC
SPC SPC SPC SPC C-x k M-x
C-x 1
C-s C-w C-w C-w
C-r C-r C-r C-r
C-x b C-x b SPC f f f
SPC SPC C-x k
C-h f
C-x 1
C-s p r o c
C-s C-x b
C-x b
M-x r e p o
r
Recent messages:
Go...
Break [2 times]
Breakpoint set in find-dired-filter
Go...
Break
Result: # [2 times]
Type C-x 1 to remove help window.
Mark saved where search started
Making completion list...
Loading emacsbug...done
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build: some menus in the menu bar stay highlighted
On Wed, 25 Apr 2007 20:10:12 +0200 Jan Djärv <[EMAIL PROTECTED]> wrote: > Jan Djärv skrev: > >> I'd say this is a bug in QtCurve. I can not find a way to undo that >> effect from within Emacs. Apart from the obvious, always update >> menus deep. But I don't think we want to do that just for one >> theme. Not that I think it would break anything, it would just make >> menu bar updating a bit slower. > > I found an easier way. Can you try the attached patch? This patch fixes the sticky menu highlighting problem with QtCurve for me; thanks! Steve Berman ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mac/INSTALL typos
YAMAMOTO Mitsuharu wrote: > Thanks. I applied your patch to both the trunk and the EMACS_22_BASE > branch. I think you should alter the changelog entry to be under your name, which seems perfectly acceptable for corrections which are simple typos (ie purely factual). Large numbers of tiny changes from authors without assignments are an issue. I haven't read any of the recent bug reports, but please don't install any code from the OP. If you're not familiar with the gory details, see admin/notes/copyright, or this thread: http://lists.gnu.org/archive/html/emacs-devel/2007-04/msg00257.html ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: undo gone in dired buffers
Francesco Potorti` wrote: > It used to work in dired buffers. [...] > The old behaviour could be occasionally useful, and had no adverse side > effects that I am aware of. Maybe this? http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-02/msg00128.html Otherwise, it seems there is something of a trend to disable undo all over the place, for no real reason, then have to un-disable it when someone complains. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: undo gone in dired buffers
>It is normal that undo does not work across revert. It used to work in dired buffers. Occasionally I happen to hit 'g' and then wanting to look at the previous state. In Emacs 21 I used to remove the read-only status of the dired with C-xC-q and then undo. This one does not work any more in Emacs 22. Or else deleting a file, then wanting to look at its lenght: toggle-read-only plus undo did the trick. This one still works. The old behaviour could be occasionally useful, and had no adverse side effects that I am aware of. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mac/INSTALL typos
> On Wed, 25 Apr 2007 20:29:50 -0600, Kevin Rodgers <[EMAIL PROTECTED]> > said: > There are 2 occurrences of /Application (singular) that should be > /Applications (plural): Thanks. I applied your patch to both the trunk and the EMACS_22_BASE branch. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mac OS X: colors in a terminal
> On Wed, 25 Apr 2007 21:17:17 -0600, Kevin Rodgers <[EMAIL PROTECTED]> > said: > The mac/INSTALL file says: To use colors in a terminal, put the > following lines in the file ~/.termcap and log in again. (snip) > Is the suggestion in mac/INSTALL obsolete altogether or does it just > need to be clarified? This description seems to be applicable only to Terminal.app on Mac OS X 10.1. I'll update it. Thanks for notifying. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Indentation bug in html-mode
Stefan Monnier wrote: The attached file is valid XHTML 1.1 but indents badly because of the < inte part. I paste it here for simplicity too: Hmm... does the patch below fix it for you? If you put a " It fixes the last two lines ( and ), but not the line. The additional patch below should fix that, provided Emacs is in XHTML mode (rather than HTML mode). If I understand the HTML docs properly your example code is not valid in HTML because the < is not allowed inside . Thanks, indeed that did the trick. I guess you with XHTML mode mean html-mode + XHTML DTD? How do I get html-mode to follow the XHTML DTD? In the circumstances I am going to use it sometimes there are no proper header part with DTD spec. No, I mean that Emacs is using html-mode with sgml-xml-mode set to t (this is normally reflected in the mode-line as "XHTML"). It would be very nice if these bug fixes were installed before the release. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
