Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
On Fri, Jun 01 2007, Richard Stallman wrote: > What version are you running? > If it is from CVS, is it the trunk or which branch? It was the trunk (tough not fully up-to-date) as written in my original mail (or isn't 22.1.50.n unique to the trunk?): | Note that my Emacs is not current, but from 2007-05-20 (trunk): | | > In GNU Emacs 22.1.50.3 (i686-pc-linux-gnu, GTK+ Version 2.10.6) | > of 2007-05-20 on viandante | > Windowing system distributor `The X.Org Foundation', version 11.0.70199902 | > configured using `configure '--prefix=/import/xtra/emacs/HEAD' | > '--with-gtk' '--exec-prefix=/import/xtra/emacs/HEAD-i686'' Hopefully the installed patch by YAMAMOTO Mitsuharu will fix the problem. (BTW, I lost the crashed gdb session due to a reboot so I cannot provide further info from the crashed session.) Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
On Fri, Jun 01 2007, YAMAMOTO Mitsuharu wrote: >> I think it crashed while creating the new frame; I don't recall >> seeing the frame appear, but I'm not absolutely sure. I think Emacs was creating a frame while/before my crash as well. > I think this is due to string data relocation caused by ENCODE_UTF_8 > in x_set_name_internal (GTK+ only). Thanks for analyzing the problem and providing the patch. Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
Richard Stallman <[EMAIL PROTECTED]> writes: > > Font-lock-keywords can not be set any more in the local variables > > section of a file. Use font-lock-defaults instead. > > I find the change in behavior sufficiently mysterious that I'm > not even sure this characterization is correct. > > We want to give users a simple and clear recommendation. > What should it be? Do we want to give a recommendation at all? I suggest simply keeping silent. Setting font-lock-keywords in file-local variables is a hack---it's not documented in the Emacs manual, and it's not something we want to encourage users to do, due to security concerns. Advanced users can search the web to find the workarounds discussed in this thread, or they can simply use hi-lock mode (which *is* documented in the Emacs manual). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: >> On Fri, 01 Jun 2007 10:05:41 +0900, YAMAMOTO Mitsuharu <[EMAIL >> PROTECTED]> said: > >> I think this is due to string data relocation caused by ENCODE_UTF_8 >> in x_set_name_internal (GTK+ only). > > GCPRO was missing in the previous patch. Below is a revised one. Yes. I dunno how you managed to deduce that this is the reason for the reported bug, but the patch looks like it DTRT. I've checked it into the branch and trunk for you. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
> Font-lock-keywords can not be set any more in the local variables > section of a file. Use font-lock-defaults instead. I find the change in behavior sufficiently mysterious that I'm not even sure this characterization is correct. We want to give users a simple and clear recommendation. What should it be? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
What version are you running? If it is from CVS, is it the trunk or which branch? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
I suggest not patching Emacs 22.1 at this time. Ok, I won't. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
> On Fri, 01 Jun 2007 10:05:41 +0900, YAMAMOTO Mitsuharu <[EMAIL > PROTECTED]> said: > I think this is due to string data relocation caused by ENCODE_UTF_8 > in x_set_name_internal (GTK+ only). GCPRO was missing in the previous patch. Below is a revised one. YAMAMOTO Mitsuharu [EMAIL PROTECTED] Index: src/xfns.c === RCS file: /sources/emacs/emacs/src/xfns.c,v retrieving revision 1.681 diff -c -p -r1.681 xfns.c *** src/xfns.c 24 Mar 2007 15:40:38 - 1.681 --- src/xfns.c 1 Jun 2007 03:24:43 - *** x_set_name_internal (f, name) *** 1605,1610 --- 1605,1620 int bytes, stringp; int do_free_icon_value = 0, do_free_text_value = 0; Lisp_Object coding_system; + #ifdef USE_GTK + Lisp_Object encoded_name; + struct gcpro gcpro1; + + /* As ENCODE_UTF_8 may cause GC and relocation of string data, + we use it before x_encode_text that may return string data. */ + GCPRO1 (name); + encoded_name = ENCODE_UTF_8 (name); + UNGCPRO; + #endif coding_system = Qcompound_text; /* Note: Encoding strategy *** x_set_name_internal (f, name) *** 1645,1651 #ifdef USE_GTK gtk_window_set_title (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), ! (char *) SDATA (ENCODE_UTF_8 (name))); #else /* not USE_GTK */ XSetWMName (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), &text); #endif /* not USE_GTK */ --- 1655,1661 #ifdef USE_GTK gtk_window_set_title (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), ! (char *) SDATA (encoded_name)); #else /* not USE_GTK */ XSetWMName (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), &text); #endif /* not USE_GTK */ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Elisp manual doc of `fontified' property
Richard Stallman <[EMAIL PROTECTED]> writes: > I think it should instead say something like: > > `fontified' >This property says whether the text is ready for display. If nil, >Emacs's redisplay routine will call the `fontification-function' (which >see) to prepare this part of the buffer before it is displayed. >This is used internally by jit-lock. > > The manual also needs updating w.r.t fontification-function since it says > that this var is used for font-lock, whereas it's used for jit-lock. > > Can you please fix it in Emacs 22? I corrected this text along the lines suggested by Stefan. However: > The manual also needs updating w.r.t fontification-function > since it says that this var is used for font-lock, whereas it's > used for jit-lock. In fact, fontification-functions is called from handle_fontified_prop in xdisp.c, so I don't think the current text is incorrect (I just read through it again briefly). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
> On Fri, 01 Jun 2007 00:35:33 +0200, [EMAIL PROTECTED] (Kim F. Storm) said: > I had a crash yesterday with the emacs 22 branch (not fully > up-to-date, but close): > GNU Emacs 22.0.990.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of > 2007-05-23 on kfs-lx > It is built on an up-to-date Debian Stable system. > Emacs had probably been running for approx. 20 hours, and the last > command I executed which triggered the crash was C-x 5 b (that's > ido-switch-buffer-other-frame), selected a buffer from the list, and > hit RET. > I think it crashed while creating the new frame; I don't recall > seeing the frame appear, but I'm not absolutely sure. I think this is due to string data relocation caused by ENCODE_UTF_8 in x_set_name_internal (GTK+ only). YAMAMOTO Mitsuharu [EMAIL PROTECTED] Index: src/xfns.c === RCS file: /sources/emacs/emacs/src/xfns.c,v retrieving revision 1.681 diff -c -p -r1.681 xfns.c *** src/xfns.c 24 Mar 2007 15:40:38 - 1.681 --- src/xfns.c 1 Jun 2007 01:00:51 - *** x_set_name_internal (f, name) *** 1605,1610 --- 1605,1615 int bytes, stringp; int do_free_icon_value = 0, do_free_text_value = 0; Lisp_Object coding_system; + #ifdef USE_GTK + /* As ENCODE_UTF_8 may cause GC and relocation of string data, + we use it before x_encode_text that may return string data. */ + Lisp_Object encoded_name = ENCODE_UTF_8 (name); + #endif coding_system = Qcompound_text; /* Note: Encoding strategy *** x_set_name_internal (f, name) *** 1645,1651 #ifdef USE_GTK gtk_window_set_title (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), ! (char *) SDATA (ENCODE_UTF_8 (name))); #else /* not USE_GTK */ XSetWMName (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), &text); #endif /* not USE_GTK */ --- 1650,1656 #ifdef USE_GTK gtk_window_set_title (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), ! (char *) SDATA (encoded_name)); #else /* not USE_GTK */ XSetWMName (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), &text); #endif /* not USE_GTK */ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
Chong Yidong <[EMAIL PROTECTED]> writes: > Reiner Steib <[EMAIL PROTECTED]> writes: > >> report-emacs-bug wrote: >> >>> Please describe exactly what actions triggered the bug >>> and the precise symptoms of the bug: >> >> My Emacs session which has been already running for several days >> (notebook with suspend to disk) crashed. I don't recall which command >> triggered the bug. >> >> (gdb) bt >> #0 0xb74fc4ca in memcpy () from /lib/libc.so.6 >> #1 0xb77a049e in XChangeProperty () from /usr/lib/libX11.so.6 >> #2 0xb77c0711 in XSetTextProperty () from /usr/lib/libX11.so.6 >> #3 0xb77c0793 in XSetWMIconName () from /usr/lib/libX11.so.6 >> #4 0x080d550a in x_set_name_internal (f=0xa4dd960, name=222515027) >> at ~/.../cvs-HEAD/emacs/src/xfns.c:1653 >> #5 0x0807efec in prepare_menu_bars () >> at ~/.../cvs-HEAD/emacs/src/xdisp.c:9015 >> >> ... > > I'll dig around and see what I can find, but OTOH this looks like a > crash in the X libraries, probably not related to Emacs. I had a crash yesterday with the emacs 22 branch (not fully up-to-date, but close): GNU Emacs 22.0.990.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-05-23 on kfs-lx It is built on an up-to-date Debian Stable system. Emacs had probably been running for approx. 20 hours, and the last command I executed which triggered the crash was C-x 5 b (that's ido-switch-buffer-other-frame), selected a buffer from the list, and hit RET. I think it crashed while creating the new frame; I don't recall seeing the frame appear, but I'm not absolutely sure. The value of default-frame-alist is: ((vertical-scroll-bars . right) (left . 10) (top . 50) (font . "-Misc-Fixed-Medium-R-Normal--13-120-75-75-C-80-ISO8859-1") (wait-for-wm) (tool-bar-lines . 1) (menu-bar-lines . 1) (right-fringe) (left-fringe)) My window manager is KDE Unfortunately, it happened while I was installing Debian on a new PC, so I wasn't running under gdb at the time. I've tried to reproduce the crash at least a 100 times, but haven't been able to repeat it. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Elisp manual doc of `fontified' property
I think it should instead say something like: `fontified' This property says whether the text is ready for display. If nil, Emacs's redisplay routine will call the `fontification-function' (which see) to prepare this part of the buffer before it is displayed. This is used internally by jit-lock. The manual also needs updating w.r.t fontification-function since it says that this var is used for font-lock, whereas it's used for jit-lock. Can you please fix it in Emacs 22? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
Reiner Steib <[EMAIL PROTECTED]> writes: > report-emacs-bug wrote: > >> Please describe exactly what actions triggered the bug >> and the precise symptoms of the bug: > > My Emacs session which has been already running for several days > (notebook with suspend to disk) crashed. I don't recall which command > triggered the bug. > > (gdb) bt > #0 0xb74fc4ca in memcpy () from /lib/libc.so.6 > #1 0xb77a049e in XChangeProperty () from /usr/lib/libX11.so.6 > #2 0xb77c0711 in XSetTextProperty () from /usr/lib/libX11.so.6 > #3 0xb77c0793 in XSetWMIconName () from /usr/lib/libX11.so.6 > #4 0x080d550a in x_set_name_internal (f=0xa4dd960, name=222515027) > at ~/.../cvs-HEAD/emacs/src/xfns.c:1653 > #5 0x0807efec in prepare_menu_bars () > at ~/.../cvs-HEAD/emacs/src/xdisp.c:9015 > > ... I'll dig around and see what I can find, but OTOH this looks like a crash in the X libraries, probably not related to Emacs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
report-emacs-bug wrote:
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
My Emacs session which has been already running for several days
(notebook with suspend to disk) crashed. I don't recall which command
triggered the bug.
> 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'.
--8<---cut here---start->8---
(gdb) bt
#0 0xb74fc4ca in memcpy () from /lib/libc.so.6
#1 0xb77a049e in XChangeProperty () from /usr/lib/libX11.so.6
#2 0xb77c0711 in XSetTextProperty () from /usr/lib/libX11.so.6
#3 0xb77c0793 in XSetWMIconName () from /usr/lib/libX11.so.6
#4 0x080d550a in x_set_name_internal (f=0xa4dd960, name=222515027)
at ~/.../cvs-HEAD/emacs/src/xfns.c:1653
#5 0x0807efec in prepare_menu_bars ()
at ~/.../cvs-HEAD/emacs/src/xdisp.c:9015
#6 0x0808828a in redisplay_internal (preserve_echo_area=)
at ~/.../cvs-HEAD/emacs/src/xdisp.c:10964
#7 0x08100e72 in read_char (commandflag=1, nmaps=5, maps=0xbfd21040,
prev_event=137472201, used_mouse_menu=0xbfd210f8, end_time=0x0)
at ~/.../cvs-HEAD/emacs/src/keyboard.c:2670
#8 0x08103726 in read_key_sequence (keybuf=0xbfd211a4, bufsize=30,
prompt=137472201, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1)
at ~/.../cvs-HEAD/emacs/src/keyboard.c:9215
#9 0x08105213 in command_loop_1 ()
at ~/.../cvs-HEAD/emacs/src/keyboard.c:1618
#10 0x0815b862 in internal_condition_case (bfun=0x8105080 ,
handlers=137517657, hfun=0x80ff9d0 )
at ~/.../cvs-HEAD/emacs/src/eval.c:1481
#11 0x080fee13 in command_loop_2 ()
at ~/.../cvs-HEAD/emacs/src/keyboard.c:1329
#12 0x0815b91a in internal_catch (tag=137510841,
func=0x80fedf0 , arg=137472201)
at ~/.../cvs-HEAD/emacs/src/eval.c:1222
#13 0x080ff80c in command_loop ()
at ~/.../cvs-HEAD/emacs/src/keyboard.c:1308
#14 0x080ffbab in recursive_edit_1 ()
at ~/.../cvs-HEAD/emacs/src/keyboard.c:1006
#15 0x080ffc96 in Frecursive_edit ()
at ~/.../cvs-HEAD/emacs/src/keyboard.c:1067
#16 0x080f59e5 in main (argc=3, argv=0xbfd218a4)
at ~/.../cvs-HEAD/emacs/src/emacs.c:1762
(gdb) bt full
#0 0xb74fc4ca in memcpy () from /lib/libc.so.6
No symbol table info available.
#1 0xb77a049e in XChangeProperty () from /usr/lib/libX11.so.6
No symbol table info available.
#2 0xb77c0711 in XSetTextProperty () from /usr/lib/libX11.so.6
No symbol table info available.
#3 0xb77c0793 in XSetWMIconName () from /usr/lib/libX11.so.6
No symbol table info available.
#4 0x080d550a in x_set_name_internal (f=0xa4dd960, name=222515027)
at ~/.../cvs-HEAD/emacs/src/xfns.c:1653
bytes = 6
stringp = 1
do_free_icon_value = 0
do_free_text_value = 0
icon = {
value = 0xf7a1a90 ,
encoding = 31,
format = 8,
nitems = 6
}
coding_system = 137664729
#5 0x0807efec in prepare_menu_bars ()
at ~/.../cvs-HEAD/emacs/src/xdisp.c:9015
tail =
frame =
f =
tooltip_frame = 137472201
#6 0x0808828a in redisplay_internal (preserve_echo_area=)
at ~/.../cvs-HEAD/emacs/src/xdisp.c:10964
tail =
w = (struct window *) 0xa0ccdf8
pause = 9
must_finish = 0
tlbufpos = {
charpos = 0,
bytepos = 0
}
number_of_visible_frames = 30
polling_stopped_here = 0
consider_all_windows_p = 13764376
#7 0x08100e72 in read_char (commandflag=1, nmaps=5, maps=0xbfd21040,
prev_event=137472201, used_mouse_menu=0xbfd210f8, end_time=0x0)
at ~/.../cvs-HEAD/emacs/src/keyboard.c:2670
link =
kb = (KBOARD *) 0x0
c = 137472201
local_getcjmp = {{
__jmpbuf = {-1076752632, 135895513, 137517177, 176817413, -1076752624, 0},
__mask_was_saved = 1,
__saved_mask = {
__val = {137472201, 3218214696, 267704, 3218214720, 175738212,
3218214696, 135895680, 137472201, 137517177, 1, 267704, 3218214720,
267704, 3218214936, 135619428, 137472201, 137517177, 175738212,
0 , 33971, 639, 0}
}
}}
save_jump = {{
__jmpbuf = {0, 0, 0, 0, 0, 0},
__mask_was_saved = 0,
__saved_mask = {
__val = {33971, 639, 0, 0, 298425, 175738212, 212582236, 33463,
3218214536, 135893162, 267704, 33462, 33971, 639, 1, 0, 298425,
175738212, 212582236, 33462, 3218214584, 135893162, 267696, 33461,
3218214616, 135893373, 1, 137472201, 267696, 137517177, 267704,
137472201}
}
}}
key_already_recorded = 0
tem = 3
save = 0
previous_echo_area_message = 137472201
also_record = 137472201
reread = 0
polling_stopped_here =
#8 0x08103726 in read_key_sequence (keybuf=0xbfd211a4, bufsize=30,
prompt=137472201, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1)
at ~/.../cvs-HEAD/emacs/src/keyboard
Re: cannot activate font-lock-mode
martin rudalics <[EMAIL PROTECTED]> writes:
>> (set (make-local-variable 'font-lock-keywords)
>> ! (font-lock-eval-keywords (or keywords font-lock-keywords)))
>
> Wouldn't this mean that old keywords survive a major-mode change?
> What about the companions in `font-lock-defaults'? In general I
> think all those should survive iff they have been hacked before.
It's saner to treat font-lock-keywords as an internal variable, so
that anything that wants to change font lock highlighting should use
font-lock-defaults or font-lock-add/remove-keywords. This is already
implicitly the case: according to the font-lock-keywords docstring,
Normally the [value of font-lock-keywords] would come from
`font-lock-defaults' ... You can also alter it by calling
`font-lock-add-keywords' or `font-lock-remove-keywords'...
The proximate cause for the problem seen by Francesco Potorti is that
font-lock-set-defaults recomputes the value of font-lock-keywords.
One easy way to avoid this is, as mentioned by Francesco Potorti, to
change font-lock-defaults; another way (since font-lock-add-keywords
runs font-lock-set-defaults) is:
Local variables:
eval: (font-lock-add-keywords nil '("^asdf"))
end:
Since setting font-lock-keywords in file local variables is something
of a hack in the first place, I don't think this should delay the
Emacs 22.1 release.
As for making font-lock-keywords and font-lock-defaults survive a
major-mode change if they have been hacked on before, I think that is
a bad idea, because it introduces an unnecessary complication. Any
"external" Lisp code that hacks font-lock-keywords/defaults and wants
it to persist through major-mode changes can easily arrange to
re-apply its changes.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
>>> I had this in my local variables section:
>>
>>> mode: font-lock
>>> font-lock-keywords: ("^\\S-.*:$")
>>
>>> which worked in Emacs 21, but does not work any more in Emacs 22. I
>>> solved the problem by writing instead:
>>
>>> mode: font-lock
>>> font-lock-defaults: (("^\\S-.*:$"))
>>
>> I must say that I don't know why this has changed.
>> Does the patch below fix your problem?
> No, nothing changed. If I use font-lock-keywords I get the message:
> "Toggling font-lock-mode off; better pass an explicit argument."
That looks correct: since font-lock is now enabled by default your "mode:
font-lock" might very well end up turning the mode OFF, and this is what the
message tells you.
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: shell-script mode vs. quoted apostrophe
>> +("\\(\\)'" (1 (sh-font-lock-backslash-quote)))
> Then we might do
>> +("\\(\\)" (1 (sh-font-lock-backslash)))
> as well.
Except that \' is much less common then \, so the first incurs the
additional cost of sh-font-lock-backslash-quote much less often.
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
>> (set (make-local-variable 'font-lock-keywords) >> ! (font-lock-eval-keywords (or keywords font-lock-keywords))) > Wouldn't this mean that old keywords survive a major-mode change? > What about the companions in `font-lock-defaults'? In general I > think all those should survive iff they have been hacked before. Could be. The patch is not really a fix, but more just a workaround. The source of the problem seems to have to do with the order in which the variable settings in file-local variables are procesed. Or something like that. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
> Only thing I say, if it is left as it is, maybe it should be mentioned > in the NEWS with something like: > Font-lock-keywords can not be set any more in the local variables > section of a file. Use font-lock-defaults instead. I find the change in behavior sufficiently mysterious that I'm not even sure this characterization is correct. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
Richard Stallman <[EMAIL PROTECTED]> writes: > Should this fix be installed in Emacs 22.1? > Or is it safer for us to leave that bug unfixed? I suggest not patching Emacs 22.1 at this time. First, this only affects setting font-lock-keywords in local variables, which is an advanced user activity that we generally discourage for security reasons; that is why font-lock-keywords is marked risky. Second, allowing file local variables to change font-lock-keywords seems to violate an implicit assumption made in font-lock that font-lock-keywords is managed by font-lock, and set by either major/minor modes or by higher-level variables such as font-lock-defaults. That assumption is why font-lock-set-defaults inadvertently wipes out the font-lock-keywords set by file-local variables. This may be a simple oversight made when revamping font-lock-keywords earlier in the development cycle, but this just emphasizes the fact that this behavior is delicate. So I think changing it is risky at this stage. Third, for those advanced users that want this feature, there are many ways to work around this problem: calling font-lock-add-keyword using an eval in the file variables section, using hi-lock-mode, etc. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Bug in lisp indentation
In lisp-mode the indentation of the following expression is wrong: (foo :bar :a12 :sie sume ) If I press TAB at the beginning of the last line I get: (foo :bar :a12 :sie sume ) I think this is wrong, the indentation should be as the first example. This was not the behaviour in emacs 21, neither is the beaviour of indent-region consistent with TAB. In GNU Emacs 22.0.990.1 (powerpc-apple-darwin8.9.0, Carbon Version 1.6.0) of 2007-05-31 on sin.local Windowing system distributor `Apple Inc.', version 10.4.9 configured using `configure '--enable-carbon-app' '--enable-maintainer-mode' '--without-x' '--with-jpeg' '--with-gif' '--with-png'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: en_US.UTF-8 value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: nil locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Lisp Minor modes in effect: encoded-kbd-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: C-x C-f t e s TAB RET C-n C-n TAB C-x u C-p C-p ESC C-@ C-x C-x C-x C-x ESC x e DEL i n d e SPC - r e SPC g SPC RET C-n C-n C-n C-n C-n C-n C-n C-n C-p DEL C-a C-p C-p C-n C-n C-n C-x C-s ESC x r e p o TAB r t TAB RET Recent messages: For information about the GNU Project and its goals, type C-h C-p. Undo! Mark set Making completion list... Loading help-mode...done Wrote /Users/lenst/test.lisp Making completion list... Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
>> I had this in my local variables section:
>
>> mode: font-lock
>> font-lock-keywords: ("^\\S-.*:$")
>
>> which worked in Emacs 21, but does not work any more in Emacs 22. I
>> solved the problem by writing instead:
>
>> mode: font-lock
>> font-lock-defaults: (("^\\S-.*:$"))
>
>I must say that I don't know why this has changed.
>Does the patch below fix your problem?
No, nothing changed. If I use font-lock-keywords I get the message:
"Toggling font-lock-mode off; better pass an explicit argument."
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
>Should this fix be installed in Emacs 22.1? >Or is it safer for us to leave that bug unfixed? I have no idea of the reasons or the implications of this change, nor if the correct behaviour was the previous or the current one. Only thing I say, if it is left as it is, maybe it should be mentioned in the NEWS with something like: Font-lock-keywords can not be set any more in the local variables section of a file. Use font-lock-defaults instead. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: shell-script mode vs. quoted apostrophe
> +("\\(\\)'" (1 (sh-font-lock-backslash-quote)))
Then we might do
> +("\\(\\)" (1 (sh-font-lock-backslash)))
as well.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
> (set (make-local-variable 'font-lock-keywords) > ! (font-lock-eval-keywords (or keywords font-lock-keywords))) Wouldn't this mean that old keywords survive a major-mode change? What about the companions in `font-lock-defaults'? In general I think all those should survive iff they have been hacked before. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
