[Top][All Lists]

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

Re: Hook doesn't run as expected, if buffer mode is set from major-mode

From: Michael Heerdegen
Subject: Re: Hook doesn't run as expected, if buffer mode is set from major-mode
Date: Sun, 10 Jan 2016 05:29:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Rolf Ade <> writes:

> >> But this documentation doesn't tell the truth.
> >
> > Or we all misunderstand it.  In both cases, a bug report could be
> > appropriate.
> Unfortunately I feel a bit uncomfortable to express myself in English;
> I'm afraid I can't make my point clear enough.

I think I already perfectly understood (with "we all misunderstand it" I
meant the docs, not what you said - but I guess the doc is just

> At the moment, I see two different, although related topics:
> 1) The (for my eyes) much more important fact is, that you may have two
> files with identical content and which only differ in file name
> suffix. Depending on your default major mode, your auto-mode-alist and
> the mode hooks of your default major mode it is possible, that you open
> the one of that file and then the other - and the two buffers have the
> same major mode but are in a different state.
> Or, to put it in other words: The effect (or the result or whatever the
> appropriate word would be) of the mode hooks of your default major mode
> depends not only on the elisp code of that hooks and the content of the
> buffer, but - at least for me a bit surpising or unexpected - also on
> the question if a new opened buffer get its major mode by a match in
> auto-mode-alist or by default major mode.
> 2) The other, somewhat minor topic is the documentation of
> `major-mode'. It suggests (although somewhat vague) that a new buffer
> switches to the default mode (and run the mode hooks) in such an eary
> state, that the contents aren't already read into the buffer (and
> therefor, the hook code can't work on the content or have the content to
> look at). This seems not to be true (at least not completely), from what
> I see. Some mystery things happen, so that, at the end, it looks like it
> would be so, as the documentation say, but it isn't true.

Yes.  Though for 1), we only have a one special case, so it can be
coincidental that some weird bug in C breaks 1).

> Are this two different bug reports?

I think so.  They can be merged later, if they appear to be related.
But you can add a note like "also see related #nnnnn" or so.

> And, out of curiosity, why are the things, as they seem to be? Why isn't
> the process of opening a file just (schematic):
> - Buffer is created
> - Bile content is read into the buffer
> - The major mode of the new buffer is searched by looking at
>   auto-mode-alist, interpreter-mode-alist and magic-mode-alist (and what
>   not else).
> - If a major mode is found, in the step above, the buffers local
>   variable major-mode is set to this and the mode hooks do run.
> - If no applicable mode was found, above, the mode of the new buffer is
>   the default mode and the hooks if that mode run.

I think that's the case now, more or less.  As I said, I didn't find an
explanation for the behavior you get in the Lisp sources.  There could
be a problem on a lower level, and what you see was never intended.



reply via email to

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