Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Alan Mackenzie]

Hi, Simon; Hi, Richard!

On Wed, Jul 19, 2006 at 10:22:00PM -0400, Richard Stallman wrote:
> Please DTRT.

> ------- Start of forwarded message -------
> From: "Marshall, Simon" <simon.marshall@misys.com>
> To: "'Emacs Pretest Bug (emacs-pretest-bug@gnu.org)'"
> 	<emacs-pretest-bug@gnu.org>
> Date: Wed, 19 Jul 2006 16:46:04 +0100
> MIME-Version: 1.0
> Content-Type: text/plain
> Subject: Font Lock on-the-fly misfontification in C++
> X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
> 	version=3.0.4

> Put the following in a fubar.cpp:

> class Fubar :
>   public Foo,	// Foo fontified as a type, at first
>   public Bar	// Bar fontified as a type, at first
> {
>   Foo bar(Snafu snafu,	// Types, function, variable fontified, at first
> 	  Foo foo,
> 	  Bar bar);
>   Foo bar(Snafu *snafu,	// Types, function, variable fontified, at first
> 	  Foo foo,
> 	  Bar bar);
> };

> Then emacs -Q fubar.cpp.  I see Foo, Bar and Snafu fontified as types
> even where declaring functions and variables.  The corresponding
> functions and variables are fontified correctly.  This is great!

> Then do the following.

> 1.  Append a space to the first (or second) commented line.  Bug:
> fontification of Foo (or Bar) is removed from that line.

> 2.  Append a space to the third commented line.  Bug: fontification of Foo
> and bar is removed from that line.

> 3.  Append a space to the fourth commented line.  Bug: fontification of Foo,
> bar, Snafu and snafu is removed from that line.

The problem is that after a textual change, the changed line gets
fontified as an atomic entity, i.e. yanked out of its context.  The
solution is to determine the bounds of the region to fontify by analysing
the surrounding text syntactically.  (Sorry about the number of big words
in that sentence.)  Such a determination would, in these cases, identify
exactly the comments on these lines.

There is a lot of work to be done here in CC Mode, and possibly some
enhancements are still needed in Font Lock.  I'm hoping to do the CC Mode
bit for release 5.32 (the current release is 5.31.3) within a year or
two.  In the meantime, a workaround is M-o M-o,
`font-lock-fontify-block'.

> Somewhat spookily, if you then repeat (2), then the fourth commented line
> (3) gets fontified correctly after the deferral delay.

Yes.  Changing the "public Bar" line marks all subsequent text for
deferred fontification.  This latter is done in the full syntactic
context.  Yes, it's disconcerting.

> I think this is some sort of problem with Jit Lock mode multiline
> fontification, at least for (2) and (3), since Lazy Lock mode works ok.

Isn't Lazy Lock obsolete in Emacs 22?

-- 
Alan Mackenzie (Munich, Germany)


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Stefan Monnier]

>> 3.  Append a space to the fourth commented line.  Bug: fontification of Foo,
>> bar, Snafu and snafu is removed from that line.

> The problem is that after a textual change, the changed line gets
> fontified as an atomic entity, i.e. yanked out of its context.  The

If you placed a font-lock-multiline property on the whole thing, font-lock
would know not to yank that one line out of its context.

> solution is to determine the bounds of the region to fontify by analysing
> the surrounding text syntactically.

Presumably, at the moment when Emacs fontified it correctly, it knew the
corresponding bounds, so it could have added the font-lock-multiline
property at that time, thus avoiding the need to re-determine those bounds
later when refontifying.


        Stefan

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Alan Mackenzie]

Afternoon, Stefan!

On Sun, Jul 23, 2006 at 11:11:45PM -0400, Stefan Monnier wrote:
> >> 3.  Append a space to the fourth commented line.  Bug:
> >> fontification of Foo, bar, Snafu and snafu is removed from that
> >> line.

> > The problem is that after a textual change, the changed line gets
> > fontified as an atomic entity, i.e. yanked out of its context.  The

> If you placed a font-lock-multiline property on the whole thing,
> font-lock would know not to yank that one line out of its context.

We've already been through this at some length.

I think we're agreed that it's not possible to put this property exactly
where it's needed (at the boundaries of the region to fontify, and
nowhere else) when it's needed (at the time of the change, before Font
Lock starts fontifying).

> > solution is to determine the bounds of the region to fontify by
> > analysing the surrounding text syntactically.

> Presumably, at the moment when Emacs fontified it correctly, it knew
> the corresponding bounds, so it could have added the
> font-lock-multiline property at that time, thus avoiding the need to
> re-determine those bounds later when refontifying.

The buffer was originally fontified as a whole, thus the corresponding
bounds were BOB and EOB.

When the buffer is changed, in the most general case, the bounds of the
region to be refontified are going to have to be recalculated before
fontifying.

As you are aware, I intensely dislike the notion that an entire buffer
should have to be left constantly marked with all places where it
fontification might have to straddle line boundaries, rather than
determining these things as they are needed.  I also dislike being
unable to specify an exact fontification region to Font Lock (such as
the bounds of one of Simon's comments).

>         Stefan

-- 
Alan.

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Stefan Monnier]

>> >> 3.  Append a space to the fourth commented line.  Bug:
>> >> fontification of Foo, bar, Snafu and snafu is removed from that
>> >> line.

>> > The problem is that after a textual change, the changed line gets
>> > fontified as an atomic entity, i.e. yanked out of its context.  The

>> If you placed a font-lock-multiline property on the whole thing,
>> font-lock would know not to yank that one line out of its context.

> We've already been through this at some length.

> I think we're agreed that it's not possible to put this property exactly
> where it's needed (at the boundaries of the region to fontify, and
> nowhere else) when it's needed (at the time of the change, before Font
> Lock starts fontifying).

I'm talking about this specific example, which is about refontification, not
about the original fontification.  As you know, the two problems are
closely related yet separate.

>> > solution is to determine the bounds of the region to fontify by
>> > analysing the surrounding text syntactically.

>> Presumably, at the moment when Emacs fontified it correctly, it knew
>> the corresponding bounds, so it could have added the
>> font-lock-multiline property at that time, thus avoiding the need to
>> re-determine those bounds later when refontifying.

> The buffer was originally fontified as a whole, thus the corresponding
> bounds were BOB and EOB.

Is that what is called a strawman argument?
Come on, be more constructive, please.
In the pattern rules where you add the correct highlighting, you probably
have a pretty good idea about where the relevant boundaries are.

Have you taken the time to look at my cc-awk.el patch example (I mean,
other than to try and find some superficial flaw in it).  It should give you
a pretty good idea of what the above paragraph refers to.

Check also my sample patch for problems number 2 and 3 for another example.

> When the buffer is changed, in the most general case, the bounds of the
> region to be refontified are going to have to be recalculated before
> fontifying.

You keep saying that, but that's not the case.  When *re*fontifying, you
don't need to recalculate those context bounds, as long as you were
careful to store them (e.g. in a font-lock-multiline property) when you
knew them.

> As you are aware, I intensely dislike the notion that an entire buffer
> should have to be left constantly marked with all places where it
> fontification might have to straddle line boundaries, rather than
> determining these things as they are needed.

That's OK: your likes an dislikes only bother you.  BTW the entire buffer
already needs to be left constantly marked with face information (takes
a lot more resources) as well as `fontified' information.
Try C-u C-x = a few times to get an idea.

> I also dislike being unable to specify an exact fontification region to
> Font Lock (such as the bounds of one of Simon's comments).

I don't understand what you're referring to.


        Stefan

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Alan Mackenzie]

Evening, Stefan!

On Mon, Jul 24, 2006 at 10:36:08AM -0400, Stefan Monnier wrote:
> >> >> 3.  Append a space to the fourth commented line.  Bug:
> >> >> fontification of Foo, bar, Snafu and snafu is removed from that
> >> >> line.

> >> > The problem is that after a textual change, the changed line gets
> >> > fontified as an atomic entity, i.e. yanked out of its context.  The

> >> If you placed a font-lock-multiline property on the whole thing,
> >> font-lock would know not to yank that one line out of its context.

> > We've already been through this at some length.

> > I think we're agreed that it's not possible to put this property exactly
> > where it's needed (at the boundaries of the region to fontify, and
> > nowhere else) when it's needed (at the time of the change, before Font
> > Lock starts fontifying).

> I'm talking about this specific example, which is about
> refontification, not about the original fontification.  As you know,
> the two problems are closely related yet separate.

I don't see the differences, except at a fine level of detail.  Either
operation has to go through the font-lock-keyword stuff, etc.

[ .... ]

> Come on, be more constructive, please.

I was being constructive when I submitted this patch:

    Date: Sun, 30 Apr 2006 12:48:36 +0000 (GMT)
    From: Alan Mackenzie <acm@muc.de>
    Reply-To: Alan Mackenzie <acm@muc.de>
    To: emacs-devel@gnu.org
    Subject: font-lock-extend-region-function: Final refinements.

It hasn't as yet been installed, although it would establish the
infrastructure with which the problems being discussed here could be
wholly and efficiently erradicated, without resort to obscure coding.

[ .... ]

> Have you taken the time to look at my cc-awk.el patch example (I mean,
> other than to try and find some superficial flaw in it).  It should
> give you a pretty good idea of what the above paragraph refers to.

I know what your paragraph refers to.  We've discussed it at great
length already, and I think I understood it at the time you posted it.
That approach is more obscure and more inefficient (in terms of
processor cycles) than anything I want to put into CC Mode.

Is there any chance of you adapting the font-lock-multiline mechanism so
that the properties can be applied _before_ fontification, exactly where
they are needed, rather than _after_ fontification throughout the entire
change region?

[ .... ]

