bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Pierre Téchoueyres]

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

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.

[-- Attachment #2: snapshot.1.png --]
[-- Type: image/png, Size: 60317 bytes --]

[-- Attachment #3: Type: text/plain, Size: 424 bytes --]


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.

[-- Attachment #4: Screenshot_20220327_183833.png --]
[-- Type: image/png, Size: 124015 bytes --]

[-- Attachment #5: Type: text/plain, Size: 8189 bytes --]


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.

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Lars Ingebrigtsen]

Pierre Téchoueyres <pierre.techoueyres@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

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Pierre Téchoueyres]

Hi Lars,
First Thanks for your reply.


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

> Pierre Téchoueyres <pierre.techoueyres@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. 

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Lars Ingebrigtsen]

Pierre Téchoueyres <pierre.techoueyres@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

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Protesilaos Stavrou]

On 2022-03-31, 13:49 +0200, Lars Ingebrigtsen <larsi@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

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Pierre Téchoueyres]

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

Hello Protesilaos,
Le jeudi 31 mars 2022 à 16:08, Protesilaos Stavrou 
<info@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 ?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Filter modus themes on modus-themes--current-theme --]
[-- Type: text/x-patch, Size: 1265 bytes --]

From 2e9802aceb9e2e77dd91f54a7727177038a35aec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre=20T=C3=A9choueyres?= <pierre.techoueyres@free.fr>
Date: Thu, 31 Mar 2022 21:16:42 +0200
Subject: [PATCH] Filter modus themes on modus-themes--current-theme

When custom-enabled-themes contains many themes, we're only
interrested by the first modus-* one.  This avoid a crash when
modus-themes--palette is called which complains that the first
theme returned by modus-themes--current-theme isn't either
modus-operandi or modus-vivendi (pcase use).
---
 modus-themes.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/modus-themes.el b/modus-themes.el
index 3f0e098..3a9a26e 100644
--- a/modus-themes.el
+++ b/modus-themes.el
@@ -3191,8 +3191,9 @@ Those are stored in `modus-themes-faces' and
        (custom-theme-set-variables ',name ,@modus-themes-custom-variables))))
 
 (defun modus-themes--current-theme ()
-  "Return current theme."
-  (car custom-enabled-themes))
+  "Return current modus theme."
+  (car (seq-filter (lambda (arg) (string-match-p "^modus" (symbol-name arg)))
+                   custom-enabled-themes)))
 
 ;; Helper functions that are meant to ease the implementation of the
 ;; above customization variables.
-- 
2.35.1

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Protesilaos Stavrou]

On 2022-03-31, 21:24 +0200, Pierre Téchoueyres <pierre.techoueyres@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

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Pierre Téchoueyres]

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

> On 2022-03-31, 21:24 +0200, Pierre Téchoueyres 
> <pierre.techoueyres@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.

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Eli Zaretskii]

> From: Protesilaos Stavrou <info@protesilaos.com>
> Date: Thu, 31 Mar 2022 22:57:57 +0300
> Cc: 54598@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
> 
> On 2022-03-31, 21:24 +0200, Pierre Téchoueyres <pierre.techoueyres@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?

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Pierre Téchoueyres]

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

>> From: Protesilaos Stavrou <info@protesilaos.com>
>> Date: Thu, 31 Mar 2022 22:57:57 +0300
>> Cc: 54598@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>
>> 
>> On 2022-03-31, 21:24 +0200, Pierre Téchoueyres 
>> <pierre.techoueyres@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.

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Eli Zaretskii]

> From: Pierre Téchoueyres <pierre.techoueyres@free.fr>
> Cc: Protesilaos Stavrou <info@protesilaos.com>, 54598@debbugs.gnu.org,
>  larsi@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.

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Pierre Téchoueyres]

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

>> From: Pierre Téchoueyres <pierre.techoueyres@free.fr>
>> Cc: Protesilaos Stavrou <info@protesilaos.com>, 
>> 54598@debbugs.gnu.org,
>>  larsi@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.

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Protesilaos Stavrou]

On 2022-04-02, 21:48 +0200, Pierre Téchoueyres <pierre.techoueyres@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

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Eli Zaretskii]

> From: Pierre Téchoueyres <pierre.techoueyres@free.fr>
> Cc: info@protesilaos.com, 54598@debbugs.gnu.org, larsi@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?

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Pierre Téchoueyres]

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


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

>> From: Pierre Téchoueyres <pierre.techoueyres@free.fr>
>> Cc: info@protesilaos.com, 54598@debbugs.gnu.org, larsi@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


[-- Attachment #2: emacs-27@Win10 --]
[-- Type: image/png, Size: 75302 bytes --]

[-- Attachment #3: emacs-27@Gnu/Linux --]
[-- Type: image/png, Size: 105795 bytes --]

[-- Attachment #4: Type: text/plain, Size: 235 bytes --]


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

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Eli Zaretskii]

> From: Pierre Téchoueyres <pierre.techoueyres@free.fr>
> Cc: info@protesilaos.com, 54598@debbugs.gnu.org, larsi@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?

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Protesilaos Stavrou]

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

>> From: Pierre Téchoueyres <pierre.techoueyres@free.fr>
>> Cc: info@protesilaos.com, 54598@debbugs.gnu.org, larsi@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

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Eli Zaretskii]

> From: Protesilaos Stavrou <info@protesilaos.com>
> Cc: 54598@debbugs.gnu.org, larsi@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?

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Protesilaos Stavrou]

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

>> From: Protesilaos Stavrou <info@protesilaos.com>
>> Cc: 54598@debbugs.gnu.org, larsi@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

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Eli Zaretskii]

> From: Protesilaos Stavrou <info@protesilaos.com>
> Cc: pierre.techoueyres@free.fr, 54598@debbugs.gnu.org, larsi@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.

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Protesilaos Stavrou]

On 2022-04-07, 11:27 +0300, Eli Zaretskii <eliz@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

bug#54598: 27.2; Bad interraction between modus-theme and hs-minor-mode

[Eli Zaretskii]

> From: Protesilaos Stavrou <info@protesilaos.com>
> Cc: pierre.techoueyres@free.fr, 54598@debbugs.gnu.org, larsi@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.