Re: autoload and auto-compression-mode
>> I can install the patches if desired. Once they are installed, I would >> also update various docstrings and loading.texi. > > The doc strings of load-suffixes and load-file-rep-suffixes left me > confused as to what each of the two lists does. I want to note also that the name `load-file-rep-suffixes' is confusing too. The meaning of the infix `-rep-' is not evident. What does it mean? `REPeat'? (i.e. repeating applying suffixes from a different suffix list.) `REPlace'? (i.e replacing suffixes.) Replacing doesn't seem correct, because suffixes from the second list get added to the file name. Maybe, then `load-file-add-suffixes' is a better name? Or maybe, `load-same-file-suffixes'? -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Customize doc strings do not respect \\<...> and \\[...]
emacs -q (defcustom foo nil "*Behavior of `[my-cmd]' when foobaz is in the wind." :type 'boolean) Then, `C-h v foo' shows the doc string correctly as, say, "Behavior of `M-a' when foobaz is in the wind." However, when you click the Customize link and get to the Customize buffer, the key bindings are not substituted in the doc string. You see this: Behavior of `\\[my-cmd]' when foobaz is in the wind. Note that one level of backslash is removed. In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-06-26 on NONIQPC X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../. ./tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/incl ude' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Customize doc strings and tag strings do not respect \\<...> and \\[...]
I should add that the same problem exists for :tag strings. emacs -q (defcustom foo nil "*Behavior of `[my-cmd]' when foobaz is in the wind." :type 'boolean) Then, `C-h v foo' shows the doc string correctly as, say, "Behavior of `M-a' when foobaz is in the wind." However, when you click the Customize link and get to the Customize buffer, the key bindings are not substituted in the doc string. You see this: Behavior of `\\[my-cmd]' when foobaz is in the wind. Note that one level of backslash is removed. In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-06-26 on NONIQPC X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../../tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ffap and ignoring case in completions
Rajesh has not responded to my questions about this, so I think we should just install the patch. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu item "Options --> Save Options" not working anymore
* Chong Yidong (2006-02-19) writes: >> The menu item "Options --> Save Options" does not work anymore. In >> order to check this, change one of the values in the Options menu, >> e.g. "Blinking Cursor", click on the "Save Options" menu item and >> compare your init file with a backup you did before. In my case >> there are no changes written to the file. > > That was an oversight on my part, now fixed. Thanks. Confirmed. Thanks. > I noticed, however, that the now-working Save Option saves some > options that aren't really "changed", like cua-mode and > display-battery-mode. Apparently those are defined by > define-minor-mode, so the mode variables don't have standard values, > so Custom can't tell if they've been changed. ISTR that this was the > old behavior of Save Options, but maybe it should be fixed somehow. I think so, too. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Empty Overlay with before-string or after-string property still treated as empty
martin rudalics wrote: > If you an overlay has equal endpoints, and a before-string or after-string property set, the face > property does not affect the before-string or after-string. I found this while modifying hl-line to > properly handle the last line in a buffer. I'd rather not use zero length overlays with before- and after-strings, compare the thread "before- and after-string issues" starting with: http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-05/msg00176.html I found additional problems since that but forgot about most of them. Which requires user code that uses a before string or after string to always set the text property in the string. Uhg. If you're going to do that, you could at least hack the overlay-put function to handle this transparently: (defconst overlay-string-props '(before-string after-string)) ;; any others? (defun my-overlay-put (overlay prop value) "Replacement for `overlay-put' that handles overlay strings transparently" (overlay-put overlay prop value) (when (member prop (cons 'face overlay-string-props)) (let ((face (overlay-get overlay 'face))) (dolist (string (mapcan (lambda (prop) (let ((value (overlay-get overlay prop))) (if value (list value) nil))) overlay-string-props)) (if face (put-text-property 0 (length string) 'face face string) (remove-text-properties 0 (length string) '(face nil) string)) It's hacky, but it works, and you could always properly fix it later on. > P.S. It would also be nice if hl-line-mode was changed to properly handle the last line in a > buffer. ;) Might be caused by redisplay, compare http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-01/msg00347.html although I'm not sure whether our problems are related. I don't think so. The bug happens regardless of where the overlay is and doesn't get fixed if I run recenter (which force a redisplay). -- MJF ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu item "Options --> Save Options" not working anymore
> The menu item "Options --> Save Options" does not work anymore. In > order to check this, change one of the values in the Options menu, > e.g. "Blinking Cursor", click on the "Save Options" menu item and > compare your init file with a backup you did before. In my case > there are no changes written to the file. That was an oversight on my part, now fixed. Thanks. I noticed, however, that the now-working Save Option saves some options that aren't really "changed", like cua-mode and display-battery-mode. Apparently those are defined by define-minor-mode, so the mode variables don't have standard values, so Custom can't tell if they've been changed. ISTR that this was the old behavior of Save Options, but maybe it should be fixed somehow. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
emacs-unicode-2: copy & paste problem of non standard encoding ctext
While copy and paste between Emacs unicode branch and a ctext required
software such as crxvt-gb, emacs can't format/decode correctly the
"gbk-0" encoded compound text.
With the following patch, emacs could accept gbk-0 encoded selection,
but still can't paste to crxvt-gb.
btw, because emacs-unicode-2 has a different internal character
representation, functions such as `following-char' and 'char-after',
return a quite different value from emacs22. We have to replace every
occurrence of these function with:
(multibyte-char-to-unibyte (char-after ... ))
(multibyte-char-to-unibyte (following-char ... ))
May be change the definitions of these functions is a better solution.
--- orig/lisp/international/mule.el
+++ mod/lisp/international/mule.el
@@ -1345,7 +1345,8 @@
(defvar ctext-non-standard-encodings-alist
'(("big5-0" big5 2 (chinese-big5-1 chinese-big5-2))
("ISO8859-14" iso-8859-14 1 latin-iso8859-14)
-("ISO8859-15" iso-8859-15 1 latin-iso8859-15))
+("ISO8859-15" iso-8859-15 1 latin-iso8859-15)
+("gbk-0" gbk 2 chinese-gbk))
"Alist of non-standard encoding names vs the corresponding usages in CTEXT.
It controls how extended segments of a compound text are handled
@@ -1375,7 +1376,7 @@
`ctext-non-standard-encodings' are used.")
(defvar ctext-non-standard-encodings
- '("big5-0")
+ '("big5-0" "gbk-0")
"List of non-standard encoding names used in extended segments of CTEXT.
Each element must be one of the names listed in the variable
`ctext-non-standard-encodings-alist' (which see).")
@@ -1412,8 +1413,8 @@
(setq pos (match-beginning 0))
(if (match-beginning 1)
;; ESC % / [0-4] M L --ENCODING-NAME-- \002 --BYTES--
- (let* ((M (char-after (+ pos 4)))
-(L (char-after (+ pos 5)))
+ (let* ((M (multibyte-char-to-unibyte (char-after (+ pos 4
+(L (multibyte-char-to-unibyte (char-after (+ pos 5
(encoding (match-string 2))
(encoding-info (assoc-string
encoding
--- orig/lisp/language/chinese.el
+++ mod/lisp/language/chinese.el
@@ -228,7 +228,9 @@
(coding-system chinese-gbk)
(coding-priority gbk iso-2022-cn chinese-big5
chinese-iso-8bit) ; fixme?
+(ctext-non-standard-encodings "gbk-0")
(input-method . "chinese-py-punct") ; fixme?
+(sample-text . "Chinese (中文,普通话,汉语) 妳好")
(features china-util)
(documentation . "Support for Chinese GBK character set."))
'("Chinese"))
In GNU Emacs 23.0.0.7 (i686-pc-linux-gnu, GTK+ Version 2.8.9)
of 2006-02-19 on emacsfans.tsinghua.edu.cn
X server distributor `The X.Org Foundation', version 11.0.60802000
configured using `configure '--with-gtk' 'CFLAGS=-g''
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: zh_CN.GBK
locale-coding-system: gbk
default-enable-multibyte-characters: t
Major mode: Group
Minor modes in effect:
gnus-topic-mode: t
gnus-undo-mode: t
display-time-mode: t
delete-selection-mode: t
pc-selection-mode: t
auto-image-file-mode: t
tooltip-mode: t
auto-compression-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
C-d C-d C-d C-d C-d
C-d C-d C-d C-d C-d C-d C-x C-s
M-x g n u s C y g
q q M-x r e p o r t
Recent messages:
Fetching headers for gnu.emacs.help...done
Scoring...done
Generating summary...done
Loading gnus-bcklg...done
Loading mail-extr...done
Loading ansi-color...done
Loading smiley...done
Loading gnus-cite...done
No more unread newsgroups
Loading emacsbug...done
--
Zhang Wei or Brep
<[EMAIL PROTECTED]>
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
menu-find-file-existing' can't open file with non-ascii filename
I have reported this bug to the emacs-devel mail list several days ago. It seems it is vanished into the flood. `read-file-name' returns an undecoded filename if it was invoked with the mouse, but returns a decoded filename if it was invoked with the keyboard. If it is an undecoded non-ascii filename, (file-directory-p filename) or something like that will report `t' falsely, that cause the file can't be opened. I think the `x-file-dialog' function should return a decoded filename, rather an undecoded filename. --- orig/src/xfns.c +++ mod/src/xfns.c @@ -5313,6 +5313,7 @@ int result; struct frame *f = SELECTED_FRAME (); Lisp_Object file = Qnil; + Lisp_Object decoded_file; Widget dialog, text, help; Arg al[10]; int ac = 0; @@ -5453,7 +5454,9 @@ if (NILP (file)) Fsignal (Qquit, Qnil); - return unbind_to (count, file); + decoded_file = DECODE_FILE (file); + + return unbind_to (count, decoded_file); } #endif /* USE_MOTIF */ @@ -5481,6 +5484,7 @@ FRAME_PTR f = SELECTED_FRAME (); char *fn; Lisp_Object file = Qnil; + Lisp_Object decoded_file; int count = SPECPDL_INDEX (); struct gcpro gcpro1, gcpro2, gcpro3, gcpro4, gcpro5, gcpro6; char *cdef_file; @@ -5521,7 +5525,9 @@ if (NILP (file)) Fsignal (Qquit, Qnil); - return unbind_to (count, file); + decoded_file = DECODE_FILE (file); + + return unbind_to (count, decoded_file); } #endif /* USE_GTK */ -- Zhang Wei or Brep <[EMAIL PROTECTED]> ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Menu item "Options --> Save Options" not working anymore
The menu item "Options --> Save Options" does not work anymore. In order to check this, change one of the values in the Options menu, e.g. "Blinking Cursor", click on the "Save Options" menu item and compare your init file with a backup you did before. In my case there are no changes written to the file. AFAICS the bug was introduced with one of the changes to custom.el, cus-edit.el, cus-theme.el, or cus-face.el made around 2006-01-02. A build with sources checked out with `cvs up -D 2006-01-02' updates the init file correctly while one with `cvs up -D 2006-01-03' does exhibit the bug. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.8.12) of 2006-02-19 on neutrino X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--with-gtk'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: desktop-save-mode: t display-time-mode: t iswitchb-mode: t recentf-mode: t show-paren-mode: t encoded-kbd-mode: t auto-compression-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: M-x r e p o r t - e m Recent messages: Loading iswitchb...done Loading time...done Loading desktop...done Loading rng-auto (source)...done Loading easy-mmode...done Loading edmacro...done No desktop file. For information about the GNU Project and its goals, type C-h C-p. Loading cl-seq...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Empty Overlay with before-string or after-string property still treated as empty
> If you an overlay has equal endpoints, and a before-string or after-string property set, the face > property does not affect the before-string or after-string. I found this while modifying hl-line to > properly handle the last line in a buffer. I'd rather not use zero length overlays with before- and after-strings, compare the thread "before- and after-string issues" starting with: http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-05/msg00176.html I found additional problems since that but forgot about most of them. > P.S. It would also be nice if hl-line-mode was changed to properly handle the last line in a > buffer. ;) Might be caused by redisplay, compare http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-01/msg00347.html although I'm not sure whether our problems are related. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
