But, in emacs-unicode-2, x_encode_text uses
encode_coding_object, and that function does call Lisp for
pre-write-conversion.
Would you please install in emacs-unicode-2 whatever GCPROs
are needed in the callers of x_encode_text?
___
If my change broke something, then please undo it; but in that case,
please put in whatever GCPROs are needed for x_encode_text.
The GCPRO you added in x_encode_text was not deleted.
I know that, but we are miscommunicating. There needs to be a GCPRO
in x_set_name_internal around
Ah, now I understand what you are saying. But even if your change had
been left in place, wouldn't these GCPRO would have been needed anyway
(for the case where HAVE_GTK is false)?
I don't think there is any variable that needed protecting in the
non-HAVE_GTK case in my version of
In article [EMAIL PROTECTED], YAMAMOTO Mitsuharu [EMAIL PROTECTED] writes:
On Sun, 03 Jun 2007 12:52:26 -0400, Richard Stallman [EMAIL PROTECTED]
said:
There needs to be a GCPRO in x_set_name_internal around the calls to
x_encode_text, at least to protect the variable encoded_name. Or
On Mon, 04 Jun 2007 09:38:14 +0900, Kenichi Handa [EMAIL PROTECTED]
said:
Such GCPROs are not necessary because x_encode_text is called with
the third arg SELECTIONP == 0. Actually, there's no SELECTIONP !=
0 case in the current Emacs code.
I remember that x_encode_text had been used to
Such GCPROs are not necessary because x_encode_text is called with the
third arg SELECTIONP == 0. Actually, there's no SELECTIONP != 0 case
in the current Emacs code.
Ok.
How about deleting the arg SELECTIONP in the trunk, to avoid confusion?
YAMAMOTO Mitsuharu skrev:
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.
No, I don't think
So I propose undoing the latest change for x_set_name_internal for
now.
If my change broke something, then please undo it; but in that case,
please put in whatever GCPROs are needed for x_encode_text.
___
emacs-pretest-bug mailing list
Richard Stallman [EMAIL PROTECTED] writes:
So I propose undoing the latest change for x_set_name_internal for
now.
If my change broke something, then please undo it; but in that case,
please put in whatever GCPROs are needed for x_encode_text.
The GCPRO you added in x_encode_text
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
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
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
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
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
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
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] 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
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
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
25 matches
Mail list logo
