GNU bug report logs - #36861
27.0.50; display-fill-column-indicator-mode in log-edit-mode

Previous Next

To reply to this bug, email your comments to 36861 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; display-fill-column-indicator-mode in log-edit-mode
Date: Tue, 30 Jul 2019 23:44:53 +0300

It has an unpleasant effect when git commit abruptly fails when
the length of the first line of the commit message is longer than
78 characters.  This patch enables a visual indication in the
log-edit buffer to help not to exceed the limit beforehand:

diff --git a/.dir-locals.el b/.dir-locals.el
index ffd65c8802..e56d8c753b 100644
--- a/.dir-locals.el
+++ b/.dir-locals.el
@@ -10,7 +10,9 @@
                (electric-quote-comment . nil)
                (electric-quote-string . nil)))
  (log-edit-mode . ((log-edit-font-lock-gnu-style . t)
-                   (log-edit-setup-add-author . t)))
+                   (log-edit-setup-add-author . t)
+                   (fill-column . 78)
+                   (eval . (display-fill-column-indicator-mode))))
  (change-log-mode . ((add-log-time-zone-rule . t)
 		     (fill-column . 74)
 		     (eval . (bug-reference-mode))))

Message #8 received at 36861 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: 36861 <at> debbugs.gnu.org
Subject: Re: bug#36861: 27.0.50; display-fill-column-indicator-mode in
 log-edit-mode
Date: Wed, 31 Jul 2019 00:21:10 +0300

> +                   (fill-column . 78)

Sorry, I missed the special variable introduced by this feature -
‘display-fill-column-indicator-column’.  But ‘fill-column’ should not be
changed, it should remain at its default value.  Here's the correct patch:

diff --git a/.dir-locals.el b/.dir-locals.el
index ffd65c8802..ad5eb066ca 100644
--- a/.dir-locals.el
+++ b/.dir-locals.el
@@ -10,7 +10,9 @@
                (electric-quote-comment . nil)
                (electric-quote-string . nil)))
  (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))))
  (change-log-mode . ((add-log-time-zone-rule . t)
 		     (fill-column . 74)
 		     (eval . (bug-reference-mode))))

Message #11 received at 36861 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 36861 <at> debbugs.gnu.org
Subject: Re: bug#36861: 27.0.50;
 display-fill-column-indicator-mode in log-edit-mode
Date: Wed, 31 Jul 2019 05:30:09 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Date: Tue, 30 Jul 2019 23:44:53 +0300
> 
> It has an unpleasant effect when git commit abruptly fails when
> the length of the first line of the commit message is longer than
> 78 characters.  This patch enables a visual indication in the
> log-edit buffer to help not to exceed the limit beforehand:
> 
> diff --git a/.dir-locals.el b/.dir-locals.el
> index ffd65c8802..e56d8c753b 100644
> --- a/.dir-locals.el
> +++ b/.dir-locals.el
> @@ -10,7 +10,9 @@
>                 (electric-quote-comment . nil)
>                 (electric-quote-string . nil)))
>   (log-edit-mode . ((log-edit-font-lock-gnu-style . t)
> -                   (log-edit-setup-add-author . t)))
> +                   (log-edit-setup-add-author . t)
> +                   (fill-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.

Message #14 received at 36861 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36861 <at> debbugs.gnu.org
Subject: Re: bug#36861: 27.0.50; display-fill-column-indicator-mode in
 log-edit-mode
Date: Wed, 31 Jul 2019 23:49:53 +0300

[Message part 1 (text/plain, inline)]

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

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:

  (put 'display-fill-column-indicator 'safe-local-variable 'booleanp)
  (put 'display-fill-column-indicator-character 'safe-local-variable 'characterp)
  (put 'display-fill-column-indicator-column 'safe-local-variable
       (lambda (value) (or (booleanp value) (integerp value))))
  (defun display-fill-column-indicator-mode ())

And for emacs-27 and future versions this patch is required as well:

[display-fill-column-indicator-cus-start.patch (text/x-diff, inline)]

diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index e1d0bce2ad..036674ef14 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -650,7 +650,7 @@ minibuffer-prompt-properties--setter
                                  "26.1")
 
              (display-fill-column-indicator display-fill-column-indicator
-                                 boolean "27.1")
+                                 boolean "27.1" :safe booleanp)
              (display-fill-column-indicator-column display-fill-column-indicator
                                  (choice
                                   (const :tag "Use fill-column variable"
@@ -659,9 +659,9 @@ minibuffer-prompt-properties--setter
                                          :value 70
                                          :format "%v")
                                   integer)
-                                 "27.1")
+                                 "27.1" :safe (lambda (value) (or (booleanp value) (integerp value))))
              (display-fill-column-indicator-character display-fill-column-indicator
-                                 character "27.1")
+                                 character "27.1" :safe characterp)
 	     ;; xfaces.c
 	     (scalable-fonts-allowed display boolean "22.1")
 	     ;; xfns.c

