new text property

new text property

[Colin Walters]

Hello,

Emacs 21.4 will have a new text property `font-lock-face'.  I would
personally like to see support for this property in XEmacs too, so the
authors of externally distributed modes can use it easily and keep their
code portable, and also to keep Emacs and XEmacs from diverging more.

The rationale for this change is that it easily allows "special" modes
to have their fontification controlled by M-x font-lock-mode, rather
than having to set a variable like `cvs-highlight', `Info-fontify', or
tracking down a -face variable and setting it to `default'.

Emacs actually doesn't implement this variable in the core C code;
instead, we added a new variable `char-property-alias-alist' which
allows properties to have alternative names.  M-x font-lock-mode can
then add and delete `font-lock-face' as an alias for the `face'
property.  There are other neat things one can do with this variable
too.

It would be nice if XEmacs could support `char-property-alias-alist' in
its entirety (I bet all you need to change is `extent-get'), but I'd be
satisfied with just implementing support for `font-lock-face', however
you choose to do it.

What do you (XEmacs people) think?

If you're interested in all the details of how we eventually arrived at
this solution, see the thread entited "kill ring menu" on emacs-devel
(we really should have chosen a different subject title at some
point...).

Re: new text property

[Stephen J. Turnbull]

>>>>> "Colin" == Colin Walters <walters@gnu.org> writes:

    Colin> Emacs 21.4 will have a new text property `font-lock-face'.

    Colin> The rationale for this change is that it easily allows
    Colin> "special" modes to have their fontification controlled by
    Colin> M-x font-lock-mode, rather than having to set a variable
    Colin> like `cvs-highlight', `Info-fontify', or tracking down a
    Colin> -face variable and setting it to `default'.

Er, as I understood that thread, the rationale is that font-lock is
too heavy (aka "slow and broken") to be used by modes that just want
some "light-weight" highlighting.  Is that not so?  Are there other
advantages to not using font-lock to do font-locking?<wink>

I think we should look into allowing all highlighting to be done by
font-lock by making font-lock performance better.  I don't mean I
oppose `font-lock-face' as such, but we should be careful to not put
obstacles in the way of a high-performance font-lock (even though it's
vaporware now, several people including Martin Buchholz and Matt
Tucker have made plausible proposals).



-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py

Re: new text property

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> Er, as I understood that thread, the rationale is that font-lock is
> too heavy (aka "slow and broken") to be used by modes that just want
> some "light-weight" highlighting.  Is that not so?  Are there other
> advantages to not using font-lock to do font-locking?

