[Top][All Lists]

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

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

From: Ergus
Subject: bug#36861: 27.0.50; display-fill-column-indicator-mode in log-edit-mode
Date: Sun, 04 Aug 2019 02:51:04 +0200
User-agent: K-9 Mail for Android

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 <address@hidden> 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.
reply via email to

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