Info does not say abbrev-mode needed

2006-10-21 Thread Lennart Borgman


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

2006-10-21 Thread Eli Zaretskii
> 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

2006-10-21 Thread Nick Roberts

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


emacs-unicode-2: `kinsoku processing' and `nospace-between-words' don't work

2006-10-21 Thread Zhang Wei

`kinsoku processing' and `nospace-between-words' don't work with
auto-fill-mode.

--
If emacs crashed, and you have the emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/local/share/emacs/23.0.0/etc/DEBUG for instructions.


In GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2006-10-19 on emacsfans.org
X server distributor `The X.Org Foundation', version 11.0.7000
configured using `configure '--with-gtk' '--enable-font-backend' 
'--with-freetype' '--with-xft' '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.UTF-8
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  shell-dirtrack-mode: t
  show-paren-mode: t
  display-time-mode: t
  delete-selection-mode: t
  pc-selection-mode: t
  auto-image-file-mode: t
  tooltip-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
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  view-mode: t

Recent input:
   
   
   
C-x C-b v C-s C-g C-x C-b  
 q  
   
  v C-s C-s M-y C-a C-s M-y C-s C-s C-s C-s 
C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s 
C-s C-s M-x r e p r o t
o r t - e m  b u  

Recent messages:
Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help
Auto-saving...done
Updating buffer list...done
Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help
Quit
Updating buffer list...done
Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help
Mark saved where search started [2 times]
Loading emacsbug...done
call-interactively: Text is read-only



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: detecting charset of directories

2006-10-21 Thread Richard Stallman
> 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: Fwd: Serious performace problems on Windows XP with new(!) GNU Emacs v22 (both patched and unpatched EmacsW32 were tried)

2006-10-21 Thread Richard Stallman
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.

  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 drag&dropped it)

has some 3500 lines which will produce approximately 7000 overlays.

Is that still true after the changes you sent?

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?


___
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

2006-10-21 Thread Zhang Wei
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)

2006-10-21 Thread martin rudalics

> 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 drag&dropped 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)

2006-10-21 Thread martin rudalics

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

2006-10-21 Thread Richard Stallman
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

2006-10-21 Thread Zhang Wei
Zhang Wei <[EMAIL PROTECTED]> writes:

> `kinsoku processing' and `nospace-between-words' don't work with
> auto-fill-mode.

Would this patch be useful?



patch
Description: test/plain
___
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

2006-10-21 Thread Zhang Wei
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

2006-10-21 Thread Nick Roberts

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

2006-10-21 Thread Stefan Monnier
> 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