Message #17 received at 36861 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 36861 <at> debbugs.gnu.org
Subject: Re: bug#36861: 27.0.50; display-fill-column-indicator-mode in
 log-edit-mode
Date: Fri, 02 Aug 2019 12:10:10 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: 36861 <at> debbugs.gnu.org
> Date: Wed, 31 Jul 2019 23:49:53 +0300
> 
> >>   (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.

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

> And for emacs-27 and future versions this patch is required as well:
> 
> diff --git a/lisp/cus-start.el b/lisp/cus-start.el
> index e1d0bce2ad..036674ef14 100644
> --- a/lisp/cus-start.el
> +++ b/lisp/cus-start.el
> @@ -650,7 +650,7 @@ minibuffer-prompt-properties--setter
>                                   "26.1")
>  
>               (display-fill-column-indicator display-fill-column-indicator
> -                                 boolean "27.1")
> +                                 boolean "27.1" :safe booleanp)
>               (display-fill-column-indicator-column display-fill-column-indicator
>                                   (choice
>                                    (const :tag "Use fill-column variable"
> @@ -659,9 +659,9 @@ minibuffer-prompt-properties--setter
>                                           :value 70
>                                           :format "%v")
>                                    integer)
> -                                 "27.1")
> +                                 "27.1" :safe (lambda (value) (or (booleanp value) (integerp value))))
>               (display-fill-column-indicator-character display-fill-column-indicator
> -                                 character "27.1")
> +                                 character "27.1" :safe characterp)
>  	     ;; xfaces.c
>  	     (scalable-fonts-allowed display boolean "22.1")
>  	     ;; xfns.c

This is fine with me, but I don't think we should make the change in
.dir-locals.el.

Thanks.

Message #20 received at 36861 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: spacibba <at> aol.com, 36861 <at> debbugs.gnu.org
Subject: Re: bug#36861: 27.0.50; display-fill-column-indicator-mode in
 log-edit-mode
Date: Sun, 04 Aug 2019 01:31:59 +0300

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

Message #23 received at 36861 <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: Juri Linkov <juri <at> linkov.net>,Eli Zaretskii <eliz <at> gnu.org>
Cc: 36861 <at> debbugs.gnu.org
Subject: Re: bug#36861: 27.0.50;
 display-fill-column-indicator-mode in log-edit-mode
Date: Sun, 04 Aug 2019 02:51:04 +0200

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #26 received at 36861 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ergus <spacibba <at> aol.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36861 <at> debbugs.gnu.org
Subject: Re: bug#36861: 27.0.50; display-fill-column-indicator-mode in
 log-edit-mode
Date: Sun, 04 Aug 2019 22:39:06 +0300

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

The problem is that is when the need is to enable dfci, it is simpler
to avoid eval to enable this mode because dfci works fine without using
dfci-mode, i.e. when only variables are set in Local Variables:

  ;;; Local Variables:
  ;;; display-fill-column-indicator: t
  ;;; display-fill-column-indicator-column: 78
  ;;; End:

or in .dir-locals.el:

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

But the display-fill-column-indicator-character can't be set
in Local Variables because its value depends on the current display:
either U+2502 or ?| if the font does not support Unicode characters.

Do you think it would be possible to set the default value of
display-fill-column-indicator-character without calling
display-fill-column-indicator-mode?

Message #29 received at 36861 <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 36861 <at> debbugs.gnu.org
Subject: Re: bug#36861: 27.0.50;
 display-fill-column-indicator-mode in log-edit-mode
Date: Sun, 04 Aug 2019 22:30:05 +0200

[Message part 1 (text/plain, inline)]

Dfci was not designed to be used in this way, and the mode initialization actually sets the character, but in the future it could make many other dynamic tests/checks if needed. So I don't think we should modify it to work the other way you suggest, because for menit is not general enough. But I will follow the Eli's suggestions in this aspects more than my own opinion. 
Any way, if you want to use the mode in this way (for now) you can/need to set the display-fill-column-indicator-character to your desired value and it should work as it is now. But I can't promise that it will work the same way in the future.
But again, probably Eli will suggest a better solution for your use case.


On August 4, 2019 9:39:06 PM GMT+02:00, Juri Linkov <juri <at> linkov.net> wrote:
>> 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.
>
>The problem is that is when the need is to enable dfci, it is simpler
>to avoid eval to enable this mode because dfci works fine without using
>dfci-mode, i.e. when only variables are set in Local Variables:
>
>  ;;; Local Variables:
>  ;;; display-fill-column-indicator: t
>  ;;; display-fill-column-indicator-column: 78
>  ;;; End:
>
>or in .dir-locals.el:
>
>  (display-fill-column-indicator . t)
>  (display-fill-column-indicator-column . 78)
>
>But the display-fill-column-indicator-character can't be set
>in Local Variables because its value depends on the current display:
>either U+2502 or ?| if the font does not support Unicode characters.
>
>Do you think it would be possible to set the default value of
>display-fill-column-indicator-character without calling
>display-fill-column-indicator-mode?

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

