emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kill ring menu


From: Colin Walters
Subject: Re: kill ring menu
Date: 19 May 2002 01:30:48 -0400

On Sat, 2002-05-18 at 14:48, Richard Stallman wrote:

> To make it work, you just need to create a distinct category symbol
> for each buffer (that uses one of those modes).  Do it with make-symbol
> so that they won't be interned.

Yes, by explicitly working with uninterned symbols I guess we can make
it work (I didn't see Miles mentioned that previously too, sorry).  

> That method probably is not very hard once you try.

It's not conceptually difficult, but it is certainly unpleasant, since
there is no way (as far as I can see) to do some sort of magic inside
font-lock.el to avoid having the programmer to explicitly manipulate
uninterned symbols.

Anyways, please find attached a patch to replace.el and ibuffer.el which
change them to work this way.  The previous font-core.el can remain
unchanged.

If there are no other objections (and if the below text doesn't convince
anyone), I'll apply the patch in a few days, and then we can hopefully
get comint.el and others changed too.

This thread has been much longer than I thought it would be at first,
and I've certainly reimplemented things more times than I thought I
would...but if this patch goes in the original goal will be achieved.

Despite this, let me raise one final point to think about:

Since we've agreed to go to the trouble of changing replace.el,
comint.el, ibuffer.el, etc. to support this new interface, we could take
this opportunity to put in a more "permanent" interface, that we expect
authors of "special" modes not distributed with Emacs to use.

And if we do want these authors to support the general M-x
font-lock-mode interface, I think it would be advantageous to choose a
clearer, more direct approach (i.e. having something like
`font-lock-face', or Miles' approach of having a variable to disable
display of `face' properties (but that approach seems more likely to
have unforseen consequences, which is why I hesitate to use it)).


Attachment: fontlock.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]