> > I also dislike being unable to specify an exact fontification region
> > to Font Lock (such as the bounds of one of Simon's comments).

> I don't understand what you're referring to.

>From Simon's example:

    public Bar    // Bar fontified as a type, at first

type a space after "first".  The region I want to specify to Font Lock
is exactly this:

    public Bar    // Bar fontified as a type, at first 
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I don't think the font-lock-multiline mechanism is capable of doing
this.  The `font-lock-extend-region-function' mechanism definitely is.

Most of CC Mode's languages are not line-based.  I think it's unhelpful
to construe it's font-locking stuff in terms of buffer lines.  This is
what has led to many complaints about font locking in CC Mode (many of
which have appeared directly in bug-cc-mode).  If CC Mode can specify a
font-locking region based on language constructs (e.g. a whole
statement, a comment, a string, a declaration), these problems will
go away.  Even entries to the obfuscated C competition would get
correctly and efficiently fontified.

>         Stefan

-- 
Alan.

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Stefan Monnier]

>     Date: Sun, 30 Apr 2006 12:48:36 +0000 (GMT)
>     From: Alan Mackenzie <acm@muc.de>
>     Reply-To: Alan Mackenzie <acm@muc.de>
>     To: emacs-devel@gnu.org
>     Subject: font-lock-extend-region-function: Final refinements.

> It hasn't as yet been installed, although it would establish the
> infrastructure with which the problems being discussed here could be
> wholly and efficiently erradicated, without resort to obscure coding.

Richard put it on the backburner, claiming he hasn't seen the other thread
where you presented your point of view and then I presented mine.  We need
to start it over, but I've had other horses to flog.

> I know what your paragraph refers to.  We've discussed it at great
> length already, and I think I understood it at the time you posted it.
> That approach is more obscure and more inefficient (in terms of
> processor cycles) than anything I want to put into CC Mode.

You haven't shown any evidence of inefficiency.

> Is there any chance of you adapting the font-lock-multiline mechanism so
> that the properties can be applied _before_ fontification, exactly where
> they are needed, rather than _after_ fontification throughout the entire
> change region?

That's the thing on the backburner.  But it's still unrelated to the OP's
problem which was specifically about *re*fontification, where the
current font-lock-multiline support is all you need (and if you don't like
it, there are already several existing alternatives, see the lispref
manual).

I.e. you need both to be able to extend the region just-before fontification
(to do the initial discovery of multi-line elements) and to re-extend the
region based on info kept from the last fontification (to properly
refontify such elements).

>> > I also dislike being unable to specify an exact fontification region
>> > to Font Lock (such as the bounds of one of Simon's comments).

>> I don't understand what you're referring to.

>> From Simon's example:

>     public Bar    // Bar fontified as a type, at first

> type a space after "first".  The region I want to specify to Font Lock
> is exactly this:

>     public Bar    // Bar fontified as a type, at first 
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Oh, I see.  It seems very minor.  Why do you care?  Is the performance
difference ever noticeable?  If yes, how often?

> Most of CC Mode's languages are not line-based.

Same as 99% of the languages supported by Emacs.

> I think it's unhelpful to construe it's font-locking stuff in terms of
> buffer lines.  This is what has led to many complaints about font locking
> in CC Mode (many of which have appeared directly in bug-cc-mode).  If CC
> Mode can specify a font-locking region based on language constructs
> (e.g. a whole statement, a comment, a string, a declaration), these
> problems will go away.

Thanks to CPP and other preprocessors, there will always be cases you
can't handle.

> Even entries to the obfuscated C competition would
> get correctly and efficiently fontified.

I don't see why we should waste our time trying to handle that correctly.


        Stefan

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Alan Mackenzie]

Hi, Stefan!

On Mon, Jul 24, 2006 at 04:43:14PM -0400, Stefan Monnier wrote:
> >     Date: Sun, 30 Apr 2006 12:48:36 +0000 (GMT)
> >     From: Alan Mackenzie <acm@muc.de>
> >     Reply-To: Alan Mackenzie <acm@muc.de>
> >     To: emacs-devel@gnu.org
> >     Subject: font-lock-extend-region-function: Final refinements.

> > It hasn't as yet been installed, although it would establish the
> > infrastructure with which the problems being discussed here could be
> > wholly and efficiently erradicated, without resort to obscure coding.

> Richard put it on the backburner, claiming he hasn't seen the other
> thread where you presented your point of view and then I presented
> mine.  We need to start it over, but I've had other horses to flog.

OK.

> > I know what your paragraph refers to.  We've discussed it at great
> > length already, and I think I understood it at the time you posted it.
> > That approach is more obscure and more inefficient (in terms of
> > processor cycles) than anything I want to put into CC Mode.

> You haven't shown any evidence of inefficiency.

I think I have, in our previous discussion.  I think it's clear that
f-l-multiline properties are erased throughout the change-region, and
have to be recalculated througout the change region, at every change.
For most C-like languages, this will be expensive for large regions.  Of
all the CC languages, you can only determine f-l region boundaries
cheaply in AWK (and maybe IDL).  By contrast, f-l-extend-region only
needs to do the calculation at the two ends of the changed region, and
has to do it just as often.

This extra calculution will delay the display of fresh buffer areas when
scrolling, for example.

> > Is there any chance of you adapting the font-lock-multiline mechanism
> > so that the properties can be applied _before_ fontification, exactly
> > where they are needed, rather than _after_ fontification throughout
> > the entire change region?

> That's the thing on the backburner.  But it's still unrelated to the
> OP's problem which was specifically about *re*fontification, where the
> current font-lock-multiline support is all you need (and if you don't
> like it, there are already several existing alternatives, see the
> lispref manual).

Could you be more explicit here, please, on what these alternatives are?
I've not been aware of them up to now.

[ .... ]

> >     public Bar    // Bar fontified as a type, at first

> > type a space after "first".  The region I want to specify to Font Lock
> > is exactly this:

> >     public Bar    // Bar fontified as a type, at first 
> >                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Oh, I see.  It seems very minor.  Why do you care?  Is the performance
> difference ever noticeable?  If yes, how often?

I don't think we should be so casual about other people's processor
cycles.  The performance difference will be very noticeable if Emacs ever
comes to be run on application servers rather than individual desktops,
for example.  If "public Bar" were a 20-line declaration, the delay might
well be noticeable, especially on the sort of older PC's which still
permeate the developed world.  ;-)

> > Most of CC Mode's languages are not line-based.

> Same as 99% of the languages supported by Emacs.

Well, there's shell-script, AWK, Fortran, Makefiles, ....  But giving the
99% of languages a method to fontify syntactic units rather than crude
single (or multiple) lines can't be a bad thing.

> > I think it's unhelpful to construe it's font-locking stuff in terms
> > of buffer lines.  This is what has led to many complaints about font
> > locking in CC Mode (many of which have appeared directly in
> > bug-cc-mode).  If CC Mode can specify a font-locking region based on
> > language constructs (e.g. a whole statement, a comment, a string, a
> > declaration), these problems will go away.

> Thanks to CPP and other preprocessors, there will always be cases you
> can't handle.

Oh, tell me all about it!  ;-)  But there's a lot of stuff which isn't
CPP in a typical C buffer.

> > Even entries to the obfuscated C competition would get correctly and
> > efficiently fontified.

> I don't see why we should waste our time trying to handle that
> correctly.

Indeed, not.  But doing our stuff in a way that obfuscated C works right
at no extra cost is not a bad way to go.

>         Stefan

-- 
Alan.

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Stefan Monnier]

>> You haven't shown any evidence of inefficiency.

> I think I have, in our previous discussion.  I think it's clear that
> f-l-multiline properties are erased throughout the change-region, and
> have to be recalculated througout the change region, at every change.
> For most C-like languages, this will be expensive for large regions.  Of
> all the CC languages, you can only determine f-l region boundaries
> cheaply in AWK (and maybe IDL).  By contrast, f-l-extend-region only
> needs to do the calculation at the two ends of the changed region, and
> has to do it just as often.

I think you're comparing apples and oranges.

And even if it weren't, it's still no evidence of inefficiency (by
"evidence" I mean actual user-visible slowdown).  In all the examples I've
shown, there is no calculation to be done for f-l-multiline: just add the
property at the time when you know where to put it (i.e. you've already
done the calculation for the purpose of highlighting anyway).

> This extra calculution will delay the display of fresh buffer areas when
> scrolling, for example.

I must be missing your reference again.

>> > Is there any chance of you adapting the font-lock-multiline mechanism
>> > so that the properties can be applied _before_ fontification, exactly
>> > where they are needed, rather than _after_ fontification throughout
>> > the entire change region?

>> That's the thing on the backburner.  But it's still unrelated to the
>> OP's problem which was specifically about *re*fontification, where the
>> current font-lock-multiline support is all you need (and if you don't
>> like it, there are already several existing alternatives, see the
>> lispref manual).

> Could you be more explicit here, please, on what these alternatives are?

- jit-lock-defer-multiline
- your new font-lock after-change-function hook (currently called
  font-lock-extend-region-function)

> I've not been aware of them up to now.

Sorry to disappoint you, you knew them.

>> >     public Bar    // Bar fontified as a type, at first 
>> >                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>> Oh, I see.  It seems very minor.  Why do you care?  Is the performance
>> difference ever noticeable?  If yes, how often?

> I don't think we should be so casual about other people's processor
> cycles.  The performance difference will be very noticeable if Emacs ever
> comes to be run on application servers rather than individual desktops,
> for example.  If "public Bar" were a 20-line declaration, the delay might
> well be noticeable, especially on the sort of older PC's which still
> permeate the developed world.  ;-)

But the delay will be noticable anyway when editing the 20 line declaration
itself (which sems just as likely as editing a comment that follows it):
solving it for the comment is not enough, you need to be able to rehighlight
just the line that was touched, even if it was part of a long
multiline element.  At this point, unless you have very long lines, having
to round up to a whole number of lines is not much of a problem either.

Anyway, I'm not opposed to your proposed change to allow
non-wholeline fontification.  I doubt it'll be useful, but I can't see it
hurting either.

> Indeed, not.  But doing our stuff in a way that obfuscated C works right
> at no extra cost is not a bad way to go.

Agreed, but it's very different from what font-lock was designed to do.


        Stefan

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Stefan Monnier]

> Put the following in a fubar.cpp:

> class Fubar :
> public Foo,	// Foo fontified as a type, at first
> public Bar	// Bar fontified as a type, at first
> {
> Foo bar(Snafu snafu,	// Types, function, variable fontified, at first
> Foo foo,
> Bar bar);
> Foo bar(Snafu *snafu,	// Types, function, variable fontified, at first
> Foo foo,
> Bar bar);
> };

> Then emacs -Q fubar.cpp.  I see Foo, Bar and Snafu fontified as types
> even where declaring functions and variables.  The corresponding
> functions and variables are fontified correctly.  This is great!

> Then do the following.

> 1.  Append a space to the first (or second) commented line.  Bug:
> fontification of Foo (or Bar) is removed from that line.

> 2.  Append a space to the third commented line.  Bug: fontification of Foo
> and bar is removed from that line.

> 3.  Append a space to the fourth commented line.  Bug: fontification of Foo,
> bar, Snafu and snafu is removed from that line.

The patch below seems to fix number 2 and 3 for me.  Someone who understands
cc-fonts.el better than me and thus knows where the two "public XXX" lines
are handled could probably do a similar adjustment for them.


        Stefan


--- orig/lisp/progmodes/cc-fonts.el
+++ mod/lisp/progmodes/cc-fonts.el
@@ -1111,6 +1111,10 @@
 		;; False alarm.  Return t to go on to the next check.
 		t
 
+              (let ((beg (max (1- match-pos) (point-min))))
+                (if (< beg (line-beginning-position))
+                    (put-text-property beg (point) 'font-lock-multiline t)))
+
 	      (if (eq decl-or-cast 'cast)
 		  ;; Save the position after the previous cast so we can feed
 		  ;; it to `c-forward-decl-or-cast-1' in the next round.  That

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Alan Mackenzie]

