[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: map: major-mode --> font-lock-defaults
From: |
Stefan Monnier |
Subject: |
Re: map: major-mode --> font-lock-defaults |
Date: |
Mon, 29 Jan 2001 17:08:30 -0500 |
> > * In message <address@hidden>
> > * On the subject of "Re: map: major-mode --> font-lock-defaults "
> > * Sent on Mon, 29 Jan 2001 14:40:53 -0500
> > * Honorable "Stefan Monnier" <monnier+gnu/address@hidden> writes:
> >
> > > great, this explains the reason for the bug, but not how to work around
> > > it without using `font-lock-defaults-alist'.
> >
> > The "don't use" here means "don't put anything there" rather than
> > "don't look at it".
>
> You mean this is a "read-only" variable?
> I thought that "obsolete" means that it will go away in a future
> version, so one should not use it at all.
It should indeed go away in a future version.
So indeed, don't put stuff in it. But if a major mode uses it, there's
generally no other place to find that info.
> > > how do I get hold of the `font-lock-defaults' associated with a mode
> > > without resorting to
> > > (with-temp-buffer (c-mode) font-lock-defaults)
> >
> > That's the only generic way that I know of.
>
> isn't this ugly and wasteful (having to create a buffer and set up a
> mode just to get the `font-lock-defaults')?
How often do you need to find the font-lock-defaults _of a mode_ (as
opposed to "of a buffer") ?
> shouldn't there be another way?
Only if it's an operation that's actually used.
The same holds for imenu-generic-expression and comment-start and plenty
of other such variables.
> > > in particular, what is wrong with using symbol properties, like
> > > (get 'c-mode 'font-lock-defaults)
> >
> > Nothing in particular except that it's not the way chosen by Emacs'
> > font-lock and since Emacs' way has other advantages (such as the fact
> > of being automatically inherited), there's little incentive to change.
>
> wait a second: it was _not_ automatically inherited from c-mode to
> d-mode (yes, you say the reason is administrative, not technical, but
> the bottom line is: it is not _always_ automatically inherited!)
Indeed, the font-lock-defaults-alist method does not automatically inherit,
which is one of its disadvantages. But I don't see how that's relevant
since I was talking about the method advocated by Emacs which is to set
the font-lock-defaults buffer-local variable (and it's the method that's
been in use for many years, the font-lock-defaults-alist has seen much
less use in comparison even when it wasn't explicitly deprecated).
> what about `lisp-mode' and `emacs-lisp-mode'?
> they are mentioned in `font-lock-defaults-alist', but they are
> maintained by the FSF, right?
Yes. But note that the value there is "not used any more" since those
modes now set font-lock-defaults themselves anyway.
They are still mentioned in font-lock-defaults-alist for various reasons,
mostly having to do with compatibility.
Stefan
- map: major-mode --> font-lock-defaults, Sam Steingold, 2001/01/28
- Re: map: major-mode --> font-lock-defaults, Stefan Monnier, 2001/01/29
- Re: map: major-mode --> font-lock-defaults, Sam Steingold, 2001/01/29
- Re: map: major-mode --> font-lock-defaults, Stefan Monnier, 2001/01/29
- Re: map: major-mode --> font-lock-defaults, Sam Steingold, 2001/01/29
- Re: map: major-mode --> font-lock-defaults, Stefan Monnier, 2001/01/29
- Re: map: major-mode --> font-lock-defaults, Sam Steingold, 2001/01/29
- Re: map: major-mode --> font-lock-defaults,
Stefan Monnier <=
- Re: map: major-mode --> font-lock-defaults, Sam Steingold, 2001/01/29