ido-ignore-directories and vc-directory-exclusion-list are similar
I was going through the ido customize group today, and I noticed the ido-ignore-directories (and ido-ignore-files) variables ignore CVS metadata, but not other paths conventionally used for SCM metadata. Emacs seems to already have a list of SCM metadata paths in vc-directory-exclusion-list; perhaps these should be synced? -- Trent Buck ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[sh-mode] .profile is not bash flavoured
In GNU Emacs 22.1.50.1 (x86_64-pc-linux-gnu) of 2007-04-28, emacs -Q ~/.profile uses the sh major mode with the bash "flavour", as seen in the modeline. This is incorrect; the "flavour" should be "sh" (or perhaps "posix"), since a large number of Bourne- and POSIX-compatible login shells read this file, not just Bash. This is a minor issue and it may not be worth implementing correctly. I guess that the change would need to go in the `sh-set-shell' call in the definition of `sh-mode'. -- Trent Buck, Student Errant signature.asc Description: Digital signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: artifacts in GNU CVS branch emacs-unicode-2
On Wed, Feb 14, 2007 at 01:37:50PM +0900, Kenichi Handa wrote: >>> I start Emacs with a proportional font: >>> >>> emacs --enable-font-backend --font 'DejaVu Sans-8' --eval >>> '(w3m-browse-url "http://en.wikipedia.org/";)' >>> >>> I scroll up and down (C-v, M-v). I see 2 pixel underline to the >>> right of some lines. The underlines should not be there; they are >>> rendering artifacts. > > Emacs was going to display an empty box of negative width when a > font for a non-spacing character is not found. I've just installed > a fix. Confirmed, the issue no longer manifests in a checkout from Wed Feb 14 16:02:45 EST 2007. -- Trent Buck, Student Errant signature.asc Description: Digital signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: feature request: C-c C-z bindings for emacs-lisp-mode, sh-mode
On Wed, Feb 07, 2007 at 02:41:12PM -0500, Richard Stallman wrote: >> I'm sorry, maybe I misread your suggestion. Are you suggesting we >> make these bindings only in Sh mode and Emacs Lisp mode? I somehow >> thought you had in mind global bindings for them. > > Sorry, yes. I am suggesting adding these bindings to sh-mode-map > and emacs-lisp-mode-map respectively. > > That could be a good idea, but this is not the time for such > changes. Would you please suggest it again after the 22.1 release? Sure thing. -- Trent Buck, Student Errant signature.asc Description: Digital signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: feature request: C-c C-z bindings for emacs-lisp-mode, sh-mode
On Tue, Feb 06, 2007 at 06:14:57PM -0500, Richard Stallman wrote: > Surely sh-mode and emacs-lisp-mode are major modes? > > I'm sorry, maybe I misread your suggestion. Are you suggesting we > make these bindings only in Sh mode and Emacs Lisp mode? I somehow > thought you had in mind global bindings for them. Sorry, yes. I am suggesting adding these bindings to sh-mode-map and emacs-lisp-mode-map respectively. -- Trent Buck, Student Errant signature.asc Description: Digital signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: feature request: C-c C-z bindings for emacs-lisp-mode, sh-mode
On Mon, Feb 05, 2007 at 07:15:27PM -0500, Richard Stallman wrote: > Key sequences C-c followed by a control char are reserved for major modes. Surely sh-mode and emacs-lisp-mode are major modes? Perhaps I have misunderstood the reservation. I chose C-c C-z and C-c C-l because they are mapped to similar actions for lisp-mode (in inf-lisp.el) and scheme-mode (in cmuscheme.el). -- Trent Buck, Student Errant signature.asc Description: Digital signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: artifacts in GNU CVS branch emacs-unicode-2
On Mon, Jan 29, 2007 at 06:04:24AM +1100, [EMAIL PROTECTED] wrote: > I start Emacs with a proportional font: > > emacs --enable-font-backend --font 'DejaVu Sans-8' --eval > '(w3m-browse-url "http://en.wikipedia.org/";)' > > I scroll up and down (C-v, M-v). I see 2 pixel underline to the right > of some lines. The underlines should not be there; they are rendering > artifacts. Screenshot attached. -- Trent Buck, Student Errant artifacts.png Description: PNG image signature.asc Description: Digital signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: CVS Emacs fails to remove server.el socket on exit
On Mon, Dec 18, 2006 at 10:14:53AM +0100, Juanma Barranquero wrote: > On 12/18/06, Trent Buck <[EMAIL PROTECTED]> wrote: > > >I believe CVS Emacs is not correctly removing the socket file created > >by server-start (from server.el). > > It is on purpose. Note the following fragment from server.el: > > ;; Delete the associated connection file, if applicable. > ;; This is actually problematic: the file may have been overwritten by > ;; another Emacs server in the mean time, so it's not ours any more. > ;; (and (process-contact proc :server) > ;; (eq (process-status proc) 'closed) > ;; (ignore-errors (delete-file (process-get proc :server-file I see. In my .emacs, I change `server-name' to be process-specific, and create a symlink to the "generic" name: ;;; Say I run "bzr commit" in a normal shell, outside of emacs. I ;;; want that to start up a full Emacs. If it used emacsclient, then ;;; buffer would show up on some random Emacs process in some GNU ;;; Screen window, and I'd have to hunt it down. ;;; ;;; HOWEVER, if I run M-x shell in Emacs, and I run "bzr commit" in ;;; THERE, I want it to talk to the parent Emacs process (via ;;; emacsclient). ;;; ;;; Since I occasionally have multiple Emacs processes running, I need ;;; to change server-name to be process-specific, so the Emacs ;;; processes' server-starts won't clobber one another's sockets. (setq server-name (format "server%d" (emacs-pid))) (let ((x (format "emacsclient -s %s" server-name))) (setenv "VISUAL" x) (setenv "EDITOR" x)) (server-start) ;; emacsclient(1) looks for a socket named "server" by default. We ;; symlink to this file, so that running emacsclient manually from the ;; command line will use the more recently opened Emacs. ;; ;; We don't bother doing this for Emacs 21 because the socket dir is ;; too difficult to deduce. (when (= emacs-major-version 22) (make-symbolic-link server-name (concat server-socket-dir "/server") t)) Is this a sensible approach to adopt as default in CVS Emacs, or would it have problems for e.g. DOS users (who have no symbolic links)? If this approach was adopted, `server-sentinel' could happily remove it's socket file, leaving a broken symlink instead of a defunct socket. -- Trent Buck, Student Errant signature.asc Description: Digital signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
CVS Emacs fails to remove server.el socket on exit
I believe CVS Emacs is not correctly removing the socket file created by server-start (from server.el). The following transcript demonstrates the issue: $ ls /tmp/emacs$UID ls: /tmp/emacs1000: No such file or directory $ emacs -q --no-site-file -f server-start -f save-buffers-kill-emacs $ ls /tmp/emacs$UID ls: /tmp/emacs1000: No such file or directory $ emacs-snapshot -q --no-site-file -f server-start -f save-buffers-kill-emacs $ ls /tmp/emacs$UID server In GNU Emacs 22.0.91.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-12-13 on rocinante, modified by Debian (Debian emacs-snapshot package, version 1:20061201-1) configured using `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/22.0.91/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.0.91/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.0.91/leim' '--with-x=yes' '--with-x-toolkit=athena' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2'' -- Trent Buck, Student Errant signature.asc Description: Digital signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ascii ppm file opens in image-mode instead of image-minor-mode in -nw frame
Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: When opening an ascii-encoded PPM file with the .ppm extension in a -nw frame, image-mode is enabled (as a major mode). Consequently, next-line, previous-line, forward-char, backward-char &c behave like beginning-of-buffer and end-of-buffer respectively. This is mildly irritating because it requires one to type M-x fundamental-mode to get said commands to behave as desired. I note that this behaviour does *not* manifest when viewing an .xpm file in an -nw frame -- it uses image-minor-mode rather than image-mode. -- Trent Buck, Engineer Extraordinare ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Comment body colourless in eight-colour terminal.
Nick Roberts <[EMAIL PROTECTED]> writes: > Trent Buck writes: > > Using Debian GNU/Linux, in a stock xterm or on the console, run > > > >TERM=linux emacs -nw -Q -fg black -bg white -f global-font-lock-mode > ~/.emacs > >TERM=linux emacs -nw -Q -fg white -bg black -f global-font-lock-mode > ~/.emacs > > > > The comment characters (;) are coloured red, but comment bodies (after ;'s) > > are the same colour as ordinary text. > > This has been done to save battery power on aging Laptops. Are there a lot of people using aging laptops? Could these people leave font lock off (it is off by default) or set font-lock-comment-face's definition to nil? > > I contend that a better default would be for the comment bodies to be the > > same colour as the comment characters. This is already the case when > > running under X11 and under Emacs 21. > > You're out of luck. You'll have to customize font-lock-comment-face. I > think you just need to get it to inherit from > font-lock-comment-delimiter-face. Actually, font-lock-comment-delimiter-face inherits from font-lock-comment-face, so that would create a circular inheritance. Currently I am simply face-spec-set to set the entire face. -- Trent Buck, Student Errant ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Comment body colourless in eight-colour terminal.
Using Debian GNU/Linux, in a stock xterm or on the console, run TERM=linux emacs -nw -Q -fg black -bg white -f global-font-lock-mode ~/.emacs TERM=linux emacs -nw -Q -fg white -bg black -f global-font-lock-mode ~/.emacs The comment characters (;) are coloured red, but comment bodies (after ;'s) are the same colour as ordinary text. I contend that a better default would be for the comment bodies to be the same colour as the comment characters. This is already the case when running under X11 and under Emacs 21. The attached patch should have the desired effect. --- font-lock.el~ 2005-09-24 09:18:34.0 +1000 +++ font-lock.el 2005-10-23 14:01:42.548618808 +1000 @@ -1685,31 +1685,31 @@ (defface font-lock-comment-face 'class grayscale) (background light)) (:foreground "DimGray" :weight bold :slant italic)) (((class grayscale) (background dark)) (:foreground "LightGray" :weight bold :slant italic)) (((class color) (min-colors 88) (background light)) (:foreground "Firebrick")) (((class color) (min-colors 88) (background dark)) (:foreground "chocolate1")) (((class color) (min-colors 16) (background light)) (:foreground "red")) (((class color) (min-colors 16) (background dark)) (:foreground "red1")) (((class color) (min-colors 8) (background light)) - ) + (:foreground "red")) (((class color) (min-colors 8) (background dark)) - ) + (:foreground "red1")) (t (:weight bold :slant italic))) "Font Lock mode face used to highlight comments." :group 'font-lock-highlighting-faces) (defface font-lock-comment-delimiter-face '((default :inherit font-lock-comment-face) (((class grayscale))) (((class color) (min-colors 16))) (((class color) (min-colors 8) (background light)) :foreground "red") (((class color) (min-colors 8) (background dark)) :foreground "red1")) "Font Lock mode face used to highlight comment delimiters." :group 'font-lock-highlighting-faces) In GNU Emacs 22.0.50.1 (powerpc-unknown-linux-gnu, GTK+ Version 2.8.3) of 2005-09-24 on rocinante, modified by Debian -- Trent Buck, Student Errant ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: set-visited-file-name with null buffer-file-name
Luc Teirlinck <[EMAIL PROTECTED]> writes: > Trent Buck wrote: > >In files.el~CVS-1.778~:2548,25 is the call > (file-name-nondirectory buffer-file-name) > >If buffer-file-name is nil, this creates an error: > (wrong-type-argument stringp nil) > >You can reproduce this behaviour as follows: > C-x b asdfasdf RET C-x C-w /tmp/tmp RET > >assuming that there is no buffer "asdfasdf" and no file "/tmp/tmp". > > Should be fixed now, Confirmed. Thanks for the prompt response. -- Trent Buck, Student Errant ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
set-visited-file-name with null buffer-file-name
In files.el~CVS-1.778~:2548,25 is the call (file-name-nondirectory buffer-file-name) If buffer-file-name is nil, this creates an error: (wrong-type-argument stringp nil) You can reproduce this behaviour as follows: C-x b asdfasdf RET C-x C-w /tmp/tmp RET assuming that there is no buffer "asdfasdf" and no file "/tmp/tmp". In GNU Emacs 22.0.50.1 (powerpc-unknown-linux-gnu, GTK+ Version 2.6.2) of 2005-07-10 on rocinante, modified by Debian configured using `configure '--build' 'powerpc-linux' '--host' 'powerpc-linux' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--with-gif' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/22.0.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.0.50/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.0.50/leim' '--with-x=yes' '--with-x-toolkit=gtk' 'CFLAGS=-DDEBIAN -g -O2' 'build_alias=powerpc-linux' 'host_alias=powerpc-linux'' -- Trent Buck, Student Errant ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
make-mode "hanging"
'^+++\|^cvs.\(update\|server\):.' < $i > $i.tmp; then mv $i.tmp $i; else rm -f $i.tmp $i; fi; done # http://twb.ath.cx/~twb/src/scripts/dpkg-trent.sh PS: I am not currently on this list, please CC replies to me ([EMAIL PROTECTED]) if possible. In GNU Emacs 22.0.50.1 (i386-pc-linux-gnu) of 2005-05-17 on malambruno, modified by Debian configured using `configure '--build' 'i386-linux' '--host' 'i386-linux' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--with-gif' '--with-x=no' 'CFLAGS=-DDEBIAN -g -O2' 'build_alias=i386-linux' 'host_alias=i386-linux'' -- Trent Buck, Student Errant ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