Hi, Stefan!

On Mon, Jul 24, 2006 at 10:35:08AM -0400, Stefan Monnier wrote:

> The patch below seems to fix number 2 and 3 for me.  Someone who
> understands cc-fonts.el better than me and thus knows where the two
> "public XXX" lines are handled could probably do a similar adjustment
> for them.

At the very least, this isn't suitable for the CC Mode repository, since
font-lock-multiline hasn't (yet?) been implemented in XEmacs or older
GNU Emacsen.

I don't know cc-fonts.el that well myself, yet, but I get the feeling
that putting in f-l-multiline properties like this is, at best, only
going to converge gradually on a working solution [to the problem of CC
Mode lines being fontified out of context].  How will we know when every
case has been covered?

As I've said once or twice before, I'd prefer to calculate the f-l
change region explicitly at each change.

> 
>         Stefan
 
> 
> --- orig/lisp/progmodes/cc-fonts.el
> +++ mod/lisp/progmodes/cc-fonts.el
> @@ -1111,6 +1111,10 @@
>  		;; False alarm.  Return t to go on to the next check.
>  		t
>  
> +              (let ((beg (max (1- match-pos) (point-min))))
> +                (if (< beg (line-beginning-position))
> +                    (put-text-property beg (point) 'font-lock-multiline t)))
> +
>  	      (if (eq decl-or-cast 'cast)
>  		  ;; Save the position after the previous cast so we can feed
>  		  ;; it to `c-forward-decl-or-cast-1' in the next round.  That

-- 
Alan.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Stefan Monnier]

>> The patch below seems to fix number 2 and 3 for me.  Someone who
>> understands cc-fonts.el better than me and thus knows where the two
>> "public XXX" lines are handled could probably do a similar adjustment
>> for them.

> At the very least, this isn't suitable for the CC Mode repository, since
> font-lock-multiline hasn't (yet?) been implemented in XEmacs or older
> GNU Emacsen.

I find it quite suitable, personally, since although it indeed only fixes
the OP's problem under Emacs-22 (and Emacs-21 if you're willing to set the
font-lock-multiline variable to t), it won't hurt in Emacs-20 or XEmacs.

Better yet: you can make it work under any old font-lock implementation
(Emacs-19/20/21, XEmacs-??) by using font-lock-fontify-region-function to
obey the font-lock-multiline property.

> I don't know cc-fonts.el that well myself, yet, but I get the feeling
> that putting in f-l-multiline properties like this is, at best, only
> going to converge gradually on a working solution [to the problem of CC
> Mode lines being fontified out of context].  How will we know when every
> case has been covered?

- Check every place where you set faces
- see on which part of the buffer's text this highlighting decision depends
- add a f-l-multiline property on it if it spans more than a line
  (or even: add a f-l-multiline property on it no matter what if you prefer
  it that way).
If you've indeed checked every place where a highlighting is added, then you
know you've covered all cases.

> As I've said once or twice before, I'd prefer to calculate the f-l
> change region explicitly at each change.

I have a hard time imagining how that's going to be very different: you'll
have to check every possible situation to figure out which region to use.
How will you know that you indeed haven't missed one possible case?
Since the cases you care about are those handled by your highlighting code,
I'd expect it's easier to make sure you've covered all cases if you add the
code directly where you handle each case.


        Stefan

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Alan Mackenzie]

Morning, Stefan!

On Mon, Jul 31, 2006 at 06:03:41PM -0400, Stefan Monnier wrote:
> >> The patch below seems to fix number 2 and 3 for me.  Someone who
> >> understands cc-fonts.el better than me and thus knows where the two
> >> "public XXX" lines are handled could probably do a similar
> >> adjustment for them.

> > At the very least, this isn't suitable for the CC Mode repository,
> > since font-lock-multiline hasn't (yet?) been implemented in XEmacs
> > or older GNU Emacsen.

> I find it quite suitable, personally, since although it indeed only
> fixes the OP's problem under Emacs-22 (and Emacs-21 if you're willing
> to set the font-lock-multiline variable to t), it won't hurt in
> Emacs-20 or XEmacs.

> Better yet: you can make it work under any old font-lock
> implementation (Emacs-19/20/21, XEmacs-??) by using
> font-lock-fontify-region-function to obey the font-lock-multiline
> property.

And yes, f-l-fontify-region-function does exist in XEmacs.  :-)

As a matter of interest, does the f-l-multiline mechanism somehow work
with a _first_ fontification?  Assume CC Mode has been enhanced to use
f-l-multiline.  Say we have a buffer of C source in fundamental mode (so
there're no f-l-m properties on the buffer), and the top of the screen
is in the middle of a C construct.  If we do M-x c-mode, will the top
line get correctly fontified?

> > I don't know cc-fonts.el that well myself, yet, but I get the
> > feeling that putting in f-l-multiline properties like this is, at
> > best, only going to converge gradually on a working solution [to the
> > problem of CC Mode lines being fontified out of context].  How will
> > we know when every case has been covered?

> - Check every place where you set faces
> - see on which part of the buffer's text this highlighting decision
>   depends
> - add a f-l-multiline property on it if it spans more than a line (or
>   even: add a f-l-multiline property on it no matter what if you
>   prefer it that way).

> If you've indeed checked every place where a highlighting is added,
> then you know you've covered all cases.

Maybe you're right here.  But care would be needed to ensure that there
is some boundary between adjacent f-l-multiline regions, such as in this
sort of thing:

        foo =
        3 ;bar =
/*        ^^ */
        4 ;

> > As I've said once or twice before, I'd prefer to calculate the f-l
> > change region explicitly at each change.

> I have a hard time imagining how that's going to be very different:
> you'll have to check every possible situation to figure out which
> region to use.

:-)  You're probably right there, too!

Actually, the convergence would be from a different direction: I'd start
using (I think) c-beginning-of-statement-1, which would be reliable but
unbearably sluggish, then optimise the sluggishness away with caching
mechanisms and whatnot.

> How will you know that you indeed haven't missed one possible case?
> Since the cases you care about are those handled by your highlighting
> code, I'd expect it's easier to make sure you've covered all cases if
> you add the code directly where you handle each case.

I don't agree here; a bug report from Peter Dyballa (back in February or
March) gave this as an example:


>	/* lots of things don't have <malloc.h> */
>	/* A/UX systems include it from stdlib, from Xos.h */
>	#ifndef VMS   /* VMS hates multi-line '#if's */
>	# if !defined(ibm032)                    && \
>	     !defined(__convex__)                && \
>	     !(defined(vax) && !defined(ultrix)) && \
>	     !defined(mips)                      && \
>	     !defined(apollo)                    && \
>	     !defined(pyr)                       && \
>	     !defined(__UMAXV__)                 && \
>	     !defined(bsd43)                     && \
>	     !defined(__bsd43)                   && \
>	     !(defined(BSD) && (BSD >= 199103))  && \
>	     !defined(aux)                       && \
>	     !defined(__bsdi__)                  && \
>	     !defined(sequent)
>
> As the attached picture shows some "defined" keywords are not
> emphasised:

There is nothing in the functions currently in cc-fonts capable of
locating the opening "# if" when one of the subsequent lines is changed.
I think I'd need to put a `c-beginning-of-statement-1' thing in the bit
of code which would apply f-l-multiline.  I think I'd need to call that
function lots of times, in each fontification routine.

I think that's because we have very different conceptual models of code.
I think that having f-l-multiline code throughout the existing
cc-fonts.el would be more difficult to test (and much easier to forget
about when making other changes) than having a distinct function
c-beginning-of-font-lock-region.


>         Stefan

-- 
Alan.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Stefan Monnier]

> As a matter of interest, does the f-l-multiline mechanism somehow work
> with a _first_ fontification?  Assume CC Mode has been enhanced to use
> f-l-multiline.  Say we have a buffer of C source in fundamental mode (so
> there're no f-l-m properties on the buffer), and the top of the screen
> is in the middle of a C construct.  If we do M-x c-mode, will the top
> line get correctly fontified?

No, as explained in the lispref manual, to handle multiline elements, you
have to handle both /rehighlighting/ (e.g. Simon's problem that started this
thread) and /identification/ (e.g. what you describe here) and although the
two are closely related, they cannot be handled in the same way.

The f-l-multiline property allows you to handle /rehighlighting/ but not
/identification/.

> Maybe you're right here.  But care would be needed to ensure that there
> is some boundary between adjacent f-l-multiline regions, such as in this
> sort of thing:

>         foo =
>         3 ;bar =
> /*        ^^ */
>         4 ;

Yes, that's a problem.  I don't even think the current code handles
it right.

> I don't agree here; a bug report from Peter Dyballa (back in February or
> March) gave this as an example:

>> /* lots of things don't have <malloc.h> */
>> /* A/UX systems include it from stdlib, from Xos.h */
>> #ifndef VMS   /* VMS hates multi-line '#if's */
>> # if !defined(ibm032)                    && \
>> !defined(__convex__)                && \
>> !(defined(vax) && !defined(ultrix)) && \
>> !defined(mips)                      && \
>> !defined(apollo)                    && \
>> !defined(pyr)                       && \
>> !defined(__UMAXV__)                 && \
>> !defined(bsd43)                     && \
>> !defined(__bsd43)                   && \
>> !(defined(BSD) && (BSD >= 199103))  && \
>> !defined(aux)                       && \
>> !defined(__bsdi__)                  && \
>> !defined(sequent)
>> 
>> As the attached picture shows some "defined" keywords are not
>> emphasised:

I don't know whether the bug was that the `defined' keywords were not
originally correctly fontified (problem of /identification/), or whether
their correct highlighting was preserved when editing the text (problem of
/rehighlighting/).  If it's the former, then it's unrelated to what I'm
talking about.

> There is nothing in the functions currently in cc-fonts capable of
> locating the opening "# if" when one of the subsequent lines is changed.

If the original highlighting was correct, then when you did this original
highlighting you happened to know where the "# if" was located (even though
you don't have any code that can find it in the general case) and you could
have remembered that info by placing a font-lock-multiline property.

> I think I'd need to put a `c-beginning-of-statement-1' thing in the bit
> of code which would apply f-l-multiline.  I think I'd need to call that
> function lots of times, in each fontification routine.

You'll probably need that indeed for /identification/.


        Stefan

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Alan Mackenzie]

'Evening, Stefan!

On Tue, Aug 01, 2006 at 10:55:41AM -0400, Stefan Monnier wrote:
> > As a matter of interest, does the f-l-multiline mechanism somehow
> > work with a _first_ fontification?  Assume CC Mode has been enhanced
> > to use f-l-multiline.  Say we have a buffer of C source in
> > fundamental mode (so there're no f-l-m properties on the buffer), and
> > the top of the screen is in the middle of a C construct.  If we do
> > M-x c-mode, will the top line get correctly fontified?

> No, as explained in the lispref manual, to handle multiline elements,
> you have to handle both /rehighlighting/ (e.g. Simon's problem that
> started this thread) and /identification/ (e.g. what you describe here)
> and although the two are closely related, they cannot be handled in the
> same way.

It seems that the identification of the "safe place" (in a previously
unfontified region) needs to be done by a function essentially the same
as font-lock-extend-region-function, since f-l-multiline properties
haven't yet been applied.  In that case, what is the advantage in using
f-l-multiline at all?  It's going to be more code.  Might it, for
example, be faster? 

> The f-l-multiline property allows you to handle /rehighlighting/ but
> not /identification/.

> > Maybe you're right here.  But care would be needed to ensure that
> > there is some boundary between adjacent f-l-multiline regions, such
> > as in this sort of thing:

> >         foo =
> >         3 ;bar =
> > /*        ^^ */
> >         4 ;

> Yes, that's a problem.  I don't even think the current code handles it
> right.

Again, this problem doesn't happen with the f-l-extend-region-function
approach.

> > I don't agree here; a bug report from Peter Dyballa (back in February or
> > March) gave this as an example:

> >> /* lots of things don't have <malloc.h> */
> >> /* A/UX systems include it from stdlib, from Xos.h */
> >> #ifndef VMS   /* VMS hates multi-line '#if's */
> >> # if !defined(ibm032)                    && \
> >> !defined(__convex__)                && \
> >> !(defined(vax) && !defined(ultrix)) && \
> >> !defined(mips)                      && \
> >> !defined(apollo)                    && \
> >> !defined(pyr)                       && \
> >> !defined(__UMAXV__)                 && \
> >> !defined(bsd43)                     && \
> >> !defined(__bsd43)                   && \
> >> !(defined(BSD) && (BSD >= 199103))  && \
> >> !defined(aux)                       && \
> >> !defined(__bsdi__)                  && \
> >> !defined(sequent)

> >> As the attached picture shows some "defined" keywords are not
> >> emphasised:

> I don't know whether the bug was that the `defined' keywords were not
> originally correctly fontified (problem of /identification/), or whether
> their correct highlighting was preserved when editing the text (problem of
> /rehighlighting/).  If it's the former, then it's unrelated to what I'm
> talking about.

When you load that file (having stripped the leading "> >>" from each
line ;-), only the first 8 "defined"s get fontified.  (Up to byte 500
(jit-lock-chunk-size), perhaps?)  If you set font-lock-support-mode to
nil, the whole caboodle is (at least to begin with) fontified right.

The point I was trying to make was that locating the "safe place" can be
a long-winded slow operation - that in a piece of code like the above
(which isn't untypical), the strategy of placing f-l-multiline properties
might cause this expensive analysis to be done several times per buffer
change.

> > There is nothing in the functions currently in cc-fonts capable of
> > locating the opening "# if" when one of the subsequent lines is
> > changed.

> If the original highlighting was correct, then when you did this
> original highlighting you happened to know where the "# if" was located
> (even though you don't have any code that can find it in the general
> case) and you could have remembered that info by placing a
> font-lock-multiline property.

In the above example, the file has merely been loaded with C-x C-f.  I
suspect that the fontification goes awry where the display code splits
the buffer into ~500 byte chunks.

>         Stefan

-- 
Alan.

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Stefan Monnier]

> It seems that the identification of the "safe place" (in a previously
> unfontified region) needs to be done by a function essentially the same
> as font-lock-extend-region-function, since f-l-multiline properties
> haven't yet been applied.  In that case, what is the advantage in using
> f-l-multiline at all?

As opposed to using what?  Remember f-l-multiline is about
/rehighlighting/.  Think of it as *de*highlighting.  I.e. find the places
where there used to be a multiline element but not any more.

> It's going to be more code.  Might it, for
> example, be faster?

It's expected to be faster than recomputing this extended region in
before-change-function (since it's the only place where you can do it
otherwise: in after-change-function it's too late (unless you saved the
info somewhere) because the buffer text may not contain the pertinent
info).

>> > Maybe you're right here.  But care would be needed to ensure that
>> > there is some boundary between adjacent f-l-multiline regions, such
>> > as in this sort of thing:

>> >         foo =
>> >         3 ;bar =
>> > /*        ^^ */
>> >         4 ;

>> Yes, that's a problem.  I don't even think the current code handles it
>> right.

> Again, this problem doesn't happen with the f-l-extend-region-function
> approach.

[ Not sure what you mean by f-l-extend-region-function, BTW.  Is it the
  current f-l-extend-region-function in Emacs-CVS, or is it some future
  thingy that will be called from f-l-refontify-region?
  The current f-l-extend-region-function can't help with
  /identification/ any more than f-l-multiline. ]

I expect that the difference is not in the approaches but in their
particular implementation at a particular moment in time.

> When you load that file (having stripped the leading "> >>" from each
> line ;-), only the first 8 "defined"s get fontified.  (Up to byte 500
> (jit-lock-chunk-size), perhaps?)  If you set font-lock-support-mode to
> nil, the whole caboodle is (at least to begin with) fontified right.

I.e. it's a problem of /identification/, so of course f-l-multiline won't
help you.

> The point I was trying to make was that locating the "safe place" can be
> a long-winded slow operation - that in a piece of code like the above
> (which isn't untypical), the strategy of placing f-l-multiline properties
> might cause this expensive analysis to be done several times per buffer
> change.

I don't understand: the costly operation to find the safe place is what you
need for /identification/.  Once you've done that, the f-l-multiline
property allows you to store the resulting info (which you computed for
/identification/, not for f-l-multiline) so you won't have to recompute
it later when deciding what to dehighlight.


        Stefan

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Alan Mackenzie]

Morning, Stefan!

On Tue, Aug 01, 2006 at 03:23:54PM -0400, Stefan Monnier wrote:
> > It seems that the identification of the "safe place" (in a previously
> > unfontified region) needs to be done by a function essentially the
> > same as font-lock-extend-region-function, since f-l-multiline
> > properties haven't yet been applied.  In that case, what is the
> > advantage in using f-l-multiline at all?

> As opposed to using what?

As opposed to using (c-font-lock-expand-region BEG END OLD-LEN) called
from \(font-lock\|jit-lock\)-after-change, and also (as we thrashed out
some while ago) from font-lock-default-fontify-region.

Stefan, was that question of yours really needed?  After the substantial
amount of discussion we've had over the issue in the last few months, was
it not clear exactly what I meant?  I've been feeling frustrated at your
posts on this topic for a long time, in that you don't seem to be
carrying the context of one post forward to the next.  This means I've
got to keep restating the basis of the discussion time after time and
this makes constructive dialog very wearisome.

> Remember f-l-multiline is about /rehighlighting/.  Think of it as
> *de*highlighting.  I.e. find the places where there used to be a
> multiline element but not any more.

The f-l-multiline mechanism forces a distinction between the first
fontification and subsequent fontifications, a distinction which didn't
previously exist.  This is surely a Bad Thing, suggesting that f-l-m is
suboptimal.

> > It's going to be more code.  Might it, for example, be faster?

> It's expected to be faster than recomputing this extended region in
> before-change-function (since it's the only place where you can do it
> otherwise: in after-change-function it's too late (unless you saved the
> info somewhere) because the buffer text may not contain the pertinent
> info).

I think your logic is flawed there.  Certainly calculations will need
doing in before-change-functions, for the reason you give.  But it is not
clear that MORE calculation has to be done, rather that it has to be done
in a different place.

> >> > Maybe you're right here.  But care would be needed to ensure that
> >> > there is some boundary between adjacent f-l-multiline regions,
> >> > such as in this sort of thing:

> >> >         foo =
> >> >         3 ;bar =
> >> > /*        ^^ */
> >> >         4 ;

> >> Yes, that's a problem.  I don't even think the current code handles
> >> it right.

> > Again, this problem doesn't happen with the
> > f-l-extend-region-function approach.

> [ Not sure what you mean by f-l-extend-region-function, BTW.  Is it the
>   current f-l-extend-region-function in Emacs-CVS, or is it some future
>   thingy that will be called from f-l-refontify-region?
>   The current f-l-extend-region-function can't help with
>   /identification/ any more than f-l-multiline. ]

I mean the function that will be called with parameters BEG, END, and
OLD-LEN from \(font\|jit\)-after-change-function, and also the same (or a
similar) function that will need to be called from
font-lock-fontify-region, as you pointed out back in ?April.

[ .... ]

> > When you load that file (having stripped the leading "> >>" from each
> > line ;-), only the first 8 "defined"s get fontified.  (Up to byte 500
> > (jit-lock-chunk-size), perhaps?)  If you set font-lock-support-mode
> > to nil, the whole caboodle is (at least to begin with) fontified
> > right.

> I.e. it's a problem of /identification/, so of course f-l-multiline won't
> help you.

So a font-lock-extend-region-function is needed for a buffer's very first
fontification.  Do you agree?

This function could determine the region for future fontifications
equally well, too.  So it would seem that applying font-lock-multiline
properties is redundant - UNLESS doing so has some other benefit, such as
reducing the amount of computation.

> > The point I was trying to make was that locating the "safe place" can
> > be a long-winded slow operation - that in a piece of code like the
> > above (which isn't untypical), the strategy of placing f-l-multiline
> > properties might cause this expensive analysis to be done several
> > times per buffer change.

> I don't understand: the costly operation to find the safe place is what
> you need for /identification/.  Once you've done that, the
> f-l-multiline property allows you to store the resulting info (which
> you computed for /identification/, not for f-l-multiline) so you won't
> have to recompute it later when deciding what to dehighlight.

In the current f-l-m approach, the f-l-m properties are erased and
recalculated after every fontification:  the _identification_ is done
repeatedly.  (Is there any fundamental reason for this?  Would it not be
possible and better to allow the major mode code to decide when to
recalculate them?)  I think you're assuming that recalculating f-l-m
properties can be done as a cheap side effect of applying faces.  I'm not
at all sure this is the case.

-- 
Alan.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Stefan Monnier]

>> > It seems that the identification of the "safe place" (in a previously
>> > unfontified region) needs to be done by a function essentially the
>> > same as font-lock-extend-region-function, since f-l-multiline
>> > properties haven't yet been applied.  In that case, what is the
>> > advantage in using f-l-multiline at all?

>> As opposed to using what?

> As opposed to using (c-font-lock-expand-region BEG END OLD-LEN) called
> from \(font-lock\|jit-lock\)-after-change, and also (as we thrashed out
> some while ago) from font-lock-default-fontify-region.

Let's say your identification function (called from f-l-d-fontify-region)
is named c-font-lock-expand-region.  Then calling this function from
f-l-after-change won't do you much good because:
- you've already solved the problem of identification (and f-l-after-change
  is not a place where you can solve the problem of identification anyway).
- the problem of rehighlighting (which amounts to figuring out which part
  of the buffer *used to be* a multiline element) needs to look at the
  buffer *before* the change, not after.

> Stefan, was that question of yours really needed?

Yes, the details matter, and it was very much unclear to me what were
your assumptions.

>> Remember f-l-multiline is about /rehighlighting/.  Think of it as
>> *de*highlighting.  I.e. find the places where there used to be a
>> multiline element but not any more.

> The f-l-multiline mechanism forces a distinction between the first
> fontification and subsequent fontifications, a distinction which didn't
> previously exist.  This is surely a Bad Thing, suggesting that f-l-m is
> suboptimal.

Actually, the distinction has always been present: it's the distinction
between highlighting and dehighlighting.

>> > It's going to be more code.  Might it, for example, be faster?

>> It's expected to be faster than recomputing this extended region in
>> before-change-function (since it's the only place where you can do it
>> otherwise: in after-change-function it's too late (unless you saved the
>> info somewhere) because the buffer text may not contain the pertinent
>> info).

