Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: >> 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). Amazing! Thanks for fixing this. -- 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: 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.
Nonetheless, the behaviour does not change. Either with your patch:
- (font-lock-eval-keywords keywords))
+ (font-lock-eval-keywords (or keywords font-lock-keywords)))
or without, the behaviour is the same. Specifically:
- if I remove the "mode: font-lock" line from the local variables, no
fontification is done
- else, if "mode: font-lock" is there:
+ if I use font-lock-keywords I get the above message
+ if I use font-lock-defaults I get fontification and no messages
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Unexpected recentering
In GNU Emacs 22.0.990 on Windows, when the cursor is moved up to the taller line, it sometimes jumps back to the center of the window. The following operation reproduces the problem. 1. emacs -q 2. C-x C-f somewhere/attached.txt ;; Read the attached file. 3. M-x show-paren-mode 4. M-x highlight-regexp RET Larger RET hi-black-hb ;; Now the highlighted line is taller than others. 5. M-: (setq scroll-step 1) 6. M-: (setq scroll-margin 1) 7. M-> 8. C-p ;; Move the cursor STEPWISE up to the highlighted line. When the ;; cursor gets there, it jumps back to the center of the window. ( Larger than the default line height ) 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 -- MIYOSHI Masanori ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Unexpected recentering
MIYOSHI Masanori <[EMAIL PROTECTED]> writes: > In GNU Emacs 22.0.990 on Windows, when the cursor is moved up to > the taller line, it sometimes jumps back to the center of the > window. This is due to a small change in paren.el that I made in April to work around the recentering-on-continued-lines problem. Recently, I checked in a better fix to the recentering problem, but at the time I did not remove the now unnecessary paren.el workaround in the branch, just the trunk. According to this bug, the workaround is problematic anyway, so I have removed it from the branch too. ___ 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
Thanks for guessing this. After your change, there was another similar bug: x_encode_text can call Lisp code, which would have needed a GCPRO. After looking at it, I realized there was no need to call x_encode_text in the GTK case. So I separated the two cases completely, which should improve things. Would people please test setting the name, in both GTK and non-GTK builds? ___ 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
Richard Stallman <[EMAIL PROTECTED]> writes: > Thanks for guessing this. > > After your change, there was another similar bug: > x_encode_text can call Lisp code, which would have needed a GCPRO. > > After looking at it, I realized there was no need to call > x_encode_text in the GTK case. So I separated the two cases > completely, which should improve things. > > Would people please test setting the name, in both GTK and non-GTK > builds? Setting the frame title works fine on both GTK and non-GTK builds. ___ 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
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). ok. ___ 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:51:12 -0400, Richard Stallman <[EMAIL PROTECTED]> > said: > After looking at it, I realized there was no need to call > x_encode_text in the GTK case. So I separated the two cases > completely, which should improve things. I'm not so familiar with GTK+, but is the call to XSetWMIconName unnecessary in the GTK+ case? Previously, it was called in both cases and that was the reason for x_encode_text in the GTK+ case. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ 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:51:12 -0400, Richard Stallman <[EMAIL PROTECTED]> >> said: > >> After looking at it, I realized there was no need to call >> x_encode_text in the GTK case. So I separated the two cases >> completely, which should improve things. > > I'm not so familiar with GTK+, but is the call to XSetWMIconName > unnecessary in the GTK+ case? Previously, it was called in both cases > and that was the reason for x_encode_text in the GTK+ case. I believe this was an oversight. However, on my Gnome desktop, it makes no observable difference. According to the Xlib specs, XSetWMIconName sets the WM_ICON_NAME window property, which is a "string that the client wants to be displayed in association with the window when it is iconified (for example, in an icon label)". However, I see the same iconfied window names for GTK and non-GTK builds, both before and after RMS's change. If we want to be safe, we can undo RMS's refactoring on the branch, going back to YAMAMOTO Mitsuharu's patch plus an additional GCPRO for x_encode_text. In either case, we should be getting on with the release! ___ 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
Setting the frame title works fine on both GTK and non-GTK builds. That is good. Please make the release tomorrow if no reason comes up why not. ___ 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: > YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: > >>> After looking at it, I realized there was no need to call >>> x_encode_text in the GTK case. So I separated the two cases >>> completely, which should improve things. >> >> I'm not so familiar with GTK+, but is the call to XSetWMIconName >> unnecessary in the GTK+ case? Previously, it was called in both cases >> and that was the reason for x_encode_text in the GTK+ case. > > I believe this was an oversight. However, on my Gnome desktop, it > makes no observable difference. According to the Xlib specs, > XSetWMIconName sets the WM_ICON_NAME window property, which is a > "string that the client wants to be displayed in association with the > window when it is iconified (for example, in an icon label)". > However, I see the same iconfied window names for GTK and non-GTK > builds, both before and after RMS's change. I looked at the GTK+ sources. Apparently, if we don't set WM_ICON_NAME ourselves, gtk_window_set_icon_name sets WM_ICON_NAME for us. So I think we are perfectly safe. ___ 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 18:42:57 -0400, Chong Yidong <[EMAIL PROTECTED]> said: > I looked at the GTK+ sources. Apparently, if we don't set > WM_ICON_NAME ourselves, gtk_window_set_icon_name sets WM_ICON_NAME > for us. So I think we are perfectly safe. But now we can't set the icon title separately from the frame title using the `icon-name' frame parameter on GTK+ builds. `icon-name' The name to use in the icon for this frame, when and if the icon appears. If this is `nil', the frame's title is used. Even with non-GTK+ builds, setting this parameter might not affect the icon title for some window managers. But at least, CDE on Solaris respects this. Maybe we can use gtk_window_set_icon_name for this purpose, but it is available only on GTK+ 2.6 and later, so some check will be necessary and it is definitely after-the-release matter. So I propose undoing the latest change for x_set_name_internal for now. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ 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: >> I looked at the GTK+ sources. Apparently, if we don't set >> WM_ICON_NAME ourselves, gtk_window_set_icon_name sets WM_ICON_NAME >> for us. So I think we are perfectly safe. > > But now we can't set the icon title separately from the frame title > using the `icon-name' frame parameter on GTK+ builds. > > So I propose undoing the latest change for x_set_name_internal for > now. I have checked in a patch to revert x_set_name_internal to the version before the latest RMS change. The GCPRO added to x_encode_text has been kept. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
