bug#36861: 27.0.50; display-fill-column-indicator-mode in log-edit-mode

[Ergus <spacibba@aol.com>]

[-- Attachment #1: Type: text/plain, Size: 3639 bytes --]

Hi, sorry, I don't understand actually why is so complex this provided code in the email. The initialization for display-fill-column-indicator makes some checks to set the default character as described in the documentation, so no extra code is needed for that in the user side.
In the initialization I see in this mail, they just set the column's value to 78 which can be done also using the variable fill-column for the whole major mode too. And actually dfci will recognize it by default and other functionalities too so in the general scenario is better to use that one.

(setq fill-column 78)
(display-fill-column-indicator t)


Should work no matters the order. Maybe as you were setting the mode's variable instead of calling the function with the same name; the mode was not properly initialized. 



On August 4, 2019 12:31:59 AM GMT+02:00, Juri Linkov <juri@linkov.net> wrote:
>>> >>   (log-edit-mode . ((log-edit-font-lock-gnu-style . t)
>>> >> -                   (log-edit-setup-add-author . t)))
>>> >> +                   (log-edit-setup-add-author . t)
>>> >> +                   (display-fill-column-indicator-column . 78)
>>> >> +                   (eval .
>(display-fill-column-indicator-mode))))
>>> >
>>> > This will cause an annoying message and prompt when editing Emacs
>>> > sources with an Emacs which doesn't yet have
>>> > display-fill-column-indicator-mode, right?  Can we avoid that?  I
>>> > routinely need to work on the latest sources with an older Emacs.
>>> 
>>> Shouldn't local-variables functions ignore undefined variables and
>commands?
>>> Probably not, since such change won't help for older versions.
>>
>> Right, and we cannot summarily allow any variables a given Emacs
>> doesn't know about, that'd we unsafe.
>
>Actually by using the word "ignore" I meant to not set an unbound
>variable
>(currently `hack-local-variables' defines and sets unbound variables).
>But this is not backward-compatible change.
>
>>> Then one way is to put such lines to the init file
>>> to avoid typing `y' to confirm local variables
>>> while using emacs-26 to commit emacs-27 changes:
>>
>> Rather than requiring users of older Emacsen to change their init
>> files in such strange ways, which will/might be a problem when they
>> upgrade to Emacs 27, why not expect users who want the early
>detection
>> of long lines to turn on display-fill-column-indicator-mode in their
>> init files?  IOW, the solution that requires changes to one's init
>> files goes both ways.
>
>I don't understand why display-fill-column-indicator customization
>should be more complicated than necessary?  Why it requires adding
>these lines:
>
>                   (display-fill-column-indicator-column . 78)
>                   (eval . (display-fill-column-indicator-mode))
>
>when it should be enough to avoid eval by:
>
>                   (display-fill-column-indicator-column . 78)
>                   (display-fill-column-indicator . t)
>
>Is it because the only purpose of display-fill-column-indicator-mode
>is to set display-fill-column-indicator-character?  But then why
>display-fill-column-indicator-character is not nil by default?
>This contradicts the docstring of
>display-fill-column-indicator-character
>that says that the default is U+2502, but actually the default is nil.
>
>I'm CC-ing the author of display-fill-column-indicator:
>Could you please consider setting the default value of
>display-fill-column-indicator-character?  This could
>simplify customization.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 4661 bytes --]