GNU bug report logs - #54598
27.2; Bad interraction between modus-theme and hs-minor-mode

Previous Next

To reply to this bug, email your comments to 54598 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: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.2; Bad interraction between modus-theme and hs-minor-mode
Date: Sun, 27 Mar 2022 18:17:17 +0200

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

Hi everybody,

I'm facing a strange behaviour.  With the following receipe I'm 
unable
to go to to the end of buffer with C-End (nor with M-x 
end-of-buffer).

First You should have modus installed from elpa somewhere. I've 
mine in
~/.emacs.d/elpa-27/

Then evalutate the code below :
 #+begin_src elisp
(let ((modus-theme-install-path (expand-file-name 
"~/.emacs.d/elpa-27/modus-themes-20220323.801/")))
 (setq display-fill-column-indicator-character 9474)
 (add-to-list 'load-path modus-theme-install-path)
 (load (expand-file-name "modus-themes-autoloads.el" 
 modus-theme-install-path))
 (modus-themes-load-vivendi)
 (find-file (expand-file-name "modus-themes.el" 
 modus-theme-install-path))
 (display-fill-column-indicator-mode)
 (hs-minor-mode)
 (hs-hide-all))
 #+end_src

Then try to jump at the end of buffer with C-end or M-x 
end-of-buffer.
The point isn't at end of buffer. See the snapshot.1.png attached.

[snapshot.1.png (image/png, attachment)]

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

What I've found is that the following conditions are mandatory to
reproduce the error :
- Use a build for Windows (There is no problem on my Gnu/Linux 
 platform)
- Use a version of modus past f76fc911 where the :height property 
 was
added to the fill-column-indicator face.
- Use hs-minor-mode and hide all regions

On my Gnu/Linux (see Screenshot_20220327_183833.png) there is no 
problems to reach the end of buffer.

[Screenshot_20220327_183833.png (image/png, attachment)]

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

You could also see that the behaviour of the fill column isn't the 
same
(I prefer the one on Gnu/Linux)

I've tried to change the behaviour of the face like descrived in 
the
manual with the code bellow :

 #+begin_src elisp
(modus-themes-with-colors
 (custom-set-faces
  `(fill-column-indicator ((,class :foreground ,bg-active)))))
 #+end_src

But I caught the following error :

 #+begin_src 
Debugger entered--Lisp error: (error "’org-beautify’ is not a 
Modus theme")
 signal(error ("’org-beautify’ is not a Modus theme"))
 error("'%s' is not a Modus theme" org-beautify)
 modus-themes--palette(org-beautify)
 modus-themes-current-palette()
 (let* ((class '((class color) (min-colors 89))) (g1663 
 (modus-themes-current-palette)) (bg-main (alist-get 'bg-main 
 g1663)) (fg-main (alist-get 'fg-main g1663)) (bg-dim (alist-get 
 'bg-dim g1663)) (fg-dim (alist-get 'fg-dim g1663)) (bg-alt 
 (alist-get 'bg-alt g1663)) (fg-alt (alist-get 'fg-alt g1663)) 
 (bg-active (alist-get 'bg-active g1663)) (fg-active (alist-get 
 'fg-active g1663)) (bg-inactive (alist-get 'bg-inactive g1663)) 
 (fg-inactive (alist-get 'fg-inactive g1663)) (bg-active-accent 
 (alist-get 'bg-active-accent g1663)) (bg-special-cold (alist-get 
 'bg-special-cold g1663)) (bg-special-faint-cold (alist-get 
 'bg-special-faint-cold g1663)) (fg-special-cold (alist-get 
 'fg-special-cold g1663)) (bg-special-mild (alist-get 
 'bg-special-mild g1663)) (bg-special-faint-mild (alist-get 
 'bg-special-faint-mild g1663)) (fg-special-mild (alist-get 
 'fg-special-mild g1663)) (bg-special-warm (alist-get 
 'bg-special-warm g1663)) (bg-special-faint-warm (alist-get 
 'bg-special-faint-warm g1663)) (fg-special-warm (alist-get 
 'fg-special-warm g1663)) (bg-special-calm (alist-get 
 'bg-special-calm g1663)) (bg-special-faint-calm (alist-get 
 'bg-special-faint-calm g1663)) (fg-special-calm (alist-get 
 'fg-special-calm g1663)) (red (alist-get 'red g1663)) (red-alt 
 (alist-get 'red-alt g1663)) (red-alt-other (alist-get 
 'red-alt-other g1663)) (red-faint (alist-get 'red-faint g1663)) 
 (red-alt-faint (alist-get 'red-alt-faint g1663)) 
 (red-alt-other-faint (alist-get 'red-alt-other-faint g1663)) 
 (green (alist-get 'green g1663)) (green-alt (alist-get 
 'green-alt g1663)) (green-alt-other (alist-get 'green-alt-other 
 g1663)) (green-faint (alist-get 'green-faint g1663)) 
 (green-alt-faint (alist-get 'green-alt-faint g1663)) 
 (green-alt-other-faint (alist-get 'green-alt-other-faint g1663)) 
 (yellow (alist-get 'yellow g1663)) (yellow-alt (alist-get 
 'yellow-alt g1663)) (yellow-alt-other (alist-get 
 'yellow-alt-other g1663)) (yellow-faint (alist-get 'yellow-faint 
 g1663)) (yellow-alt-faint (alist-get 'yellow-alt-faint g1663)) 
 (yellow-alt-other-faint (alist-get 'yellow-alt-other-faint 
 g1663)) (blue (alist-get 'blue g1663)) (blue-alt (alist-get 
 'blue-alt g1663)) (blue-alt-other (alist-get 'blue-alt-other 
 g1663)) (blue-faint (alist-get 'blue-faint g1663)) 
 (blue-alt-faint (alist-get 'blue-alt-faint g1663)) 
 (blue-alt-other-faint (alist-get 'blue-alt-other-faint g1663)) 
 (magenta (alist-get 'magenta g1663)) ...) (ignore class bg-main 
 fg-main bg-dim fg-dim bg-alt fg-alt bg-active fg-active 
 bg-inactive fg-inactive bg-active-accent bg-special-cold 
 bg-special-faint-cold fg-special-cold bg-special-mild 
 bg-special-faint-mild fg-special-mild bg-special-warm 
 bg-special-faint-warm fg-special-warm bg-special-calm 
 bg-special-faint-calm fg-special-calm red red-alt red-alt-other 
 red-faint red-alt-faint red-alt-other-faint green green-alt 
 green-alt-other green-faint green-alt-faint 
 green-alt-other-faint yellow yellow-alt yellow-alt-other 
 yellow-faint yellow-alt-faint yellow-alt-other-faint blue 
 blue-alt blue-alt-other blue-faint blue-alt-faint 
 blue-alt-other-faint magenta ...) (custom-set-faces (list 
 'fill-column-indicator (list (list class ':foreground 
 bg-active)))))
 eval((let* ((class '((class color) (min-colors 89))) (g1663 
 (modus-themes-current-palette)) (bg-main (alist-get 'bg-main 
 g1663)) (fg-main (alist-get 'fg-main g1663)) (bg-dim (alist-get 
 'bg-dim g1663)) (fg-dim (alist-get 'fg-dim g1663)) (bg-alt 
 (alist-get 'bg-alt g1663)) (fg-alt (alist-get 'fg-alt g1663)) 
 (bg-active (alist-get 'bg-active g1663)) (fg-active (alist-get 
 'fg-active g1663)) (bg-inactive (alist-get 'bg-inactive g1663)) 
 (fg-inactive (alist-get 'fg-inactive g1663)) (bg-active-accent 
 (alist-get 'bg-active-accent g1663)) (bg-special-cold (alist-get 
 'bg-special-cold g1663)) (bg-special-faint-cold (alist-get 
 'bg-special-faint-cold g1663)) (fg-special-cold (alist-get 
 'fg-special-cold g1663)) (bg-special-mild (alist-get 
 'bg-special-mild g1663)) (bg-special-faint-mild (alist-get 
 'bg-special-faint-mild g1663)) (fg-special-mild (alist-get 
 'fg-special-mild g1663)) (bg-special-warm (alist-get 
 'bg-special-warm g1663)) (bg-special-faint-warm (alist-get 
 'bg-special-faint-warm g1663)) (fg-special-warm (alist-get 
 'fg-special-warm g1663)) (bg-special-calm (alist-get 
 'bg-special-calm g1663)) (bg-special-faint-calm (alist-get 
 'bg-special-faint-calm g1663)) (fg-special-calm (alist-get 
 'fg-special-calm g1663)) (red (alist-get 'red g1663)) (red-alt 
 (alist-get 'red-alt g1663)) (red-alt-other (alist-get 
 'red-alt-other g1663)) (red-faint (alist-get 'red-faint g1663)) 
 (red-alt-faint (alist-get 'red-alt-faint g1663)) 
 (red-alt-other-faint (alist-get 'red-alt-other-faint g1663)) 
 (green (alist-get 'green g1663)) (green-alt (alist-get 
 'green-alt g1663)) (green-alt-other (alist-get 'green-alt-other 
 g1663)) (green-faint (alist-get 'green-faint g1663)) 
 (green-alt-faint (alist-get 'green-alt-faint g1663)) 
 (green-alt-other-faint (alist-get 'green-alt-other-faint g1663)) 
 (yellow (alist-get 'yellow g1663)) (yellow-alt (alist-get 
 'yellow-alt g1663)) (yellow-alt-other (alist-get 
 'yellow-alt-other g1663)) (yellow-faint (alist-get 'yellow-faint 
 g1663)) (yellow-alt-faint (alist-get 'yellow-alt-faint g1663)) 
 (yellow-alt-other-faint (alist-get 'yellow-alt-other-faint 
 g1663)) (blue (alist-get 'blue g1663)) (blue-alt (alist-get 
 'blue-alt g1663)) (blue-alt-other (alist-get 'blue-alt-other 
 g1663)) (blue-faint (alist-get 'blue-faint g1663)) 
 (blue-alt-faint (alist-get 'blue-alt-faint g1663)) 
 (blue-alt-other-faint (alist-get 'blue-alt-other-faint g1663)) 
 (magenta (alist-get 'magenta g1663)) ...) (ignore class bg-main 
 fg-main bg-dim fg-dim bg-alt fg-alt bg-active fg-active 
 bg-inactive fg-inactive bg-active-accent bg-special-cold 
 bg-special-faint-cold fg-special-cold bg-special-mild 
 bg-special-faint-mild fg-special-mild bg-special-warm 
 bg-special-faint-warm fg-special-warm bg-special-calm 
 bg-special-faint-calm fg-special-calm red red-alt red-alt-other 
 red-faint red-alt-faint red-alt-other-faint green green-alt 
 green-alt-other green-faint green-alt-faint 
 green-alt-other-faint yellow yellow-alt yellow-alt-other 
 yellow-faint yellow-alt-faint yellow-alt-other-faint blue 
 blue-alt blue-alt-other blue-faint blue-alt-faint 
 blue-alt-other-faint magenta ...) (custom-set-faces (list 
 'fill-column-indicator (list (list class ':foreground 
 bg-active))))) nil)
 elisp--eval-last-sexp(nil)
 eval-last-sexp(nil)
 funcall-interactively(eval-last-sexp nil)
 call-interactively(eval-last-sexp nil nil)
 command-execute(eval-last-sexp)
 #+end_src

 I've tracked it down to modus-themes--current-theme
 #+begin_src elisp
(defun modus-themes--current-theme ()
 "Return current theme."
 (car custom-enabled-themes))
 #+end_src

 I think those function should filter on symbols and take the 
 first
 occurence of a modus-* theme. Maybe something like :
 #+begin_src elisp
(defun modus-themes--current-theme ()
 "Return current theme."
 (car (seq-filter (lambda (arg) (string-match-p "^modus" 
 (symbol-name arg))) custom-enabled-themes)))
 #+end_src

 Thanks in advance for your help.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
Cc: 54598 <at> debbugs.gnu.org
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Tue, 29 Mar 2022 15:06:42 +0200

Pierre Téchoueyres <pierre.techoueyres <at> free.fr> writes:

> What I've found is that the following conditions are mandatory to
> reproduce the error :
> - Use a build for Windows (There is no problem on my Gnu/Linux
>   platform)
> - Use a version of modus past f76fc911 where the :height property
>   was
> added to the fill-column-indicator face.
> - Use hs-minor-mode and hide all regions

This could be an issue with point movement in invisible text (I haven't
tried reproducing the problem because the recipe is a lot of work 🙃),
but if I remember correctly, there's been a bunch of fixes for point
movement and invisible text in Emacs lately.

Would it be possible for you to build the current Emacs development tree
and see whether these changes have fixed what you're seeing, too?

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

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

From: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 54598 <at> debbugs.gnu.org
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Tue, 29 Mar 2022 23:05:50 +0200

Hi Lars,
First Thanks for your reply.


Le mardi 29 mars 2022 à 15:06, Lars Ingebrigtsen <larsi <at> gnus.org> 
a écrit :

> Pierre Téchoueyres <pierre.techoueyres <at> free.fr> writes:
>
>> What I've found is that the following conditions are mandatory 
>> to
>> reproduce the error :
>> - Use a build for Windows (There is no problem on my Gnu/Linux
>>   platform)
>> - Use a version of modus past f76fc911 where the :height 
>> property
>>   was
>> added to the fill-column-indicator face.
>> - Use hs-minor-mode and hide all regions
>
> This could be an issue with point movement in invisible text (I 
> haven't
> tried reproducing the problem because the recipe is a lot of 
> work 🙃),
And a bit tricky ... see below 

> but if I remember correctly, there's been a bunch of fixes for 
> point
> movement and invisible text in Emacs lately.
>
> Would it be possible for you to build the current Emacs 
> development tree
> and see whether these changes have fixed what you're seeing, 
> too?

I've build master up to 271c03d89f3b1f67b44a46ee43447e25f5eef1a8 
commit.
Alas the problem is still here. FYI I can reproduce it on 27.2, 
28.1
(last commit on branch) and on master (main ? what's the right 
name now ?)

*But*, and I'm sorry for this, my recipe is incorrect / 
incomplete.
To trigger the problem I must use a specific font (not the default 
one on Microsoft Windows).

i.e. You should start emacs with the following args :
#+begin_src cmd
emacs -q --no-site-file --no-site-lisp --no-splash -fn "-*-DejaVu 
Sans Mono-normal-r-*-*-12-*-*-*-c-*-iso8859-1"
#+end_src

So, to resume, here are the problems I see with the modus theme 
and hs-minor-mode on my Windows 10 machine :
- I can't jump to the end of buffer (the worst),
- the function modus-themes--current-theme doesn't work when there 
 are
 others themes in custom-enabled-themes, 
- the linux and Windows version of the same customisation aren't 
 looking
 the same (see my screen shots). Personnaly I prefer the Linux 
 way
 where the vertical line is thinner. 

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
Cc: 54598 <at> debbugs.gnu.org, Protesilaos Stavrou <info <at> protesilaos.com>
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Thu, 31 Mar 2022 13:49:19 +0200

Pierre Téchoueyres <pierre.techoueyres <at> free.fr> writes:

> I've build master up to 271c03d89f3b1f67b44a46ee43447e25f5eef1a8
> commit.  Alas the problem is still here. FYI I can reproduce it on
> 27.2, 28.1 (last commit on branch) and on master (main ? what's the
> right name now ?)

Thanks for testing.  (And it's called "master" still, but I call it "the
trunk".  😀)

> *But*, and I'm sorry for this, my recipe is incorrect / incomplete.
> To trigger the problem I must use a specific font (not the default one
> on Microsoft Windows).
>
> i.e. You should start emacs with the following args :
>
> #+begin_src cmd
> emacs -q --no-site-file --no-site-lisp --no-splash -fn "-*-DejaVu 
> Sans Mono-normal-r-*-*-12-*-*-*-c-*-iso8859-1"
> #+end_src
>
> So, to resume, here are the problems I see with the modus theme 
> and hs-minor-mode on my Windows 10 machine :
> - I can't jump to the end of buffer (the worst),
> - the function modus-themes--current-theme doesn't work when there 
>   are
>   others themes in custom-enabled-themes, 
> - the linux and Windows version of the same customisation aren't 
>   looking
>   the same (see my screen shots). Personnaly I prefer the Linux 
>   way
>   where the vertical line is thinner. 

Perhaps Prot has some comments here (especially about the
modus-themes--current-theme thing), so I've added him to the CCs.

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

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

From: Protesilaos Stavrou <info <at> protesilaos.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Pierre Téchoueyres
 <pierre.techoueyres <at> free.fr>
Cc: 54598 <at> debbugs.gnu.org
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Thu, 31 Mar 2022 16:08:56 +0300

On 2022-03-31, 13:49 +0200, Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

>> *But*, and I'm sorry for this, my recipe is incorrect / incomplete.
>> To trigger the problem I must use a specific font (not the default one
>> on Microsoft Windows).
>>
>> i.e. You should start emacs with the following args :
>>
>> #+begin_src cmd
>> emacs -q --no-site-file --no-site-lisp --no-splash -fn "-*-DejaVu 
>> Sans Mono-normal-r-*-*-12-*-*-*-c-*-iso8859-1"
>> #+end_src
>>
>> So, to resume, here are the problems I see with the modus theme 
>> and hs-minor-mode on my Windows 10 machine :
>> - I can't jump to the end of buffer (the worst),
>> - the function modus-themes--current-theme doesn't work when there 
>>   are
>>   others themes in custom-enabled-themes, 
>> - the linux and Windows version of the same customisation aren't 
>>   looking
>>   the same (see my screen shots). Personnaly I prefer the Linux 
>>   way
>>   where the vertical line is thinner. 
>
> Perhaps Prot has some comments here (especially about the
> modus-themes--current-theme thing), so I've added him to the CCs.

Thank you Lars!

Pierre, your suggestion to filter the custom-enabled-themes is better
than what we have.  Do you want to send it to me as a patch?

All the best,
Prot

-- 
Protesilaos Stavrou
https://protesilaos.com

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

From: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
To: Protesilaos Stavrou <info <at> protesilaos.com>
Cc: 54598 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Thu, 31 Mar 2022 21:24:16 +0200

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

Hello Protesilaos,
Le jeudi 31 mars 2022 à 16:08, Protesilaos Stavrou 
<info <at> protesilaos.com> a écrit :
> ...
> Pierre, your suggestion to filter the custom-enabled-themes is 
> better
> than what we have.  Do you want to send it to me as a patch?
What dou you think of the attached one ?

>
> All the best,
Same here :-)
> Prot

Apart from that, do you know why the vertical line doesn't look 
the
same on Windows ?

[0001-Filter-modus-themes-on-modus-themes-current-theme.patch (text/x-patch, attachment)]

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

From: Protesilaos Stavrou <info <at> protesilaos.com>
To: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
Cc: 54598 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Thu, 31 Mar 2022 22:57:57 +0300

On 2022-03-31, 21:24 +0200, Pierre Téchoueyres <pierre.techoueyres <at> free.fr> wrote:

>> Pierre, your suggestion to filter the custom-enabled-themes is better
>> than what we have.  Do you want to send it to me as a patch?
> What dou you think of the attached one ?

Installed it in my repo.  Thank you!  I was planning to prepare a
release in the coming days and sync it with emacs.git.  Might do it
tomorrow.  Is it okay for you if you wait a bit before this patch makes
it to 'master'?

> Apart from that, do you know why the vertical line doesn't look the
> same on Windows ?

Sorry, I don't know.  I do not have access to a Windows machine.

-- 
Protesilaos Stavrou
https://protesilaos.com

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

From: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
To: Protesilaos Stavrou <info <at> protesilaos.com>
Cc: 54598 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Thu, 31 Mar 2022 22:19:18 +0200

Le jeudi 31 mars 2022 à 22:57, Protesilaos Stavrou 
<info <at> protesilaos.com> a écrit :

> On 2022-03-31, 21:24 +0200, Pierre Téchoueyres 
> <pierre.techoueyres <at> free.fr> wrote:
>
>>> Pierre, your suggestion to filter the custom-enabled-themes is 
>>> better
>>> than what we have.  Do you want to send it to me as a patch?
>> What dou you think of the attached one ?
>
> Installed it in my repo.  Thank you!  I was planning to prepare 
> a
> release in the coming days and sync it with emacs.git.  Might do 
> it
> tomorrow.  Is it okay for you if you wait a bit before this 
> patch makes
> it to 'master'?
>
Yes. Don't worry. For now I just redefine the function in my 
init.el and
call the macro.

>> Apart from that, do you know why the vertical line doesn't look 
>> the
>> same on Windows ?
>
> Sorry, I don't know.  I do not have access to a Windows machine.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Protesilaos Stavrou <info <at> protesilaos.com>
Cc: 54598 <at> debbugs.gnu.org, larsi <at> gnus.org, pierre.techoueyres <at> free.fr
Subject: Re: bug#54598: 27.2;
 Bad interraction between modus-theme and hs-minor-mode
Date: Fri, 01 Apr 2022 09:05:56 +0300

> From: Protesilaos Stavrou <info <at> protesilaos.com>
> Date: Thu, 31 Mar 2022 22:57:57 +0300
> Cc: 54598 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
> 
> On 2022-03-31, 21:24 +0200, Pierre Téchoueyres <pierre.techoueyres <at> free.fr> wrote:
> 
> >> Pierre, your suggestion to filter the custom-enabled-themes is better
> >> than what we have.  Do you want to send it to me as a patch?
> > What dou you think of the attached one ?
> 
> Installed it in my repo.  Thank you!  I was planning to prepare a
> release in the coming days and sync it with emacs.git.  Might do it
> tomorrow.  Is it okay for you if you wait a bit before this patch makes
> it to 'master'?
> 
> > Apart from that, do you know why the vertical line doesn't look the
> > same on Windows ?
> 
> Sorry, I don't know.  I do not have access to a Windows machine.

What is that "vertical line", and what is its look on MS-Windows as
opposed to other systems?

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

From: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54598 <at> debbugs.gnu.org, Protesilaos Stavrou <info <at> protesilaos.com>,
 larsi <at> gnus.org
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Sat, 02 Apr 2022 19:53:27 +0200

Hello Eli,
Le vendredi 01 avril 2022 à 09:05, Eli Zaretskii <eliz <at> gnu.org> a 
écrit :

>> From: Protesilaos Stavrou <info <at> protesilaos.com>
>> Date: Thu, 31 Mar 2022 22:57:57 +0300
>> Cc: 54598 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
>> 
>> On 2022-03-31, 21:24 +0200, Pierre Téchoueyres 
>> <pierre.techoueyres <at> free.fr> wrote:
>> 
>> >> Pierre, your suggestion to filter the custom-enabled-themes 
>> >> is better
>> >> than what we have.  Do you want to send it to me as a patch?
>> > What dou you think of the attached one ?
>> 
>> Installed it in my repo.  Thank you!  I was planning to prepare 
>> a
>> release in the coming days and sync it with emacs.git.  Might 
>> do it
>> tomorrow.  Is it okay for you if you wait a bit before this 
>> patch makes
>> it to 'master'?
>> 
>> > Apart from that, do you know why the vertical line doesn't 
>> > look the
>> > same on Windows ?
>> 
>> Sorry, I don't know.  I do not have access to a Windows 
>> machine.
>
> What is that "vertical line", and what is its look on MS-Windows 
> as
> opposed to other systems?

The vertical line is what I see as the fill column indicator when 
I enable the display-fill-column-indicator-mode.
I've provided screen shots on my first e-mail.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
Cc: 54598 <at> debbugs.gnu.org, info <at> protesilaos.com, larsi <at> gnus.org
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Sat, 02 Apr 2022 21:58:27 +0300

> From: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
> Cc: Protesilaos Stavrou <info <at> protesilaos.com>, 54598 <at> debbugs.gnu.org,
>  larsi <at> gnus.org
> Date: Sat, 02 Apr 2022 19:53:27 +0200
> 
> > What is that "vertical line", and what is its look on MS-Windows
> > as opposed to other systems?
> 
> The vertical line is what I see as the fill column indicator when 
> I enable the display-fill-column-indicator-mode.
> I've provided screen shots on my first e-mail.

I see no fill-column-indicator vertical line on those screenshots.

The only difference between systems (unrelated to MS-Windows vs
GNU/Linux differences) regarding this display might be related to
whether your default font supports the U+2502 character.

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

From: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54598 <at> debbugs.gnu.org, info <at> protesilaos.com, larsi <at> gnus.org
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Sat, 02 Apr 2022 21:48:05 +0200

Le samedi 02 avril 2022 à 21:58, Eli Zaretskii <eliz <at> gnu.org> a 
écrit :

>> From: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
>> Cc: Protesilaos Stavrou <info <at> protesilaos.com>, 
>> 54598 <at> debbugs.gnu.org,
>>  larsi <at> gnus.org
>> Date: Sat, 02 Apr 2022 19:53:27 +0200
>> 
>> > What is that "vertical line", and what is its look on 
>> > MS-Windows
>> > as opposed to other systems?
>> 
>> The vertical line is what I see as the fill column indicator 
>> when 
>> I enable the display-fill-column-indicator-mode.
>> I've provided screen shots on my first e-mail.
>
> I see no fill-column-indicator vertical line on those 
> screenshots.
>
> The only difference between systems (unrelated to MS-Windows vs
> GNU/Linux differences) regarding this display might be related 
> to
> whether your default font supports the U+2502 character.

But it's the same font on both systtems. I started emacs with the 
following args to reproduce the bug and take the screenshots :
#+begin_src sh
emacs -q --no-site-file --no-site-lisp --no-splash -fn "-*-DejaVu 
Sans Mono-normal-r-*-*-12-*-*-*-c-*-iso8859-1"
#+end src

And even if you suppress the (setq ...) which define the character 
the result is still the same :
a thin line on Gnu/Linux an wider one on Windows.

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

From: Protesilaos Stavrou <info <at> protesilaos.com>
To: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>, Eli
 Zaretskii <eliz <at> gnu.org>
Cc: 54598 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Sun, 03 Apr 2022 07:18:51 +0300

On 2022-04-02, 21:48 +0200, Pierre Téchoueyres <pierre.techoueyres <at> free.fr> wrote:

>>> > What is that "vertical line", and what is its look on MS-Windows
>>> > as opposed to other systems?
>>> 
>>> The vertical line is what I see as the fill column indicator when I
>>> enable the display-fill-column-indicator-mode.  I've provided screen
>>> shots on my first e-mail.
>>
>> I see no fill-column-indicator vertical line on those screenshots.
>>
>> The only difference between systems (unrelated to MS-Windows vs
>> GNU/Linux differences) regarding this display might be related to
>> whether your default font supports the U+2502 character.
>
> But it's the same font on both systtems. I started emacs with the 
> following args to reproduce the bug and take the screenshots :
> #+begin_src sh
> emacs -q --no-site-file --no-site-lisp --no-splash -fn "-*-DejaVu 
> Sans Mono-normal-r-*-*-12-*-*-*-c-*-iso8859-1"
> #+end src
>
> And even if you suppress the (setq ...) which define the character the
> result is still the same : a thin line on Gnu/Linux an wider one on
> Windows.

Perhaps this will help test the issue on emacs -Q:

    (set-face-attribute 'fill-column-indicator nil :height 1 :background "gray50" :foreground "gray50")

    (display-fill-column-indicator-mode 1)

-- 
Protesilaos Stavrou
https://protesilaos.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
Cc: 54598 <at> debbugs.gnu.org, info <at> protesilaos.com, larsi <at> gnus.org
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Sun, 03 Apr 2022 08:14:36 +0300

> From: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
> Cc: info <at> protesilaos.com, 54598 <at> debbugs.gnu.org, larsi <at> gnus.org
> Date: Sat, 02 Apr 2022 21:48:05 +0200
> 
> > The only difference between systems (unrelated to MS-Windows vs
> > GNU/Linux differences) regarding this display might be related to
> > whether your default font supports the U+2502 character.
> 
> But it's the same font on both systtems. I started emacs with the 
> following args to reproduce the bug and take the screenshots :
> #+begin_src sh
> emacs -q --no-site-file --no-site-lisp --no-splash -fn "-*-DejaVu 
> Sans Mono-normal-r-*-*-12-*-*-*-c-*-iso8859-1"
> #+end src
> 
> And even if you suppress the (setq ...) which define the character
> the result is still the same : a thin line on Gnu/Linux an wider one
> on Windows.

If you type that character into the buffer text on both systems, does
it look the same?

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

From: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54598 <at> debbugs.gnu.org, info <at> protesilaos.com, larsi <at> gnus.org
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Wed, 06 Apr 2022 20:57:37 +0200

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

Le dimanche 03 avril 2022 à 08:14, Eli Zaretskii <eliz <at> gnu.org> a 
écrit :

>> From: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
>> Cc: info <at> protesilaos.com, 54598 <at> debbugs.gnu.org, larsi <at> gnus.org
>> Date: Sat, 02 Apr 2022 21:48:05 +0200
>> 
>> > The only difference between systems (unrelated to MS-Windows 
>> > vs
>> > GNU/Linux differences) regarding this display might be 
>> > related to
>> > whether your default font supports the U+2502 character.
>> 
>> But it's the same font on both systtems. I started emacs with 
>> the 
>> following args to reproduce the bug and take the screenshots :
>> #+begin_src sh
>> emacs -q --no-site-file --no-site-lisp --no-splash -fn 
>> "-*-DejaVu 
>> Sans Mono-normal-r-*-*-12-*-*-*-c-*-iso8859-1"
>> #+end src
>> 
>> And even if you suppress the (setq ...) which define the 
>> character
>> the result is still the same : a thin line on Gnu/Linux an 
>> wider one
>> on Windows.
>
> If you type that character into the buffer text on both systems, 
> does
> it look the same?
yes see the attached images.

1) show you that the width is larger on Windows
2) show you that the characters are the same

[20220404_102556.png (image/png, attachment)]

[20220406_211400.png (image/png, attachment)]

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

Tell me if I could provide others informations

#+begin_src elisp
(set-face-attribute 'fill-column-indicator nil :height 1 
:background "gray50" :foreground "gray50")
(display-fill-column-indicator-mode 1)

(insert ?\u2502)
#+end_src

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
Cc: 54598 <at> debbugs.gnu.org, info <at> protesilaos.com, larsi <at> gnus.org
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Thu, 07 Apr 2022 08:51:48 +0300

> From: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
> Cc: info <at> protesilaos.com, 54598 <at> debbugs.gnu.org, larsi <at> gnus.org
> Date: Wed, 06 Apr 2022 20:57:37 +0200
> 
> > If you type that character into the buffer text on both systems, 
> > does
> > it look the same?
> yes see the attached images.
> 
> 1) show you that the width is larger on Windows
> 2) show you that the characters are the same

Not sure I follow: it looks to me like in buffer text the character
looks the same on both system, but as fill-column-indicator the same
character displays much wider on Windows than on GNU/Linux, is that
correct?

If so, I think the reason is the settings of the face attributes,
especially the background color.  What you see is the background color
whose width is (of course) the entire character cell, not the
character itself.  Can you explain these strange face attributes, and
what did you intend to achieve by using them?

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

From: Protesilaos Stavrou <info <at> protesilaos.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Pierre Téchoueyres
 <pierre.techoueyres <at> free.fr>
Cc: 54598 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Thu, 07 Apr 2022 09:51:16 +0300

On 2022-04-07, 08:51 +0300, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Pierre Téchoueyres <pierre.techoueyres <at> free.fr>
>> Cc: info <at> protesilaos.com, 54598 <at> debbugs.gnu.org, larsi <at> gnus.org
>> Date: Wed, 06 Apr 2022 20:57:37 +0200
>> 
>> > If you type that character into the buffer text on both systems, 
>> > does
>> > it look the same?
>> yes see the attached images.
>> 
>> 1) show you that the width is larger on Windows
>> 2) show you that the characters are the same
>
> Not sure I follow: it looks to me like in buffer text the character
> looks the same on both system, but as fill-column-indicator the same
> character displays much wider on Windows than on GNU/Linux, is that
> correct?
>
> If so, I think the reason is the settings of the face attributes,
> especially the background color.  What you see is the background color
> whose width is (of course) the entire character cell, not the
> character itself.  Can you explain these strange face attributes, and
> what did you intend to achieve by using them?

Good day Eli!

The face on GNU/Linux produces a thin line.  Whereas on Windows it
covers the entire character cell.  The intent is to get that thin line.
If anything, the given face attributes suggest that the GNU/Linux
version is the one with the odd looks.

@ Pierre: Assuming that we can only achieve this by tinkering with face
attributes, I am happy to make the necessary changes.  Though please
note that I cannot test them on Windows.  What happens, for example, if
the face also inherits from 'variable-pitch'?

(set-face-attribute 'fill-column-indicator nil :inherit 'variable-pitch :height 1 :background "gray50" :foreground "gray50")

-- 
Protesilaos Stavrou
https://protesilaos.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Protesilaos Stavrou <info <at> protesilaos.com>
Cc: 54598 <at> debbugs.gnu.org, larsi <at> gnus.org, pierre.techoueyres <at> free.fr
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Thu, 07 Apr 2022 10:31:05 +0300

> From: Protesilaos Stavrou <info <at> protesilaos.com>
> Cc: 54598 <at> debbugs.gnu.org, larsi <at> gnus.org
> Date: Thu, 07 Apr 2022 09:51:16 +0300
> 
> > Not sure I follow: it looks to me like in buffer text the character
> > looks the same on both system, but as fill-column-indicator the same
> > character displays much wider on Windows than on GNU/Linux, is that
> > correct?
> >
> > If so, I think the reason is the settings of the face attributes,
> > especially the background color.  What you see is the background color
> > whose width is (of course) the entire character cell, not the
> > character itself.  Can you explain these strange face attributes, and
> > what did you intend to achieve by using them?
> 
> Good day Eli!
> 
> The face on GNU/Linux produces a thin line.  Whereas on Windows it
> covers the entire character cell.  The intent is to get that thin line.
> If anything, the given face attributes suggest that the GNU/Linux
> version is the one with the odd looks.

Please explain which part(s) of those face attributes are supposed to
produce the thin line, and why do you think that should happen.  Maybe
I'm missing something, but I'm not aware of any face-related feature
in Emacs that allows us to produce a thin vertical line.  That's why
we use for fill-column-indicator a character whose image is supposed
to be such a thin vertical line.

> @ Pierre: Assuming that we can only achieve this by tinkering with face
> attributes, I am happy to make the necessary changes.  Though please
> note that I cannot test them on Windows.  What happens, for example, if
> the face also inherits from 'variable-pitch'?
> 
> (set-face-attribute 'fill-column-indicator nil :inherit 'variable-pitch :height 1 :background "gray50" :foreground "gray50")

Why do you think this should change anything?  What do you think the
inheritance from variable-pitch should do here?

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

From: Protesilaos Stavrou <info <at> protesilaos.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54598 <at> debbugs.gnu.org, larsi <at> gnus.org, pierre.techoueyres <at> free.fr
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Thu, 07 Apr 2022 11:00:14 +0300

On 2022-04-07, 10:31 +0300, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Protesilaos Stavrou <info <at> protesilaos.com>
>> Cc: 54598 <at> debbugs.gnu.org, larsi <at> gnus.org
>> Date: Thu, 07 Apr 2022 09:51:16 +0300
>> 
>> > Not sure I follow: it looks to me like in buffer text the character
>> > looks the same on both system, but as fill-column-indicator the same
>> > character displays much wider on Windows than on GNU/Linux, is that
>> > correct?
>> >
>> > If so, I think the reason is the settings of the face attributes,
>> > especially the background color.  What you see is the background color
>> > whose width is (of course) the entire character cell, not the
>> > character itself.  Can you explain these strange face attributes, and
>> > what did you intend to achieve by using them?
>> 
>> Good day Eli!
>> 
>> The face on GNU/Linux produces a thin line.  Whereas on Windows it
>> covers the entire character cell.  The intent is to get that thin line.
>> If anything, the given face attributes suggest that the GNU/Linux
>> version is the one with the odd looks.
>
> Please explain which part(s) of those face attributes are supposed to
> produce the thin line, and why do you think that should happen.  Maybe
> I'm missing something, but I'm not aware of any face-related feature
> in Emacs that allows us to produce a thin vertical line.  That's why
> we use for fill-column-indicator a character whose image is supposed
> to be such a thin vertical line.

I think the end-result on GNU/Linux is puzzling, given that no face
attribute should explicitly produce this thin line.  Still, this result
was discovered experimentally.

With 'emacs -Q' and a fallback/default typeface such as DejaVu Sans Mono
or Hack:

 1. Create some empty lines in the scratch buffer, such as with 'C-o'.
 2. M-x display-fill-column-indicator-mode

Notice the thin dashed line.

 3. (set-face-attribute 'fill-column-indicator nil :height 1 :background "gray50" :foreground "gray50")

The line is now thin and contiguous.

Note that the dashed line up to step 2 depends on the ':family'
attribute of the 'default' face.  For example, Source Code Pro produces
a contiguous line with the above recipe.  Though it too changes to a
dashed style when 'line-spacing' is >= 2.

When the 'fill-column-indicator' is changed with what is in step 3, even
a higher 'line-spacing' value produces a contiguous line.

>> @ Pierre: Assuming that we can only achieve this by tinkering with face
>> attributes, I am happy to make the necessary changes.  Though please
>> note that I cannot test them on Windows.  What happens, for example, if
>> the face also inherits from 'variable-pitch'?
>> 
>> (set-face-attribute 'fill-column-indicator nil :inherit 'variable-pitch :height 1 :background "gray50" :foreground "gray50")
>
> Why do you think this should change anything?  What do you think the
> inheritance from variable-pitch should do here?

The assumption is that the proportionate spacing will produce a thinner
character cell, as opposed to the 'default' face which in Pierre's case
is a monospaced font.

-- 
Protesilaos Stavrou
https://protesilaos.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Protesilaos Stavrou <info <at> protesilaos.com>
Cc: 54598 <at> debbugs.gnu.org, larsi <at> gnus.org, pierre.techoueyres <at> free.fr
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Thu, 07 Apr 2022 11:27:20 +0300

> From: Protesilaos Stavrou <info <at> protesilaos.com>
> Cc: pierre.techoueyres <at> free.fr, 54598 <at> debbugs.gnu.org, larsi <at> gnus.org
> Date: Thu, 07 Apr 2022 11:00:14 +0300
> 
> > Please explain which part(s) of those face attributes are supposed to
> > produce the thin line, and why do you think that should happen.  Maybe
> > I'm missing something, but I'm not aware of any face-related feature
> > in Emacs that allows us to produce a thin vertical line.  That's why
> > we use for fill-column-indicator a character whose image is supposed
> > to be such a thin vertical line.
> 
> I think the end-result on GNU/Linux is puzzling, given that no face
> attribute should explicitly produce this thin line.  Still, this result
> was discovered experimentally.

I think it's a side effect of some peculiarity of the particular
implementation.  Did you try that with and without Cairo, for example?

> With 'emacs -Q' and a fallback/default typeface such as DejaVu Sans Mono
> or Hack:
> 
>  1. Create some empty lines in the scratch buffer, such as with 'C-o'.
>  2. M-x display-fill-column-indicator-mode
> 
> Notice the thin dashed line.

On my system, using DejaVu Sans Mono produces a contiguous vertical
line to begin with.

In any case, if that doesn't happen with some default font on some
system, the solution is either specify a font for this face which does
produce a contiguous vertical line, or maybe use an image instead of a
character.

>  3. (set-face-attribute 'fill-column-indicator nil :height 1 :background "gray50" :foreground "gray50")
> 
> The line is now thin and contiguous.
> 
> Note that the dashed line up to step 2 depends on the ':family'
> attribute of the 'default' face.  For example, Source Code Pro produces
> a contiguous line with the above recipe.  Though it too changes to a
> dashed style when 'line-spacing' is >= 2.
> 
> When the 'fill-column-indicator' is changed with what is in step 3, even
> a higher 'line-spacing' value produces a contiguous line.

The background color fills the entire character cell, which is why it
isn't affected by the line-spacing.  But we have no mechanism that I'm
aware of to make the background be 1-pixel thin.

> >> (set-face-attribute 'fill-column-indicator nil :inherit 'variable-pitch :height 1 :background "gray50" :foreground "gray50")
> >
> > Why do you think this should change anything?  What do you think the
> > inheritance from variable-pitch should do here?
> 
> The assumption is that the proportionate spacing will produce a thinner
> character cell, as opposed to the 'default' face which in Pierre's case
> is a monospaced font.

The width that it takes is determined by the metrics of the U+2502
character in a particular font used by the variable-pitch face on the
user's platform.  You cannot expect in advance that this width is
indeed thin enough, because that character is not designed for these
purposes.

So I think what you are trying to do is fundamentally unportable, not
as long as characters are used for the indicator.

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

From: Protesilaos Stavrou <info <at> protesilaos.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54598 <at> debbugs.gnu.org, larsi <at> gnus.org, pierre.techoueyres <at> free.fr
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Thu, 07 Apr 2022 15:44:56 +0300

On 2022-04-07, 11:27 +0300, Eli Zaretskii <eliz <at> gnu.org> wrote:

> So I think what you are trying to do is fundamentally unportable, not
> as long as characters are used for the indicator.

Thank you for the feedback!

I will try to elicit opinions on the matter from existing users
regarding their preferred style.  Will update the code/manual
accordingly.  My stylistic preference is for the thin contiguous line.

Fundamentally, the constraint lies in the implimation of the
'fill-column-indicator'.  Ideally, it would be the same as the
'vertical-border' which, in my understanding, is always rendered as a
thin contiguous line.

-- 
Protesilaos Stavrou
https://protesilaos.com

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Protesilaos Stavrou <info <at> protesilaos.com>
Cc: 54598 <at> debbugs.gnu.org, larsi <at> gnus.org, pierre.techoueyres <at> free.fr
Subject: Re: bug#54598: 27.2; Bad interraction between modus-theme and
 hs-minor-mode
Date: Thu, 07 Apr 2022 17:25:57 +0300

> From: Protesilaos Stavrou <info <at> protesilaos.com>
> Cc: pierre.techoueyres <at> free.fr, 54598 <at> debbugs.gnu.org, larsi <at> gnus.org
> Date: Thu, 07 Apr 2022 15:44:56 +0300
> 
> Fundamentally, the constraint lies in the implimation of the
> 'fill-column-indicator'.  Ideally, it would be the same as the
> 'vertical-border' which, in my understanding, is always rendered as a
> thin contiguous line.

The difference is that the vertical-border is displayed between
windows, whereas the fill-column indicator, by its very nature, must
be displayed in the window's text area.  That is the reason behind the
different implementation: we don't have capabilities to display
arbitrary graphics in the text area of a window,l except showing a
glyph there.

Previous Next

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