> Perhaps one could find these easily with a Lisp program
> that searches for a defun whose start matches "(defun [-a-z]+-mode "
> and that does not contain "(run-".
I did this. I think I found all and fixed most modes that did not run
mode hooks.
Thanks.
There are a f
Juri Linkov <[EMAIL PROTECTED]> writes:
>> We also need to find other modes that are effectively "derived" and
>> ought to use delay-mode-hooks. I think one could write a Lisp
>> program that would search for a match for "([-a-z]+-mode " within a
>> defun that starts with "(defun [-a-z]+-mode ".
Richard Stallman <[EMAIL PROTECTED]> writes:
> Of course my method failed to find any major modes that don't run mode
> hooks at all. Maybe someone else could try to fix those?
>
> Perhaps one could find these easily with a Lisp program
> that searches for a defun whose start matches "(de
Stefan Monnier wrote:
Don't know about the TeXinfo doc, but the docstring is pretty clear:
MODE should be a symbol, the major mode command name, such as `c-mode'
or nil. If nil, highlighting keywords are added for the current buffer.
What was not clear was what it was supposed to
>Could be, but your change does not try to fix it, instead it documents the
>part of the misbehavior we happen to know about, thus legitimizing the use,
>rather than discouraging it.
> But your previous text, even when read as intended:
>whereas I meant it to mean:
> Use a
So this patch would change the default appearance of comint prompts in
Emacs 22.
That change is ok. We have decided to move towards a more consistent
system where buffer-specific highlighting can be enabled and disabled
by calling font-lock-mode. This inevitably means an incompatible
cha
I rewrote this a different way.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Stefan Monnier wrote:
Could be, but your change does not try to fix it, instead it documents the
part of the misbehavior we happen to know about, thus legitimizing the use,
rather than discouraging i.t
But your previous text, even when read as intended:
whereas I meant it to mean:
>> ! @strong{Warning:} Only use a [EMAIL PROTECTED] @var{mode} argument when
>> ! you use @code{font-lock-add-keywords} or
>> ! @code{font-lock-remove-keywords} in your @file{.emacs} file. When you
>> ! use these functions from a Lisp program (such as a minor mode), we
>> ! recommend that you use
Stefan Monnier wrote:
> ! @strong{Warning:} Only use a [EMAIL PROTECTED] @var{mode} argument when
> ! you use @code{font-lock-add-keywords} or
> ! @code{font-lock-remove-keywords} in your @file{.emacs} file. When you
> ! use these functions from a Lisp program (such as a minor mode),
> I suppose the answer is really "it depends". Many people probably
> like some highlighting but not all. It seems the sort of thing that
> might actually be best handled by the concept of font-lock levels, but
> my impression is that they are not really used these days, and that
> it's fruit-sal
> ! @strong{Warning:} Only use a [EMAIL PROTECTED] @var{mode} argument when
> ! you use @code{font-lock-add-keywords} or
> ! @code{font-lock-remove-keywords} in your @file{.emacs} file. When you
> ! use these functions from a Lisp program (such as a minor mode), we
> ! recommend that you use @code
> In Emacs 21, the behavior was that comint prompts were _always_
> highlighted, but font-lock could be turned on to add other faces
> (e.g., colorization of error messages). When I changed the
In Emacs-20 the behavior was: no highlighting unless you turn on font-lock.
So the patch just gets us b
Miles Bader wrote:
So this patch would change the default appearance of comint prompts in
Emacs 22. I don't know if the average user would be annoyed/confused
("my prompts disappeared!") or happy ("ah those evil colorized prompts
are gone!") by such a change.
Because recently seve
On 6/7/05, Luc Teirlinck <[EMAIL PROTECTED]> wrote:
>So this patch would change the default appearance of comint prompts in
>Emacs 22. I don't know if the average user would be annoyed/confused
>("my prompts disappeared!") or happy ("ah those evil colorized prompts
>are gone!") by
On 6/7/05, Luc Teirlinck <[EMAIL PROTECTED]> wrote:
>(defcustom comint-mode-hook '(turn-on-font-lock)
>
>Shouldn't we remove that? Is it a desirable thing, nowadays,
>for some modes to enable Font Lock on their own, instead of letting
>the user do so if he wants?
>
> Unless M
Richard Stallman wrote:
To clarify, this is how comint enables Font Lock:
(defcustom comint-mode-hook '(turn-on-font-lock)
Shouldn't we remove that? Is it a desirable thing, nowadays,
for some modes to enable Font Lock on their own, instead of letting
the user do so if he
RichardStallman wrote:
And certainly, if a minor mode uses
font-lock-add-keywords, and then people use define-global-minor-mode
to make a global version of it, then font-lock-add-keywords will be
called from major modes through after-change-major-mode-hook.
Are you saying that kind
Richard Stallman wrote:
I will add this to the documentation of font-lock-add-keywords.
@strong{Warning:} major mode functions must not call
@code{font-lock-add-keywords} under any circumstances, either directly
or indirectly. (This would lead to incorrect behavior for some minor
If you call font-lock-{add,remove}-keywords with nil for MODE inside a
parent mode's body instead of its mode hook, the keyword is not
enabled in the derived mode. If the parent mode does call
font-lock-{add,remove}-keywords in its mode hook, the keyword may not be
enabled in t
In addition to that, there would be a problem with major modes that do
follow the conventions but call font-lock-{add,remove}-keywords with
nil for MODE in their body instead of their hook. Major modes are not
supposed to do that. A nil argument was not designed to be used that
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> I believe that it is possible to implement things completely
> reliably by letting major modes specify a list of major modes from
> which they want to inherit keywords and using a non-nil MODE
> argument. But that would require more extensive changes to
Just to avoid confusion: you mean that all three patches are OK to
install? The one to easy-mmode _and_ the ones to font-lock and
font-core?
Yes.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-
Stefan Monnier wrote:
Actually, don't worry too mucvh about that, because I think that even with
the current code things don't work right unless the major mode follows
the conventions w.r.t major-mode-derivation.
My changes do not introduce new problems, they fix problems with the
curren
> Other than that, the major remaining issue is that calling
> font-lock-{add,remove}-keywords with nil for MODE only works reliably
> for major modes that follow the new conventions. But one of your
Actually, don't worry too mucvh about that, because I think that even with
the current code thing
Richard Stallman wrote:
I am not sure what problems those are.
Maybe I explained just when they occurred, but not what they are.
If you call font-lock-{add,remove}-keywords with nil for MODE inside a
parent mode's body instead of its mode hook, the keyword is not
enabled in the derived mode.
I am not sure what problems those are. There were so many messages
yesterday that just reading them would take a long time. I hoped to
bypass that job by asking you to summarize the result of all that
discussion.
I thought I did that in the message prior to the one you responded to.
I received many long messages yesterday about this issue.
What conclusions were reached from them?
If you do not consider the remaining problems, described in my
previous message, to be a real problem, then I believe that there are
not many conclusions left to be reached.
Richard Stallman wrote:
This patch looks good to me. Please install it.
Just to avoid confusion: you mean that all three patches are OK to
install? The one to easy-mmode _and_ the ones to font-lock and
font-core? I can not install the patch to easy-mmode without
installing the other two, or
This patch looks good to me. Please install it.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Richard Stallman wrote:
The only difference between the following patch to font-lock.el and
the previous one are two doc fixes. After those doc fixes, everything
should work as documented when my three patches are applied.
In that case, my previous comments about the prev
I received many long messages yesterday about this issue.
What conclusions were reached from them?
If you do not consider the remaining problems, described in my
previous message, to be a real problem, then I believe that there are
not many conclusions left to be reached.
I personally belie
The only difference between the following patch to font-lock.el and
the previous one are two doc fixes. After those doc fixes, everything
should work as documented when my three patches are applied.
In that case, my previous comments about the previous patch
still apply to this one.
Hi guys,
could you please take me off the cc for this discussion? Thanks.
- Carsten
> "LT" == Luc Teirlinck <[EMAIL PROTECTED]> writes:
LT> I still do not understand exactly what a nil argument for MODE in
LT> font-lock-{add,remove}-keywords is supposed to accomplish. The
LT> font-lock
The new patch below to easy-mmode implements the suggested changes
with a few proposed differences. Instead of thismode-... I believe it
is better to use MODE-..., since thismode could refer to major modes
or to the global minor mode. I believe that MODE-.. more clearly
indicates that it refers t
And my second patch contained stray punctuation. This should finally
be correct:
===File ~/font-lock-b-diff==
*** font-lock.el29 May 2005 09:15:38 -0500 1.259
--- font-lock.el01 Jun 2005 18:59:56 -0500
***
*** 683,691
a
>From my previous message:
My previous patch called add-hook in the wrong way.
I meant the call in the docstring example.
Sincerely,
Luc.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Stefan Monnier <[EMAIL PROTECTED]> writes:
>>*Warning:* Only use a non-`nil' MODE argument when you use
>> `font-lock-add-keywords' or `font-lock-remove-keywords' in your
>> `.emacs' file. When you use these functions from a Lisp
>> program (such as a minor mode), we recommend
My previous patch called add-hook in the wrong way.
Corrected patch:
===File ~/font-lock-b-diff==
*** font-lock.el29 May 2005 09:15:38 -0500 1.259
--- font-lock.el01 Jun 2005 18:39:50 -0500
***
*** 683,691
adds two font
>*Warning:* Only use a non-`nil' MODE argument when you use
> `font-lock-add-keywords' or `font-lock-remove-keywords' in your
> `.emacs' file. When you use these functions from a Lisp program (such
> as a minor mode), we recommend that you use `nil' for MODE (and place
> th
The only difference between the following patch to font-lock.el and
the previous one are two doc fixes. After those doc fixes, everything
should work as documented when my three patches are applied. I still
have to look at Richard's comments about my easy-mmode patch.
===File ~/font-lock-b-diff=
Stefan Monnier wrote:
Who said it will? BTW, why did you underscore the "in your .emacs"?
Are you implying that things might be different elsewhere?
I am not implying that. I am claiming that it makes no difference
whatsoever. But several docstrings, the Emacs manual and the Elisp
manual
>Can't remember. IIRC there were problems where adding keywords to
>comint-mode didn't add them to all derivatives.
> So you actually _want_ them added to derivatives.
Typically a derivative is a minor tweak and by default it should inherit
*all* characteristics of the parent mode. This
Can't remember. IIRC there were problems where adding keywords to
comint-mode didn't add them to all derivatives.
So you actually _want_ them added to derivatives. That was not at all
obvious. The actual patches I sent will add them to derivatives as
long as the mode conventions are foll
> I still do not understand exactly what a nil argument for MODE in
> font-lock-{add,remove}-keywords is supposed to accomplish.
It adds the keywords for the current buffer only.
> When used from a Lisp program (such as a minor mode), it is recommended to
> use nil for mode (and place the cal
> Maybe we should label each of these things by the name of the minor
> mode. That way, we could tell which of them to discard. Or we could
> give each one a flag saying whether to preserve it when changing the
> major mode.
> Would that solve the problem?
Yes, I think a real solution is to def
>From my earlier message:
A permanent buffer-local minor mode that wants to add the keyword
independent of the mode could use after-change-major-mode-hook to add it.
I forgot to say that it should add it _buffer-locally_ to that hook.
Sincerely,
Luc.
__
I still do not understand exactly what a nil argument for MODE in
font-lock-{add,remove}-keywords is supposed to accomplish. The
font-lock-add-keywords docstring contains the following mysterious
sentence:
When used from a Lisp program (such as a minor mode), it is recommended to
use nil for
>From my previous message:
If one is not willing to rely on after-change-major-mode-hook,
there could be a separate font-lock-permanent-local-keywords-alist,
for permanent-local minor modes.
Actually, that should be a list, not an alist, as it does not need to
refer to the major mode.
Richard Stallman wrote:
With "current" major mode, I mean the value of `major-mode' when
font-lock-add-keywords is called. That could be the parent mode or
even an earlier ancestor mode of the final major mode.
Ok, now I understand what you meant by that particular
Richard Stallman wrote:
Any function could potentially
set up the minor mode for a given major mode, not just the minor mode
function.
I do not understand what you're talking about.
Font Lock is a pretty wild example of that.
Would you please be specific?
>Suppose we make font-lock-add-keywords with nil for MODE
>record its argument in some permanent buffer-local variable.
>Then changing the major mode and reenabling font-lock
>would use the same keywords previously added.
Problem is that some of those keywords s
The problem is that if you call these functions with `nil' for MODE,
this sets up Font Lock for the current major mode, which could be an
ancestor mode (it calls font-lock-set-defaults).
I don't understand. How can the current major mode "be" an ancestor
(buffers (intern (concat global-mode-name "-buffers")))
!(buffers-check (intern (concat global-mode-name "-check-buffers")))
!(cmmh (intern (concat global-mode-name "-cmmh")))
!(stored-mode (intern (concat (symbol-name mode) "-stored-mode"
The code would be
No, but what _really_ matters is that it is completely impossible for
define-minor-mode to reliably keep track of what major mode the minor
mode was set up for,
What is the difficulty? Please explain the reasons for this claim.
Any function could potentially
set up the mino
Stefan Monnier wrote:
The assumption is that those keywords are added via a function placed on the
major mode's hook, i.e. the keywords tweak the major mode and should thus be
removed/readded when the major mode changes.
Of course in other settings it should behave differently.
One so
I probably did not quote enough in my latest reply. The latest patch to
easy-mmode, which I just come to send, no longer has the following problem:
Note that even after this patch, there is one potentially troublesome
case left. It concerns the case of a major mode that gets enable
Richard Stallman wrote:
Would you please explain what problem would happen in this case?
I could, but it would be moot. The patch to easy-mmode I propose
below does not have the problem. It assumes, however, that the
problems for Font Lock mode get taken care of.
===File ~/easy-mmode-diff==
Richard Stallman wrote:
Anyway, how about if we change define-minor-mode so that it generates
the code to record which major mode enabled it?
The very vast majority of minor modes have no reason whatsoever to do
this.
Does that matter?
No, but what _really_
Richard Stallman wrote:
The problem is that if you call these functions with `nil' for MODE,
this sets up Font Lock for the current major mode, which could be an
ancestor mode (it calls font-lock-set-defaults).
I don't understand. How can the current major mode "be" an an
>Suppose we make font-lock-add-keywords with nil for MODE
>record its argument in some permanent buffer-local variable.
>Then changing the major mode and reenabling font-lock
>would use the same keywords previously added.
Problem is that some of those keywords should be permanent a
--- Luc Teirlinck <[EMAIL PROTECTED]> wrote:
> Both Stefan and me might have partially misunderstood your problem.
>
That's okay, I've only understood about 2% of this whole thread. :)
> `sql-interactive-mode' calls comint-mode without enclosing it in a
> delay-mode-hooks form, as it should. T
Richard Stallman wrote:
Suppose we make font-lock-add-keywords with nil for MODE
record its argument in some permanent buffer-local variable.
Then changing the major mode and reenabling font-lock
would use the same keywords previously added.
As I already said, if that variable _needs_
Richard Stallman wrote:
But it seems plausible to me that mode hook
functions might call functions that call font-lock-add-keywords.
Would that be a problem?
I am not the Font Lock maintainer and I do not know every aspect of
Font Lock. But, in as far as I understand things, if they pas
Major modes should follow the conventions for
major modes rigorously. But, in addition, they should not enable Font
Lock in any way, directly or indirectly (other than through the
define-global-minor-mode machinery), and they also should not call
font-lock-add-keywords directly
>From my previous message:
If real_this_command would be exported to Lisp, it would probably be
ideal, assuming there is no other reliable way to check whether code
is being run from a timer or asynchronous process.
Well, a timer or asynchronous process can run during a command, in
which
>From my previous message:
unless I somehow can recognize whether we are running
from a timer or process. (I can not immediately think of way to do
that. Is there away?)
To answer my own question, I guess that checking whether
`this-command' is nil should work reliably e
>From my previous message:
unless I somehow can recognize whether we are running
from a timer or process. (I can not immediately think of way to do
that. Is there away?)
To answer my own question, I guess that checking whether
`this-command' is nil should work reliably enough.
Sincere
Maybe I could still use MODE-stored-mode as a define-global-minor-mode
internal variable for efficiency reasons (unless it is easy to
recognize whether we are running from a process or timer, in which
case it is not necessary). That way, we are checking whether
_after-change-major-mode-hook_ got t
>From my previous message:
Note that even after this patch, there is one potentially troublesome
case left...
Sorry, I was confused. That entire long paragraph makes no sense
(sorry about that). Without MODE-stored-mode, I can not avoid some
inefficiency for non-file buffers (unnecessaril
I still found some problems with my latest patches to font-core. I
have corrected patches for font-core and font-lock. However, since I
do not know whether or not we will instead opt to make dis- and
re-enable Font Lock take care of the problem (which it currently does
not), I do not send the cor
Here is still another patch to easy-mmode. It gets rid of the new
MODE-stored-mode variable, replacing it with the condition that dis-
and re-enabling MODE should adapt MODE reliably to the current major
mode. That means that one way or the other, we have to take care of
Font Lock, which currentl
Richard Stallman wrote:
It sounds like you are saying that with your patch, Font Lock mode
still works wrong.
Essentially, yes. It can only work correctly if all major modes not
only adhere strictly to our new Emacs 22 conventions, but in addition
carefully avoid anything that enables font
Richard Stallman wrote:
I think I understand that. But...
In effect, we know of at least
two examples of major modes that do this, comint-mode and
interactive-sql-mode.
This makes no sense to me. I thought you were talking about minor
modes and what they need to
Hopefully, we are only talking about Font Lock. The new
patch to font-core makes font-lock-mode issue a warning, thereby
taking care of Stefan's objection.
It sounds like you are saying that with your patch, Font Lock mode
still works wrong. And all the patch does is warn the user
Why not have
define-global-minor-mode automatically arrange to save the value in
that variable?
Because we have to know in which major mode the minor mode was
enabled. That could easily happen behind define-global-minor-mode's
back, by using the non-global variant.
Here are the latest versions of my patches to easy-mmode and
font-core. The patch to cwarn remains unchanged from the revised
version I sent earlier.
The docstring of `define-global-minor-mode' now says that if the minor
mode's setup depends on the major mode for which it was enabled, it
should f
Stefan Monnier wrote:
> ! (unless (eq font-lock-mode-stored-mode major-mode)
> ! (setq font-lock-set-defaults nil))
As I said earlier, the above "fix up" may break things. It's OK because at
that point there's no much else we can do, but we really need to inform the
use
Richard Stallman wrote:
The reference "the function that does the initial set-up" is not concrete.
I am not completely sure which function you mean. It would be better
to refer to it by name.
In the latest version of the patch I am going to send soon, it just
says that enabling the mode
Richard Stallman wrote:
To clarify, this is how comint enables Font Lock:
(defcustom comint-mode-hook '(turn-on-font-lock)
Shouldn't we remove that? Is it a desirable thing, nowadays,
for some modes to enable Font Lock on their own, instead of letting
the user do so if he
To clarify, this is how comint enables Font Lock:
(defcustom comint-mode-hook '(turn-on-font-lock)
Shouldn't we remove that? Is it a desirable thing, nowadays,
for some modes to enable Font Lock on their own, instead of letting
the user do so if he wants?
__
! If the minor mode's set-up depends on the major mode, the function that
! does the initial set-up should record the value of the variable
`major-mode'
! in the variable MODE-stored-mode.
The reference "the function that does the initial set-up" is not concrete.
I am not completely s
My original patch for font-lock.el had problems. It did not work well
for modes that only use font-lock for font-lock-face and it did not
work for modes with a non-standard font-lock-function. I now propose
to leave font-lock.el unchanged and to apply the patch below to
font-core.el instead.
I a
To clarify, this is how comint enables Font Lock:
(defcustom comint-mode-hook '(turn-on-font-lock)
...
Without delay-mode-hooks, this is executed at the end of the call to
comint-mode. With delay-mode-hooks, it is run during the call to
run-mode-hooks, just before your own hook. Note that a use
Both Stefan and me might have partially misunderstood your problem.
`sql-interactive-mode' calls comint-mode without enclosing it in a
delay-mode-hooks form, as it should. To standardize your mode, you
should either define it using `define-derived-mode' (see `(elisp)Derived
Modes') or read `(elis
>From my earlier message:
When testing this patch, do not rely on stuff like `C-h v
font-lock-set-defaults', because this is currently buggy.
This is a consequence of a bug I reported in another thread,
`Bug in buffer-local-value'.
Sincerely,
Luc.
__
Here are my proposed changes to easy-mmode.el. Unlike my previous
proposed patch, they require some cooperation from the individual
minor modes, but this seemed necessary to catch (and attempt to work
around) all possible ways to mess up the major mode for which the
minor mode is set up. The onl
> I've run into the same problem in sql-mode; the need to alter the
> font-lock rules after font-lock-mode has been enabled. My current
> solution is as follows:
> ;; Force font lock to reinitialize if it is already on
> ;; Otherwise, we can wait until it can be started.
> (when (and
Michael Mauger wrote:
;; Force font lock to reinitialize if it is already on
;; Otherwise, we can wait until it can be started.
(when (and (fboundp 'font-lock-mode)
(boundp 'font-lock-mode)
font-lock-mode)
(font-lock-defontify)
Michael Mauger wrote:
;; Force font lock to reinitialize if it is already on
;; Otherwise, we can wait until it can be started.
(when (and (fboundp 'font-lock-mode)
(boundp 'font-lock-mode)
font-lock-mode)
(font-lock-defontify)
Luc Teirlinck dms.auburn.edu> writes:
>
> Stefan Monnier wrote:
>
>Can you explain the change?
>I really don't like the
>
> (defun turn-on-font-lock-as-appropriate ()
>(let (font-lock-set-defaults)
>(turn-on-font-lock-if-enabled)))
>
>since it may cause font-l
Of course my method failed to find any major modes that don't run mode
hooks at all. Maybe someone else could try to fix those?
Perhaps one could find these easily with a Lisp program
that searches for a defun whose start matches "(defun [-a-z]+-mode "
and that does not contain "(run-".
> We also need to find other modes that are effectively "derived" and
> ought to use delay-mode-hooks. I think one could write a Lisp program
> that would search for a match for "([-a-z]+-mode " within a defun that
> starts with "(defun [-a-z]+-mode ".
For searching in Lisp structures I use the f
> If there are any major modes that fail to use run-mode-hooks, we want
> to fix them now. It would be good for someone to look for them.
I'll do that.
I see you have already done it. Thank you.
We also need to find other modes that are effectively "derived" and
ought to use delay-
Lute Kamstra <[EMAIL PROTECTED]> writes:
> Richard Stallman <[EMAIL PROTECTED]> writes:
>
>> If there are any major modes that fail to use run-mode-hooks, we want
>> to fix them now. It would be good for someone to look for them.
>
> I'll do that.
I've fixed some 100 major modes by grepping lisp
I understand better now, thank you.
> after-change-major-mode ran to soon. (Maybe we should also print an
> error message in this case, which my current patch does not).
Yes, I think it's more important to signal a clear warning/error than to try
and auto-fix the problem.
BTW, why use "check-"
Richard Stallmn wrote:
Thus, I think each global minor mode needs to have its own
variable for this purpose.
That is correct. I will change my patch to implement this, once we
are sure that my patch is really basically the way to go.
Sincerely,
Luc.
Stefan Monnier wrote:
Can you explain the change?
I really don't like the
(defun turn-on-font-lock-as-appropriate ()
(let (font-lock-set-defaults)
(turn-on-font-lock-if-enabled)))
since it may cause font-lock-keywords to be reset from font-lock-defaults,
thus thr
The following changes fix both bugs, by using post-command-hook to
check whether font-lock was enabled for the correct mode and adapting
the turn-on function to be able to correct it.
That is a clever solution. However, I think there may be a bug in the
code. The reason is that any n
> The following changes fix both bugs, by using post-command-hook to
> check whether font-lock was enabled for the correct mode and adapting
> the turn-on function to be able to correct it. I still will have to
> see whether this automatically fixes the second bug for other
> functions defined wit
1 - 100 of 121 matches
Mail list logo
