RE: display problem
> > > (defun make-glyph-code (char &optional face) > > > "Return a glyph code representing char CHAR with face FACE." > > > (if face (logior char (lsh (face-id face) 19)) char)) > ... > > > I admit to not understanding a lot about glyphs, character codes, or > > > Unicode. Perhaps it is silly to expect that `make-glyph-code' > > > would work as proposed for Emacs 23 also. Please explain. Otherwise, > > > if this is a bug, HTH. > > > The "19" should be "21" in the unicode branch. > > Actually, it should be "22". > > > [I'll make that change in the CVS tree, as make-glyph-code already > > exists there.] > > I've already installed that change in emacs-unicode-2 > branch. Great. Glad the report served some purpose. Thx - Drew ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
> On Sun, 27 May 2007 22:32:28 -0400, Chong Yidong <[EMAIL PROTECTED]> said: >> Could someone check if this works on Windows for the original >> problem? > It fixes the bug as seen on GNU/Linux (i.e., with `debug-on-error' > on, I no longer see a `forward-list' error with original bug recipe; > I never observed the "other operations are blocked" part of the bug > report on this platform.) > Let's get this into the branch. Done. Reports from Windows users still wanted. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display problem
In article <[EMAIL PROTECTED]>, Miles Bader <[EMAIL PROTECTED]> writes: > "Drew Adams" <[EMAIL PROTECTED]> writes: > > (defun make-glyph-code (char &optional face) > > "Return a glyph code representing char CHAR with face FACE." > > (if face (logior char (lsh (face-id face) 19)) char)) ... > > I admit to not understanding a lot about glyphs, character codes, or > > Unicode. Perhaps it is silly to expect that `make-glyph-code' would work as > > proposed for Emacs 23 also. Please explain. Otherwise, if this is a bug, > > HTH. > The "19" should be "21" in the unicode branch. Actually, it should be "22". > [I'll make that change in the CVS tree, as make-glyph-code already > exists there.] I've already installed that change in emacs-unicode-2 branch. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: > I meant the only direct call to `current_column' from > redisplay_internal: > > /* If %c is in the mode line, update it if needed. */ > if (!NILP (w->column_number_displayed) > /* This alternative quickly identifies a common case >where no change is needed. */ > && !(PT == XFASTINT (w->last_point) > && XFASTINT (w->last_modified) >= MODIFF > && XFASTINT (w->last_overlay_modified) >= OVERLAY_MODIFF) > && (XFASTINT (w->column_number_displayed) > != (int) current_column ())) /* iftc */ > w->update_mode_line = Qt; > > and as I said, binding Qinhibit_point_motion_hooks just around this > part as the following patch also works for me on Mac OS X. > > Could someone check if this works on Windows for the original problem? It fixes the bug as seen on GNU/Linux (i.e., with `debug-on-error' on, I no longer see a `forward-list' error with original bug recipe; I never observed the "other operations are blocked" part of the bug report on this platform.) Let's get this into the branch. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display problem
"Drew Adams" <[EMAIL PROTECTED]> writes: > (defun make-glyph-code (char &optional face) > "Return a glyph code representing char CHAR with face FACE." > (if face (logior char (lsh (face-id face) 19)) char)) ... > I admit to not understanding a lot about glyphs, character codes, or > Unicode. Perhaps it is silly to expect that `make-glyph-code' would work as > proposed for Emacs 23 also. Please explain. Otherwise, if this is a bug, > HTH. The "19" should be "21" in the unicode branch. [I'll make that change in the CVS tree, as make-glyph-code already exists there.] -Miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: display problem
> Drew Adams wrote: > > emacs -Q > > > > (aset standard-display-table ?\014 [10 33030176 33030176 33030176 > > > > See two attached images. In Emacs 22 (all recent builds), this is > > displays correctly. In Emacs 23: 1) Each character appears as an empty > > rectangle. > > What do you mean by Emacs 23? Thinking about this might help with your > problem. What does Emacs mean by "Emacs 23"? See my mail, where "Help > Send bug report" reported the version and build information. If you understand the problem, and it is in fact user ignorance, please feel free to explain. FYI, the display-table entries were generated using Kim's proposal for a post-Emacs 22 release `make-glyph-code': (defun make-glyph-code (char &optional face) "Return a glyph code representing char CHAR with face FACE." (if face (logior char (lsh (face-id face) 19)) char)) The face used was this: (defface my-highlight 'type x w32 mac graphic) (class color)) (:box (:line-width 3 :style pressed-button))) (t (:inverse-video t))) "..." :group 'faces) The vector was generated using this: (aset standard-display-table ?\014 (vconcat "\n" (mapcar (lambda (c) (make-glyph-code c 'my-highlight)) " Section (Printable Page) "))) I admit to not understanding a lot about glyphs, character codes, or Unicode. Perhaps it is silly to expect that `make-glyph-code' would work as proposed for Emacs 23 also. Please explain. Otherwise, if this is a bug, HTH. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
> On Sun, 27 May 2007 19:21:28 -0400, Richard Stallman <[EMAIL PROTECTED]> > said: > Where is the actual call to `current_column' for which you > specifically want to bind this? Could you bind > Qinhibit_point_motion_hooks for just that? I meant the only direct call to `current_column' from redisplay_internal: /* If %c is in the mode line, update it if needed. */ if (!NILP (w->column_number_displayed) /* This alternative quickly identifies a common case where no change is needed. */ && !(PT == XFASTINT (w->last_point) && XFASTINT (w->last_modified) >= MODIFF && XFASTINT (w->last_overlay_modified) >= OVERLAY_MODIFF) && (XFASTINT (w->column_number_displayed) != (int) current_column ())) /* iftc */ w->update_mode_line = Qt; and as I said, binding Qinhibit_point_motion_hooks just around this part as the following patch also works for me on Mac OS X. Could someone check if this works on Windows for the original problem? Index: src/xdisp.c === RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v retrieving revision 1.1149.2.2 diff -c -p -r1.1149.2.2 xdisp.c *** src/xdisp.c 24 May 2007 23:21:32 - 1.1149.2.2 --- src/xdisp.c 28 May 2007 00:33:00 - *** redisplay_internal (preserve_echo_area) *** 10836,10842 int must_finish = 0; struct text_pos tlbufpos, tlendpos; int number_of_visible_frames; ! int count; struct frame *sf; int polling_stopped_here = 0; --- 10836,10842 int must_finish = 0; struct text_pos tlbufpos, tlendpos; int number_of_visible_frames; ! int count, count1; struct frame *sf; int polling_stopped_here = 0; *** redisplay_internal (preserve_echo_area) *** 10974,10979 --- 10974,10983 update_mode_lines++; } + /* Avoid invocation of point motion hooks by `current_column' below. */ + count1 = SPECPDL_INDEX (); + specbind (Qinhibit_point_motion_hooks, Qt); + /* If %c is in the mode line, update it if needed. */ if (!NILP (w->column_number_displayed) /* This alternative quickly identifies a common case *** redisplay_internal (preserve_echo_area) *** 10985,10990 --- 10989,10996 != (int) current_column ())) /* iftc */ w->update_mode_line = Qt; + unbind_to (count1, Qnil); + FRAME_SCROLL_BOTTOM_VPOS (XFRAME (w->frame)) = -1; /* The variable buffer_shared is set in redisplay_window and > Or what about binding it in `current_column_1'? Maybe that is the > right thing to do. Sorry, I'm afraid I'm not familiar enough with this matter. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
martin rudalics <[EMAIL PROTECTED]> writes: >> This patch works on Mac OS X for the original problem (without my >> previous patch). Adding specbind and unbind_to around the >> `current_column' in redisplay_internal also works. > > I'm still uncertain whether this would catch all occurrences. > > The most simple patch I can come up with is specbinding it within > `display_mode_line' since that's causing the present problems. Please > test it (no other patches needed). This patch does not work for me. I think we should go with the approach suggested by YAMAMOTO Mitsuharu, which does work. It may not be the most general approach---as you pointed out, exotic user-set mode lines might cause failures---but such situations are sufficiently rare that I think it is good enough for 22.1. Could you (or Mitsuharu) implement that and check it in? I am travelling at the moment, and cannot work on this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Infinite loop in log-edit-changelog-entries
I installed your fix. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
From: YAMAMOTO Mitsuharu <[EMAIL PROTECTED]>
Maybe you need to use specbind for the `current_column' call in
redisplay_internal instead.
*** src/xdisp.c.~1.1149.2.2.~ Fri May 25 11:00:00 2007
--- src/xdisp.c Sun May 27 22:48:48 2007
*** redisplay_internal (preserve_echo_area)
*** 10888,10893
--- 10888,10894
Fcons (make_number (redisplaying_p),
selected_frame));
++redisplaying_p;
specbind (Qinhibit_free_realized_faces, Qnil);
+ specbind (Qinhibit_point_motion_hooks, Qt);
{
Lisp_Object tail, frame;
This binds the variable across nearly all of redisplay.
That is a bit drastic as a solution; it might be right,
but it is hard to be sure.
Where is the actual call to `current_column' for which you
specifically want to bind this? Could you bind
Qinhibit_point_motion_hooks for just that?
Or what about binding it in `current_column_1'?
Maybe that is the right thing to do.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display problem
Drew Adams wrote: > emacs -Q > > (aset standard-display-table ?\014 [10 33030176 33030176 33030176 > > See two attached images. In Emacs 22 (all recent builds), this is > displays correctly. In Emacs 23: 1) Each character appears as an empty > rectangle. > What do you mean by Emacs 23? Thinking about this might help with your problem. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
display problem
emacs -Q (aset standard-display-table ?\014 [10 33030176 33030176 33030176 33030176 33030176 33030176 33030176 33030176 33030176 33030176 33030227 33030245 33030243 33030260 33030249 33030255 33030254 33030176 33030184 33030224 33030258 33030249 33030254 33030260 33030241 33030242 33030252 33030245 33030176 33030224 33030241 33030247 33030245 33030185 33030176 33030176 33030176 33030176 33030176 33030176 33030176 33030176 33030176 33030176]) See two attached images. In Emacs 22 (all recent builds), this is displays correctly. In Emacs 23: 1) Each character appears as an empty rectangle. 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 c:/Emacs-23-2007-01-02/etc/DEBUG for instructions. In GNU Emacs 23.0.0.1 (i386-mingw-nt5.1.2600) of 2007-01-01 on DTOP X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.1) --cflags -O2 -g0 -march=i386 -mtune=i686 -pipe -IC:/gnuwin32/include_ emacs -IC:/gnuwin32/lib -IC:/gnuwin32/src --ldflags -s ' 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: ENU value of $XMODIFIERS: nil locale-coding-system: cp1252 default-enable-multibyte-characters: t <><>___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
rx doc string
Hello, The documentation for `rx' currently claims `word-start' matches the end of a word. Also, it neglects to mention `symbol-start' and `symbol-end'. regards, Nikolaj Schumacher diff -du /Users/nik/svn/carbon-emacs/emacs/lisp/emacs-lisp/rx.el /tmp/buffer-content-6339OMN --- lisp/emacs-lisp/rx.el 2007-05-27 21:59:08.0 +0200 +++ lisp/emacs-lisp/rx.el 2007-05-27 21:59:26.0 +0200 @@ -725,8 +725,7 @@ matches the empty string, but only at point. `word-start', `bow' - matches the empty string, but only at the beginning or end of a - word. + matches the empty string, but only at the beginning of a word. `word-end', `eow' matches the empty string, but only at the end of a word. @@ -740,6 +739,12 @@ matches the empty string, but not at the beginning or end of a word. +`symbol-start' + matches the empty string, but only at the beginning of a symbol. + +`symbol-end' + matches the empty string, but only at the end of a symbol. + `digit', `numeric', `num' matches 0 through 9. Diff finished. Sun May 27 21:59:26 2007 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
> BTW, as far as I can tell, this is a satisfactory permanent solution, > not just a temporary hack; so we might as well check it into the trunk > too. However, we may want to overhaul the way column-number-works, > after the release, to avoid problems of this sort. Suppose someone wants to put the length of the current line into the mode-line (or the name of the current function into the frame-title). Running point-entered/-left hooks has to be avoided for all sorts of code that simply wants to "analyze" buffer text. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
> This patch works on Mac OS X for the original problem (without my > previous patch). Adding specbind and unbind_to around the > `current_column' in redisplay_internal also works. I'm still uncertain whether this would catch all occurrences. The most simple patch I can come up with is specbinding it within `display_mode_line' since that's causing the present problems. Please test it (no other patches needed). If there are more occurrences left I'll have move it to `display_mode_element'. *** xdisp.c Thu May 3 08:00:52 2007 --- xdisp.c Sun May 27 17:21:18 2007 *** *** 16664,16669 --- 16664,16667 struct it it; struct face *face; int count = SPECPDL_INDEX (); + specbind (Qinhibit_point_motion_hooks, Qt); init_iterator (&it, w, -1, -1, NULL, face_id); /* Don't extend on a previously drawn mode-line. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
Chong Yidong <[EMAIL PROTECTED]> writes:
>> Maybe you need to use specbind for the `current_column' call in
>> redisplay_internal instead.
>>
>> *** src/xdisp.c.~1.1149.2.2.~Fri May 25 11:00:00 2007
>> --- src/xdisp.c Sun May 27 22:48:48 2007
>> *** redisplay_internal (preserve_echo_area)
>> *** 10888,10893
>> --- 10888,10894
>> Fcons (make_number (redisplaying_p), selected_frame));
>> ++redisplaying_p;
>> specbind (Qinhibit_free_realized_faces, Qnil);
>> + specbind (Qinhibit_point_motion_hooks, Qt);
>>
>> {
>> Lisp_Object tail, frame;
>>
>> This patch works on Mac OS X for the original problem (without my
>> previous patch). Adding specbind and unbind_to around the
>> `current_column' in redisplay_internal also works.
>
> For safety, I would prefer to add specbind and unbind_to around the
> `current_column' in redisplay_internal, instead of binding
> Qinhibit_point_motion_hooks for the entirety of redisplay_internal.
>
> If that works, I suggest checking this into just the branch, and
> investigating further after the release.
BTW, as far as I can tell, this is a satisfactory permanent solution,
not just a temporary hack; so we might as well check it into the trunk
too. However, we may want to overhaul the way column-number-works,
after the release, to avoid problems of this sort.
Thanks.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes:
> Maybe you need to use specbind for the `current_column' call in
> redisplay_internal instead.
>
> *** src/xdisp.c.~1.1149.2.2.~ Fri May 25 11:00:00 2007
> --- src/xdisp.c Sun May 27 22:48:48 2007
> *** redisplay_internal (preserve_echo_area)
> *** 10888,10893
> --- 10888,10894
>Fcons (make_number (redisplaying_p), selected_frame));
> ++redisplaying_p;
> specbind (Qinhibit_free_realized_faces, Qnil);
> + specbind (Qinhibit_point_motion_hooks, Qt);
>
> {
> Lisp_Object tail, frame;
>
> This patch works on Mac OS X for the original problem (without my
> previous patch). Adding specbind and unbind_to around the
> `current_column' in redisplay_internal also works.
For safety, I would prefer to add specbind and unbind_to around the
`current_column' in redisplay_internal, instead of binding
Qinhibit_point_motion_hooks for the entirety of redisplay_internal.
If that works, I suggest checking this into just the branch, and
investigating further after the release.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
(2) A bug in redisplay. Somewhere Qinhibit_point_motion_hooks doesn't get bound to Qt but so far I was not able to find out where. There's evidence that the bug shows up when `column-number-mode' is enabled, `current-column' is called and triggers sgml's point-entered hook. If you can arrange to enter GDB (perhaps with a breakpoint at Fsignal) and send the backtrace, we should be able to figure out straightaway where that is. Thanks for getting a handle on this problem. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
> On Sun, 27 May 2007 14:09:07 +0200, martin rudalics <[EMAIL PROTECTED]>
> said:
>> Hmm, I couldn't test on Windows, and my previous patch worked on
>> Mac OS X (both X11 and Carbon) and Solaris for the original
>> problem.
> Hence the original problem is present on these platforms?
Yes. And there was a report that it could be reproduced on GNU/Linux.
I guess Chong was using another html-mode.
>>> I continue to have no idea how current_column gets called with
>>> Qinhibit_point_motion_hooks not bound to Qt here ...
>>
>>
>> Maybe you can find such traces by setting a breakpoint to
>> current_column with the condition `Vinhibit_point_motion_hooks ==
>> Qnil'. I found the following cases:
>>
>> pos_visible_p -> display_mode_line echo_area_display ->
>> redisplay_mode_lines -> display_mode_lines -> display_mode_line
> Thanks, I'm aware of these. I don't understand why pos_visible_p
> should be called by redisplay. For the second one I earlier tried
> to specbind Qinhibit_point_motion_hooks around it - to no avail. I
> have to retry.
Maybe you need to use specbind for the `current_column' call in
redisplay_internal instead.
*** src/xdisp.c.~1.1149.2.2.~ Fri May 25 11:00:00 2007
--- src/xdisp.c Sun May 27 22:48:48 2007
*** redisplay_internal (preserve_echo_area)
*** 10888,10893
--- 10888,10894
Fcons (make_number (redisplaying_p), selected_frame));
++redisplaying_p;
specbind (Qinhibit_free_realized_faces, Qnil);
+ specbind (Qinhibit_point_motion_hooks, Qt);
{
Lisp_Object tail, frame;
This patch works on Mac OS X for the original problem (without my
previous patch). Adding specbind and unbind_to around the
`current_column' in redisplay_internal also works.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
>>>SET_PT_BOTH (opoint, opoint_byte); > > >>still spoils everything on Windows. Commenting out that line works, >>though. > > > Hmm, I couldn't test on Windows, and my previous patch worked on Mac > OS X (both X11 and Carbon) and Solaris for the original problem. Hence the original problem is present on these platforms? Anyway, I'll have to wait what Windows XP people say about this. >>I continue to have no idea how current_column gets called with >>Qinhibit_point_motion_hooks not bound to Qt here ... > > > Maybe you can find such traces by setting a breakpoint to > current_column with the condition `Vinhibit_point_motion_hooks == > Qnil'. I found the following cases: > > pos_visible_p -> display_mode_line > echo_area_display -> redisplay_mode_lines -> display_mode_lines -> display_mode_line Thanks, I'm aware of these. I don't understand why pos_visible_p should be called by redisplay. For the second one I earlier tried to specbind Qinhibit_point_motion_hooks around it - to no avail. I have to retry. In any case this would just solve the current_column problem. There are, however, no restrictions as to what the modeline is allowed to display. Hence, this problem may raise it's ugly head whenever modeline calculations set point. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
> On Sun, 27 May 2007 11:12:35 +0200, martin rudalics <[EMAIL PROTECTED]> > said: >> Unless someone who is familiar with this matter gives a better one, >> I'd propose the following minimal and conservative change to avoid >> regression at this stage. > It's too minimal. The following >> SET_PT_BOTH (opoint, opoint_byte); > still spoils everything on Windows. Commenting out that line works, > though. Hmm, I couldn't test on Windows, and my previous patch worked on Mac OS X (both X11 and Carbon) and Solaris for the original problem. > I continue to have no idea how current_column gets called with > Qinhibit_point_motion_hooks not bound to Qt here ... Maybe you can find such traces by setting a breakpoint to current_column with the condition `Vinhibit_point_motion_hooks == Qnil'. I found the following cases: pos_visible_p -> display_mode_line echo_area_display -> redisplay_mode_lines -> display_mode_lines -> display_mode_line YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
> Unless someone who is familiar with this matter gives a better one, > I'd propose the following minimal and conservative change to avoid > regression at this stage. It's too minimal. The following > SET_PT_BOTH (opoint, opoint_byte); still spoils everything on Windows. Commenting out that line works, though. I continue to have no idea how current_column gets called with Qinhibit_point_motion_hooks not bound to Qt here ... Anyway, could people on Windows affected by this please try whether it works with Yamamoto's change or the attached one? *** indent.cMon Apr 9 09:24:48 2007 --- indent.cSun May 27 11:02:30 2007 *** *** 522,528 scan_newline (PT, PT_BYTE, BEGV, BEGV_BYTE, -1, 1); current_column_bol_cache = PT; scan = PT, scan_byte = PT_BYTE; ! SET_PT_BOTH (opoint, opoint_byte); next_boundary = scan; if (tab_width <= 0 || tab_width > 1000) tab_width = 8; --- 522,533 scan_newline (PT, PT_BYTE, BEGV, BEGV_BYTE, -1, 1); current_column_bol_cache = PT; scan = PT, scan_byte = PT_BYTE; ! /* Restore point to the original value. */ ! TEMP_SET_PT_BOTH (opoint, opoint_byte); ! /* The following commented out to avoid that SET_PT_BOTH runs point-entered ! hooks when displaying the mode-line. If this forms a regression, restore ! it and find out why these hooks are run during redisplay at all. */ ! /*** SET_PT_BOTH (opoint, opoint_byte); ***/ next_boundary = scan; if (tab_width <= 0 || tab_width > 1000) tab_width = 8; ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
