bug#38111: 27.0.50; globalized-minor-mode not enabled on get-buffer-create

bug#38111: 27.0.50; globalized-minor-mode not enabled on get-buffer-create

[Juri Linkov]

This looks like a bug.  I found this issue while using global-tab-line-mode,
but to confirm that it's unrelated to tab-line, this bug report uses another
globalized minor-mode global-display-fill-column-indicator-mode:

0. emacs -Q
1. M-x global-display-fill-column-indicator-mode RET
2. C-x b test1 RET
3. RET  ;; this inserts newline to show column indicator
        ;; that confirms this mode is enabled in the buffer

4. M-: (switch-to-buffer (get-buffer-create "test2")) RET
5. RET  ;; no column indicator, mode not enabled
6. C-h v display-fill-column-indicator-mode RET
   ;; confirms its value is nil

bug#38111: 27.0.50; globalized-minor-mode not enabled on get-buffer-create

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Thu, 07 Nov 2019 23:53:04 +0200
> 
> This looks like a bug.  I found this issue while using global-tab-line-mode,
> but to confirm that it's unrelated to tab-line, this bug report uses another
> globalized minor-mode global-display-fill-column-indicator-mode:
> 
> 0. emacs -Q
> 1. M-x global-display-fill-column-indicator-mode RET
> 2. C-x b test1 RET
> 3. RET  ;; this inserts newline to show column indicator
>         ;; that confirms this mode is enabled in the buffer
> 
> 4. M-: (switch-to-buffer (get-buffer-create "test2")) RET
> 5. RET  ;; no column indicator, mode not enabled
> 6. C-h v display-fill-column-indicator-mode RET
>    ;; confirms its value is nil

Sounds like globalized-minor-mode machinery sdomehow doesn't support
the latter method of creating a buffer?  Does the turn-on function of
the mode get called in that scenario?

bug#38111: 27.0.50; globalized-minor-mode not enabled on get-buffer-create

[Juri Linkov]

tags 38111 + notabug
close 38111
quit

>> This looks like a bug.  I found this issue while using global-tab-line-mode,
>> but to confirm that it's unrelated to tab-line, this bug report uses another
>> globalized minor-mode global-display-fill-column-indicator-mode:
>>
>> 0. emacs -Q
>> 1. M-x global-display-fill-column-indicator-mode RET
>> 2. C-x b test1 RET
>> 3. RET  ;; this inserts newline to show column indicator
>>         ;; that confirms this mode is enabled in the buffer
>>
>> 4. M-: (switch-to-buffer (get-buffer-create "test2")) RET
>> 5. RET  ;; no column indicator, mode not enabled
>> 6. C-h v display-fill-column-indicator-mode RET
>>    ;; confirms its value is nil
>
> Sounds like globalized-minor-mode machinery sdomehow doesn't support
> the latter method of creating a buffer?  Does the turn-on function of
> the mode get called in that scenario?

'C-x b' (switch-to-buffer) uses ‘window-normalize-buffer-to-switch-to’
to call after 'get-buffer-create' explicitly:

  (set-buffer-major-mode buffer)

It seems this is not a problem in practice, since callers
can add set-buffer-major-mode, so closing.

bug#38111: 27.0.50; globalized-minor-mode not enabled on get-buffer-create

[Phil Sainty]

On 2019-11-08 22:50, Eli Zaretskii wrote:
> Sounds like globalized-minor-mode machinery somehow doesn't support
> the latter method of creating a buffer?

Yep, globalized modes use `after-change-major-mode-hook' to call the
buffer-local minor mode, and that hook is not triggered in these cases
because, although new buffers are in `fundamental-mode' by default,
the `fundamental-mode' function is not actually called, and so no mode
change occurs.

I believe this has cropped up in past discussion, but I don't recall
where offhand.

I agree that it's surprising when you are expecting the global mode(s)
to be enabled (I first realised it when attempting to use a globalized
mode for my custom key bindings, and discovering they were not being
enabled in various buffers).

If this were changed then there *might* be undesirable consequences to
having lots of created-behind-the-scenes buffers suddenly doing things
they never did before.

If the current behaviour is kept, the documentation for globalized
modes and for creating buffers should probably say something about the
matter.


-Phil

bug#38111: 27.0.50; globalized-minor-mode not enabled on get-buffer-create

[Juri Linkov]

>> Sounds like globalized-minor-mode machinery somehow doesn't support
>> the latter method of creating a buffer?
>
> Yep, globalized modes use `after-change-major-mode-hook' to call the
> buffer-local minor mode, and that hook is not triggered in these cases
> because, although new buffers are in `fundamental-mode' by default,
> the `fundamental-mode' function is not actually called, and so no mode
> change occurs.
>
> I believe this has cropped up in past discussion, but I don't recall
> where offhand.
>
> I agree that it's surprising when you are expecting the global mode(s)
> to be enabled (I first realised it when attempting to use a globalized
> mode for my custom key bindings, and discovering they were not being
> enabled in various buffers).
>
> If this were changed then there *might* be undesirable consequences to
> having lots of created-behind-the-scenes buffers suddenly doing things
> they never did before.
>
> If the current behaviour is kept, the documentation for globalized
> modes and for creating buffers should probably say something about the
> matter.