Some modes just want to do their own face manipulation because it's
simpler, faster, and in some case, _possible_ -- there are types of
formatting which _cannot_ be done by font-lock, because they depend on
external information (it was suggested to retain such information using
a non-face text-property, and then have font-lock continually update the
face property using it, but that's just silly).

Rather than trying to shoehorn such modes into font-lock's model,
Colin's change simply allows modes to easily use whichever method suits
them best (and in fact, they could use both at the same time).

BTW, the `char-property-alias-alist' variable is used to implement the
`font-lock-face' feature, but otherwise is independent of font-lock, and
potentially useful on its own.

> I don't mean I oppose `font-lock-face' as such, but we should be
> careful to not put obstacles in the way of a high-performance
> font-lock

Which obstacles are those?

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: new text property

[Colin Walters]

On Mon, 2002-06-10 at 00:29, Stephen J. Turnbull wrote:

> Er, as I understood that thread, the rationale is that font-lock is
> too heavy (aka "slow and broken") to be used by modes that just want
> some "light-weight" highlighting.  Is that not so?  Are there other
> advantages to not using font-lock to do font-locking?<wink>

The font-lock you are thinking of is regexp and search-based
fontification, both of which can be slow (and in the case of regexps
quite often broken).  

But typing 'M-x font-lock-mode' is a nice *interface* to enabling and
disabling fontification.  It doesn't mean the mode has to use regexp or
search-based fontification.  In Emacs we now have "font-core.el", which
just defines the bare bones of `font-lock-mode' and
`global-font-lock-mode'.  It allows a mode (like `occur') which uses the
new `font-lock-face' to allow its fontification to be toggled via M-x
font-lock-mode, without loading all of the regexp and other machinery of
font-lock.el.

> I think we should look into allowing all highlighting to be done by
> font-lock by making font-lock performance better.  

The performance of `font-lock-face' in Emacs is essentially equivalent
to that of the `face' property; i.e. it is not an issue.  I suspect you
could easily achieve the same results in XEmacs.

Re: new text property

[Stephen J. Turnbull]

>>>>> "Miles" == Miles Bader <miles@lsi.nec.co.jp> writes:

    Miles> Which obstacles are those?

If I knew, I'd say.

What I do know is that font-lock itself has a minimum of five
implementations (font-lock, font-lock-cache, lazy-lock, lazy-shot, and
jit-lock).  Primitive highlighting has at least three interfaces
(overlays, text properties, extents).  This looks like an area ripe
for consolidation, not proliferation, of APIs to me.

I also don't like the idea that semantics apparently depend on whether
a reference is an "original" or an "alias".

Thus the warning.  This may be the right thing to do, but I want to
make sure that XEmacs people _discuss_ this change rather than simply
adopt it for the sake of compatibility.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py

Re: new text property

[Colin Walters]

On Mon, 2002-06-10 at 02:38, Stephen J. Turnbull wrote:

> What I do know is that font-lock itself has a minimum of five
> implementations (font-lock, font-lock-cache, lazy-lock, lazy-shot, and
> jit-lock). 

Those are all ways of dynamically searching for text and placing `face'
properties on them.  That's a very different approach from the way
`font-lock-face' is used.

Really, `font-lock-face' has nothing to do with what people
traditionally think of as "Font Lock" (i.e. regexps, searching), except
that it happens to be toggled on and off when the user types M-x
font-lock-mode.  The amount of code dealing with `font-lock-face' in
font-core.el amounts to about 8 lines.

> Primitive highlighting has at least three interfaces
> (overlays, text properties, extents).  This looks like an area ripe
> for consolidation, not proliferation, of APIs to me.

Yes, but adding `char-property-alias-alist' will not really increase the
difference between interfaces.  XEmacs appears to already have
`default-text-properties', which is similar.

> I also don't like the idea that semantics apparently depend on whether
> a reference is an "original" or an "alias".

They don't.

> Thus the warning.  This may be the right thing to do, but I want to
> make sure that XEmacs people _discuss_ this change rather than simply
> adopt it for the sake of compatibility.

I understand that.  But could you please study `font-lock-face' a little
bit more carefully?  The points you have raised so far don't really
apply to it.

Re: new text property

[Stefan Monnier]

>     Miles> Which obstacles are those?
> 
> If I knew, I'd say.
> 
> What I do know is that font-lock itself has a minimum of five
> implementations (font-lock, font-lock-cache, lazy-lock, lazy-shot, and
> jit-lock).

font-lock-cache, lazy-lock, lazy-shot, and jit-lock and 4 different
implementations of various mechanisms to try and reduce the amount
of work that font-lock does.  They are mostly orthogonal to font-lock
itself and they are in no way reimplementations of font-lock.

> Primitive highlighting has at least three interfaces
> (overlays, text properties, extents).  This looks like an area ripe
> for consolidation, not proliferation, of APIs to me.

`extents' are the consolidation, aren't they ?


	Stefan

Re: new text property

[Adrian Aichner]

>>>>> "Stefan" == Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> writes:

    Miles> Which obstacles are those?
    >> 
    >> If I knew, I'd say.
    >> 
    >> What I do know is that font-lock itself has a minimum of five
    >> implementations (font-lock, font-lock-cache, lazy-lock, lazy-shot, and
    >> jit-lock).

    Stefan> font-lock-cache, lazy-lock, lazy-shot, and jit-lock and 4 different
    Stefan> implementations of various mechanisms to try and reduce the amount
    Stefan> of work that font-lock does.  They are mostly orthogonal to font-lock
    Stefan> itself and they are in no way reimplementations of font-lock.

    >> Primitive highlighting has at least three interfaces
    >> (overlays, text properties, extents).  This looks like an area ripe
    >> for consolidation, not proliferation, of APIs to me.

    Stefan> `extents' are the consolidation, aren't they ?

Does Emacs 21.x have extents?

    Stefan> 	Stefan



-- 
Adrian Aichner
 mailto:adrian@xemacs.org
 http://www.xemacs.org/

Re: new text property

[Eli Zaretskii]

On 10 Jun 2002, Adrian Aichner wrote:

> Does Emacs 21.x have extents?

No.

Re: new text property

[Stephen J. Turnbull]

>>>>> "Stefan" == Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> writes:

    Stefan> They are mostly orthogonal to font-lock itself and they
    Stefan> are in no way reimplementations of font-lock.

I don't care what they _are_, it's the namespace pollution.  I have to
know a little about everything, and I really really wish "everything"
would shrink and become more rational.  Miles talks a good game about
this new interface helping with both, but there's that nasty backward
compatibility stuff.

Hey, you guys just did it.  So I'm all for Hrvoje's strategy of
listening to the silence of satisfied customers for a while.

    >> Primitive highlighting has at least three interfaces (overlays,
    >> text properties, extents).  This looks like an area ripe for
    >> consolidation, not proliferation, of APIs to me.

    Stefan> `extents' are the consolidation, aren't they ?

Again, I would like to _deprecate_ interfaces, not add them.  We get a
proposal to deprecate our overlay-compatibility library every 3-4
months, and we can't do it because of the agonized screaming from the
package developers.  This font-lock-face thing is definitely an
increase in complexity from my point of view, and the benefit is not
clear (except for GNU Emacs compatibility).


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py

Re: new text property

[Hrvoje Niksic]

Colin Walters <walters@gnu.org> writes:

> The rationale for this change is that it easily allows "special"
> modes to have their fontification controlled by M-x font-lock-mode,
> rather than having to set a variable like `cvs-highlight',
> `Info-fontify', or tracking down a -face variable and setting it to
> `default'.

I don't understand why it would be desirable for font-lock-mode to
control non-font-lock highlighting.

If there is a need to manipulate faces on the buffer level, such as
turning them all off, regardless of whether they come from font-lock
or from another source of highlighting, shouldn't that be made
generic?  That way both font-lock and other sources of highlighting
could be using the same feature.  For example, the extents used for
highlighting could have a `highlight' property whose presence would
indicate that it's ok to remove their `face' property at the request
of the user.

I don't think char-property-alias-alist makes sense, as we don't use
char properties, except in the compatibility layer.  Adding features
only to that compatibility layer is dangerous because we often want
the properties to be accessible from both interfaces.

> It would be nice if XEmacs could support `char-property-alias-alist' in
> its entirety (I bet all you need to change is `extent-get'),

I don't know what extent-get is, but supporting
char-property-alias-alist would surely require more changes, such as
in map-extents, extent-at, and many others.

Re: new text property

[Kai Großjohann]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> If there is a need to manipulate faces on the buffer level, such as
> turning them all off, regardless of whether they come from font-lock
> or from another source of highlighting, shouldn't that be made
> generic?

As I understand, M-x font-lock-mode RET _is_ generic, despite the
name.

I'm not sure how it works:  (a) The mode always puts properties on the
text, but they are ignored on display (depending on font-lock-mode).
(b) The mode looks at font-lock-mode and refrains from putting the
properties on the text.

But in the end, it doesn't make too much of a difference:
font-lock-mode is just a general toggle for the mode to do
highlighting however it likes to do that.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: new text property

[Hrvoje Niksic]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai writes:

> As I understand, M-x font-lock-mode RET _is_ generic, despite the
> name.

How have you come to that conclusion?  There are different
highlighting mechanisms that have nothing to do with font-lock mode,
such as those used by Gnus and VM.

> But in the end, it doesn't make too much of a difference:
> font-lock-mode is just a general toggle for the mode to do
> highlighting however it likes to do that.

You can overload font-lock-mode to mean that, but it has traditionally
not been the case.

Re: new text property

[Miles Bader]

Hrvoje Niksic <hniksic@xemacs.org> writes:
> You can overload font-lock-mode to mean that, but it has traditionally
> not been the case.