> I think your logic is flawed there.  Certainly calculations will need
> doing in before-change-functions, for the reason you give.

Well, no, not really:
Actually, the calculations can happen at any time between the highlighting
and before-change-function.  With font-lock-multiline, the "calculation" is
done while highlighting (because at this point you already have the info
necessary so no extra real calculation is needed).  Then this info is saved
(in the form of the font-lock-multiline text-property) to be used after
the change.

> But it is not clear that MORE calculation has to be done, rather that it
> has to be done in a different place.

Maybe you're right.  In my experience, adding the font-lock-multiline
property while highlighting has *never* required any significant
extra calculations.  The examples I've shown (in cc-awk.el and cc-fonts.el)
have been pretty typical in this respect.

>> >> > Maybe you're right here.  But care would be needed to ensure that
>> >> > there is some boundary between adjacent f-l-multiline regions,
>> >> > such as in this sort of thing:

>> >> >         foo =
>> >> >         3 ;bar =
>> >> > /*        ^^ */
>> >> >         4 ;

>> >> Yes, that's a problem.  I don't even think the current code handles
>> >> it right.

>> > Again, this problem doesn't happen with the
>> > f-l-extend-region-function approach.

>> [ Not sure what you mean by f-l-extend-region-function, BTW.  Is it the
>> current f-l-extend-region-function in Emacs-CVS, or is it some future
>> thingy that will be called from f-l-refontify-region?
>> The current f-l-extend-region-function can't help with
>> /identification/ any more than f-l-multiline. ]