[Message part 2 (text/html, inline)]

Message #32 received at 36861 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36861 <at> debbugs.gnu.org
Subject: Re: bug#36861: 27.0.50; display-fill-column-indicator-mode in
 log-edit-mode
Date: Tue, 06 Aug 2019 00:43:18 +0300

severity 36861 wishlist
tags 36861 + patch
quit

>> diff --git a/lisp/cus-start.el b/lisp/cus-start.el
>>               (display-fill-column-indicator-character display-fill-column-indicator
>> -                                 character "27.1")
>> +                                 character "27.1" :safe characterp)
>
> This is fine with me, but I don't think we should make the change in
> .dir-locals.el.

So I only added :safe in cus-start.el.  And leaving here the
patch for the time when after Emacs 27 release it could be added
to .dir-locals.el:

diff --git a/.dir-locals.el b/.dir-locals.el
index 35dc154375..4d0151f355 100644
--- a/.dir-locals.el
+++ b/.dir-locals.el
@@ -12,7 +12,9 @@
                (electric-quote-string . nil)
 	       (mode . bug-reference-prog)))
  (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)
+                   (mode . display-fill-column-indicator)))
  (change-log-mode . ((add-log-time-zone-rule . t)
 		     (fill-column . 74)
 		     (mode . bug-reference)))

Message #39 received at 36861 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ergus <spacibba <at> aol.com>
Cc: 36861 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#36861: 27.0.50;
 display-fill-column-indicator-mode in log-edit-mode
Date: Tue, 06 Aug 2019 17:59:28 +0300

> Date: Sun, 04 Aug 2019 22:30:05 +0200
> CC: Eli Zaretskii <eliz <at> gnu.org>,36861 <at> debbugs.gnu.org
> From: Ergus <spacibba <at> aol.com>
> 
> Dfci was not designed to be used in this way, and the mode initialization actually sets the character, but in the
> future it could make many other dynamic tests/checks if needed. So I don't think we should modify it to work
> the other way you suggest, because for menit is not general enough. But I will follow the Eli's suggestions in
> this aspects more than my own opinion. 
> Any way, if you want to use the mode in this way (for now) you can/need to set the
> display-fill-column-indicator-character to your desired value and it should work as it is now. But I can't promise
> that it will work the same way in the future.
> But again, probably Eli will suggest a better solution for your use case.

I don't think I understand the problem.  Why doesn't just setting the
characters and the mode variable work as expected?  AFAIU, one needs
to call the mode function only if one wants Emacs to deduce the
indicator character automatically.

Message #42 received at 36861 <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36861 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#36861: 27.0.50; display-fill-column-indicator-mode in
 log-edit-mode
Date: Tue, 6 Aug 2019 19:51:46 +0200

On Tue, Aug 06, 2019 at 05:59:28PM +0300, Eli Zaretskii wrote:
>> Date: Sun, 04 Aug 2019 22:30:05 +0200
>> CC: Eli Zaretskii <eliz <at> gnu.org>,36861 <at> debbugs.gnu.org
>> From: Ergus <spacibba <at> aol.com>
>>
>> Dfci was not designed to be used in this way, and the mode initialization actually sets the character, but in the
>> future it could make many other dynamic tests/checks if needed. So I don't think we should modify it to work
>> the other way you suggest, because for menit is not general enough. But I will follow the Eli's suggestions in
>> this aspects more than my own opinion.
>> Any way, if you want to use the mode in this way (for now) you can/need to set the
>> display-fill-column-indicator-character to your desired value and it should work as it is now. But I can't promise
>> that it will work the same way in the future.
>> But again, probably Eli will suggest a better solution for your use case.
>
>I don't think I understand the problem.  Why doesn't just setting the
>characters and the mode variable work as expected?  AFAIU, one needs
>to call the mode function only if one wants Emacs to deduce the
>indicator character automatically.

Hi:

It should work as you say. But the default value for
display-fill-column-indicator-character is nil until the mode function
is executed (at least once).

I think that what they want is display-fill-column-indicator-character
to be non-nil without initialization; which we cannot set without some
checks.

Probably I'll need to reword the doc string about the default value to
specify that the value is really nil and it is initialized to the other
non-nil values in the mode function.

Does it makes sense?

Message #45 received at 36861 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ergus <spacibba <at> aol.com>
Cc: 36861 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#36861: 27.0.50; display-fill-column-indicator-mode in
 log-edit-mode