From a user's perspective, `most' fontified stuff has traditionally been
handled by font-lock, and so `M-x font-lock-mode' (and
global-font-lock-mode) is the familiar interface to turning on and off
fontification.

So, if you want to have a unified method of doing this, what are your
choices?

I can see:

  (1) Add a new command/mode/whatever that does it, which acts as a
      layer on top of the traditional font-lock code, gnus, comint, etc.
  
  (2) Extend the familiar UI aspect of `M-x font-lock-mode' to work
      generally for modes that don't use the traditional font-lock
      mechanism, and additionally add more separation between the
      font-lock UI and the regexp-scanning etc.  [note that for a user,
      the name `font-lock-mode' makes perfect sense as a way to toggle
      fontification]

Method (1) means that users have to learn a new command to use in many
cases, whereas (2) means that for most cases, the interface remains the
same, and in fact starts to work for other modes -- an extension which
I'd argue is quite natural (unless you're a font-lock hacker, in which
case you're probably grumbling that `none of this makes any sense,
font-lock is font-lock!!').

Don't get hung up on the traditional conflation of the font-lock UI with
the mechanism used to implement it; it's really not necessary.

-Miles

-- 
.Numeric stability is probably not all that important when you're guessing.

Re: new text property

[Hrvoje Niksic]

Miles Bader <miles@gnu.org> writes:

> Don't get hung up on the traditional conflation of the font-lock UI
> with the mechanism used to implement it; it's really not necessary.

Why not?  Font-lock is not only about the hairy regexps that implement
it; it's also about respecting the settings for font-lock-*-face and
variables such as font-lock-maximum-decoration,
font-lock-auto-fontify, font-lock-maximum-size, etc.  A highlighting
mechanism that doesn't respect any of those has no reason to be bound
by `M-x font-lock-mode' either.

I'm not a font-lock hacker, I just think that overloading the meaning
of `M-x font-lock-mode' might not be such a good idea.  Confusing the
two will lead people to try to use other font-lock settings in
non-font-lock environments, and that will silently fail.

So, between your choices of (1) and (2), either is OK if done right.
But I'd rather leave things as they are than do the wrong thing.

Re: new text property

[Stefan Monnier]

> > Don't get hung up on the traditional conflation of the font-lock UI
> > with the mechanism used to implement it; it's really not necessary.
> 
> Why not?  Font-lock is not only about the hairy regexps that implement
> it; it's also about respecting the settings for font-lock-*-face and
> variables such as font-lock-maximum-decoration,
> font-lock-auto-fontify, font-lock-maximum-size, etc.

You forgot jit-lock (aka lazy-shot).

> A highlighting
> mechanism that doesn't respect any of those has no reason to be bound
> by `M-x font-lock-mode' either.

Agreed.  I proposed a new `highlighting-mode' (or some other name,
I can't remember) instead of moving code out of font-lock.el to
font-core.el (I hate moving code, among other things because it makes
CVS much less useful) but for some reason it was not retained.  I didn't
(and still don't) have time/energy to follow the whole discussion, tho.


	Stefan "font-lock hacker"

Re: new text property

[Kai Großjohann]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> Miles Bader <miles@gnu.org> writes:
>
>> Don't get hung up on the traditional conflation of the font-lock UI
>> with the mechanism used to implement it; it's really not necessary.
>
> Why not?  Font-lock is not only about the hairy regexps that implement
> it; it's also about respecting the settings for font-lock-*-face and
> variables such as font-lock-maximum-decoration,
> font-lock-auto-fontify, font-lock-maximum-size, etc.  A highlighting
> mechanism that doesn't respect any of those has no reason to be bound
> by `M-x font-lock-mode' either.

I guess the idea is to do all of this.

But maybe it is not so important to use the font-lock-*-faces.  After
all, if there is a language which does not have comments, then it is
natural that font-lock-comment-face is not used.  The same argument
can be repeated for other font-lock-*-faces.

In a Gnus article buffer, for example, none of the predefined faces
really catch the semantics of anything that's displayed in the buffer.

There is also precedence for using other faces: cperl-mode uses a
cperl-hash-face, for instance, in addition to the standard
font-lock-*-faces.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: new text property

[Colin Walters]

On Mon, 2002-06-10 at 09:32, Hrvoje Niksic wrote:

> I'm not a font-lock hacker, I just think that overloading the meaning
> of `M-x font-lock-mode' might not be such a good idea.  Confusing the
> two will lead people to try to use other font-lock settings in
> non-font-lock environments, and that will silently fail.

But the only reason many of those variables (e.g.
`font-lock-maximum-size', `font-lock-maximum-decoration') were added is
for speed reasons.  There are no speed issues with `font-lock-face'.

> So, between your choices of (1) and (2), either is OK if done right.
> But I'd rather leave things as they are than do the wrong thing.

I really don't see how having a few speed-related variables not
applicable to `font-lock-face' is a big drawback compared to what I
think is a big improvement in the user interface.

Re: new text property

[Hrvoje Niksic]

Colin Walters <walters@gnu.org> writes:

> But the only reason many of those variables (e.g.
> `font-lock-maximum-size', `font-lock-maximum-decoration') were added
> is for speed reasons.

Other highlighting mechanims have speed issues as well.  For example,
Gnus prefers not to highlight huge messages because that would take
too long.  If I controled that with `M-x font-lock-mode' (which would
buy me nothing in turns of convenience; Gnus has variables to
fine-tune its highlighting), I would expect things like
`font-lock-maximum-size' to keep working.

Plus, font-lock-maximum-decoration is not only about speed.  Some
people don't *like* too much decoration.

Re: new text property

[Colin Walters]

On Tue, 2002-06-11 at 07:40, Hrvoje Niksic wrote:

> Other highlighting mechanims have speed issues as well.  For example,
> Gnus prefers not to highlight huge messages because that would take
> too long.  If I controled that with `M-x font-lock-mode' (which would
> buy me nothing in turns of convenience; Gnus has variables to
> fine-tune its highlighting), 

It would be convenient because it is the same interface that one uses to
enable and disable fontification in many prominent Emacs modes;
specifically, I'm thinking of C and Lisp mode buffers, although there
are plenty of other examples.

Otherwise, to disable/enable highlighting, you have to track down one of
those variables, change it, and then recreate the buffer somehow so the
change in the variable takes effect.  Just typing 'M-x font-lock-mode'
is tons easier.

> I would expect things like
> `font-lock-maximum-size' to keep working.

Why?  There is no slowdown when using `font-lock-face'.  For what other
possible reason would you set `font-lock-maximum-size' other than speed?

> Plus, font-lock-maximum-decoration is not only about speed.  Some
> people don't *like* too much decoration.

Well, that's a hard problem to solve.  Note that even not all modes
which use "traditional" font-lock supply multiple levels of keywords,
which `font-lock-maximum-decoration' needs.

Re: new text property

[Hrvoje Niksic]

Colin Walters <walters@gnu.org> writes:

> On Tue, 2002-06-11 at 07:40, Hrvoje Niksic wrote:
>
>> Other highlighting mechanims have speed issues as well.  For example,
>> Gnus prefers not to highlight huge messages because that would take
>> too long.  If I controled that with `M-x font-lock-mode' (which would
>> buy me nothing in turns of convenience; Gnus has variables to
>> fine-tune its highlighting), 
>
> It would be convenient because it is the same interface that one uses to
> enable and disable fontification in many prominent Emacs modes;

But in my view, that convenience does not outweigh the need for
consistency.  Respecting `M-x font-lock-mode', but not any other
font-lock variable, is quite inconsistent.

>> I would expect things like `font-lock-maximum-size' to keep
>> working.
>
> Why?

Because I `M-x font-lock-mode' worked just fine.  Because `C-h f
font-lock-mode' claims it does.

> There is no slowdown when using `font-lock-face'.

I never claimed that, sorry if that was unclear.  Read the whole of my
paragraph, which you broke down in two pieces.  It's all about
consistency between `M-x font-lock-mode' and the rest of the
font-lock-* setup (where font-lock-maximum-size is but one element),
which would be broken.

>> Plus, font-lock-maximum-decoration is not only about speed.  Some
>> people don't *like* too much decoration.
>
> Well, that's a hard problem to solve.

Exactly.  That's one more reason why I think it's not a good idea to
merge font-lock and other highlighting on the surface.

Again, I don't have strong feelings about this.  If many users request
this feature, I will not veto its inclusion.

Re: new text property

[Kai Großjohann]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> But in my view, that convenience does not outweigh the need for
> consistency.  Respecting `M-x font-lock-mode', but not any other
> font-lock variable, is quite inconsistent.

I guess that the new feature should be changed in such a way that as
many font-lock-* variables as reasonable should be respected.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: new text property

[Miles Bader]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> I guess that the new feature should be changed in such a way that as
> many font-lock-* variables as reasonable should be respected.

The main point about the `new feature' is that font-lock itself does
almost nothing, the font-lock-using mode does all the work.  If those
modes want to respect other font-lock-* variables, they certainly can.

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: new text property

[Stephen J. Turnbull]

>>>>> "Colin" == Colin Walters <walters@gnu.org> writes:

    Colin> Otherwise, to disable/enable highlighting, you have to
    Colin> track down one of those variables, change it, and then
    Colin> recreate the buffer somehow so the change in the variable
    Colin> takes effect.  Just typing 'M-x font-lock-mode' is tons
    Colin> easier.

Good idea, but we're already heading this way in general with
"behaviors."  Unification we don't have, but the mechanism would allow
arbitrary unifications, I think, just as custom allows you to "set"
variables that don't exist or are a group of related variables..  And
the "recreate buffer somehow" is the main (current) point of the
"behavior feature."

So AFAICT, we can get the immediate effect of the new features through
our general mechanism.  Why reduplicate it ad hoc?

grep for "ben wing + behavior" in xemacs-beta, xemacs-design,
xemacs-patches:  http://list-archive.xemacs.org/$LIST_NAME



-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py

Re: new text property

[Colin Walters]

On Tue, 2002-06-11 at 21:14, Stephen J. Turnbull wrote:

> Good idea, but we're already heading this way in general with
> "behaviors."  Unification we don't have, but the mechanism would allow
> arbitrary unifications, I think, just as custom allows you to "set"
> variables that don't exist or are a group of related variables..  And
> the "recreate buffer somehow" is the main (current) point of the
> "behavior feature."

But recreating the buffer is a bad way to solve this problem.  For
example, suppose I do "M-x occur RET foo", and I keep that *Occur*
buffer around, but I kill the source buffer, because I don't need it
anymore.  Then later I want to see it unfontified, so I do the natural
thing: type M-x font-lock-mode.  But the `occur' will fail because the
original buffer is gone.

And if we ever extended Occur to allow the user to edit the buffer
(which I plan to do for Emacs at some point), then it becomes a lot
harder to recreate it.

> So AFAICT, we can get the immediate effect of the new features through
> our general mechanism.  Why reduplicate it ad hoc?

Well, if these "behaviors" aren't implemented, it is hard to discuss.

One thing that bugs me about using behaviors for this is that you still
have to hunt down a `foo-highlight', `foo-fontify',
`foo-enable-fontification', etc. variable to set in the first place.

> grep for "ben wing + behavior" in xemacs-beta, xemacs-design,
> xemacs-patches:  http://list-archive.xemacs.org/$LIST_NAME

I got no results:

http://list-archive.xemacs.org/cgi-bin/wilma_glimpse/xemacs-beta?query=ben%3Bwing%3Bbehavior&Search=Search&filelist=200206&filelist=200205&filelist=200204&filelist=200203&filelist=200202&filelist=200201&filelist=200112&filelist=200111&filelist=200110&filelist=200109&filelist=200108&filelist=200107&filelist=200106&filelist=200105&filelist=200104&filelist=200103&filelist=200102&filelist=200101&filelist=200012&filelist=200011&filelist=200010&filelist=200009&filelist=200008&filelist=200007&filelist=200006&filelist=200005&filelist=200004&filelist=200003&filelist=200002&filelist=200001&filelist=199912&errors=0&maxfiles=50&maxlines=10&.cgifields=lineonly&.cgifields=filelist&.cgifields=case&.cgifields=partial&.cgifields=restricttofiles
http://list-archive.xemacs.org/cgi-bin/wilma_glimpse/xemacs-patches?query=ben%3Bwing%3Bbehavior&Search=Search&filelist=200206&filelist=200205&filelist=200204&filelist=200203&filelist=200202&filelist=200201&filelist=200112&filelist=200111&filelist=200110&filelist=200109&filelist=200108&filelist=200107&filelist=200106&filelist=200105&filelist=200104&filelist=200103&filelist=200102&filelist=200101&filelist=200012&filelist=200011&filelist=200010&filelist=200009&filelist=200008&filelist=200007&filelist=200006&filelist=200005&filelist=200004&filelist=200003&filelist=200002&filelist=200001&filelist=199912&errors=0&maxfiles=50&maxlines=10&.cgifields=lineonly&.cgifields=filelist&.cgifields=case&.cgifields=partial&.cgifields=restricttofiles
http://list-archive.xemacs.org/cgi-bin/wilma_glimpse/xemacs-design?query=ben%3Bwing%3Bbehavior&Search=Search&filelist=200206&filelist=200205&filelist=200204&filelist=200203&filelist=200202&filelist=200201&filelist=200112&filelist=200111&filelist=200110&filelist=200109&filelist=200108&filelist=200107&filelist=200106&filelist=200105&filelist=200104&filelist=200103&filelist=200102&filelist=200101&filelist=200012&filelist=200011&filelist=200010&filelist=200009&filelist=200008&filelist=200007&filelist=200006&filelist=200005&filelist=200004&filelist=200003&filelist=200002&filelist=200001&filelist=199912&errors=0&maxfiles=50&maxlines=10&.cgifields=lineonly&.cgifields=filelist&.cgifields=case&.cgifields=partial&.cgifields=restricttofiles

Re: new text property

[Stephen J. Turnbull]

>>>>> "Colin" == Colin Walters <walters@gnu.org> writes:

    Colin> But recreating the buffer is a bad way to solve this
    Colin> problem.

You said "recreate", not me.  Whatever the right thing is, if you can
do it in Lisp, you can automate it through a behavior.  Hopefully more
intuitively than just creating a random `sjt:foo-dwim' function, but
we'll see as we use them.

    Colin> One thing that bugs me about using behaviors for this is
    Colin> that you still have to hunt down a `foo-highlight',
    Colin> `foo-fontify', `foo-enable-fontification', etc. variable to
    Colin> set in the first place.

The person who implements the behavior does.  But this is always a
problem when you abstract independently developed mechanisms.

    >> grep for "ben wing + behavior" in xemacs-beta, xemacs-design,
    >> xemacs-patches: http://list-archive.xemacs.org/$LIST_NAME

    Colin> I got no results:

*sigh*  Somebody's working on the search engines, but the mailing list
engine is still substandard.



-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py

Re: new text property

[Adrian Aichner]

>>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

    >>> grep for "ben wing + behavior" in xemacs-beta, xemacs-design,
    >>> xemacs-patches: http://list-archive.xemacs.org/$LIST_NAME

    Colin> I got no results:

    Stephen> *sigh* Somebody's working on the search engines, but the
    Stephen> mailing list engine is still substandard.

Well, "ben wing + behavior" (without the quotes) is incorrect syntax.

"ben;wing;behavior" would be correct but doesn't find any original
information.

Meanwhile I found this:
http://list-archive.xemacs.org/xemacs-beta/200204/msg00107.html
with
http://list-archive.xemacs.org/cgi-bin/wilma_glimpse/xemacs-beta?query=behaviors&errors=0&maxfiles=50&maxlines=10&.cgifields=lineonly&.cgifields=filelist&.cgifields=case&.cgifields=partial&.cgifields=restricttofiles
and this
http://www.xemacs.org/Documentation/21.5/html/xemacs_30.html#SEC352
with
http://www.xemacs.org/cgi-bin/namazu.cgi?query=behaviors&whence=0&lang=en

-- 
Adrian Aichner
 mailto:adrian@xemacs.org
 http://www.xemacs.org/

Re: new text property

[Kai Großjohann]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai writes:
>
>> As I understand, M-x font-lock-mode RET _is_ generic, despite the
>> name.
>
> How have you come to that conclusion?  There are different
> highlighting mechanisms that have nothing to do with font-lock mode,
> such as those used by Gnus and VM.

Because there was a lengthy discussion to do just that: allow M-x
font-lock-mode RET as the user interface for highlighting which is
done in another way.

>> But in the end, it doesn't make too much of a difference:
>> font-lock-mode is just a general toggle for the mode to do
>> highlighting however it likes to do that.
>
> You can overload font-lock-mode to mean that, but it has traditionally
> not been the case.

In Emacs, this overloading has happened some days ago.  Hence this
thread, xposted to xemacs-devel.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: new text property

[Hrvoje Niksic]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai writes:

> Because there was a lengthy discussion to do just that: allow M-x
> font-lock-mode RET as the user interface for highlighting which is
> done in another way.
[...]
> In Emacs, this overloading has happened some days ago.

See my other message for why I believe it's a bad idea.  Of course,
GNU Emacs can choose to do it that way; I simply don't think XEmacs
should follow in this particular instance.

It can be a good experiment, though.  If many users ask for the same
feature, it's easy to add it.