> I mean the function that will be called with parameters BEG, END, and
> OLD-LEN from \(font\|jit\)-after-change-function, and also the same (or a
> similar) function that will need to be called from
> font-lock-fontify-region, as you pointed out back in ?April.

As mentioned above, I can't see how those two functions could be the same
(or similar) and yet both be useful.

> So a font-lock-extend-region-function is needed for a buffer's very first
> fontification.  Do you agree?

Yes.  It's now even in Emacs-CVS under the name
font-lock-extend-region-functions.

> This function could determine the region for future fontifications
> equally well, too.

Yes, it could be used in a before-change-function as well.

> So it would seem that applying font-lock-multiline properties is
> redundant - UNLESS doing so has some other benefit, such as reducing the
> amount of computation.

Indeed.
[ Modulo the fact that if you don't have an identification function, you
  may still be able to use the font-lock-multiline property to properly
  handle those multiline elements which you happen to identify somehow.  ]

> I think you're assuming that recalculating f-l-m properties can be done as
> a cheap side effect of applying faces.

Yes.

> I'm not at all sure this is the case.

This has been my experience in every single case.  And I think it's
no coincidence.


        Stefan

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Richard Stallman]

To speak of "GNU Emacs" and "XEmacs" gives the impression that XEmacs
has nothing to do with GNU.  Since XEmacs is a forked version of Emacs,
that is a misleading impression.  Please write "Emacs" and "XEmacs",
or else "GNU Emacs" and "GNU XEmacs".

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Alan Mackenzie]

Good morning, Richard!

On Mon, Jul 31, 2006 at 07:59:55PM -0400, Richard Stallman wrote:

> To speak of "GNU Emacs" and "XEmacs" gives the impression that XEmacs
> has nothing to do with GNU.

XEmacs isn't maintained by the GNU project.

> Since XEmacs is a forked version of Emacs, that is a misleading
> impression.  Please write "Emacs" and "XEmacs", or else "GNU Emacs"
> and "GNU XEmacs".

"Emacs", unqualified, can be ambiguous.  It can mean either (i) "an
editor of the Emacs persuasion"; or (ii) "the best editor in the world,
maintained by the GNU project".  In contexts where it is important to
emphasise that (ii) is meant, surely "GNU Emacs" is what to write.  

"XEmacs", by contrast, means what it means.  It's what its maintainers
call it, and I think they would be irritated a fair bit by "GNU XEmacs".
Also, "GNU XEmacs" is so unusual, that to write it would distract
attention from one's intented message.

-- 
Alan.

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Good morning, Richard!
>
> On Mon, Jul 31, 2006 at 07:59:55PM -0400, Richard Stallman wrote:
>
>> To speak of "GNU Emacs" and "XEmacs" gives the impression that
>> XEmacs has nothing to do with GNU.
>
> XEmacs isn't maintained by the GNU project.

Correct.

>> Since XEmacs is a forked version of Emacs, that is a misleading
>> impression.  Please write "Emacs" and "XEmacs", or else "GNU Emacs"
>> and "GNU XEmacs".
>
> "Emacs", unqualified, can be ambiguous.

No.

> It can mean either (i) "an editor of the Emacs persuasion";

In which case you can write "Emacsen".  Anyway, there are quite more
"editors of the Emacs persuasion", such as MicroEmacs and jed, and we
don't mean them when writing "Emacs", either.

If you mean "Emacs or XEmacs", write "Emacs or XEmacs".

> or (ii) "the best editor in the world, maintained by the GNU
> project".

This is redundant.

> In contexts where it is important to emphasise that (ii) is meant,
> surely "GNU Emacs" is what to write.

Please read the Emacs FAQ entry.  We don't need to go through all that
_again_.  It has been discussed to death already.

> "XEmacs", by contrast, means what it means.  It's what its
> maintainers call it.

So why would "Emacs" not mean what its maintainers call it?

Here is the FAQ entry:

(info "(efaq) Difference between Emacs and XEmacs.")

[...]

       If you want to talk about these two versions and distinguish
    them, please call them "Emacs" and "XEmacs."  To contrast "XEmacs"
    with "GNU Emacs" would be misleading, since XEmacs too has its
    origin in the work of the GNU Project.  Terms such as "Emacsen"
    and "(X)Emacs" are not wrong, but they are not very clear, so it
    is better to write "Emacs and XEmacs."

We have had lots of discussions before settling on this, so please
don't start it again.  We need to get work done.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Richard Stallman]

    "Emacs", unqualified, can be ambiguous.  It can mean either (i) "an
    editor of the Emacs persuasion"; or (ii) "the best editor in the world,
    maintained by the GNU project".  In contexts where it is important to
    emphasise that (ii) is meant, surely "GNU Emacs" is what to write.  

That is true, but if you want to write "GNU Emacs", then write "GNU XEmacs".

Every way of contrasting these two versions of GNU Emacs is partly
inaccurate.  Using "GNU Emacs" and "XEmacs", the inaccuracy is at the
expense of the GNU Project, and I don't want that.  So please use a
different way, with a different inaccuracy.

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Romain Francoise]

Richard Stallman <rms@gnu.org> writes:

> To speak of "GNU Emacs" and "XEmacs" gives the impression that XEmacs
> has nothing to do with GNU.  Since XEmacs is a forked version of Emacs,
> that is a misleading impression.  Please write "Emacs" and "XEmacs",
> or else "GNU Emacs" and "GNU XEmacs".

But XEmacs is not a GNU package.

Maybe we should call it "non-GNU XEmacs" instead... ;-)

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Richard Stallman]

    > To speak of "GNU Emacs" and "XEmacs" gives the impression that XEmacs
    > has nothing to do with GNU.  Since XEmacs is a forked version of Emacs,
    > that is a misleading impression.  Please write "Emacs" and "XEmacs",
    > or else "GNU Emacs" and "GNU XEmacs".

    But XEmacs is not a GNU package.

