The manual also needs updating w.r.t fontification-functions
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
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
Dired sorts the file case sensitive on w32. I do not think that is what
users on w32 expects since file names are case insensitive on w32
(except for the display of the names).
In GNU Emacs 22.0.990.1 (i386-mingw-nt5.1.2600)
of 2007-05-31
___
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
Date: Mon, 04 Jun 2007 00:55:54 +0200
From: Lennart Borgman (gmail) [EMAIL PROTECTED]
Dired sorts the file case sensitive on w32. I do not think that is what
users on w32 expects since file names are case insensitive on w32
(except for the display of the names).
This is on purpose: we
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?
