Works again (was: Bootstrapping CVS Emacs fails with error)
Thank you! ___ 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
From: Nick Roberts [EMAIL PROTECTED] Date: Sat, 14 Jul 2007 12:21:55 +1200 Cc: emacs-pretest-bug@gnu.org 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? 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? What happens in a no-window (-nw) session? 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)? 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. 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. ___ 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 [EMAIL PROTECTED] writes: + (if (case gud-gdb-annotations +(2 nil) +(nil (string-match --annotate=3 command-line)) FWIW, this should be `((nil) ...)'. `nil' means an empty KEYLIST (which always fails). The manual says To make a clause that matches the actual symbol `t', `nil', or `otherwise', enclose the symbol in a list. Maybe a similar note should be added to the docstring. -- Johan Bockgård ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `cp' don't preserve timestamps by default on windows-xp
Eli Zaretskii [EMAIL PROTECTED] writes: I guess we could rewrite the install target in lisp/Makefile so that it copies the *.el files first. Done. Please resync with the CVS and see if the problem is gone. It works fine, thank you. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
Eli Zaretskii [EMAIL PROTECTED] writes: [...] I have now installed a change to use @documentencoding and the --enable-encoding switch, so that the `coding:' tag is produced in info/emacs-mime. Please see if that solves the problem. No problem now, thanks. ___ 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
On 7/14/07, Eli Zaretskii [EMAIL PROTECTED] wrote: ??? 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? Animism? Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `cp' don't preserve timestamps by default on windows-xp
Cc: emacs-pretest-bug@gnu.org From: Zhang Wei [EMAIL PROTECTED] Date: Sat, 14 Jul 2007 19:22:59 +0800 Eli Zaretskii [EMAIL PROTECTED] writes: I guess we could rewrite the install target in lisp/Makefile so that it copies the *.el files first. Done. Please resync with the CVS and see if the problem is gone. It works fine, thank you. Thanks for testing. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info pages opened with an incorrect coding system
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-pretest-bug@gnu.org From: Zhang Wei [EMAIL PROTECTED] Date: Sat, 14 Jul 2007 19:23:50 +0800 Eli Zaretskii [EMAIL PROTECTED] writes: [...] I have now installed a change to use @documentencoding and the --enable-encoding switch, so that the `coding:' tag is produced in info/emacs-mime. Please see if that solves the problem. No problem now, thanks. Thank you for testing this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] Chinese characters too small
In article [EMAIL PROTECTED], Leo [EMAIL PROTECTED] writes: On 2007-07-12 12:19 +0100, Kenichi Handa wrote: It appears that Chinese characters have pixelsize 16 in Emacs rxvt-unicode gnome-terminal but have a larger pixelsize in gedit xterm. How did you specify the font pixelsize in gedit? As far as I know, what you set via Edit-Preferences-FontColors is pointsize? I didn't specify pixelsize for gedit. I just make sure their ASCII characters have the same size before comparing Chinese characters. Ah, I see. --- Kenichi Handa [EMAIL PROTECTED] ___ 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
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. 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. Of course, I didn't file a bug report about it: that would have been too easy, right? More seriously, I simply had no time at that moment and couldn't reproduce it afterwards. I'm not sure what's the reason for gdb-ui's historical instability, but I suspect it's due to the interface between gdb and gdb-ui (the --annotate-3 annotations). I hope GDB/MI is better. Unless the problem is directly in GDB's own instability. Stefan ___ 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
To make a clause that matches the actual symbol `t', `nil', or `otherwise', enclose the symbol in a list. Thanks for catching it. Not that it mattered since this was intended for human consumption exclusively: don't ever pass it to `patch' or try to splice the code in by hand either. Not only it's got the above bug but it's a quickdirty hack. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