It is a modified version of a GNU package.

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Aidan Kehoe]

 Ar an t-aonú lá is triochad de mí Iúil, scríobh Richard Stallman: 

 > To speak of "GNU Emacs" and "XEmacs" gives the impression that XEmacs has
 > nothing to do with GNU. Since XEmacs is a forked version of Emacs, that
 > is a misleading impression. Please write "Emacs" and "XEmacs", or else
 > "GNU Emacs" and "GNU XEmacs".

Substantial parts of the code of XEmacs are not copyrighted by the FSF, the
legal entity stewarding the GNU project, and this is almost certain to
remain so. The XEmacs project members do not consider the advancement of the
GNU project as a significant part of our job. We use the term XEmacs, we
never use the term GNU XEmacs.

While there is an argument for the term GNU XEmacs, it is not stronger than
the argument for the term FSF Emacs; we have stopped using the latter out of
respect for the maintainers of GNU Emacs. If you want to be wilfully
disrespectful to the members of the XEmacs project, use GNU XEmacs to refer
to the editor; otherwise, the established usage, XEmacs on its own, will
raise fewer hackles and doesn’t require you to think extra hard every time
you mention the editor. 

-- 
Santa Maradona, priez pour moi!

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[David Kastrup]

Aidan Kehoe <kehoea@parhasard.net> writes:

>  Ar an t-aonú lá is triochad de mí Iúil, scríobh Richard Stallman: 
>
>  > To speak of "GNU Emacs" and "XEmacs" gives the impression that XEmacs has
>  > nothing to do with GNU. Since XEmacs is a forked version of Emacs, that
>  > is a misleading impression. Please write "Emacs" and "XEmacs", or else
>  > "GNU Emacs" and "GNU XEmacs".
>
> Substantial parts of the code of XEmacs are not copyrighted by the
> FSF, the legal entity stewarding the GNU project, and this is almost
> certain to remain so. The XEmacs project members do not consider the
> advancement of the GNU project as a significant part of our job. We
> use the term XEmacs, we never use the term GNU XEmacs.

And we use the term "Emacs" for referring to Emacs.  When the term
"GNU Emacs" is used, it is to draw attention to the GNU project and
the part Emacs plays within it, not to insinuate that the scope of
Emacs is supposed to be restricted to within GNU.

Contrasting "XEmacs" and "GNU Emacs" is therefore misleading.  The
proper names of the editors are "Emacs" and "XEmacs".  "GNU Emacs" is
a distinction, but not one differentiating Emacs and XEmacs.

> If you want to be wilfully disrespectful to the members of the
> XEmacs project, use GNU XEmacs to refer to the editor; otherwise,
> the established usage, XEmacs on its own, will raise fewer hackles
> and doesn’t require you to think extra hard every time you mention
> the editor.

The same goes for Emacs.  Here is the passage from the Emacs FAQ:

(info "(efaq) Difference between Emacs and XEmacs")

       If you want to talk about these two versions and distinguish
    them, please call them "Emacs" and "XEmacs."  To contrast "XEmacs"
    with "GNU Emacs" would be misleading, since XEmacs too has its
    origin in the work of the GNU Project.  Terms such as "Emacsen"
    and "(X)Emacs" are not wrong, but they are not very clear, so it
    is better to write "Emacs and XEmacs."

I don't think it too onerous to expect that XEmacs developers call
Emacs "Emacs".  The stance that "Emacs" is supposed to mean "Emacs and
XEmacs" and only "GNU Emacs" is supposed to carry the meaning "Emacs"
is not really helpful, not even to XEmacs users.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Aidan Kehoe]

 Ar an dara lá de mí Lúnasa, scríobh David Kastrup: 

 > And we use the term "Emacs" for referring to Emacs.

 > When the term "GNU Emacs" is used, it is to draw attention to the GNU
 > project and the part Emacs plays within it, not to insinuate that the
 > scope of Emacs is supposed to be restricted to within GNU.

No-one uses “GNU Emacs” to insinuate that the editor is supposed to be
restricted to within the GNU project. What gave you that impression? 

 > Contrasting "XEmacs" and "GNU Emacs" is therefore misleading.  The
 > proper names of the editors are "Emacs" and "XEmacs". 

Then GNU Emacs should call itself just “Emacs” on its startup screen, as
XEmacs calls itself “XEmacs” on its startup screen.  

 > "GNU Emacs" is a distinction, but not one differentiating Emacs and
 > XEmacs.

I disagree. 

 > [...] I don't think it too onerous to expect that XEmacs developers call
 > Emacs "Emacs". 

Active developers call your branch of the editor GNU Emacs! It is
hypocritical at best to object when others do likewise. 

 > The stance that "Emacs" is supposed to mean "Emacs and
 > XEmacs" and only "GNU Emacs" is supposed to carry the meaning "Emacs" is
 > not really helpful, not even to XEmacs users.

XEmacs still supports (emacs-version); lots of our documentation uses
“emacs” to refer to any version of the editor, something the GNU branch
rarely does (that is, it rarely admits that the documentation may be
applicable to other branches.). I personally would prefer to do this less; I
changed the title bar to say “XEmacs” rather than “emacs” partly because of
that. 

-- 
Santa Maradona, priez pour moi!

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[David Kastrup]

Aidan Kehoe <kehoea@parhasard.net> writes:

>  Ar an dara lá de mí Lúnasa, scríobh David Kastrup: 
>
>  > And we use the term "Emacs" for referring to Emacs.
>
>  > When the term "GNU Emacs" is used, it is to draw attention to the
>  > GNU project and the part Emacs plays within it, not to insinuate
>  > that the scope of Emacs is supposed to be restricted to within
>  > GNU.
>
> No-one uses “GNU Emacs” to insinuate that the editor is supposed to
> be restricted to within the GNU project. What gave you that
> impression?

Why else use it for distinguishing between Emacs and XEmacs?  Their
relation to the GNU project is similar.  Many parts of GNU are not
copyrighted by the FSF, including software carrying "GNU" in its
name.

>  > Contrasting "XEmacs" and "GNU Emacs" is therefore misleading.
>  > The proper names of the editors are "Emacs" and "XEmacs".
>
> Then GNU Emacs should call itself just “Emacs” on its startup
> screen, as XEmacs calls itself “XEmacs” on its startup screen.

I repeat: when the term "GNU Emacs" is used, it is to draw attention
to the GNU project and the part Emacs plays within it.

>  > "GNU Emacs" is a distinction, but not one differentiating Emacs
>  > and XEmacs.
>
> I disagree.

I am afraid that I consider the opinion of the creator of Emacs more
relevant than yours with regard on whether Emacs should be allowed to
be named Emacs.  Of course, you are free to call XEmacs whatever you
like.  But the name "Emacs" is already taken.

>  > [...] I don't think it too onerous to expect that XEmacs
>  > developers call Emacs "Emacs".
>
> Active developers call your branch of the editor GNU Emacs! It is
> hypocritical at best to object when others do likewise.

I repeat: When the term "GNU Emacs" is used, it is to draw attention
to the GNU project and the part Emacs plays within it, not to
insinuate that the scope of Emacs is supposed to be restricted to
within GNU.

>  > The stance that "Emacs" is supposed to mean "Emacs and XEmacs"
>  > and only "GNU Emacs" is supposed to carry the meaning "Emacs" is
>  > not really helpful, not even to XEmacs users.
>
> XEmacs still supports (emacs-version); lots of our documentation
> uses “emacs” to refer to any version of the editor, something the
> GNU branch rarely does (that is, it rarely admits that the
> documentation may be applicable to other branches.).

Don't you find it silly to blame upstream for your failures to update
the documentation in order to reflect the fork?

> I personally would prefer to do this less; I changed the title bar
> to say “XEmacs” rather than “emacs” partly because of that.

A perfectly reasonable stance.

I'll give you a historical document which might make it clearer to you
why
a) the documentation of XEmacs has not from early on bothered to
distinguish between Lucid Emacs and Emacs.
b) RMS is not too enthused about XEmacs documentation and developers
trying to hijack the name of Emacs to mean anything but Emacs.

<URL:http://groups.google.com/group/gnu.emacs.help/msg/764864608067f821?as_q=&as_umsgid=9302242219.AA14714@inferno.lucid.com>

Note that this is all water under the draw bridge now, but
historically, the creators of Lucid Emacs laid claim to and hijacked
the name Emacs (without any further qualifications) for their own fork
of it.

Their claim to be the legitimate successor of interest to Emacs was
what has fueled the idea that "Emacs" somehow is supposed be a proper
name of XEmacs.  These claims were made in order to cause developers
to move over to Lucid Emacs.

XEmacs is not Emacs, but a fork of it.  The license of Emacs permits
forking its code, it does not permit forking its name.

That is a bit of the background why the usage put forth in the Emacs
FAQ should be just "Emacs" and "XEmacs".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Aidan Kehoe]

 Ar an dara lá de mí Lúnasa, scríobh David Kastrup: 

 > >  > When the term "GNU Emacs" is used, it is to draw attention to the
 > >  > GNU project and the part Emacs plays within it, not to insinuate
 > >  > that the scope of Emacs is supposed to be restricted to within GNU.
 > >
 > > No-one uses “GNU Emacs” to insinuate that the editor is supposed to
 > > be restricted to within the GNU project. What gave you that
 > > impression?
 > 
 > Why else use it for distinguishing between Emacs and XEmacs?  

Because it has currency as a term for a specific editor and code base, and
it’s clear. I refer you to http://www.gnu.org/gnu/rms-lisp.html: RMS uses
“Emacs” without qualification thirteen times to refer to something other
than GNU Emacs, and uses “GNU Emacs” when he wants to underline that he’s
talking about that editor, not just when he’s underlining that it’s part of
the GNU project.

“Emacs” on its own is ambiguous; that this ambiguity is often resolved by
context on emacs-devel@gnu.org does not contradict that. 

 > Their relation to the GNU project is similar. Many parts of GNU are not
 > copyrighted by the FSF, including software carrying "GNU" in its name.

XEmacs doesn’t carry GNU in its name, no more than GNU Emacs carries
“Electrotechnical Laboratory Japan” in its name. 

 > >  > Contrasting "XEmacs" and "GNU Emacs" is therefore misleading.
 > >  > The proper names of the editors are "Emacs" and "XEmacs".
 > >
 > > Then GNU Emacs should call itself just “Emacs” on its startup
 > > screen, as XEmacs calls itself “XEmacs” on its startup screen.
 > 
 > I repeat: when the term "GNU Emacs" is used, it is to draw attention
 > to the GNU project and the part Emacs plays within it.

