bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[積丹尼 Dan Jacobson]

global-display-fill-column-indicator-mode is great. However it makes no
sense and is simply a distraction on readonly buffers, e.g., *Help* etc.

(Of course some people might still enjoy it there.)
emacs-version "27.1"

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Lars Ingebrigtsen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> global-display-fill-column-indicator-mode is great. However it makes no
> sense and is simply a distraction on readonly buffers, e.g., *Help* etc.
>
> (Of course some people might still enjoy it there.)

Yeah, it's not very useful in special mode buffers, is it?  On the other
hand, it's pretty useless in all modes that aren't text-like, whether
they're read-only or not, so I'd expect people to only switch the mode
on in modes that inherit from text-mode, probably.

I'm not sure anything can be done for
global-display-fill-column-indicator-mode, though -- a global mode is,
well, global?  Is there any mechanism in place for making global modes
less global?

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

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[積丹尼 Dan Jacobson]

(A workaround might be for
    fill-column is a variable defined in ‘C source code’.
    Its value is 70
to be turned off for Dired, Gnus, etc. buffers.)

(Hmmm, (describe-variable 'fill-column) doesn't say what happens when one
makes it nil, or how to make it "infinity.")

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Lars Ingebrigtsen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> (A workaround might be for
>     fill-column is a variable defined in ‘C source code’.
>     Its value is 70
> to be turned off for Dired, Gnus, etc. buffers.)

That's true.  `special-mode' could set it to nil, and then everything
that inherits from that would have no fill column.

Does anybody see any disadvantages to that?

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

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 26 Oct 2020 12:17:07 +0100
> Cc: 44232@debbugs.gnu.org
> 
> 積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:
> 
> > (A workaround might be for
> >     fill-column is a variable defined in ‘C source code’.
> >     Its value is 70
> > to be turned off for Dired, Gnus, etc. buffers.)
> 
> That's true.  `special-mode' could set it to nil, and then everything
> that inherits from that would have no fill column.
> 
> Does anybody see any disadvantages to that?

This is an opt-in feature.  People who don't like it can solve that
very easily: by never enabling this mode.

As for the specific suggestion: it sounds somewhat kludgey to me.  Why
not take the Emacsy way: add a defcustom that lists major modes whose
users are unlikely to want this mode turned on, and let the default
value include the modes you think belong to that group.  (It should be
a defcustom because I can easily envision someone who may wish to see
this indicator even in those modes, perhaps to use it for some purpose
other than filling, e.g. to find filenames longer than some limit in
Dired.)

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson
>  <jidanni@jidanni.org>
> Date: Mon, 26 Oct 2020 19:09:06 +0800
> Cc: 44232@debbugs.gnu.org
> 
> (Hmmm, (describe-variable 'fill-column) doesn't say what happens when one
> makes it nil

What do you think happens then?

> or how to make it "infinity."

What is "infinity" in this context, and why would one need it?

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> As for the specific suggestion: it sounds somewhat kludgey to me.  Why
> not take the Emacsy way: add a defcustom that lists major modes whose
> users are unlikely to want this mode turned on, and let the default
> value include the modes you think belong to that group.

Is this how other globalized minor modes work?  I tried poking around
but couldn't really see any patterns...

But here's one that works along this way:

---
highlight-changes-global-modes is a variable defined in ‘hilit-chg.el’.
Its value is t

  You can customize this variable.

Documentation:
Determine whether a buffer is suitable for global Highlight Changes mode.

A function means call that function to decide: if it returns non-nil,
the buffer is suitable.

A list means the elements are major modes suitable for Highlight
Changes mode, or a list whose first element is ‘not’ followed by major
modes which are not suitable.

A value of t means the buffer is suitable if it is visiting a file and
its name does not begin with ‘ ’ or ‘*’.

A value of nil means no buffers are suitable for ‘global-highlight-changes-mode’
(effectively disabling the mode).

Example:
	(c-mode c++-mode)
means that Highlight Changes mode is turned on for buffers in C and C++
modes only.
---

So it's a complex

(c-mode (not text-mode) ...)

kind of thing that sounds like it could be generalised for globalized
minor modes.  (Although I'd say use derived-mode-p instead of eq to
check.)

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

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[積丹尼 Dan Jacobson]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
>> (Hmmm, (describe-variable 'fill-column) doesn't say what happens when one
>> makes it nil

EZ> What do you think happens then?

No idea. Wish they would document this stuff.

>> or how to make it "infinity."

EZ> What is "infinity" in this context, and why would one need it?

All I know is I often use C-u 9999 C-x f
to get the effect I want, as no other way is documented.

So the fill-column Docstring should say how to make it infinity(=no filling).

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> As for the specific suggestion: it sounds somewhat kludgey to me.  Why
>> not take the Emacsy way: add a defcustom that lists major modes whose
>> users are unlikely to want this mode turned on, and let the default
>> value include the modes you think belong to that group.
>
> Is this how other globalized minor modes work?  I tried poking around
> but couldn't really see any patterns...

Does whitespace-enable-predicate fit the bill?

-- 
Basil

bug#44232: (no subject)

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> As for the specific suggestion: it sounds somewhat kludgey to me.  Why
>>> not take the Emacsy way: add a defcustom that lists major modes whose
>>> users are unlikely to want this mode turned on, and let the default
>>> value include the modes you think belong to that group.
>>
>> Is this how other globalized minor modes work?  I tried poking around
>> but couldn't really see any patterns...
>
> Does whitespace-enable-predicate fit the bill?

That's basically the same as highlight-changes-global-modes, but with
the added

         ;; ...the buffer is not internal (name starts with a space)
         (not (eq (aref (buffer-name) 0) ?\ ))
         ;; ...the buffer is not special (name starts with *)
         (or (not (eq (aref (buffer-name) 0) ?*))

So that's kinda kludgy.

And the syntax for highlight-changes-global-modes was simpler than I
thought when skimming -- it requires the `not' to be the first element,
etc, so it's not really that flexible.

Perhaps `define-globalized-minor-mode' should take a keyword to create
one of these defcustoms (with semantics like I sketched previously)...
then there'd be more opportunity for shared behaviour.

I'll take a whack at writing that.

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

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: jidanni@jidanni.org,  44232@debbugs.gnu.org
> Date: Mon, 26 Oct 2020 17:19:25 +0100
> 
> Example:
> 	(c-mode c++-mode)
> means that Highlight Changes mode is turned on for buffers in C and C++
> modes only.
> ---
> 
> So it's a complex
> 
> (c-mode (not text-mode) ...)

I proposed something simpler: a list of modes where
display-fill-column-indicator-mode will NOT be turned on automatically
by the globalized minor mode.

> (Although I'd say use derived-mode-p instead of eq to check.)

Yes, of course.

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: larsi@gnus.org,  44232@debbugs.gnu.org
> Date: Tue, 27 Oct 2020 00:25:07 +0800
> 
> >>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> >> (Hmmm, (describe-variable 'fill-column) doesn't say what happens when one
> >> makes it nil
> 
> EZ> What do you think happens then?
> 
> No idea. Wish they would document this stuff.

There's nothing to document, AFAICT: the value must be a number.

> >> or how to make it "infinity."
> 
> EZ> What is "infinity" in this context, and why would one need it?
> 
> All I know is I often use C-u 9999 C-x f
> to get the effect I want, as no other way is documented.
> 
> So the fill-column Docstring should say how to make it infinity(=no filling).

There's no such setting; use a value larger than any window, like you
did.

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>> As for the specific suggestion: it sounds somewhat kludgey to me.  Why
>>>> not take the Emacsy way: add a defcustom that lists major modes whose
>>>> users are unlikely to want this mode turned on, and let the default
>>>> value include the modes you think belong to that group.
>>>
>>> Is this how other globalized minor modes work?  I tried poking around
>>> but couldn't really see any patterns...
>>
>> Does whitespace-enable-predicate fit the bill?
>
> That's basically the same as highlight-changes-global-modes, but with
> the added
>
>          ;; ...the buffer is not internal (name starts with a space)
>          (not (eq (aref (buffer-name) 0) ?\ ))
>          ;; ...the buffer is not special (name starts with *)
>          (or (not (eq (aref (buffer-name) 0) ?*))
>
> So that's kinda kludgy.

It's not quite the same thing, because whitespace-enable-predicate only
takes on function values, and is explicitly intended to be customised
with the existing DSL of add-function, rather than a new ad-hoc DSL.

[Not that I'd argue for the superiority of whitespace-enable-predicate
over other customisation approaches.]

-- 
Basil

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

>> That's basically the same as highlight-changes-global-modes, but with
>> the added
>>
>>          ;; ...the buffer is not internal (name starts with a space)
>>          (not (eq (aref (buffer-name) 0) ?\ ))
>>          ;; ...the buffer is not special (name starts with *)
>>          (or (not (eq (aref (buffer-name) 0) ?*))
>>
>> So that's kinda kludgy.
>
> It's not quite the same thing, because whitespace-enable-predicate only
> takes on function values, and is explicitly intended to be customised
> with the existing DSL of add-function, rather than a new ad-hoc DSL.

I'm not quite sure I follow.  The bit before the thing I quoted was
pretty much the equivalent of highlight-changes-global-modes:

          ((listp whitespace-global-modes)
           (if (eq (car-safe whitespace-global-modes) 'not)
               (not (memq major-mode (cdr whitespace-global-modes)))
             (memq major-mode whitespace-global-modes)))

> [Not that I'd argue for the superiority of whitespace-enable-predicate
> over other customisation approaches.]

So I'd say whitespace-enable-predicate has the same ad-hoc DSL built in,
but with an add-function DSL on top of it?

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

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I proposed something simpler: a list of modes where
> display-fill-column-indicator-mode will NOT be turned on automatically
> by the globalized minor mode.

Yes, I just generalised, since a couple modes already have a more
general logic here (like highlight-changes-mode-turn-on).  (And then I
generalised that a bit more.)

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

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Lars Ingebrigtsen]

And I've now pushed the change to
global-display-fill-column-indicator-mode, so it's off in special-mode
buffers by default, and I'm closing this bug report.

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

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 44232@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Mon, 26 Oct 2020 19:26:27 +0100
> 
> And I've now pushed the change to
> global-display-fill-column-indicator-mode, so it's off in special-mode
> buffers by default, and I'm closing this bug report.

Thanks, but the variable global-display-fill-column-indicator-modes
you advertised doesn't seem to exist...

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, but the variable global-display-fill-column-indicator-modes
> you advertised doesn't seem to exist...

Hm, it only seems to exist after you've switched
`global-display-fill-column-indicator-mode' on...  I must have put the
defcustom form in the wrong place; will fix.

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

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Lars Ingebrigtsen]

No, you just need to load display-fill-column-indicator.el, like with
any defcustom that belongs in that file, I think?  It's not
;;;###autoloaded...

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

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 44232@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Mon, 26 Oct 2020 19:51:59 +0100
> 
> No, you just need to load display-fill-column-indicator.el, like with
> any defcustom that belongs in that file, I think?  It's not
> ;;;###autoloaded...

Which means this defcustom is unlike any other: you cannot "M-x
customize-variable" it until you load the mode?  That's confusing, I
think.

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Which means this defcustom is unlike any other: you cannot "M-x
> customize-variable" it until you load the mode?  That's confusing, I
> think.

Is there special magic for defcustoms?

I just tried "emacs -Q" and `M-x customize-variable RET gnusTAB' and I
get a single user option (which is ;;;###autoloaded).  The other two
million gnus variables only appear after I load gnus...

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

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 44232@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Mon, 26 Oct 2020 20:20:39 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Which means this defcustom is unlike any other: you cannot "M-x
> > customize-variable" it until you load the mode?  That's confusing, I
> > think.
> 
> Is there special magic for defcustoms?

No.

Sorry, I meant the minor-mode variables: those are autoloaded by
define-minor-mode.  So maybe you could teach define-minor-mode to also
autoload the variable generated by :predicate.

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Sorry, I meant the minor-mode variables: those are autoloaded by
> define-minor-mode.  So maybe you could teach define-minor-mode to also
> autoload the variable generated by :predicate.

Sure; I've now moved the defcustom to the autoloaded part of the
globalized minor mode stuff.  (You'll have to rebuild loaddefs.el,
though.)

Feel free to change the -modes name to something else -- it's possibly
somewhat confusing with -mode and -modes.

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

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>>> That's basically the same as highlight-changes-global-modes, but with
>>> the added
>>>
>>>          ;; ...the buffer is not internal (name starts with a space)
>>>          (not (eq (aref (buffer-name) 0) ?\ ))
>>>          ;; ...the buffer is not special (name starts with *)
>>>          (or (not (eq (aref (buffer-name) 0) ?*))
>>>
>>> So that's kinda kludgy.
>>
>> It's not quite the same thing, because whitespace-enable-predicate only
>> takes on function values, and is explicitly intended to be customised
>> with the existing DSL of add-function, rather than a new ad-hoc DSL.
>
> I'm not quite sure I follow.  The bit before the thing I quoted was
> pretty much the equivalent of highlight-changes-global-modes:
>
>           ((listp whitespace-global-modes)
>            (if (eq (car-safe whitespace-global-modes) 'not)
>                (not (memq major-mode (cdr whitespace-global-modes)))
>              (memq major-mode whitespace-global-modes)))

Oops, I missed whitespace-global-modes.  Yes, that seems to be the same
thing as highlight-changes-global-modes.

>> [Not that I'd argue for the superiority of whitespace-enable-predicate
>> over other customisation approaches.]
>
> So I'd say whitespace-enable-predicate has the same ad-hoc DSL built in,
> but with an add-function DSL on top of it?

Yep.  Maximal customisability. ;)

-- 
Basil

bug#44232: (no subject)

[Dmitry Gutov]

On 26.10.2020 18:51, Lars Ingebrigtsen wrote:
> That's basically the same as highlight-changes-global-modes, but with
> the added
> 
>           ;; ...the buffer is not internal (name starts with a space)
>           (not (eq (aref (buffer-name) 0) ?\ ))
>           ;; ...the buffer is not special (name starts with *)
>           (or (not (eq (aref (buffer-name) 0) ?*))
> 
> So that's kinda kludgy.

Also see project-kill-buffer-conditions for another example of a DSL-ish 
list of conditions.

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[積丹尼 Dan Jacobson]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
>> So the fill-column Docstring should say how to make it infinity(=no filling).

EZ> There's no such setting; use a value larger than any window, like you
EZ> did.

OK, the docstring should say "to disable filling, use some large
number".

("If you use zero instead, you
w
i
l
l

maybe get something like that. So don't waste time guessing. So that's
why we will tell you right in the Docstring!")

bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: larsi@gnus.org,  44232@debbugs.gnu.org
> Date: Tue, 27 Oct 2020 06:28:53 +0800
> 
> OK, the docstring should say "to disable filling, use some large
> number".
> 
> ("If you use zero instead, you
> w
> i
> l
> l
> 
> maybe get something like that. So don't waste time guessing. So that's
> why we will tell you right in the Docstring!")

That's so self-evident that doesn't warrant any changes in the doc
string.