Info does not say abbrev-mode needed
In (info (emacs) Expanding Abbrevs) the first paragraph does not mention that abbrev-mode must be on for expansion using whitespace or punctuation chars to work. Should it not do that? In GNU Emacs 22.0.50.1 (i386-mingw-nt5.0.2195) of 2006-10-15 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `.newsrc.eld' saves chinese group name in wrong coding
Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org, [EMAIL PROTECTED], [EMAIL PROTECTED] From: Stefan Monnier [EMAIL PROTECTED] Date: Fri, 20 Oct 2006 18:06:09 -0400 It could be, although it would make sense to manipulate group names in encoded form, in the sense of not decoded. It could ``make sense'', but it's IMO a bad idea, since, as we both know, Emacs is not well suited to handling unibyte strings. Huh? Unibyte strings are perfectly well supported as far as I know. You have to be careful to remember which strings are unibyte and which are multibyte, so you don't decode multibyte strings or encode unibyte strings, and especially not implicitly (by inserting a unibyte string in a multibyte buffer or vice versa). So if you mean that it requires discipline, then I agree, but otherwise I don't know what you're referring to. To me, the second paragraph is precisely the meaning of ``not well suited'' and ``not perfectly supported''. What kind of ``well supported'' is that if I as a programmer need to carry with each string additional information, and make sure I know _exactly_ what primitives are invoked by every function I call, to take care that I don't inadvertently call something that deep inside assumes I passed a multibyte string? That way lies madness. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
highlight-changes-mode
highlight-changes-mode in mode-line-mode-menu doesn't toggle on the mode-line because it has three values: With an argument ARG: If ARG is positive, set state to active; If ARG is zero, set state to passive; If ARG is negative, disable Highlight Changes mode completely. Also column-number-mode ans line-number-mode are the only global minor-modes in mode-line-mode-menu. Perhaps they should be listed first with a separator. -- 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: detecting charset of directories
I think to make that work, dired-revert needs the same fix as dired-mode, namely: (set (make-local-variable 'file-name-coding-system) (or coding-system-for-read file-name-coding-system)) Kevin, I don't understand that suggestion. I don't see anything like that code in dired-mode. Are you proposing a change to dired-mode AND a change to dired-revert? Could use diff to show the change you are suggesting? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2: `kinsoku processing' and `nospace-between-words' don't work
Zhang Wei [EMAIL PROTECTED] writes: `kinsoku processing' and `nospace-between-words' don't work with auto-fill-mode. It don't work with UTF-8 and Chinese-GBK language environment, but it work with Chinese-GB language envrionment, strange behavior. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fwd: Serious performace problems on Windows XP with new(!) GNU Emacs v22 (both patched and unpatched EmacsW32 were tried)
It looks like we could speed it up even more by producing this list ! (setq whitespace-retval (cons (match-beginning 0) whitespace-retval)) only if it is actually wanted. Calling from whitespace-buffer could pass t as an optional argument saying do produce this list. We could at least shorten such lists to a reasonably length. The overhead for maintaining these overlays may grow non-linearly with respect to their number. Your 3. unzip and then visit the attached slowtst.el (I dragdropped it) has some 3500 lines which will produce approximately 7000 overlays. Is that still true after the changes you sent? Yes. But the file is pathological. In addition, `whitespace-buffer' may unconditionally trigger a non-idle timer which may trigger further executions of `whitespace-buffer'. The doc-string of the timer says: Timer object used to rescan the files in buffers that have been modified. That's false, whitespace doesn't check whether a file is modified. Can you fix that up too? I think (1) the timer should become an idle-timer, (2) quitting must be permitted, and (3) one could use `buffer-chars-modified-tick' - to check whether the latter works;-). On the other hand, most of this could be done via font-lock which would ask for a completely different design. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fwd: Serious performace problems on Windows XP with new(!) GNU Emacs v22 (both patched and unpatched EmacsW32 were tried)
I forgot to say that I can't follow Peter's argument that older 2006 Emacsen didn't have this problem. I tried with a couple of versions starting with a mid-2005 one and all exhibited the same behavior as the most recent one. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse-face redisplay messy on Windows XP x64 Edition
I can reproduce similar results with M-x shell on GNU/Linux following your description (terminating each multi-line with C-j is crusial!!) It looks like redisplay fails to delete to end of line when lines have mouse face. Is it really a bug in Emacs, or is this just a matter of how to implement output of CR into the comint buffer? If it is a real bug, can you fix it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2: `kinsoku processing' and `nospace-between-words' don't work
Zhang Wei [EMAIL PROTECTED] writes: `kinsoku processing' and `nospace-between-words' don't work with auto-fill-mode. Would this patch be useful? ? patch ? admin/unidata/unidata.txt Index: lisp/international/characters.el === RCS file: /cvsroot/cvs.savannah.gnu.org/emacs/emacs/lisp/international/characters.el,v retrieving revision 1.42.4.18 diff -u -r1.42.4.18 characters.el --- lisp/international/characters.el28 Aug 2006 02:32:19 - 1.42.4.18 +++ lisp/international/characters.el21 Oct 2006 18:09:44 - @@ -869,8 +869,10 @@ ;; Setup auto-fill-chars for charsets that should invoke auto-filling. -;; SPACE and NEWLINE are already set. Also put `nospace-between-words' -;; property on the charsets. +;; SPACE and NEWLINE are already set, put `nospace-between-words' +;; property on the charsets. Also put `fill-find-break-point-function' +;; property to charsets which require special functions to find line +;; breaking point. (set-char-table-range auto-fill-chars '(#x3041 . #x30FF) t) (set-char-table-range auto-fill-chars '(#x3400 . #x4DB5) t) @@ -879,16 +881,31 @@ (set-char-table-range auto-fill-chars '(#xFF00 . #xFF9F) t) (set-char-table-range auto-fill-chars '(#x2 . #x2) t) -(let ((l '(katakana-jisx0201 - japanese-jisx0208 japanese-jisx0212 - japanese-jisx0213-1 japanese-jisx0213-2 - chinese-gb2312 chinese-gbk chinese-big5-1 chinese-big5-2 - chinese-cns11643-1 chinese-cns11643-2 chinese-cns11643-3 - chinese-cns11643-4 chinese-cns11643-5 chinese-cns11643-6 - chinese-cns11643-7))) - (while l -(put-charset-property (car l) 'nospace-between-words t) -(setq l (cdr l +(dolist (pair '((katakana-jisx0201 . kinsoku) + (japanese-jisx0208 . kinsoku) + (japanese-jisx0212 . kinsoku) + (japanese-jisx0213-1 . kinsoku) + (japanese-jisx0213-2 . kinsoku) + (chinese-gb2312 . kinsoku) + (chinese-gbk . kinsoku) + (gb18030-2-byte . kinsoku) + (gb18030-4-byte-bmp . kinsoku) + (gb18030-4-byte-smp . kinsoku) + (gb18030-4-byte-ext-1 . kinsoku) + (gb18030-4-byte-ext-2 . kinsoku) + (chinese-big5-1 . kinsoku) + (chinese-big5-2 . kinsoku) + (big5-hkscs . kinsoku) + (chinese-cns11643-1 . kinsoku) + (chinese-cns11643-2 . kinsoku) + (chinese-cns11643-3 . kinsoku) + (chinese-cns11643-4 . kinsoku) + (chinese-cns11643-5 . kinsoku) + (chinese-cns11643-6 . kinsoku) + (chinese-cns11643-7 . kinsoku) + (unicode . kinsoku))) + (put-charset-property (car pair) 'fill-find-break-point-function (cdr pair)) + (put-charset-property (car pair) 'nospace-between-words t)) ;; CJK double width characters. Index: lisp/textmodes/fill.el === RCS file: /cvsroot/cvs.savannah.gnu.org/emacs/emacs/lisp/textmodes/fill.el,v retrieving revision 1.164.2.16 diff -u -r1.164.2.16 fill.el --- lisp/textmodes/fill.el 14 Sep 2006 09:23:51 - 1.164.2.16 +++ lisp/textmodes/fill.el 21 Oct 2006 18:09:44 - @@ -368,16 +368,6 @@ (looking-at paragraph-start (run-hook-with-args-until-success 'fill-nobreak-predicate) -;; Put `fill-find-break-point-function' property to charsets which -;; require special functions to find line breaking point. -(dolist (pair '((katakana-jisx0201 . kinsoku) - (chinese-gb2312 . kinsoku) - (japanese-jisx0208 . kinsoku) - (japanese-jisx0212 . kinsoku) - (chinese-big5-1 . kinsoku) - (chinese-big5-2 . kinsoku))) - (put-charset-property (car pair) 'fill-find-break-point-function (cdr pair))) - (defun fill-find-break-point (limit) Move point to a proper line breaking position of the current line. Don't move back past the buffer position LIMIT. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
More mode-line stuff
If you move the mouse over the line=number indicator you get the tooltip: mouse-1: select (drag to resize), mouse-2: delete others, mouse-3: delete this so you might expect mouse-3 to delete the indicator/turn off the mode and not the window. I think mouse-3 _should_ turn off the mode and that mouse-3 should also turn off the minor-mode when the mouse is over one of the minor-mode indicators grouped within the round brackets with the mayor mode (currently it pops up the list of minor modes (mode-line-menu-mode-1) just as it does over the mayor mode indicator). Also (maybe because the default font size has changed) the message mouse-1: select (drag to resize), mouse-2: delete other windows, mouse-3: delete this window fits on one line in the tooltip (the comment in bindings suggests that at one time it didn'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
Re: mouse-face redisplay messy on Windows XP x64 Edition
I can reproduce similar results with M-x shell on GNU/Linux following your description (terminating each multi-line with C-j is crusial!!) It looks like redisplay fails to delete to end of line when lines have mouse face. Is it really a bug in Emacs, or is this just a matter of how to implement output of CR into the comint buffer? If it is a real bug, can you fix it? I think it's really a bug, but it's difficult to fix: basically CR in comint currently erases line and puts point at BOL, but it should only put point at BOL (and then overwrite the line when subsequent output comes). Problem is that comint's normal behavior is not to overwrite text but to insert it, so it's not trivial to change. Maybe we could try to special case the situation where CR is immediately followed by LF? Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