I refer you to the link above, where “GNU Emacs” is used to distinguish that
version written subsequent to Gosling Emacs in C and maintained by RMS from
other versions of the editor.

 > >  > "GNU Emacs" is a distinction, but not one differentiating Emacs
 > >  > and XEmacs.
 > >
 > > I disagree.
 > 
 > I am afraid that I consider the opinion of the creator of Emacs more
 > relevant than yours with regard on whether Emacs should be allowed to
 > be named Emacs.

I said nothing whatsoever about allowing anyone to name anything. 
 
 > Of course, you are free to call XEmacs whatever you like. But the name
 > "Emacs" is already taken.

Happily, we call it XEmacs. 

 > > [...] XEmacs still supports (emacs-version); lots of our documentation
 > > uses “emacs” to refer to any version of the editor, something the GNU
 > > branch rarely does (that is, it rarely admits that the documentation
 > > may be applicable to other branches.).
 > 
 > Don't you find it silly to blame upstream for your failures to update
 > the documentation in order to reflect the fork?

I find it helpful to indicate that functionality, while available in XEmacs,
is not limited to it. I’m not blaming anyone for anything. 

 > Note that this is all water under the draw bridge now, but
 > historically, the creators of Lucid Emacs laid claim to and hijacked
 > the name Emacs (without any further qualifications) for their own fork
 > of it.

As Stallman hijacked the name of TECO Emacs (which editor he did not come up
with on his own, remember) before them. Lucid is long dead, Ben Wing is
working intermittently at best, the editor has been called XEmacs for a
decade, the documentation no longer tries to confuse the issue; I have
relatively little sympathy for paranoia on this. 

-- 
Santa Maradona, priez pour moi!

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[David Kastrup]

Aidan Kehoe <kehoea@parhasard.net> writes:

>  Ar an dara lá de mí Lúnasa, scríobh David Kastrup: 
>
>  > Note that this is all water under the draw bridge now, but
>  > historically, the creators of Lucid Emacs laid claim to and
>  > hijacked the name Emacs (without any further qualifications) for
>  > their own fork of it.
>
> As Stallman hijacked the name of TECO Emacs (which editor he did not
> come up with on his own, remember) before them.

Please get your history right, for example by looking at
<URL:http://www.jwz.org/doc/emacs-timeline.html>.  The name "Emacs"
came first into use for a system coauthored by Richard.

> Lucid is long dead, Ben Wing is working intermittently at best, the
> editor has been called XEmacs for a decade, the documentation no
> longer tries to confuse the issue; I have relatively little sympathy
> for paranoia on this.

The current XEmacs manual begins with:

    The XEmacs Editor
    *****************

    XEmacs is the extensible, customizable, self-documenting real-time
    display editor.  This Info file describes how to edit with Emacs and
    some of how to customize it, but not how to extend it.  It corresponds
    to XEmacs version 21.0.

As you can see, the name "Emacs" is still used to refer to XEmacs.  It
is also used interchangeably in the manual to refer to XEmacs:

    Important General Concepts
    * Frame::      How to interpret what you see on the screen.
    * Keystrokes::  Keyboard gestures XEmacs recognizes.
    * Pull-down Menus::
                    The XEmacs Pull-down Menus available under X.
    * Entering Emacs::
                    Starting Emacs from the shell.
    * Exiting::     Stopping or killing XEmacs.
    * Command Switches::

So I can't really say that "the documentation no longer tries to
confuse the issue" is accurate, whether by oversight or design.

