Re: tool-bar doesn't work on the trunk with (default) GTK build
> > Does anybody else see this? (I'm using Ubuntu 7.4, if that's relevant) > > You mean 7.04 I guess? Yes. > > It looks to me like some kind of timing problem and presumably it doesn't > > respond nicely to running an underlying asynchronous process. > > > > Dou you have click to focus or focus follows mouse or something else? Do you > use metacity? It sounds like after the first click, GUD does something that > moves the focus away from the tool bar. I'm fairly sure it's metacity. I just use the default desktop which is Gnome. I don't even know how to change the window manager. I use click to focus (default again) but if I change to focus follows mouse then I can indeed click on a toolbar button again without moving it away first. There's still something a bit odd though because the highlighting around the button still disappears after the first click. This is not the case if I look at another GTK application with a toolbar, e.g., Firefox. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tool-bar doesn't work on the trunk with (default) GTK build
> I can't reproduce this on HEAD or EMACS_22_BASE. Maybe it's a problem with my build/configuration. > What version of Gtk do you have? GTK+ Version 2.10.11 (I did give this in my first post) > Does the clicks show up in C-h l? That is > if you do two rapid clicks, do you get two tool bar events or just one? Interestingly if they are rapid I do get two tool bar events and the button remains active. However, if I just do one click the highlighting around the button disappears and I can't activate it again without moving it away first. Does anybody else see this? (I'm using Ubuntu 7.4, if that's relevant) It looks to me like some kind of timing problem and presumably it doesn't respond nicely to running an underlying asynchronous process. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tool-bar doesn't work on the trunk with (default) GTK build
> > > > I don't think this is the right fix. On some of the GUD toolbar > > > > icons in a debug session, if I don't move the mouse pointer off the > > > > tool-bar button and click again, e.g., next, step nothing happens. I > > > > have to move the pointer away and back again to activate the button. > > > > Oddly, there doesn't seem to be a problem with other buttons like > > > > Info-next in Info. > > > > > > > > > > That is another bug. It only shows up in Gnus. > > > > The report above demonstrates that it doesn't only show up in Gnus. Does > > it occur on EMACS_22_BASE with a GTK build too? I find it quite > > inconvenient and a reason to revert to the Lucid toolkit. Are you saying > > that it can't be fixed? > > > > No, I'm not saying it can't be fixed. Which GUD toolbar icons have this bug? In addition to the ones I've already mentioned above (we seem to have a very poor line!), gud-stepi, gud-nexti, perhaps gud-finish but not gud-up or gud-down. It looks like the ones which restart execution of the program being debugged. Perhaps the problem in Gnus involves another process too. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tool-bar doesn't work on the trunk with (default) GTK build
Jan Djärv writes: > Nick Roberts skrev: > > If I click on tool-bar buttons e.g. when the *scratch* buffer is current, I > > get messages like: > > > > is undefined > > is undefined > > > > I don't know if this is particular to the trunk, using GTK, or my build. > > > > > > Now fixed, please test it. I don't think this is the right fix. On some of the GUD toolbar icons in a debug session, if I don't move the mouse pointer off the tool-bar button and click again, e.g., next, step nothing happens. I have to move the pointer away and back again to activate the button. Oddly, there doesn't seem to be a problem with other buttons like Info-next in Info. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
tool-bar doesn't work on the trunk with (default) GTK build
If I click on tool-bar buttons e.g. when the *scratch* buffer is current, I get messages like: is undefined is undefined I don't know if this is particular to the trunk, using GTK, or my build. -- Nick http://www.inet.net.nz/~nickrob In GNU Emacs 22.1.50.5 (i686-pc-linux-gnu, GTK+ Version 2.10.11) of 2007-08-02 on kahikatea.snap.net.nz Windowing system distributor `The X.Org Foundation', version 11.0.7020 configured using `configure 'CFLAGS=-g3'' 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_NZ.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: show-paren-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 line-number-mode: t transient-mark-mode: t Recent input: e f i n d d i r e d I f SPC I SPC c l i c k SPC o n SPC t o o l - b a r SPC b i u t t o n U s i n g SPC E m s SPC e . g . SPC i w h e n SPC t h e SPC * s c r a t c h * SPC b u f f e r SPC i s SPC c u r r e t n t SPC . SPC , SPC I g e t SPC m e s s a g e s SPC l i k e : I SPC d o n ' t SPC k n o w SPC i f SPC t h i s SPC i s SPC p a r t i c u l a r SPC t o SPC t h e SPC , SPC u s i g n g SPC G T K SPC , SPC o r SPC m y SPC b u i l d . M-x r e p o e r t SPC e m SPC b SPC Recent messages: Saving... Saving file /home/nickrob/mail/mbox... Wrote /home/nickrob/mail/mbox Mark set Loading mail-utils...done Auto-saving...done Mark set [2 times] Auto-saving...done Mark set Loading emacsbug...done -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
> > In my opinion we should very much make the gdb-ui code the default. > > As for keeping support for --fullname, I believe it's needed as long as the > > gdb-ui code isn't as robust as the --fullname one. I'm not sure what is the > > current state of affairs, but I've had to switch to --fullname because of > > minor problems at least once in the last year. > I think another issue is multiple-debugging session support (though I > like the new gdb-ui too). Not critical for most people, but may be for > some. FWIW I never suggested removing --fullname now, just not allowing it's use with "M-x gdb" so that the Graphical Interface would work in those cases where currently only M-x gdba does. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
> > > IMO, it's not nice to change the package semantic in such radical ways > > > behind users' backs. I know a few people who like the current "M-x > > > gdb" and will not be pleased to see the GUI version instead. > > > > It's not nice trying to get Emacs to work out which option has been > > selected as well as which version of GDB is running. > > ??? Emacs is a program; how can one be ``nice'' or ``not nice'' to a > program? Are you saying it is hard to check the value of a single > variable and invoke one of two functions depending on that? What am I > missing here? This is just a misunderstanding in the use of English. Here, to whom it is not nice is implicit. In your sentence it's the users. In mine, the developer(s). > > At it's basic level, the GUI version works just like the old version > > except that breakpoints are marked with a bulet in the fringe. > > What happens if there's no fringe? It creates a display margin and displays the bullet there. > What happens in a no-window (-nw) > session? It creates a display margin and displays a B/b there. > Also, what if in the future we decide that gdb-ui opens its > additional windows by default (a reasonable decision for a > GUI-oriented debugging interface)? If users like the old behaviour then we wouldn't change the default. > > Johan Walles is the just about the only user to make a bug report on it > > since the release. If users choose not to report problems, then it makes > > it hard to accomodate their view. > > I didn't say I objected to invoking gdb-ui by default. Even if you did, I could try to convice you that it would be alright. Clearly I can't do that who have not expressed their reasons. > > > How about if we modify "M-x gdb" to invoke gdb-ui if a certain option > > > is set? Whether this option should be on or off by default, is > > > another matter, but at least users will be able to control what UI > > > they get by flipping a single option. > > > > Most users will just use the default until it causes problems, so I don't > > see that there's much difference. > > It makes difference to those who would like the old interface: they > will need to flip a single variable, and still use the same command. You might, indeed, be right but I don't know who these people are because they haven't posted to this mailing list. My ultimate aim is to _replace_ the old mode with one using GDB/MI, which will also need changes to GDB. A release from the trunk won't happen for a long time. I think this is an opportunity to make that transition. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
> IMO, it's not nice to change the package semantic in such radical ways > behind users' backs. I know a few people who like the current "M-x gdb" > and will not be pleased to see the GUI version instead. > > I agree. Perhaps being disruptive sometimes is a good thing. > How about if we modify "M-x gdb" to invoke gdb-ui if a certain option > is set? > > That would be ok. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
Stefan Monnier writes: > > How about if we modify "M-x gdb" to invoke gdb-ui if a certain option > > is set? Whether this option should be on or off by default, is > > another matter, but at least users will be able to control what UI > > they get by flipping a single option. > > Yes, I suggest the following: > > - introduce a new custom var with three values (one for --fullname, one for > --annotate=3 and one for auto-detect, this last one being the default). > - get rid of the `gdba' name. > - improve `gdb's autodetection by checking the command provided for > "--fullname" or "--annotate=3" (this may fail if the command just runs > a script, so we still need the current autodetection). > - change default gud-gdb-command-name depending on gud-gdb-annotations. This seems to be the classic Emacs approach of an option for everything. Sometimes I prefer that someone who has a deeper understanding to make clear choices for me. In the case of "M-x gdb" I'm striving towards having just one mode. AFAICS the old mode still remains because the new one doesn't do everything that the old one does. However, that doesn't mean that we should encourage or legitimise use of the old one. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
> > This is a suggestion to the mailing list, but also a RFA to RMS. Now that > > gdb-ui is part of the release, how about renaming gdb to gdbf and gdba to > > gdb on the trunk so that the new mode takes the focus? > > IMO, it's not nice to change the package semantic in such radical ways > behind users' backs. I know a few people who like the current "M-x gdb" > and will not be pleased to see the GUI version instead. It's not nice trying to get Emacs to work out which option has been selected as well as which version of GDB is running. At it's basic level, the GUI version works just like the old version except that breakpoints are marked with a bulet in the fringe. So I'd like to know why some people would not be pleased to see the GUI version instead. Johan Walles is the just about the only user to make a bug report on it since the release. If users choose not to report problems, then it makes it hard to accomodate their view. > How about if we modify "M-x gdb" to invoke gdb-ui if a certain option > is set? Whether this option should be on or off by default, is > another matter, but at least users will be able to control what UI > they get by flipping a single option. Most users will just use the default until it causes problems, so I don't see that there's much difference. > > This would ensure that GDB initialisation scripts that start execution > > don't cause problems with "M-x gdb". It would also mean that using > > "-fullname" would only work for "M-x gdbf", for which it could be the > > default. > > Can't we fix these issues with "N-x gdb", so that both UIs work with > them? Not without making changes to the behaviour of annotations in GDB itself which I don't intend to do as we're trying to move over to GDB/MI. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
> > ...What's the difference betweeen gdb and gdba? I wasn't able to > > find anything documenting the difference, according to the docs they > > seem to do roughly the same thing. > > > M-x gdba assumes that GDB is being run with the "--annotate=3" option. M-x > > gdb filters the output to determine whether GDB is being run with > > "--fullname" or "--annotate=3". The former gives the old Emacs 21 > > functionality (or lack of it!) and is worth using if all else fails. > > As someone read somewhere that --annotate=3 should be used with > Emacs22, that's what we're using with Emacs22. So if all "gdb" (sans > "a") does it trying to figure that out, "gdba" is what we should and > will use. > > > So they do indeed do the same thing, in most cases, when "--annotate=3" is > > used (the default). There is a problem when GDB commands like "run" are > > included in GDB scripts because these get run _before_ GDB commands that > > Emacs uses to set up the mode. Perhaps I'll add a note in the manual. > > Something in there about how "gdba" and "gdb" differs would be great! This is a suggestion to the mailing list, but also a RFA to RMS. Now that gdb-ui is part of the release, how about renaming gdb to gdbf and gdba to gdb on the trunk so that the new mode takes the focus? This would ensure that GDB initialisation scripts that start execution don't cause problems with "M-x gdb". It would also mean that using "-fullname" would only work for "M-x gdbf", for which it could be the default. WDYT? -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
> I'm attaching a new debug log where I've gone one step further and > done "f" in the GDB pane to get the source window to refresh. That > did get me a bunch of error messages which might make this log a bit > more interesting to you. It still doesn't seem to contain the errors but I don't think they can be avoided without deffering execution or using M-x gdba anyway. > > What happens if you start your application under GDB without the GDB > > scripts? > The reason we have the scripts is that what we're debugging is a > library (libjvm.so), and the scripts run load and run things long > enough for us to get into our library. If we don't run the scripts, > nothing will even get loaded into gdb. I see, but presumably you can do this after M-x gdb has started up: M-x gdb Run gdb (like this): gdb -annotate=3 myprog In GUD buffer: Current directory is /home/nickrob/ GNU gdb 6.6-debian ... (gdb) source myscript but, in any case, M-x gdba is probably more convenient. > > I think that M-x gdb doesn't work in you start execution from within a > > script. In this case you must use M-x gdba. Does this work? > Yes! What's the difference betweeen gdb and gdba? I wasn't able to > find anything documenting the difference, according to the docs they > seem to do roughly the same thing. M-x gdba assumes that GDB is being run with the "--annotate=3" option. M-x gdb filters the output to determine whether GDB is being run with "--fullname" or "--annotate=3". The former gives the old Emacs 21 functionality (or lack of it!) and is worth using if all else fails. So they do indeed do the same thing, in most cases, when "--annotate=3" is used (the default). There is a problem when GDB commands like "run" are included in GDB scripts because these get run _before_ GDB commands that Emacs uses to set up the mode. Perhaps I'll add a note in the manual. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs 23.0.0.1 fails parsing gdb output
> In GNU Emacs 23.0.0.1 (i486-pc-linux-gnu, GTK+ Version 2.10.11) > of 2007-07-06 on helios I have GNU gdb 6.6-debian and it works fine with GNU Emacs 23.0.0.3 (i686-pc-linux-gnu, GTK+ Version 2.10.11). > > Does it fail with Emacs 22.1? > I'm having the same or very similar problems on Solaris / Sparc using > Emacs 22.1 and gdb-6.5. There might be problems with GDB on Solaris / Sparc. > > then post the value of gdb-debug-log to [EMAIL PROTECTED] > Attached. This log looks OK but it's prior to execution. Your earlier report, which I should have looked at more carefully, shows the problem occurs after execution begins: Loading GDB sequences... *** Hope you've got /home/appeal/bin or //depot/jrockit/cce/gdbutils in your path *** I use a few helper scripts nowadays Generating isNativeIp and printmodule What happens if you start your application under GDB without the GDB scripts? I think that M-x gdb doesn't work in you start execution from within a script. In this case you must use M-x gdba. Does this work? >Since this (or something very similar) is a problem with > both 22.1 and 23.0.0.1 I'm posting to both bug lists. Yes, it's taken so long to release 22.1, I forget that bug-gnu-emacs is the proper mailing list for 22.1. It's probably sufficient though to keep the thread on emacs-pretest-bug and just report conclusions (if any) on bug-gnu-emacs. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: clipboard integration hangs pasting text from emacs
> I think names for releases is completely confusing. > Debian does this, and I never remember which one is which. Its not just Debian. Fedora, Apple and Ubuntu do too. It has the advantage that if you make a bugfix or security release, as with Emacs 21.4, it doesn't throw all of us who have been calling it the next big release. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: clipboard integration hangs pasting text from emacs
Jason Rumney writes: > Peter Wisnovsky wrote: > > In GNU Emacs 22.0.990.1 (i386-mingw-nt5.1.2600) > > > > Loading semantic-edit...done > > Loading semanticdb-file...done > > Emacs 21.1 has been released, so please use that rather than a pretest > version. I think you mean "Emacs 22.1 has been released". I've made the same mistake. Perhaps we should give the next release a name. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Recent change to Faccept_process_output
> The relevant thread can be found here: > http://lists.gnu.org/archive/html/bug-gnu-emacs/2007-05/msg6.html For future reference, my understanding is that bug-gnu-emacs is for released versions of Emacs, while emacs-pretest-bug is for versions in CVS. That is why many of us didn't read it. You just have to remember to use M-x report-emacs-bug and your version of Emacs should select the right list. It also supplies your configuration which can also sometimes be useful. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Recent change to Faccept_process_output
2007-05-03 Per Cederqvist * process.c (Faccept_process_output): Revert 2006-03-22 change so that the third argument once again is in microseconds (not milliseconds). This makes it compatible with Emacs 21 and earlier. Problem found by Henrik Rindl??w. I've seen no discussion about this change. It seems to just revert an earlier one. Did you read the thread in the archives about why it was made? Maybe it solves a problem for Henrik Rindl??w, but it probably causes problems for many others. Another solution would be to revert back again and explain in NEWS that this feature is no longer compatible with Emacs 21. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-` cannot access emacs Menu Bar.
> In GNU Emacs 22.0.97.1 (powerpc-apple-darwin8.9.0, Carbon Version 1.6.0) > of 2007-04-16 on silver-lightnin.local >... > tmm-menubar: Wrong type argument: listp, keymap > Buffer is read-only: # > tmm-menubar: Wrong type argument: listp, keymap >... I think this has already been fixed in CVS. Can you update and try again. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python(pdb) & gud: "stop" causes uncaught exception
> There is a project called "pydb" which seems to improve upon PDB: > > http://bashdb.sourceforge.net/pydb/ > > They claim to have "gdb-style signal handling". > It comes with an Emacs mode: The debugger (gud-pdb-command-name) was set the this at one time but Dave Love got me to revert it back to pdb. > http://wiki.showmedo.com/index.php/PythonBernsteinPydbIntro > > Unfortunately, comint-stop-subjob doesn't do much - pydb just prints > "program received SIGINT", but doesn't interrupt the program. > > It seems like it is set up to handle the signal: > > (Pydb) handle SIGINT > SignalStop Print Stack PassDescription > SIGINTYesYes No No Interrupt > > ... but it doesn't do this. I don't understand why. I'm cc'ing the > appropriate mailing list - maybe they can shed some light on this. We need someone who uses Python to deal with this, but for some reason (historical, perhaps) Python developers are more aligned with XEmacs. Pdbtrack is meant to be better for debugging Python programs and, on more than one occasion, I have posted a patch (python.el) here for this. It's not been committed because the some of the authorship is unclear. However, you might want to resurrect it for Aquamacs -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python(pdb) & gud: "stop" causes uncaught exception
> Pressing the "stop" button in gud with pdb running (gud-stop-subjob) > causes an unhandled python exception (stack trace below). Yes, I've seen this too. I couold make the "stop" button invisible for pdb but the underlying is with comint-stop-subjob which is on the menubar of the GUD buffer and C-c C-z. >... > KeyboardInterrupt > Uncaught exception. Entering post mortem debugging > Running 'cont' or 'step' will restart the program > > /usr/local/lib/python2.4/cmd.py(151)cmdloop() > -> pass > (Pdb) All comint-stop-subjob does is send SIGINT to the process. When a program runs under GDB, SIGINT is intercepted by GDB and not normally passed on to the program, but pdb doesn't seem to do this. If you run a pythons script under pdb from the command line and type ^C then you should get the same result that you see in Emacs. So the question is: How do you interrupt a python script that is being debugged? -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Help buffer links on a console
> On a linux console and using t-mouse, clicking on a link in a help > buffer only works if the cursor is already over the link. Otherwise > Emacs reports "No cross-reference here" which indicates that > help-follow-mouse has been activated, rather than push-button. > > Can you debug it? I don't know how to try to repeat this. I have looked at it but it's a low level problem and involves code that I'm not I'm not familar with. Both t-mouse.el and xt-mouse.el put mouse clicks into the command input via the variable unread-command-events. For some reason xt-mouse.el works as I would expect, but t-mouse.el doesn't. It's quite forward to reproduce if you have gpm installed and running: all you have to do is try to click on a link in the help buffer while the cursor is elsewhere in the buffer or another window is selected. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info-scroll-up/down on mode-line
> Maybe: > > *** info.el 01 Apr 2007 23:11:10 -0700 1.500 > --- info.el 23 Apr 2007 00:02:02 -0700 > *** > *** 2602,2607 > --- 2602,2608 > in other ways.)" > > (interactive) > + (select-window (posn-window (event-start last-input-event))) > (if (or (< (window-start) (point-min)) >(> (window-start) (point-max))) > (set-window-start (selected-window) (point))) >... Sometimes I see it like below. Also I wonder if the window should be selected or save-selected-window used. -- Nick http://www.inet.net.nz/~nickrob *** info.el 02 Apr 2007 17:11:22 +1200 1.500 --- info.el 23 Apr 2007 21:01:49 +1200 *** *** 2587,2593 (goto-char (point-max) (t (error "No previous nodes" ! (defun Info-scroll-up () "Scroll one screenful forward in Info, considering all nodes as one sequence. Once you scroll far enough in a node that its menu appears on the screen but after point, the next scroll moves into its first subnode, unless --- 2587,2593 (goto-char (point-max) (t (error "No previous nodes" ! (defun Info-scroll-up (e) "Scroll one screenful forward in Info, considering all nodes as one sequence. Once you scroll far enough in a node that its menu appears on the screen but after point, the next scroll moves into its first subnode, unless *** *** 2601,2607 item. (That case won't normally result from this command, but can happen in other ways.)" ! (interactive) (if (or (< (window-start) (point-min)) (> (window-start) (point-max))) (set-window-start (selected-window) (point))) --- 2601,2608 item. (That case won't normally result from this command, but can happen in other ways.)" ! (interactive (list last-input-event)) ! (select-window (posn-window (event-start e))) (if (or (< (window-start) (point-min)) (> (window-start) (point-max))) (set-window-start (selected-window) (point))) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Help buffer links on a console
On a linux console and using t-mouse, clicking on a link in a help buffer only works if the cursor is already over the link. Otherwise Emacs reports "No cross-reference here" which indicates that help-follow-mouse has been activated, rather than push-button. Typing `C-h c' and clicking as before, however, tells the user that push-button will be activated. Also clicking works properly both on a graphical display and an xterm. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Info-scroll-up/down on mode-line
Info-scroll-up/down are bound on the mode-line (over the node name) to mouse-1 and mouse-3. However, in a split window configuaration with Info at the top and the bottom window selected, clicking there scrolls the _bottom_ window, and Emacs gets confused if this is already at the top or bottom. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
> It papers over it. An optimization in dispnew.c gets screwed up when > display margins are present for terminal display. I just checked in a > patch that basically disables the optimization when we are in that > situation. > > So it's not *really* solving the problem. But it's a lot safer, and > AFAICT it completely prevents the problem from appearing. So we can > probably live with it for now. It looks good to me. Thanks. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
> Oh, good, I am delaying the Unicode release! I did not think of that. > > Sorry, I could not really resist. I can understand your frustration, Your replies show that you don't even begin to understand. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
> In other words: I have seen this bug. I'm not questioning that you have seen it, just the wisdom of ignoring the advice of those who are experts in that part of the code and say that it is dangerous to fix shortly before the release. Given that you appear to be the only one to have been inconvenienced by this bug (and how often do you need an overlay at the start of the buffer?) while probably thousands want to see a release, and thousands more want to see Unicode added to Emacs, I just find the whole thing absurd. Some things are worth dying for, but I don't this is one of them. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
> > Does drawing cursor in the wrong position on multi-line before-strings > > cause "real trouble"? Is the display of multi-line before-strings an > > "important feature"? > > And is fixing it important enough to delay the release - or risk > introducing other bugs which we only discover after the release. Yes, I've never seen this `bug', but there must be a real danger that I will see one caused by the fix, as Kim says, after the release. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
> > I managed to reproduce the bug. > > > > emacs -nw > > M-: (set-window-margins (selected-window) 1) RET > > C-x 2 > > C-x ^ > > > > Pressing left and right button and inserting text now makes it clear > > that redisplay is broken. > > > > The call to enlarge-window and set-window-margins appears to be > > essential to producing this bug. A related error that may/may not help: when I do this I can only drag the mode-line in one direction. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
> >> I see no function assq-remove-all. Is this in Emacs 23? > > My guess is, it's (another) one of Stefan's local changes... :) > > No. I don't have such a thing here either. But the name should make the > intended behavior clear enough. It's hard enough remembering what actual functions should do without having to work out what hypothetical ones would do! -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
Glenn Morris writes: > Nick Roberts wrote: > > > But isn't globalbind already a copy of the global map? > > > > (setq globalbind (cdr (global-key-binding keyseq))) > > By experiment, no, eg: > > (define-key lisp-interaction-mode-map [menu-bar edit] 'undefined) > M-x tmm-menubar > > will delete the Edit menu from _all_ buffers. I don't see that. I only see a problem if I toggle a minor mode, e.g: M-x view-mode (define-key view-mode-map [menu-bar edit] 'undefined) M-x view-mode The edit menu-item has disappeared from the global-map. > Adding a copy-sequence > prevents that. Yes, so I have committed this change. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
Stefan Monnier writes: > >> ! (setq globalbind (assq-delete-all (car-safe item) > >> globalbind > > If I read the code correctly, this is dangerous because it may modify the > global map. I.e. it should use assq-remove-all or copy-sequence. But isn't globalbind already a copy of the global map? (setq globalbind (cdr (global-key-binding keyseq))) I see no function assq-remove-all. Is this in Emacs 23? Despite the subject header this was an Emacs 22 problem too. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
> > Does it fix the bug, or just mask the error? I mean does the menu on > > a tty for Org mode look as it should with this change? > > Well, it looks alright to me (at least, it looks the same as it does > in 21.3 when I load org-mode), but I don't know what problem your > recent change was trying to fix. Ok, I've committed this change. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
> > Yes, that's strange. It seems to have something to do with > > xterm-mouse-mode being enabled. I can't see any connection between the > > two, though. > > I can't seem to reproduce this, even with xterm-mouse-mode enabled. > > Can you give a more precise recipe? Actually now I can only seem to reproduce it when the xterm has a scrollbar (with or without xterm-mouse-mode). I thought I also saw it in the Linux console but I'm moving between machines/terminal types. It's probably best to disregard this bug report - sorry. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
> So how about this fix: > > *** tmm.el 3 Apr 2007 10:09:45 - 1.52 > --- tmm.el 12 Apr 2007 22:46:20 - > *** > *** 547,555 >;; the global list. >(dolist (minor minorbind) > (dolist (item (cdr minor)) > ! (setq globalbind (assq-delete-all (car item) globalbind >(dolist (item (cdr localbind)) > !(setq globalbind (assq-delete-all (car item) globalbind))) > >(setq globalbind (cons 'keymap globalbind)) >(setq allbind (cons globalbind (cons localbind minorbind))) > --- 547,555 >;; the global list. >(dolist (minor minorbind) > (dolist (item (cdr minor)) > ! (setq globalbind (assq-delete-all (car-safe item) > globalbind >(dolist (item (cdr localbind)) > ! (setq globalbind (assq-delete-all (car-safe item) globalbind))) > >(setq globalbind (cons 'keymap globalbind)) >(setq allbind (cons globalbind (cons localbind minorbind))) Does it fix the bug, or just mask the error? I mean does the menu on a tty for Org mode look as it should with this change? -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
> Here is an easily reproducible bug: > > o emacs -Q > o M-x org-mode > o M-x tmm-menubar > > And backtrace: > , > | Debugger entered--Lisp error: (wrong-type-argument listp keymap) > | tmm-get-keybind([menu-bar]) > | tmm-menubar() > | call-interactively(tmm-menubar) > | execute-extended-command(nil) > | call-interactively(execute-extended-command) > ` It fails on Emacs 22 too (it would be best if you checked this first). I'm pretty sure it relates to my changes, but I'm not sure yet that the bug is in tmm.el. org-mode has an awesome menubar! Looking at the local map, I see the keyword keymap in the list many times but not as a car. Is that reasonable? I can't find the entries that follow them in the menubar, i.e, "Headings", "Up", "Show All" and "Hide Leaves" which look like they should appear under the "Tbl" top level menu item. ... (Column menu-item "Column" ...) ...)) keymap (headings "Headings" keymap (outline-up-heading "Up" . outline-up-heading) (outline-next-visible-heading "Next" . outline-next-visible-heading) (outline-previous-visible-heading "Previous" . outline-previous-visible-heading) (outline-forward-same-level "Next Same Level" . outline-forward-same-level) (outline-backward-same-level "Previous Same Level" . outline-backward-same-level) (outline-insert-heading "New heading" . outline-insert-heading) (copy menu-item "Copy to kill ring" outline-headers-as-kill :enable mark-active) (move-subtree-up menu-item "Move subtree up" outline-move-subtree-up) (move-subtree-down menu-item "Move subtree down" outline-move-subtree-down) ...) (show "Show" keymap (show-all "Show All" . show-all) (show-entry "Show Entry" . show-entry) (show-branches "Show Branches" . show-branches) (show-children "Show Children" . show-children) (show-subtree "Show Subtree" . show-subtree) "Show") (hide "Hide" keymap (hide-leaves "Hide Leaves" . hide-leaves) (hide-body "Hide Body" . hide-body) (hide-entry "Hide Entry" . hide-entry) (hide-subtree "Hide Subtree" . hide-subtree) (hide-sublevels "Hide Sublevels" . hide-sublevels) (hide-other "Hide Other" . hide-other) "Hide")) Carsten, Does this keymap look right to you? -- Nick http://www.inet.net.nz/~nickrob___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
> I don't see this. > > But I cannot use the mouse when emacs -nw is running in an xterm > (xterm seems to own the mouse) - is it necessary to use the mouse to > see the problem? Yes, that's strange. It seems to have something to do with xterm-mouse-mode being enabled. I can't see any connection between the two, though. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
display margin errors on a tty
I might have reported this before but display seems all over the place when the buffer has a left margin in a tty. To see this start Emacs in an xterm, debug a program with M-x gdb, set a breakpoint, run and click alternately on the GUD and source buffer, or even repeatedly in the source buffer. The margin appears and disappears, so does the breakpoint symbol, B. Also various source lines get indented. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
> > > It might still be logically true but generally it's best to say exactly > > > what > > > things are i.e "is a non-negative integer.", if this change is made. If > > > it's > > > not made then maybe the manual should be changed to be more precise: > > > > > > A "character" in Emacs Lisp is just an integer. > > > I think it would be more clear to say something like: > > >A "character" in emacs is represented by a normal integer. > > > Because emacs does have the concept of characters, separate from > > integers, it's just that they share a concrete representation in lisp. > > I agree. What's an abnormal integer? (A "character" in emacs is represented by an integer. ?) -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
> `eq' compares immediate values in lisp. All integers in emacs lisp are > immediate values. Floating point numbers in Emacs lisp are "boxed" -- > allocated on the heap -- just like cons-cells or whatever. Well a symbol also seems to be a pointer/allocated on the heap, but OK, thanks, that gives me some understanding. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
> > The manual says: > > > >A "character" in Emacs Lisp is nothing more than an integer. > > > > That would have to change. > > > Not really, since that statement does not imply that the reverse is true. It might still be logically true but generally it's best to say exactly what things are i.e "is a non-negative integer.", if this change is made. If it's not made then maybe the manual should be changed to be more precise: A "character" in Emacs Lisp is just an integer. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
> > I also find this confusing: > > > > (eq 1 1) > > t > > > > (eq 1.0 1.0) > > nil > > (eql 1.0 1.0) > t Yes. I still don't get it. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
> > It doesn't on Emacs 22: > > > (char-or-string-p -4) > > t > > > and if it does on Emacs 23 then I think that must be the bug. > > Emacs 23 surely returns nil in that case. I think the > behaviour of Emacs 22 is a bug (or at least very confusing). Emacs 21 appears to have the same behaviour. > Don't people think OBJ can be safely used as an argument of > a function that expects a character (e.g. insert, > char-to-string) if (char-or-string-p OBJ) is true? The manual says: A "character" in Emacs Lisp is nothing more than an integer. That would have to change. And continues with: In other words, characters are represented by their character codes. For example, the character `A' is represented as the integer 65. Perhaps the `character' -4 just doesn't have a representation/character code. I also find this confusing: (eq 1 1) t (eq 1.0 1.0) nil but perhaps "Ours is not to reason why..." -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
> skeleton-internal-1 can enter an infinite loop if the ELEMENT argument > is a negative integer. To reproduce: > > emacs -Q > > M-x auto-insert-mode RET > > C-x C-f ~/tmp/test.tex > > Answer yes when asked to perform auto insertion for latex mode. > > Hit RET repeatedly. I can't reproduce this on Emacs 22, although oddly it tells me that the buffer is not modified when it completes. > This bug is due to skeleton-internal-1 relying on char-or-string-p to > return non-nil if its argument is an integer, while in fact, > char-or-string-p returns nil if its argument is a negative integer. It doesn't on Emacs 22: (char-or-string-p -4) t and if it does on Emacs 23 then I think that must be the bug. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: get-lru-window should mention what lru stands for
> > Do you know what car or cdr stand for? If not, has it stopped > > you from using them? > > Good point, Nick. Let's change all Emacs functions to have incomprehensible > names - after the release, of course. Actually my point was that even if you can't make the small mental leap as to what lru stands for (which your first post shows you could), it wouldn't stop you from understanding what the function did. I see Eli has now added what lru stands for, but I hope he doesn't stop there. I've always wondered who bobp is, and what's his full surname? Ah I see now! Perhaps to be clear we should call this function: beginning-of-buffer-p but wait the doc says: If the buffer is narrowed, this means the beginning of the narrowed part. So perhaps: beginning-of-narrowed-part-of-buffer-p but then the user might not know what narrowed means in this context: beginning-of-the-accessible-portion-of-the-text-in-the-buffer-p Eli, could make those changes before the release? -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: get-lru-window should mention what lru stands for
> > get-lru-window is a built-in function in `C source code'. > > (get-lru-window &optional frame dedicated) > > > > Return the window least recently selected or used for display. > > ... > > > > I don't think it could be much clearer. > > "Return the window least recently used or selected for display" Oh that's much clearer! Wait a minute that, that would mean it should be called return-window-lru. How about: "Get the least recently used (selected) window for display." However, as Glenn says, perhaps we should continue this thread on 1st April. Do you know what car or cdr stand for? If not, has it stopped you from using them? -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: get-lru-window should mention what lru stands for
> Presumably, "lru" stands for "least recently used". That should be > mentioned in the doc string, to avoid confusion. (We should still say > that "used" means selected.) ? get-lru-window is a built-in function in `C source code'. (get-lru-window &optional frame dedicated) Return the window least recently selected or used for display. ... I don't think it could be much clearer. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Find this error in... Changes in complete.el?
> > because my compilation message (gcc version 4.1.0) is: > > > myprint.o: In function `myprint':/home/nickrob/myprint.c:27: undefined > > ^ > > reference to `mysquare6' > > Please complain to the linker guys that they should use error messages that > follow the GNU standard. OK. I've tried to do this by sending a message to the binutils mailing list. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Find this error in... Changes in complete.el?
> Anyhoo, hit enter in compilation-mode to select the next error works > opening the mini-windows with the prompt... > Find this error in (Default BLAH.c): /path/to/cwd > > Previously hitting tab-tab would list possible completions, including > folders. Now only files are listed. > > Previously I could navigate to the correct file by typing part of the > directory name, hitting tab to complete the name... > > Now it just goes "beep" and does nothing. The directory name is not a > valid completion. > > I believe, but not sure its the changes that went into "complete.el" > in the last few days. > > Is there any work-around to recover the previous behaviour? I think it's due to this change 2006-07-18 Stefan Monnier <[EMAIL PROTECTED]> * progmodes/compile.el (compilation-find-file): Handle the cases where the user selects a non-existent file. Does the patch below restore the old behaviour for you? It's not a fix because it undoes whatever Stefan's patch intended, which I don't quite understand because I have a different problem when a generate this message (with a linker error): Find this error in (default In function `myprint':/home/nickrob/myprint.c): ~/ because my compilation message (gcc version 4.1.0) is: myprint.o: In function `myprint':/home/nickrob/myprint.c:27: undefined ^ reference to `mysquare6' where everything above is matched by the error regexp. -- Nick http://www.inet.net.nz/~nickrob *** compile.el 21 Jan 2007 23:13:40 +1300 1.417 --- compile.el 14 Mar 2007 10:29:23 +1300 *** Pop up the buffer containing MARKER and *** 1862,1878 (let* ((name (read-file-name (format "Find this %s in (default %s): " compilation-error filename) ! spec-dir filename t nil ! ;; Try to make sure the user can only select ! ;; a valid answer. This predicate may be ignored, ! ;; tho, so we still have to double-check afterwards. ! ;; TODO: We should probably fix read-file-name so ! ;; that it never ignores this predicate, even when ! ;; using popup dialog boxes. ! (lambda (name) ! (if (file-directory-p name) ! (setq name (expand-file-name filename name))) ! (file-exists-p name (origname name)) (cond ((not (file-exists-p name)) --- 1862,1868 (let* ((name (read-file-name (format "Find this %s in (default %s): " compilation-error filename) ! spec-dir filename t nil)) (origname name)) (cond ((not (file-exists-p name)) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: x-show-tip color choices
> I'm not quite sure if this qualifies as a bug, however I find it > irritating: > > I have this in my .emacs: > (add-to-list 'default-frame-alist '(background-color . "black")) > (add-to-list 'default-frame-alist '(foreground-color . "wheat")) > > So when I call > (x-show-tip "hello") Why do you call x-show-tip? > I get a tooltip with wheat-colored text and a yellow background. I think x-show-tip is just meant as an internal function for tooltip-show. Why not use that, or even tooltip-mode and the help-echo text proerty, instead? > I don't think it should override only one of the background and > foreground colors; either both or none. It probably overrides the background so that it doesn't appear as part of the parent frame (unless that happens to be lightyellow) when debugging tooltip functionality. Unless you have a real purpose for using x-show-tip directly, I don't think this is worth changing. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
> >> Can someone please fix that, then ack? > > > > The behavior where X resources override Custom (and all other Elisp > > face settings) seems to have been around since forever --- it can be > > seen in Emacs 21 ... > > So we obviously don't need to anything about it before the release. Actually it seems to be present for the mode-line and toolbar, but not the scrollbar. That is, if I start "emacs -Q", customize the background of the faces of all three (to white, say), then do `C-x 5 2', the new frame displays the mode-line and toolbar with the previos face, but the scrollbar retains its white background. However, I don't if this is because Emacs implements the scrollbar differently, or because Metacity handles it differently. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
function is not fontified when return type is not given
The keyword main isn't fontified with K&R syntax (unless it is given a return
type), e.g,
main (argc, argv)
int argc;
char **argv;
{
return;
}
I see that it does fontify correctly with the ANSI syntax:
main (int argc, char** argv) {
{
return;
}
--
Nick http://www.inet.net.nz/~nickrob
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mode-line face and window manager
Richard Stallman writes: > > It happens because some window managers set up X resources to control > > this face. It happens to me with GNOME. That is an intentional > > feature, I think. > > If mode-line must take from X resources then maybe mode-line-inactive > could > take a suitably different value. > > That would be rather hard to do, given the facilities in Emacs now for > working with colors. We'd need to write code to decide if two colors > are "too similar", and then figure out how to change mode-line-inactive. > It sounds like a hard problem to me. > > Another solution is to ask the maintainers of that window manager > (metacity?) to turn off that feature for mode-line. Can you tell me > how to write to them? I don't know who to write to, but I'm not sure that we would ask the right question anyway (a mode-line for a buffer without focus is presumably the same kind of widget yet it's face is unaffected by Metacity for some reason). I'd like to hear what Jan D has to say. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: syntax-table for info
> We already solved this kind of problem once for capitalize-region: > > if ((int) flag >= (int) CASE_CAPITALIZE) > inword = SYNTAX (c) == Sword && (inword || !SYNTAX_PREFIX (c)); > > Since ' in text-mode has syntax "w p", it means that a ' after a word char > is considered by capitalize-region as being a word-char, whereas a ' after > a non-word char is considered as a non-word char. This way > capitalize-region applied to > > 'can't' > gives > 'Can't' > > I guess the same idea should be applied to word movement. Interesting. It might be a bit harder in this case though, because you can have an apostrophe at the end of a word, e.g, "two mens' sons", meaning the sons of two men. So you would also have to check for an apostrophe at the start of the word. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Toolbar with GTK
If I do:
M-x gdb
Run gdb (like this): ~/src6/gdb/gdb --annotate=3 myprog
then in the GUD buffer:
(gdb) b main
(gdb) run
and then repeatedly click on the gud-next icon in the toolbar ("Next Line"),
after two or three clicks it stops doing anything. At this point the button no
longer shows relief. The only way that I can get it to work again is by moving
the cursor away from the icon and back again. The same thing happens for other
execution icons (gud-step, gud nexti and gud-stepi). It doesn't happen with
"gdb --fullname".
I sometimes see something similar with i686-pc-linux-gnu, X toolkit, Xaw3d
scroll bars where I can get something like " is undefined"
after a few clicks, but then I can get it working again without moving the
cursor away from the icon.
In GNU Emacs 22.0.95.1 (i686-pc-linux-gnu, GTK+ Version 2.8.15)
of 2007-03-08 on kahikatea.snap.net.nz
X server distributor `The X.Org Foundation', version 11.0.7000
configured using `configure '--with-gtk' '--with-xft''
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: Debugger
Minor modes in effect:
show-paren-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
line-number-mode: t
transient-mark-mode: t
Recent input:
I f SPC I
SPC d o :
C-x kM-x r e p o
t r t SPC e m a SPC SPC
Recent messages:
Cannot find image file `/home/nickrob/emacs1/etc/vm/file-up.xpm'
Cannot find image file `/home/nickrob/emacs1/etc/vm/reply-up.xpm'
Cannot find image file `/home/nickrob/emacs1/etc/vm/compose-up.xpm'
Cannot find image file `/home/nickrob/emacs1/etc/vm/print-up.xpm'
Cannot find image file `/home/nickrob/emacs1/etc/vm/visit-up.xpm'
Cannot find image file `/home/nickrob/emacs1/etc/vm/quit-up.xpm'
Cannot find image file `/home/nickrob/emacs1/etc/vm/help-up.xpm'
Command: next 1 [34 times]
Auto-saving...
Loading emacsbug...done
--
Nick http://www.inet.net.nz/~nickrob
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mode-line face and window manager
> Barely. You can see this by customising mode-line face the have the same > foreground value as mode-line-inactive. I mean background, of course. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mode-line face and window manager
> But mode-line has a 3D appearance of a released button, while > mode-line-inactive does not. Doesn't this alone distinguish them > enough? Barely. You can see this by customising mode-line face the have the same foreground value as mode-line-inactive. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mode-line face and window manager
> > The value for mode-line face seems to be taken from the window manager > > or theme. > > How do you see this? > > It happens because some window managers set up X resources to control > this face. It happens to me with GNOME. That is an intentional > feature, I think. If mode-line must take from X resources then maybe mode-line-inactive could take a suitably different value. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: syntax-table for info
> Frequently when I want to search for a another occurrence of a word I
> type C-s C-s but this picks up the apostrophe (') at the end of the
> word. It would make things easier if the syntax table in Info was
> modified so that the apostrophe was regarded as punctuation rather than
> word.
>
> The reason ' is treated as part of a word is for the sake of M-f.
> I don't think we should change that.
>
> I do not understand what you mean by "picks up the apostrophe at the
> end of the word".
I mean if you're looking at:
`C-k'
Kill to the end of the line (`kill-line').
and you want to see if the manual says anything else about kill-line. Then
putting the cursor on the last k and doing C-s C-s makes i-search search for
kill-line'.
^
I guess I never use M-f, but I notice that the help buffer treats apostrophes
as punctuation.
--
Nick http://www.inet.net.nz/~nickrob
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Testsuite? [was Re: Can't isearch for non-ASCII text]
> > Thanks I ended up with the same diagnostic and have installed a similar > > fix. > > Thanks. So, Lennart, now you can apply this change safely. ;-) > > 2007-03-01 Lennart Borgman <[EMAIL PROTECTED]> > > * isearch.el (isearch-message-prefix): > Use minibuffer-prompt-properties. I hope that's just a joke, and no more. I think we should create a testsuite to help stop such regressions. This is difficult, of course, with a GUI application but here's a suggestion for one approach: Arrange for error to print to standard error when Emacs is run non-interactively (actually I think it already does this). Then for each bug report that results in a Lisp error, we create a Lisp test file to reproduce the conditions that generated it, put it in a directory called testsuite and create a Makefile where: make test will run: emacs --batch -l testxy.el for each test file in the directory. and check for output on standard error (I don't know how to do this in a Makefile or from sh. Currently I get some messages, e.g., "Loading /usr/share/emacs/site-lisp/site-start.d/..." on standard error but I'm not sure why. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mode-line face and window manager
Eli Zaretskii writes: > > From: Nick Roberts <[EMAIL PROTECTED]> > > Date: Wed, 7 Mar 2007 09:51:47 +1300 > > Cc: emacs-pretest-bug@gnu.org > > > > > > Where's the coupling with the window manager or theme? > > > > That's my question really, presumably somewhere in the C code. If I change > > theme, the colour of the mode-line changes along with the colour of the > > toolbar, while the colour of mode-line-inactive face remains fixed. > > Maybe changing theme (whatever that means) has the effect of changing > X resources? Sorry I got that wrong, the mode-line doesn't change if I change theme, but it does pick up the background value of #ede9e3 from some gnome/gtk related setting along with the toolbar (the initial window manager seems to use this setting for the panel and frames without focus). The scroll-bar, however, does has a value of grey75 (although I'm not sure where this comes frome). Previously it didn't matter that the colour of the mode-line was tied to X resources, but my point is that now there is mode-line-inactive face, it's important that Emacs doesn't do this. I find it hard to see which window is selected by looking at the mode-line. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
syntax-table for info
Many words in Info, e.g, code, are quoted because the syntax table is
inherited from text-mode-syntax-table.
Frequently when I want to search for a another occurrence of a word I type
C-s C-s but this picks up the apostrophe (') at the end of the word. It
would make things easier if the syntax table in Info was modified so that
the apostrophe was regarded as punctuation rather than word. If the
apostrophe really is wanted as part of the search it can easily be picked
up br pressing C-s again.
--
Nick http://www.inet.net.nz/~nickrob
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mode-line face and window manager
Eli Zaretskii writes: > > The value for mode-line face seems to be taken from the window manager or > > theme. > > How do you see this? I see the following in faces.el: > > (defface mode-line > 'class color) (min-colors 88)) > :box (:line-width -1 :style released-button) > :background "grey75" :foreground "black") > (t > :inverse-video t)) > > which seems to say that this face has the release-button style and > grey75 background color. > > Where's the coupling with the window manager or theme? That's my question really, presumably somewhere in the C code. If I change theme, the colour of the mode-line changes along with the colour of the toolbar, while the colour of mode-line-inactive face remains fixed. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
mode-line face and window manager
The value for mode-line face seems to be taken from the window manager or theme. This is inconvenient when that is close to mode-line-inactive, as is the case for the defalut theme for Fedora Core 5. Would it be possible to uncouple this relationship, as appears to be the case for mode-line-inactive, so that it always has the default value of grey75? -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Emacs mailing lists [was Re: Partial completion]
> Oops, this has all been discussed on emacs-devel. Apologies for the > total time waste. Let's get rid of one of the mailing lists (emacs-pretest-bug), point report-emacs-bug to emacs-devel, and ask savannah hackers (?) to make emacs-pretest-bug an alias for emacs-devel. I can't see why anyone would want to be subscribed to one and not the other and it just creates irritation when people post to both mailing lists. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: SIGSEGV, not the first time around
> > Although I can't reproduce that bug, I found the code I committed > > recently was incomplete. As I've just installed a fix, could you > > please try again. > > The bug is not really in the "reproducible" class here, either. I > think I got it three times so far, in probably three weeks or so. > > Nevertheless, I'll of course update and see where this leads us. If you observed the crash three weeks ago, it can't due to the change to send_process_object, as that is only a week old. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: error in process filter: gdb-starting: Unexpected `starting' annotation
> Then I opened foo.c with emacs and started gdb from within emacs. > I put a breakpoint on line 5, and started running. After it hit > the breakpoint, I typed step. Then I held down return to step > through a bunch more lines. I got some error messages like this: > > error in process filter: gdb-starting: Unexpected `starting' annotation > error in process filter: Unexpected `starting' annotation I tried this but couldn't get it to fail. In the past it did fail in this way more often. If GDB is running when Emacs has more input to send, it thinks this is input for the program being debugged and not another GDB command, and so sends it immediately instead of queuing it. It can only be avoided by using a separate terminal for program output which will be the case when we move to GDB/MI after the release. The only advice I can give you is "Don't do that.". It's somewhat lame, but I find that clicking mouse-3 in the fringe useful for advancing to where I want. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: info.el displays blank line in menus
> AFAICS, the blank line is produced by makeinfo, at least on my > machine. Can you verify that the file emacs-2 has this blank line on > your system? If it does, the right place to complain about this is on > [EMAIL PROTECTED] Yes, you're right, I'll post something there. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Move hide-ifdef-mode toggle button
I'm not likely to want to toggle hide-ifdef-mode when browsing info, so how about moving it off the list in the pop up menu on the mode line? Although it's not part of cc-mode it could be moved to the Toggle... menu-item on the C menu. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
info.el displays blank line in menus
info.el displays a menus blank line when ifnottex is used, e.g: * SavingSaving makes your changes permanent. * Reverting Reverting cancels all the changes not saved. @ifnottex * AutorevertAuto Reverting non-file buffers. @end ifnottex * Auto Save Auto Save periodically protects against loss of data. * File Aliases Handling multiple names for one file. in files.texi, looks like this in info (in 23 File Handling): * Saving:: Saving makes your changes permanent. * Reverting:: Reverting cancels all the changes not saved. * Autorevert:: Auto Reverting non-file buffers. * Auto Save:: Auto Save periodically protects against loss of data. * File Aliases::Handling multiple names for one file. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs .gdbinit incompatible with latest GDB
Richard Stallman writes: > 2000-01-04 Gerd Moellmann <[EMAIL PROTECTED]> > > * lisp.h (struct Lisp_String): Make DATA member `unsigned char *'. > > I guess the questions to ask are: > > 1) Why was this change made? > > Probably to make it easier to avoid incorrect conversions when > extracting elements. We don't want to get negative numbers > for byte values above 127. Yes, that bit is self-evident but when are eight bit strings needed? Mathieu Lacage stated on gdb-patches: a lot of people (the first which comes to my mind is libxml2) decided to use "unsigned char *" to identify utf-8 encoded strings in C. Would this also be the case for Emacs? -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs .gdbinit incompatible with latest GDB
> Due to applied GDB patch
> http://sources.redhat.com/ml/gdb-patches/2007-01/msg00533.html
>
> the recent GDB has problems running GDB `xbacktrace' on EMACS
> http://sources.redhat.com/ml/gdb/2007-02/msg00252.html
>
> provided the following patch fixing the problem, either in
> http://sources.redhat.com/ml/gdb/2007-02/msg00257.html
>
> or an alternative one herein:
I've already made this change but perhaps we can generalise the subject, as the
incompatibility is with GDB in the CVS repository and not the latest GDB,
i.e. this GDB patch could still be reverted.
In Jan's words, the patch in GDB does:
currently all these types are printed as strings:
char
signed char
unsigned char
the patch will reduce the printed strings only to
char
and the signed/unsigned version gets printed as an array of byte values
(characters). I hope nobody uses sign-specification for strings.
On the other hand byte arrays become unreadable if printed as strings.
The functions in xbacktrace (xsymbol etc) were then printed as arrays of
character because in lisp.h:
struct Lisp_String
{
EMACS_INT size;
EMACS_INT size_byte;
INTERVAL intervals; /* text properties in this string */
unsigned char *data;
};
which has been this way since:
2000-01-04 Gerd Moellmann <[EMAIL PROTECTED]>
* lisp.h (struct Lisp_String): Make DATA member `unsigned char *'.
I guess the questions to ask are:
1) Why was this change made?
2) Are there other strings in Emacs which are of type `unsigned char *' where
this change will cause a problem?
--
Nick http://www.inet.net.nz/~nickrob
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: vertical scrollbar error on MS Windows
> > While it helps to just report bugs and with due respect, it's not > > reasonable to claim that the Emacs developers don't give the Window port a > > high priority, > > If you could cite from a message where I _claimed_ that, it would be > much easier for me to respond to that. I'm not asking you to respond to it, just to reflect on it. > After rereading my message, I think I didn't claim anything about Emacs > development, but only wrote up some personal experiences I've made with > Emacs on Windows during the last years. I was referring to: Peter Tury> I hope you can regenerate the situation easily and fix this bug. SH> I hope so, too. But unfortunately, given the fact that it's known for SH> nearly two years, I don't think the issue has high priority for the SH> developers. If that's related to the fact that it's only present in the SH> Windows port, I don't know. SH> At this time, you can't tell a person from Windows island to have a look SH> at LaTeX & Emacs+AUCTeX. He'd laugh at you and say: "It can't even SH> scroll your files without flickering. I like Office SH> better." Well, I don't know what auditorium Emacs targets to. But it's SH> obviously not (new) Windows users. First impression failed. > > if you're not in a position to even test the patches which are > > provided. > > Even if I were able to compile and test patches I don't think that > brought me into a position to claim anything about Emacs development. It would give your opinion more weight. > I'll try my best to make my points more clear in the future, but > honestly, I can't see yours. Currently, I tend to guess you're trying > to say: "You'd better shut up as long as you're not an active > developer!" Not at all. Just that the state of the Windows port reflects the level of contributions from the user community, of which you are a part. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: vertical scrollbar error on MS Windows
> > > Unfortunately, I have only a dial-up connection and can't give > > > immediate feedback on new Emacs versions. > > > > One advantage of using CVS over tarballs is that you only need to download > > the (compressed) _changes_. Even with a dial-up connection that shouldn't > > take a long time. > > Thanks for the hint. I am already familiar with rcs, actually. But I > didn't set up a proper environment for compiling Emacs by myself yet. > There just wasn't much use in that so far. :) While it helps to just report bugs and with due respect, it's not reasonable to claim that the Emacs developers don't give the Window port a high priority, if you're not in a position to even test the patches which are provided. Some developers work hard on that very issue, -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: c-mode imenu: Stack overflow in regexp matcher
G > > I guess a quick fix is to replace [^()] by [^()\n]. > > Ping, anyone in CC land? Don't know about CC land, but I'd say there are a few in la-la land. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: vertical scrollbar error on MS Windows
> > So, also tell me if you tested it, and didn't find any problems! > > Unfortunately, I have only a dial-up connection and can't give immediate > feedback on new Emacs versions. One advantage of using CVS over tarballs is that you only need to download the (compressed) _changes_. Even with a dial-up connection that shouldn't take a long time. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: runaway emacs process
> Emacs seems to be running continuously, hogging 100% of one > processor. gdb also runs periodically, using about 1% of a > processor. However, gdb does not appear to be working correctly. In > the gud buffer, it seems that gdb has been stopped since friday > night. I last used it then to print a value. Now, when I try to print the > same value, it prints a breakpoint summary instead: > > (gdb) p *ctarget > Num Type Disp Enb AddressWhat > 2 breakpoint keep y 0x0002755c in rcData::set_rc(char*, bool) at > ../src/driver/bit_util.cc:1010 > breakpoint already hit 1 time This is very probably a bug in gdb-ui.el. When gdb is doing nothing, the variables gdb-input-queue and gdb-pending-triggers should be nil. What are the values in your case? Which other GDB buffers are you using? (Do C-x C-b and look for "* of bits*"). To debug this properly we need a precise recipe. Can you post a simple program and configuration where this happens? -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info indices are slow to display
> > Info indices take too long to display. > > How long is ``too long'' for you? The ELisp index takes about 4 > seconds here. 40 seconds on a 800MHz Pentium. I've followed Martin Rudalics suggestion and reduced Info-fontify-maximum-menu-size. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Info indices are slow to display
Info indices take too long to display. I wonder if that's why they didn't used to be fontified. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 'C-x 4 a' broken in diff buffer
> PS: There was still a bug that I just fixed, which may explain what you > were seeing, although in my case it manifested itself by signalling an > error rather than silently ignoring the function name. Could be due to > local changes. It looks good now. I think this last change must have fixed things for me. Thanks. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 'C-x 4 a' broken in diff buffer
Stefan Monnier writes: > >> Hmm... are you sure it worked in Emacs-21? > > Yes. > > Sure, sure, sure, in the very same circumstances? You seem sceptical. > >> There has been changes in this part of the code, but IIRC they're > >> fairly minor. And in any case we've never made use of the text added by > >> the > >> "-p" flag. > > > No, but maybe the text is inadvertantly used in trying to match up the > > function. > > That would be a bug, but of course, it could be. > > >> If you can find a case that works in Emacs-21 and fails now, it's probably > >> a bug, but then you'll need to give us a precise recipe. > > > I've already given one. > > > Evaluate (setq diff-switches "-cp") > > diff-switches is not used by diff-mode, so this should make no difference. It makes a difference to what gets inserted into the buffer. > > Put the diff that I sent earlier in a file temp.diff and 'C-x 4 a" behaves > > as I explained. > > C-x 4 a will first look for the corresponding source file and then run C-x > 4 a there, so the result depends on the gdb-ui.el file you happen to have in > the same directory. Maybe this recipe's no good but you could create your own change. > PS: There was still a bug that I just fixed, which may explain what you > were seeing, although in my case it manifested itself by signalling an > error rather than silently ignoring the function name. Could be due to > local changes. I'm getting thoroughly confused. Forget this report for the moment. I'll come back again when I have something concrete. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 'C-x 4 a' broken in diff buffer
> Hmm... are you sure it worked in Emacs-21? Yes. > There has been changes in this part of the code, but IIRC they're > fairly minor. And in any case we've never made use of the text added by the > "-p" flag. No, but maybe the text is inadvertantly used in trying to match up the function. > If you can find a case that works in Emacs-21 and fails now, it's probably > a bug, but then you'll need to give us a precise recipe. I've already given one. Evaluate (setq diff-switches "-cp") Put the diff that I sent earlier in a file temp.diff and 'C-x 4 a" behaves as I explained. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 'C-x 4 a' broken in diff buffer
> >> > ISTR it also fails for changed functions (not just added ones). > >> I believe Per has fixed this very bug earlier today. > > Well it doesn't seem to supply a function with "-cp" any longer. > > Also I notice that when it does find a function e.g with "-c", it's often > > the wrong one, but I think this might always have been the case. > > I'm sorry to tell that I have no idea what you're talking about. > Care to spell it out loud for me ? Presumably you must have the gist of my first post to make your reply. Per's ChangeLog entry says: * diff-mode.el (diff-sanity-check-hunk): Don't reject the hunk just because the diff was produced using "-p" (--show-c-function). Im my .emacs, I have (setq diff-switches "-cp") so I'm guessing that that 'C-x 4 a' failing had something to do with the line "-p" adds: > *** gdb-ui.el 08 Feb 2007 10:06:25 +1300 1.203 > --- gdb-ui.el 08 Feb 2007 10:13:21 +1300 > *** With arg, use separate IO iff arg is pos which, as we've said before, is not reliable for languages other than C. I find that, with the above value of diff-switches, 'C-x 4 a' fails to identify a function to put in the ChangeLog, while it found one in Emacs 21.1. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 'C-x 4 a' broken in diff buffer
> > ISTR it also fails for changed functions (not just added ones). > > I believe Per has fixed this very bug earlier today. Well it doesn't seem to supply a function with "-cp" any longer. Also I notice that when it does find a function e.g with "-c", it's often the wrong one, but I think this might always have been the case. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
'C-x 4 a' broken in diff buffer
This change breaks 'C-x 4 a' (add-change-log-entry-other-window) when used in a diff (*vc-diff*) buffer: revision 1.94 date: 2007-01-11 16:52:59 +; author: monnier; state: Exp; lines: +83 -1 (diff-sanity-check-context-hunk-half, diff-sanity-check-hunk): New functions. (diff-find-source-location): Use'em to check the hunks are well-formed. e.g do 'C-x 4 a' on the added function in the text below (it has to be in a (vc?) diff buffer). It used to do: 2007-02-07 Nick Roberts <[EMAIL PROTECTED]> * progmodes/gdb-ui.el (gdb-if-arrow): but now it does 2007-02-07 Nick Roberts <[EMAIL PROTECTED]> * progmodes/gdb-ui.el: ISTR it also fails for changed functions (not just added ones). -- Nick http://www.inet.net.nz/~nickrob *** gdb-ui.el 08 Feb 2007 10:06:25 +1300 1.203 --- gdb-ui.el 08 Feb 2007 10:13:21 +1300 *** With arg, use separate IO iff arg is pos *** 606,611 --- 606,621 (setq gdb-version "6.4+")) (gdb-init-2)) + (defmacro gdb-if-arrow (arrow-position &rest body) + `(if ,arrow-position + (let ((buffer (marker-buffer ,arrow-position)) (line)) + (if (equal buffer (window-buffer (posn-window end))) + (with-current-buffer buffer + (when (or (equal start end) + (equal (posn-point start) + (marker-position ,arrow-position))) + ,@body)) + (defun gdb-mouse-until (event) "Continue running until a source line past the current line. The destination source line can be selected either by clicking with mouse-2 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [BUG] recent-menu-filter doesn't work
> Probably this is because `recentf-show-file-shortcuts-flag' is non-nil > (default) _ and your recentf-list contains no more than 10 files_ so > the 10 first items, which are assigned a digit shortcut key, are shown > differently without passing them to the `recentf-menu-filter' filter. > > It should work if you disable `recentf-show-file-shortcuts-flag'? OK, thanks, I see now. I couldn't find any documentation. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[BUG] recent-menu-filter doesn't work
To see this: 1) M-x recentf-mode 2) Open a few files 3) M-x recentf-open-files 4) Customize recent-menu-filter (to recentf-show-basenames, say) 5) M-x recentf-open-files The layout of recentf menu doesn't change. It stopped working with recentf.el version 1.43. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: gdb adds random filename to command
> I see your point... perhaps we can get the best of both worlds by > introducing a > new boolean variable that tells whether emacs guesses executable filenames > or not. I suspect it wouldn't be generally useful if only because no-one else has asked for it. There aren't large numbers on this list but somethings come up more often. Humour me one more time. What happens if you put: (gdb "gdb --annotate=3 /projects/dl/cvstrunk/shared/sw/gvu/bin/fc6debug1_singlethread/gvu") in your lisp file? -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: gdb adds random filename to command
> I use makefiles for a project to open emacs with etags and a preconfigured > gud-gdb-command-name. When using emacs as an IDE, this makes my life > easier... especially since in real life, my gud command has a filename > a lot more complicated than /tmp/foo: > > gdb --annotate=3 > /projects/dl/cvstrunk/shared/sw/gvu/bin/fc6debug1_singlethread/gvu > > I don't like typing that long filename. If the new behavior is not a bug > that will be fixed, > any suggestions for getting the old behavior? I don't know the exact details but maybe, in your lisp file, you could put: (setq default-directory "/projects/dl/cvstrunk/shared/sw/gvu/bin/fc6debug1_singlethread/") Emacs doesn't add a random filename, as you suggest, but the most recently compiled executable, so it might even find your executable in this case. If not, you will only have to type gvu. I think gud-gdb-command-name was never meant to include the executable, it just worked. The reason for not including it, I guess, is that users generally want to debug more than one filename. I think that, generally, the convenience of Emacs guessing the right name of the executable is greateer than the inconvenience of guessing the wrong one. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [BUG] describe-variable
martin rudalics writes: > > In Emacs 22 evaluate: > > > > (setq myvar '((0) (1) (2) (3) (4) (5) (6) (7) (8) (9))) > > > > (make-local-variable 'myvar) > > > > (setq myvar 1) > > > > then do C-h v myvar . > > > > Help buffer output: > [...] > > > > Note the local value of 1 is not shown. > > Would the below break anything else? Looks good to me. I can't _see_ that it breaks anything but there many cases to consider. > *** help-fns.el.~1.94.~ Sun Dec 24 22:38:56 2006 > --- help-fns.el Fri Jan 12 08:46:02 2007 > *** > *** 553,559 > ;; of a symbol. > (set-syntax-table emacs-lisp-mode-syntax-table) > (goto-char val-start-pos) > !(delete-region (point) (progn (end-of-line) (point))) > (save-excursion >(insert "\n\nValue:") >(set (make-local-variable 'help-button-cache) > --- 553,559 > ;; of a symbol. > (set-syntax-table emacs-lisp-mode-syntax-table) > (goto-char val-start-pos) > !(when (looking-at "value is") (replace-match "")) > (save-excursion >(insert "\n\nValue:") >(set (make-local-variable 'help-button-cache) > *** > *** 563,569 > 'action help-button-cache > 'follow-link t > 'help-echo "mouse-2, RET: show value") > !(insert ".\n\n"))) > > ;; Mention if it's an alias >(let* ((alias (condition-case nil > --- 563,569 > 'action help-button-cache > 'follow-link t > 'help-echo "mouse-2, RET: show value") > !(insert ".\n"))) > > ;; Mention if it's an alias >(let* ((alias (condition-case nil > -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: gdb adds random filename to command
> I loaded a lisp file like this "emacs -l foo.lisp" at the command line. > That file contained one line: > (setq gud-gdb-command-name "gdb --annotate=3 /tmp/foo") > > When I tried to run gdb using M-x gdb, it added a random filename from > the working directory to the end of the gdb command like this: > gdb --annotate=3 foo randomfilename That's because it tries now to guess the name of the executable that you want to debug. > Although it's possible, I'm doing something wrong, the behavior is > different with older versions of emacs. It looks like gud-gdb-command-name wasn't documented in earlier Emacsen but it is now: Documentation: Default command to execute an executable under the GDB debugger. It's also mentioned in the Emacs manual now. I suggest that you leave it at it's default value and type in the name of the executable. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: problem with tumme.el
> > The problem is that the ">" fails if the file already exists. > > > > So I made a change to "tumme-rotate-original" that checks if that > > file is there and deletes it before running the current rotate > > command. > > Really strange. I rotate images all the time with tumme and I have > never seen this problem. Normally ">" has no problem overwriting old > files. twurgl probably uses a csh variant and has set noclobber while you don't. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[BUG] describe-variable
In Emacs 22 evaluate: (setq myvar '((0) (1) (2) (3) (4) (5) (6) (7) (8) (9))) (make-local-variable 'myvar) (setq myvar 1) then do C-h v myvar . Help buffer output: - myvar's value is shown below. Documentation: Not documented as a variable. Value: Local in buffer *scratch*; global value is ((0) (1) (2) (3) (4) (5) (6) (7) (8) (9)) - Note the local value of 1 is not shown. This bug is also in Emacs 21 but presumably has never been reported before. There must be many more like it. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: lisp/progmodes/gdb-ui.el
> > Can you please find a way to get the full log?
>
> attached (this is with the CVS head build from this morning)
There's still something odd because the first entry (at the end) is:
(send-item #1# gdb-info-breakpoints-handler)
and all the initial commands at startup are missing (set height 0, set width 0
etc). Below is part of a typical log that I get. Also, for me, newlines are
printed with \n. Maybe this isn't an issue, but the start of the log must
exist somewhere.
--
Nick http://www.inet.net.nz/~nickrob
...
(recv . "\n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n")
(recv . "\n^Z^Zpost-prompt\nNo breakpoints or watchpoints.\n")
(send-item "server info breakpoints\n" gdb-info-breakpoints-handler)
(recv . "\n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n")
(recv . "\n^Z^Zpost-prompt\n\n^Z^Zerror-begin\nNo stack.\n\n^Z^Zerror\n")
(send-item "server info frame\n" gdb-frame-handler)
(recv . "\n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n")
(recv . "\n^Z^Zpost-prompt\nCurrent source file is myprog.c\nCompilation
directory is /home/nickrob\nLocated in /home/nickrob/myprog.c\nContains 139
lines.\nSource language is c.\nCompiled with DWARF 2 debugging
format.\nIncludes preprocessor macro info.\n")
(send-item "server info source\n" gdb-source-info)
(recv . "\n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n")
(recv . "\n^Z^Zpost-prompt\n53 }\n54 \n55donowt (void)\n56 {\n57
int i;\n58 while (1)\n59 i = 4;\n60 }\n61 \n62main (int argc,
char** argv) {\n")
(send-item "server list\n" ignore)
(recv . "\n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n")
(recv . "\n^Z^Zpost-prompt\nSource files for which symbols have been read
in:\n\n\n\nSource files for which symbols will be read in on
demand:\n\n/home/nickrob/myprint.c, /home/nickrob/myprog.c\n")
(send-item "server info sources\n" gdb-set-gud-minor-mode-existing-buffers)
(recv . "\n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n")
(recv . "\n^Z^Zpost-prompt\n")
(send-item "set width 0\n" ignore)
(recv . "\n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n")
(recv . "\n^Z^Zpost-prompt\n")
(send-item "set height 0\n" ignore)
(recv . "\n^Z^Zpre-prompt\n(gdb) \n^Z^Zprompt\n")
(recv . "^Z^Zpost-prompt\n^error,msg=\"Undefined mi command: stack-info-frame
(missing implementation)\"\n(gdb) \n")
(recv . "\n")
(send-item "server interpreter mi -stack-info-frame\n" gdb-get-version))
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: lisp/progmodes/gdb-ui.el
> > >... > > > ^Z^Zpost-prompt > > > Num Type Disp Enb AddressWhat > > > 1 breakpoint keep y 0x080ba832 in rd_ch_unbuffered at > > stream.d:5063 > > > breakpoint already hit 1 time > > > ") (recv . " > > > ^Z^Zpre-prompt > > > (gdb) > > > ^Z^Zprompt > > > ") ...) > > ^^^ > > > > This ends in an ellipsis because the length of the list exceeds > > eval-expression-print-length. This means that you've not sent the start of > > the log. Can you please make it unlimited by setting > > eval-expression-print-length to nil. > > done At the bottom of the log I see: ^Z^Zstarting ^Z^Zframes-invalid ^Z^Zframes-invalid ^Z^Zframes-invalid ^Z^Zsource /mnt/local/sda1/src/clisp/current/build-g/stream.d:5064:192834:beg:0x80ba83a ^Z^Zstopped ") (send-item "server info frame " gdb-frame-handler) ...)) You have ^Z^Zstopped before ^Z^Zstarting (the log reads backwards) so it looks like something is running the progran before you do. But the log still ends in ellipsis. Maybe I'm wrong about eval-expression-print-length but I don't have time to investigate. Can you please find a way to get the full log? (Maybe by evaluating in the scratch buffer and clicking mouse-2 on the ellipsis.) -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: lisp/progmodes/gdb-ui.el
> gdb-debug-ring > ((recv . " > ^Z^Zpost-prompt > ... Thanks, but can you send it as an attachment. I think it gets a bit mangled by the ^Z characters. >... > ^Z^Zpost-prompt > Num Type Disp Enb AddressWhat > 1 breakpoint keep y 0x080ba832 in rd_ch_unbuffered at stream.d:5063 > breakpoint already hit 1 time > ") (recv . " > ^Z^Zpre-prompt > (gdb) > ^Z^Zprompt > ") ...) ^^^ This ends in an ellipsis because the length of the list exceeds eval-expression-print-length. This means that you've not sent the start of the log. Can you please make it unlimited by setting eval-expression-print-length to nil. Thanks, -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: lisp/progmodes/gdb-ui.el
> > That narrows it down a lot. Those changes are:
> >
> > 2006-12-26 Nick Roberts <[EMAIL PROTECTED]>
> >
> > * progmodes/gdb-ui.el (gud-watch): Allow duplicate names for watch
> > expressions.
> > (gdb-var-delete): Handle duplicate names. Print message for non
> > root expressions.
> >
> > This should only make a difference if you create a watch expression in the
> > speedbar.
> >
> > (gdb-partial-output-name): Start buffer name with a space.
> > (gdb-info-breakpoints-custom, gdb-reset): Handle space in above
> > buffer name.
> >
> > This looks a more likely candidate. I've made the partial-output
> > buffer invisible to `C-x b' and tried to change the regexp accordingly.
>
> I still see it (with cvs head from Monday):
> Debugger entered--Lisp error: (error "Unexpected `starting' annotation")
>signal(error ("Unexpected `starting' annotation"))
>error("Unexpected `starting' annotation")
>gdb-starting("")
What about if you back out these two changes separately?
> > It's hard for me to guess but do you see the same problem with another
> > program? i.e is it the program or something else e.g .emacs, OS, version
> > of GDB?
>
> alas, I don't see it with a different program.
I guess that's somewhat reassuring. ;-). You could also try "emacs -Q" but
it looks like it's do with your program (but it colud be both).
--
Nick http://www.inet.net.nz/~nickrob
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: lisp/progmodes/gdb-ui.el
> > They *should* be fine. What happens if you run your program under GDB
> > without your .gdbinit (gdb -nx), perhaps setting a breakpoint from the GUD
> > buffer?
>
>...
> ==>
>
> Debugger entered--Lisp error: (error "Unexpected `starting' annotation")
>signal(error ("Unexpected `starting' annotation"))
>error("Unexpected `starting' annotation")
>gdb-starting("")
>gud-gdba-marker-filter("\npre-prompt\n(gdb)
>...
Can you set the variable gdb-enable-debug to t, and do this again. Then
please post the value of gdb-debug-ring (or send it me off list if it's
large).
THanks
--
Nick http://www.inet.net.nz/~nickrob
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Elisp manual node Active Keymaps: "above" is dangling ref
> emacs -Q > C-h i; pick Elisp manual > > Node Active Keymaps contains this sentence: "The argument > ACCEPT-DEFAULTS controls checking for default bindings, as in > `lookup-key' (above)." > > There is no "(above)": `lookup-key' is not mentioned in this node > prior to this. A real cross reference to the correct node is needed. I've updated this. Thanks. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [BUG?] vc-directory
Richard Stallman writes: > Stefan is the expert on VC now, but I don't know whether he will work > on this soon, so would you please try? Done. I've moved the existing test for dired-mode so that it catches this case too. Same old question: how about splitting lisp/ChangeLog (1149753 bytes). We could break off ChangeLog-2005, or even ChangeLog-2005 and ChangeLog-2006 now. I've read somewhere that CVS doesn't compress uploads, which is presumably why ChangeLog takes so long to commit. It's silly for the most frequently committed file to be the largest. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
