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
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
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
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
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
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
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
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
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
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
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
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
12 matches
Mail list logo
