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

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

[Rolf Ade]

I see the following with emacs 24.5.1 as well as with 25.1.50.2, even
with emacs -Q.

If the major mode of a new buffer is determined by the variable
major-mode (nothing from auto-mode-alist et. al matches), then the hooks
of that major mode doesn't run, as I expect.

From what I see, it looks like the hooks do run, but in this case (mode
selection comes from major-mode, not from auto-mode-alist) somehow
wrapped into a (save-excursion).

To reproduce, do:

- Prepare a file with a suffix not included in auto-mode-alist (e.g.
  test.abc) with some text in it. Create a copy of that file with the
  name test.txt

- Start emacs -Q

- In the scratch buffer, evaluate:

(setq-default major-mode 'text-mode)
(add-hook 'text-mode-hook 'end-of-buffer)

- find-file the above prepared file test.abc

After opening the file, the buffer is in fact in text-mode. But the
point is at the beginning of the buffer, not at the end (as, at least I
expected).

- Then open the file test.txt.

In this case, the major mode of the new buffer is determined by
auto-mode-alist (the default of this variable includes ("\\.te?xt\\'" .
text-mode)). After opening the file, the buffer is, as expected, also in
text-mode, but now the point is at the end of the buffer.

Further observations:

- This isn't special to text-mode. If I do the steps from above with
  another major mode (in an appropriate way), I see the same.

- From what I see, the hooks do run, even if the mode is determined by
  major-mode. You may verify this by adding

  (add-hook 'text-mode-hook 'auto-fill-mode)

  to the third step above.

Is it me, doing something wrong or stupid? If not, what's the rationale
behind this behavior?

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

[Drew Adams]

> If the major mode of a new buffer is determined by the variable
> major-mode (nothing from auto-mode-alist et. al matches), then the hooks
> of that major mode doesn't run, as I expect.

`major-mode' is a buffer-local variable.
It is set by the newly current major mode.
IOW, you cannot use it to set the mode, as the mode sets it.

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

[Michael Heerdegen]

Rolf Ade <rolf@pointsman.de> writes:

> Is it me, doing something wrong or stupid? If not, what's the
> rationale behind this behavior?

Though it's better to set `default-major-mode' and use (goto-char
(point-max)) instead of `end-of-buffer' (which sets the mark) - it
should work as you expect.  But it doesn't.

I tried to edebug `set-auto-mode' - this is where the point is
apparently set to the buffer's beginning.  But the point seems to be
changed magically right after the beginning without any code involved.

Either some hook is doing that, or this is some internal thing at the C
level (bug?).

In a different trial, I traced `goto-char' and `point-min'.  But every
of these calls was inside a `save-excursion'.

So, from the Lisp level, it's a miracle.


Michael.

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

[Rolf Ade]

Drew Adams <drew.adams@oracle.com> writes:

>> If the major mode of a new buffer is determined by the variable
>> major-mode (nothing from auto-mode-alist et. al matches), then the hooks
>> of that major mode doesn't run, as I expect.
>
> `major-mode' is a buffer-local variable.
> It is set by the newly current major mode.
> IOW, you cannot use it to set the mode, as the mode sets it.

So, what do you think determines the major-mode of a new buffer, if (as
I wrote) nothing from auto-mode-alist, interpreter-mode-alist and
magic-mode-alist matches? What should I use for that (if I don't want
the default fundamental-mode)?

It is right, that major-mode is a buffer-local variable. And it is also
true, that it is set by the newly current major-mode. But what value
does the local variable major-mode have, if there isn't a major-mode,
for a new buffer? Right, its default value. And this is a way to set the
major mode of a new buffer, if there isn't another known from other
sources.

Take a look at C-h v major-mode RET. (And, maybe, C-h v
default-major-mode RET).

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

[Drew Adams]

> >> If the major mode of a new buffer is determined by the variable
> >> major-mode (nothing from auto-mode-alist et. al matches), then the
> >> hooks of that major mode doesn't run, as I expect.
> >
> > `major-mode' is a buffer-local variable.
> > It is set by the newly current major mode.
> > IOW, you cannot use it to set the mode, as the mode sets it.
> 
> So, what do you think determines the major-mode of a new buffer, if (as
> I wrote) nothing from auto-mode-alist, interpreter-mode-alist and
> magic-mode-alist matches? What should I use for that (if I don't want
> the default fundamental-mode)?

Well, I was wrong, it seems; sorry.

I was going to say "Customize option `default-major-mode', but
`C-h v' tells me this:

   This variable is obsolete since 23.2;
   use `major-mode' instead.

 Documentation:
 Value of `major-mode' for new buffers.

So you can still customize it (I do), but you can also
just customize `major-mode', to provide the default value.

And `C-h v major mode' tells you how it works.  Summary:
it works just like `default-major-mode' works (and used to
work).  The current doc string for option `major-mode' is
identical to the pre-Emacs 23.2 doc string for
`default-major-mode' (except for the first line).

Seems to me that it was less confusing before this change,
but I suppose there were good reasons that offset the added
confusion.

Unfortunately, they did not put anything in the Emacs 23.2
NEWS about this change, so you would need to do a bit of
archaeology to find the rationale for the change.

> Take a look at C-h v major-mode RET. (And, maybe, C-h v
> default-major-mode RET).

Right.  Sorry for introducing confusion.

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

[Rolf Ade]

Michael Heerdegen <michael_heerdegen@web.de> writes:
> Rolf Ade <rolf@pointsman.de> writes:
>> Is it me, doing something wrong or stupid? If not, what's the
>> rationale behind this behavior?
>
> Though it's better to set `default-major-mode' and use (goto-char
> (point-max)) instead of `end-of-buffer' (which sets the mark) - it
> should work as you expect.  But it doesn't.

Thanks for confirming.

The variable `default-major-mode' was, what I used since ages in my
init.el just to learn this evening, while analyzing this problem, that
this variable is obsolete since 23.2, see C-h v default-major-mode RET.

The documentation of `default-major-mode' points to major-mode. The
behavior is the same, regardless which of the two variables I use.

Also true is your note about (goto-char (point-max)). I tested both with
the same behavior. Picked just 'end-of-buffer to simplify the
reproducing recipe.

Diging further I realize, that what the documentation say explains, what
I see. C-h v major#-mode RET say:

    When a mode is used by default, `find-file' switches to it before it
    reads the contents into the buffer and before it finishes setting up
    the buffer. Thus, the mode and its hooks should not expect [...]

If the mode-hooks run, before the content is read into the buffer it
isn't surprising that (end-of-buffer) doesn't set the point at the end
of the (up to know not read into) content.

But this documentation doesn't tell the truth.

- Prepare a file with a suffix not included in auto-mode-alist (e.g.
  test.abc) with some text in it. Create a copy of that file with the
  name test.txt

- Start emacs -Q

- In the scratch buffer, evaluate:

(setq-default major-mode 'text-mode)
(add-hook 'text-mode-hook (lambda () (message "End of buffer: %s" (point-max))))

- find-file the above prepared file test.abc

If your file test.abc contains some text, as requested, something other
than 1 is show in the message line. If the content isn't read into the
buffer at the moment, the hook runs, how could it know the (point-max)
of the up to now not known data?

rolf

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

[Drew Adams]

> But this documentation doesn't tell the truth.

Then please consider filing a doc bug report about it.
(`M-x report-emacs-bug'.)

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

[Michael Heerdegen]

Rolf Ade <rolf@pointsman.de> writes:

> But this documentation doesn't tell the truth.

Or we all misunderstand it.  In both cases, a bug report could be
appropriate.


Michael.

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

[Rolf Ade]

Michael Heerdegen <michael_heerdegen@web.de> writes:
> Rolf Ade <rolf@pointsman.de> 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.

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.

Are this two different bug reports?

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.

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

[Michael Heerdegen]

Rolf Ade <rolf@pointsman.de> 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
outdated).


> 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.


Regards,

Michael.