Date: Tue, 06 Aug 2019 21:26:22 +0300

> Date: Tue, 6 Aug 2019 19:51:46 +0200
> From: Ergus <spacibba <at> aol.com>
> Cc: juri <at> linkov.net, 36861 <at> debbugs.gnu.org
> 
> >I don't think I understand the problem.  Why doesn't just setting the
> >characters and the mode variable work as expected?  AFAIU, one needs
> >to call the mode function only if one wants Emacs to deduce the
> >indicator character automatically.
> 
> Hi:
> 
> It should work as you say. But the default value for
> display-fill-column-indicator-character is nil until the mode function
> is executed (at least once).
> 
> I think that what they want is display-fill-column-indicator-character
> to be non-nil without initialization; which we cannot set without some
> checks.

Why can't we set display-fill-column-indicator-character to ?| by
default?  Invoking the mode function will still do its job, but at
least people who want to just set the variable will have a functional
feature.  Am I missing something?

Message #48 received at 36861 <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36861 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#36861: 27.0.50;
 display-fill-column-indicator-mode in log-edit-mode
Date: Tue, 06 Aug 2019 21:25:00 +0200

[Message part 1 (text/plain, inline)]

We can do that... I was just trying to avoid using ?| by default in any case. 

There is also the case when a user sets ?| by default and then call the function. If the check we add is just comparing to the default value then ?| will be always overwritten so an extra internal variable will be needed to cache where the ?| comes from. But OK, if this use case seems to be general enough I can make this changes. BTW. Have you seen my comments about the display engine in the other issue?
Best,
Ergus



On August 6, 2019 8:26:22 PM GMT+02:00, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Tue, 6 Aug 2019 19:51:46 +0200
>> From: Ergus <spacibba <at> aol.com>
>> Cc: juri <at> linkov.net, 36861 <at> debbugs.gnu.org
>> 
>> >I don't think I understand the problem.  Why doesn't just setting
>the
>> >characters and the mode variable work as expected?  AFAIU, one needs
>> >to call the mode function only if one wants Emacs to deduce the
>> >indicator character automatically.
>> 
>> Hi:
>> 
>> It should work as you say. But the default value for
>> display-fill-column-indicator-character is nil until the mode
>function
>> is executed (at least once).
>> 
>> I think that what they want is
>display-fill-column-indicator-character
>> to be non-nil without initialization; which we cannot set without
>some
>> checks.
>
>Why can't we set display-fill-column-indicator-character to ?| by
>default?  Invoking the mode function will still do its job, but at
>least people who want to just set the variable will have a functional
>feature.  Am I missing something?

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

[Message part 2 (text/html, inline)]

Message #51 received at 36861 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ergus <spacibba <at> aol.com>
Cc: 36861 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#36861: 27.0.50;
 display-fill-column-indicator-mode in log-edit-mode
Date: Wed, 07 Aug 2019 17:42:14 +0300

> Date: Tue, 06 Aug 2019 21:25:00 +0200
> CC: juri <at> linkov.net,36861 <at> debbugs.gnu.org
> From: Ergus <spacibba <at> aol.com>
> 
> We can do that... I was just trying to avoid using ?| by default in any case. 

Why should we avoid that?  It might be not the best alternative, but
at least it lets users who just set the mode variable have an
indicator.  If they want a prettier display, they will have to call
the mode function instead, as they do now.  So I think this is a net
win.  Or am I missing something?

> There is also the case when a user sets ?| by default and then call the function. If the check we add is just
> comparing to the default value then ?| will be always overwritten so an extra internal variable will be needed to
> cache where the ?| comes from.

Not sure we need another variable.  After all, if the conditions
stayed the same, the result will be the same as well, and you will
overwrite the value with an identical one.  Right?

Message #54 received at 36861 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Ergus <spacibba <at> aol.com>, 36861 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#36861: 27.0.50; display-fill-column-indicator-mode in
 log-edit-mode
Date: Sun, 09 Aug 2020 21:18:18 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> There is also the case when a user sets ?| by default and then call
>> the function. If the check we add is just
>> comparing to the default value then ?| will be always overwritten so
>> an extra internal variable will be needed to
>> cache where the ?| comes from.
>
> Not sure we need another variable.  After all, if the conditions
> stayed the same, the result will be the same as well, and you will
> overwrite the value with an identical one.  Right?

Reading the code, if display-fill-column-indicator-character is set,
then the mode will never do its computation to see whether we can use
the prettier U+2502 │ character.  We could special-case that, though,
and if it's ?|, then we replace it with ?│ (that is, ascii bar with
Unicode bar).

That would be kinda hacky, though, wouldn't it?  Then there would no way
to use the ASCII bar, for those that hate all things Unicode.

So we'd need another variable, unfortunately.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.