Thanks for referring to the documentation.  It already explains this in
(info "(elisp) Defining Minor Modes")

 -- Macro: define-globalized-minor-mode global-mode mode turn-on
          keyword-args... body...
...
     Globally enabling the mode also affects buffers subsequently
     created by visiting files, and buffers that use a major mode other
     than Fundamental mode; but it does not detect the creation of a new
     buffer in Fundamental mode.

bug#38111: 27.0.50; globalized-minor-mode not enabled on get-buffer-create

[Eli Zaretskii]

> Date: Wed, 13 Nov 2019 11:42:07 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: Juri Linkov <juri@linkov.net>, 38111@debbugs.gnu.org
> 
> If the current behaviour is kept, the documentation for globalized
> modes and for creating buffers should probably say something about the
> matter.

I think updating the documentation about this is indeed the way to go
in this case.

Thanks.

bug#38111: 27.0.50; globalized-minor-mode not enabled on get-buffer-create

[Juri Linkov]

reopen 38111
tags 38111 - notabug
quit

>> Sounds like globalized-minor-mode machinery somehow doesn't support
>> the latter method of creating a buffer?
>
> Yep, globalized modes use `after-change-major-mode-hook' to call the
> buffer-local minor mode, and that hook is not triggered in these cases
> because, although new buffers are in `fundamental-mode' by default,
> the `fundamental-mode' function is not actually called, and so no mode
> change occurs.
>
> I believe this has cropped up in past discussion, but I don't recall
> where offhand.
>
> I agree that it's surprising when you are expecting the global mode(s)
> to be enabled (I first realised it when attempting to use a globalized
> mode for my custom key bindings, and discovering they were not being
> enabled in various buffers).
>
> If this were changed then there *might* be undesirable consequences to
> having lots of created-behind-the-scenes buffers suddenly doing things
> they never did before.

Actually that turned out to be a problem in practice, e.g. with this recipe:

0. emacs -Q
1. M-x global-display-fill-column-indicator-mode RET

2. M-& ls -la RET  ;; or any other command that produces enough lines
3. observe that the global mode is activated in the output buffer

4. M-! ls -la RET
5. the global mode is NOT activated in the output buffer

The difference between these two is that shell-command-on-region uses just

  (get-buffer-create "*Shell Command Output*")

and doesn't set its default fundamental-mode explicitly.

The following patch fixes this, but I'm still not sure if we need
to grep all occurrences of get-buffer-create and add set-buffer-major-mode
everywhere?

diff --git a/lisp/simple.el b/lisp/simple.el
index 67ddab3d34..1c4fdf9945 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -3925,6 +3926,7 @@ shell-command-on-region
         ;; replacing its entire contents.
         (let ((buffer (get-buffer-create
                        (or output-buffer "*Shell Command Output*"))))
+          (set-buffer-major-mode buffer)
           (unwind-protect
               (if (and (eq buffer (current-buffer))
                        (or (not shell-command-dont-erase-buffer)

bug#38111: 27.0.50; globalized-minor-mode not enabled on get-buffer-create

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  38111@debbugs.gnu.org
> Date: Sun, 08 Dec 2019 00:56:00 +0200
> 
> The following patch fixes this, but I'm still not sure if we need
> to grep all occurrences of get-buffer-create and add set-buffer-major-mode
> everywhere?

This is a problem with all globalized minor modes, right?

bug#38111: 27.0.50; globalized-minor-mode not enabled on get-buffer-create

[Juri Linkov]

>> The following patch fixes this, but I'm still not sure if we need
>> to grep all occurrences of get-buffer-create and add set-buffer-major-mode
>> everywhere?
>
> This is a problem with all globalized minor modes, right?

Yes, with all globalized minor modes.

So I installed the patch that fixes this particular case,
and leaving this bug report open waiting for a more general solution.

bug#38111: 27.0.50; globalized-minor-mode not enabled on get-buffer-create

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>>> The following patch fixes this, but I'm still not sure if we need
>>> to grep all occurrences of get-buffer-create and add set-buffer-major-mode
>>> everywhere?
>>
>> This is a problem with all globalized minor modes, right?
>
> Yes, with all globalized minor modes.
>
> So I installed the patch that fixes this particular case,
> and leaving this bug report open waiting for a more general solution.

I don't think a general solution is really possible here.  We don't want
any get-buffer-create to run the globalised modes -- that would be slow
and awkward.  We only want those to run in buffers that users actually
end up using, and I think that's something the modes themselves must
somehow decide.

So I don't think there's any realistic progress to be made in this bug
report, and I'm closing it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no