If you take a look at the node "Distribution", for example you can
read

    Getting Other Versions of Emacs
    ===============================

    The Free Software Foundation's version of Emacs (called "FSF
    Emacs" in this manual and often referred to as "GNU Emacs") is
    available by anonymous FTP from `prep.ai.mit.edu'.

So your contention that the "documentation no longer tries to confuse
the issue" is simply wrong.  Whether this is by intent, by sloppiness,
or because nobody bothers updating or correcting the manuals from
XEmacs 21.4, the stable version, I don't know.

But there are certainly more than enough instances where the XEmacs
manual suggests that XEmacs is a version rather than a fork of Emacs.

For example, in the node "Bugs", in "How to report a Bug", there is
only the name "Emacs" used throughout the whole node.

It ends like this:

       For possible display bugs, it is important to report the terminal
    type (the value of environment variable `TERM'), the complete termcap
    entry for the terminal from `/etc/termcap' (since that file is not
    identical on all machines), and the output that Emacs actually sent to
    the terminal.  The way to collect this output is to execute the Lisp
    expression:

         (open-termscript "~/termscript")

    using `Meta-<ESC>' or from the `*scratch*' buffer just after starting
    Emacs.  From then on, all output from Emacs to the terminal will be
    written in the specified termscript file as well, until the Emacs
    process is killed.  If the problem happens when Emacs starts up, put
    this expression into your init file so that the termscript file will be
    open when Emacs displays the screen for the first time.  *Note Init
    File::. Be warned: it is often difficult, and sometimes impossible, to
    fix a terminal-dependent bug without access to a terminal of the type
    that stimulates the bug.

       The newsgroup `comp.emacs.xemacs' may be used for bug reports, other
    discussions and requests for assistance.

       If you don't have access to this newgroup, you can subscribe to the
    mailing list version: the newsgroup is bidirectionally gatewayed into
    the mailing list `xemacs@xemacs.org'.

       To be added or removed from this mailing list, send mail to
    `xemacs-request@xemacs.org'.  Do not send requests for addition to the
    mailing list itself.


This implies that "Emacs" is synonymous to the editor maintained by
the XEmacs developers: if you have a problem with Emacs, contact the
XEmacs mailing lists.

So yes, there is still a lot of confusing material around that tries
to sell off XEmacs as "the" Emacs, and even in the core documentation
of XEmacs.  So I don't think your characterization as "paranoia"
appropriate: there are good reasons still for Emacs developers to
cleanly distinguish between Emacs and XEmacs.  It is our project
policy, it is mentioned in the Emacs FAQ, and I personally consider it
reasonable.  I considered it reasonable even before checking the
current XEmacs documentation and seeing that it was much more
off-kilter than I thought it to be.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Aidan Kehoe]

 Ar an dara lá de mí Lúnasa, scríobh David Kastrup: 

 > > As Stallman hijacked the name of TECO Emacs (which editor he did not
 > > come up with on his own, remember) before them.
 > 
 > Please get your history right, for example by looking at
 > <URL:http://www.jwz.org/doc/emacs-timeline.html>.  The name "Emacs"
 > came first into use for a system coauthored by Richard.

Please read what I write before replying to it.

 > [...] As you can see, the name "Emacs" is still used to refer to XEmacs.

... in contexts where it shares behaviour with GNU Emacs. As I wrote before.
If it’s used to describe XEmacs-specific behaviouir, that’s something we
need to fix. 

-- 
Santa Maradona, priez pour moi!

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[David Kastrup]

Aidan Kehoe <kehoea@parhasard.net> writes:

>  Ar an dara lá de mí Lúnasa, scríobh David Kastrup: 
>
>  > > As Stallman hijacked the name of TECO Emacs (which editor he did not
>  > > come up with on his own, remember) before them.
>  > 
>  > Please get your history right, for example by looking at
>  > <URL:http://www.jwz.org/doc/emacs-timeline.html>.  The name "Emacs"
>  > came first into use for a system coauthored by Richard.
>
> Please read what I write before replying to it.
>
>  > [...] As you can see, the name "Emacs" is still used to refer to XEmacs.
>
> ... in contexts where it shares behaviour with GNU Emacs.

But it doesn't.  That's the point.  It shares, at best, behavior with
an ancient version of Emacs.  XEmacs developers can't be reasonably
expected to track the progress of Emacs development and change those
instances of "Emacs" in their manual whenever Emacs has moved past the
state described in the XEmacs manual.  And it would be nonsensical to
do a tracking project of this kind.  The XEmacs manual describes
XEmacs and tracks XEmacs development, and so there is little point in
referring to "Emacs" when Emacs might do things completely different.

The XEmacs Lisp reference also states right in the beginning under
"Caveats":

       This manual was originally written for FSF Emacs 19 and was
    updated by Ben Wing (ben@xemacs.org) for Lucid Emacs 19.10 and
    later for XEmacs 19.12, 19.13, 19.14, and 20.0.  It was further
    updated by the XEmacs Development Team for 19.15 and 20.1.  Please
    send comments and corrections relating to XEmacs-specific portions
    of this manual to xemacs@xemacs.org

> As I wrote before.  If it’s used to describe XEmacs-specific
> behaviouir, that’s something we need to fix.

And who is going to track changes in Emacs, so that he can keep up
with fixing the references?  Really, this makes no sense.  Anyway, I
quoted from introductory material and explanatory material, the stuff
that you reference as a newbie if you want to figure out things.  And
whether or not the mind frame of active XEmacs developers has moved on
beyond the time where this material was written, it is still out there
and teaching people who read it.

I don't really think you should protest too much if Emacs developers
have decided to maintain the distinction between Emacs and XEmacs in
the sort of documentation they are responsible for, and that includes
the documentation of code placed within Emacs and distributed as part
as Emacs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Stefan Monnier]

People, can we move on to something else?  It's not like someone's going to
change his mind anyway.  The Emacs camp wants to call their editor "Emacs"
and the XEmacs camp wants to call their editor "XEmacs".  That's that.
Now whether you want to respect their wishes is up to you.


        Stefan "who personally prefers to use Emacs on GNU/Linux
                rather than GNU Emacs on Linux"


>>>>> "David" == David Kastrup <dak@gnu.org> writes:

> Aidan Kehoe <kehoea@parhasard.net> writes:
>> Ar an dara lá de mí Lúnasa, scríobh David Kastrup: 
>> 
>> > And we use the term "Emacs" for referring to Emacs.
>> 
>> > When the term "GNU Emacs" is used, it is to draw attention to the
>> > GNU project and the part Emacs plays within it, not to insinuate
>> > that the scope of Emacs is supposed to be restricted to within
>> > GNU.
>> 
>> No-one uses “GNU Emacs” to insinuate that the editor is supposed to
>> be restricted to within the GNU project. What gave you that
>> impression?

> Why else use it for distinguishing between Emacs and XEmacs?  Their
> relation to the GNU project is similar.  Many parts of GNU are not
> copyrighted by the FSF, including software carrying "GNU" in its
> name.

>> > Contrasting "XEmacs" and "GNU Emacs" is therefore misleading.
>> > The proper names of the editors are "Emacs" and "XEmacs".
>> 
>> Then GNU Emacs should call itself just “Emacs” on its startup
>> screen, as XEmacs calls itself “XEmacs” on its startup screen.

> I repeat: when the term "GNU Emacs" is used, it is to draw attention
> to the GNU project and the part Emacs plays within it.

>> > "GNU Emacs" is a distinction, but not one differentiating Emacs
>> > and XEmacs.
>> 
>> I disagree.

> I am afraid that I consider the opinion of the creator of Emacs more
> relevant than yours with regard on whether Emacs should be allowed to
> be named Emacs.  Of course, you are free to call XEmacs whatever you
> like.  But the name "Emacs" is already taken.

>> > [...] I don't think it too onerous to expect that XEmacs
>> > developers call Emacs "Emacs".
>> 
>> Active developers call your branch of the editor GNU Emacs! It is
>> hypocritical at best to object when others do likewise.

> I repeat: When the term "GNU Emacs" is used, it is to draw attention
> to the GNU project and the part Emacs plays within it, not to
> insinuate that the scope of Emacs is supposed to be restricted to
> within GNU.

>> > The stance that "Emacs" is supposed to mean "Emacs and XEmacs"
>> > and only "GNU Emacs" is supposed to carry the meaning "Emacs" is
>> > not really helpful, not even to XEmacs users.
>> 
>> XEmacs still supports (emacs-version); lots of our documentation
>> uses “emacs” to refer to any version of the editor, something the
>> GNU branch rarely does (that is, it rarely admits that the
>> documentation may be applicable to other branches.).

> Don't you find it silly to blame upstream for your failures to update
> the documentation in order to reflect the fork?

>> I personally would prefer to do this less; I changed the title bar
>> to say “XEmacs” rather than “emacs” partly because of that.

> A perfectly reasonable stance.

> I'll give you a historical document which might make it clearer to you
> why
> a) the documentation of XEmacs has not from early on bothered to
> distinguish between Lucid Emacs and Emacs.
> b) RMS is not too enthused about XEmacs documentation and developers
> trying to hijack the name of Emacs to mean anything but Emacs.

> <URL:http://groups.google.com/group/gnu.emacs.help/msg/764864608067f821?as_q=&as_umsgid=9302242219.AA14714@inferno.lucid.com>

> Note that this is all water under the draw bridge now, but
> historically, the creators of Lucid Emacs laid claim to and hijacked
> the name Emacs (without any further qualifications) for their own fork
> of it.

> Their claim to be the legitimate successor of interest to Emacs was
> what has fueled the idea that "Emacs" somehow is supposed be a proper
> name of XEmacs.  These claims were made in order to cause developers
> to move over to Lucid Emacs.

> XEmacs is not Emacs, but a fork of it.  The license of Emacs permits
> forking its code, it does not permit forking its name.

> That is a bit of the background why the usage put forth in the Emacs
> FAQ should be just "Emacs" and "XEmacs".

> -- 
> David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Aidan Kehoe]

 Ar an dara lá de mí Lúnasa, scríobh Stefan Monnier: 

 > People, can we move on to something else?  It's not like someone's going to
 > change his mind anyway.  The Emacs camp wants to call their editor "Emacs"
 > and the XEmacs camp wants to call their editor "XEmacs".  That's that.

That’s not that. RMS and other developers of his branch of the editor
regularly call it both Emacs and GNU Emacs in many and varied contexts and
express the opinion that other people should avoid the second term in
a recent, cited context where RMS has used it (that is, to distinguish it
from other versions of the editor.) 

 > Now whether you want to respect their wishes is up to you.

Also a matter of individual choice is one’s opinion on what telling people
to do what you say, not what you do is best described as.

-- 
Santa Maradona, priez pour moi!

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> People, can we move on to something else?  It's not like someone's
> going to change his mind anyway.  The Emacs camp wants to call their
> editor "Emacs" and the XEmacs camp wants to call their editor
> "XEmacs".  That's that.  Now whether you want to respect their
> wishes is up to you.

I consider it reasonable to adhere to the conventions of the Emacs
camp when putting code into the Emacs code base.  And the
reasonability of our documented conventions for this was questioned,
and I chose to answer those questions.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Richard Stallman]

For distinguishing the two versions I write "Emacs" and "XEmacs",
because the context shows we are talking about these two variants
of the original GNU Emacs.

In other contexts, there is no need to refer to the two variants but
there is a need to connect Emacs with the GNU system.  There I write
"GNU Emacs".

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Alan Mackenzie]

Morning, Richard!

On Wed, Aug 02, 2006 at 05:20:12PM -0400, Richard Stallman wrote:
> For distinguishing the two versions I write "Emacs" and "XEmacs",
> because the context shows we are talking about these two variants
> of the original GNU Emacs.

This leaves a difficulty when there is no context.  For example, you
might find this in an overview of editors:

(1)  "Most free editors do syntax highlighting.  In vim, ........  In
     Emacs, syntax highlighting is usually called "font locking"."

A bit lower down in the same article, there might be ....

(2)  "In some editors you can also highlight a region of text explicitly.
     In vim you do ......., in Emacs you can type M-o M-o."

> In other contexts, there is no need to refer to the two variants but
> there is a need to connect Emacs with the GNU system.  There I write
> "GNU Emacs".

In paragraph (1), it is clear that "Emacs" includes XEmacs.  To
substitute "Emacs and XEmacs" would make the sentence clumsy and
less readable, and wouldn't be helpful to the target readership.

In paragraph (2), the context of bare "Emacs" having previously been set
to "generic Emacs", clarity demands the substitution of "GNU Emacs".

I believe "GNU Emacs" is used mainly for unambiguous identification
rather than connecting it with the GNU system - much like "John of
Gaunt" is used to clarify which John you're talking about rather than to
associate him with the town of Gent in Belgium.

The root of the problem is that XEmacs is neither identical with Emacs
nor totally independent from it.  Until such time as XEmacs diverges
completely from Emacs (another Boston tea party? ;-), or remerges with
it, there will be no good solution to the problem.

How about using a mixture of judgement, good sense, and tact, taking
each case on its merits?  :-(

-- 
Alan.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Morning, Richard!
>
> On Wed, Aug 02, 2006 at 05:20:12PM -0400, Richard Stallman wrote:
>> For distinguishing the two versions I write "Emacs" and "XEmacs",
>> because the context shows we are talking about these two variants
>> of the original GNU Emacs.
>
> This leaves a difficulty when there is no context.  For example, you
> might find this in an overview of editors:
>
> (1)  "Most free editors do syntax highlighting.  In vim, ........  In
>      Emacs, syntax highlighting is usually called "font locking"."
>
> A bit lower down in the same article, there might be ....
>
> (2)  "In some editors you can also highlight a region of text explicitly.
>      In vim you do ......., in Emacs you can type M-o M-o."
>
>> In other contexts, there is no need to refer to the two variants but
>> there is a need to connect Emacs with the GNU system.  There I write
>> "GNU Emacs".
>
> In paragraph (1), it is clear that "Emacs" includes XEmacs.

Not at all.  It is clear to those knowing the editors, but they are
hardly the target readership.

> To substitute "Emacs and XEmacs" would make the sentence clumsy and
> less readable, and wouldn't be helpful to the target readership.

I can't say I agree here.  And you could also write "Emacs variants",
but "Emacs and XEmacs" is quite clearer and not at all clumsy.  After
all, jed and Microemacs, two Emacs-like editors, don't use that
terminology.

> In paragraph (2), the context of bare "Emacs" having previously been
> set to "generic Emacs", clarity demands the substitution of "GNU
> Emacs".

But there is no point in an implicit "generic Emacs" context when one
is discussing Emacs and XEmacs as separate editors.  It is only
confusing the readers, with no actual gain.

> I believe "GNU Emacs" is used mainly for unambiguous identification
> rather than connecting it with the GNU system - much like "John of
> Gaunt" is used to clarify which John you're talking about rather
> than to associate him with the town of Gent in Belgium.
>
> The root of the problem is that XEmacs is neither identical with
> Emacs nor totally independent from it.  Until such time as XEmacs
> diverges completely from Emacs (another Boston tea party? ;-), or
> remerges with it, there will be no good solution to the problem.

Since XEmacs has diverged completely from Emacs, it is pointless to
try maintaining a language greyzone which has to be constantly
adjusted.  Keybindings, semantics, data structures (keymaps,
characters, integers, specifiers, toolbars, menubars, extents),
keybindings and so on _all_ have completely diverged.  The editors are
dissimilar enough that users accustomed to one of them will not put up
with the other interchangeably.  There is almost no person who will
say "I use Emacs on this computer, and XEmacs on that computer".

> How about using a mixture of judgement, good sense, and tact, taking
> each case on its merits?  :-(

It is no help to the reader if he has to secondguess the author and
the author's knowledge of the internals of both Emacs and XEmacs.  One
could make a weak case for using "Emacs" as a proper name and "an
Emacs" to signify the class of Emacs and XEmacs, but since there is
usually nothing else grouped in that class ever, there is little point
in doing so.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Aidan Kehoe]

 Ar an triú lá de mí Lúnasa, scríobh David Kastrup: 

 > [...] There is almost no person who will say "I use Emacs on this
 > computer, and XEmacs on that computer".

Minus how you express it, that’s what I do. If something with M-< and Emacs
Lisp is available on a machine, I’m certainly going to use it before nano or
vim, even if C-x 4 F doesn’t work. 

-- 
Santa Maradona, priez pour moi!

Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Richard Stallman]

    I believe "GNU Emacs" is used mainly for unambiguous identification
    rather than connecting it with the GNU system - much like "John of
    Gaunt" is used to clarify which John you're talking about rather than to
    associate him with the town of Gent in Belgium.

Yes, exactly.

    > For distinguishing the two versions I write "Emacs" and "XEmacs",
    > because the context shows we are talking about these two variants
    > of the original GNU Emacs.

    This leaves a difficulty when there is no context.  For example, you
    might find this in an overview of editors:

In an overview of editors there will be a place to provide the context
to explain what "Emacs" and "XEmacs" refer to, their history (joint
and separate), etc.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV