PGTK issue: doesn't look like expected on my setup

[magthe]

This is what the defaults look like for me (zoomed in a bit):

My config:

(use-package indent-bars
  :straight (:host github
             :repo "jdtsmith/indent-bars")
  :hook ((haskell-mode python-mode yaml-mode) . indent-bars-mode))

I seem to have stipple support, but maybe it's broken?

(set-face-stipple 'default (,(window-font-width) 1 ,(unibyte-string 1)))` gives the following error

Debugger entered--Lisp error: (error "Invalid stipple attribute" 23 1 "\1")
  set-face-attribute(default nil :stipple (23 1 "\1"))
  set-face-stipple(default (23 1 "\1"))
  eval-expression((set-face-stipple 'default `(,(window-font-width) 1 ,(unibyte-string 1))) nil nil 127)
  funcall-interactively(eval-expression (set-face-stipple 'default `(,(window-font-width) 1 ,(unibyte-string 1))) nil nil 127)
  command-execute(eval-expression)

I'm not sure what that means really.

[jdtsmith]

I see, so it is working, just looks different. I bet it is the theme after all. How do your outline-* faces look? M-x list-faces-display. I suspect they have background set in this manner. If so, just add :face-bg t to indent-bars-color-by-depth, checking that variable doc for more info.

For the other error, for this large of a character width, you need 3 bytes! I updated the test code; please give a try.

[jdtsmith]

Also, C-h v indent-bars-color-by-depth and show the value.

[magthe]

The outline faces:

and

indent-bars-color-by-depth: (:regexp "outline-\\([0-9]+\\)" :blend 1)

also, trying the updated test code gives me a window that looks like this

The theme I'm using is Nord from doom themes.

[skrat]

Same issue here. Also doomed.

[magthe]

Actually it doesn't look right with the default theme either:

Could Wayland or GTK3 be to blame?

[sauvala]

Same issue for me. I tried with my vanilla Emacs (on Linux + Wayland) config with different themes but there was always that “wider background” color of the indentation marks that did not match my theme’s color.

[jdtsmith]

Huh, interesting. Yeah, thinking about it more, there is no background specified (except for the current depth highlight, if you have :background set). So it's unclear why "stipple + face foreground color = inverse". Can you all try the stipple test code in a plain scratch buffer and post images of results? @magthe what is up with those colored blocks? Are those text?

For me the test looks like:

[jdtsmith]

Also, everyone post their version, please. All Wayland?

[magthe]

@magthe what is up with those colored blocks? Are those text?

Yes, that would by due to rainbow-delimiters. When it's turned off it looks like this when I run the stipple test code.

[magthe]

Version and build options:

GNU Emacs 30.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.8) of 2023-07-26

--prefix=/usr
--sysconfdir=/etc
--libexecdir=/usr/lib
--localstatedir=/var
--mandir=/usr/share/man
--with-gameuser=:games
--with-modules
--without-libotf
--without-m17n-flt
--without-gconf
--with-native-compilation=yes
--with-native-compilation=aot
--with-xinput2
--with-pgtk
--without-xaw3d
--with-sound=no
--with-xwidgets
--with-tree-sitter
--without-compress-install
'--program-transform-name=s/\\([ec]tags\\)/\\1.emacs/'
'CFLAGS=-march=x86-64
-mtune=generic
-O2
-pipe
-fno-plt
-fexceptions
-Wp,-D_FORTIFY_SOURCE=2
-Wformat
-Werror=format-security
-fstack-clash-protection
-fcf-protection'
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
'CXXFLAGS=-march=x86-64
-mtune=generic
-O2
-pipe
-fno-plt
-fexceptions
-Wp,-D_FORTIFY_SOURCE=2
-Wformat
-Werror=format-security
-fstack-clash-protection
-fcf-protection
-Wp,-D_GLIBCXX_ASSERTIONS'

[jdtsmith]

I see, now I can see the "inverse text" just barely peeking through there in your image. Needless to say, this is not how a stipple is supposed to look (it was invented as a "cheap shading option" in the monochrome days). This seems to draw the inverse of overlaying a stipple. I.e. it uses the stipple as a mask and only lets through data in those regions.

This is looking more to me like a display bug in whichever version you are all using; please report that with M-x emacs-report-bug.

[jdtsmith]

Thanks for the info: --with-pgtk means Wayland right (not on Linux anymore)? @sauvala , @skrat ? Also, let me know if you can test on a non-Wayland version.

[skrat]

@jdtsmith ---with-pgtk doesn't mean Wayland, it means Pure GTK. This is Emacs rendering engine, and it's been merged to master, the old X11 stuff is no longer being developed. It's now role of GTK to manage the windows and handle the rendering. And yes, that's what I'm running along with native compilation.

[jdtsmith]

OK, it seems clear that Pure GTK emacs incorrectly displays stipples. I'd suggest reporting that with M-x report-emacs-bug; feel free to use my test code for this. I'll document it, but not sure I can do much unless someone has a trick to enable correct stipple display. Will leave open for a bit to see.

[jdtsmith]

You can also try this simpler test:

(let* ((w (window-font-width))
       (stipple `(,w 1 ,(apply #'unibyte-string
			       (append (make-list (1- (/ (+ w 7) 8)) ?\0)
				       '(1))))))
  (insert "\n" (propertize (concat  (make-string 15 ?\s)
				    "THIS IS A TEST"
				    (make-string 15 ?\s))
                           'face `(:background "red" :foreground "blue" :stipple ,stipple))))

Should look like:

[skrat]

[skrat]

To be honest, I think 'stipple` is kinda cool, but I don't truly care what face attributes are being used. I'd rather be in control of that instead of the package. And if stipple doesn't work, who cares, I'll use something else. I'm here because all the other indent guides packages suck and I'm hoping this one won't. That all

[jdtsmith]

There aren't a lot of choices for face attributes that draw vertical bars; who knew a >40yr old functionality for monochrome displays would be so poorly supported in various modern builds?

I have an update in the works that will let you use display box-chars, which should work for terminal and stipple-misbehaving emacsen. That might work for you, keep an eye out.

[magthe]

I made an attempt at reporting the bug using M-x report-emacs-bug, hopefully it worked (it still hasn't appeared in the archive, but maybe it's just really slow).

[magthe]

The upstream bug is here and due to my impatience and the amazingly slow processing there's a copy here.

The associated archived emails are here and here.

[magthe]

A fix announcement has been posted upstream.

• 74d6604eaa2d770626309181ac4bc4f2598e63e7

I've tested it and both the test expression and the indent-bars package itself. Both now look as expected.

Note that the fix is on the Emacs 30 branch only, i.e. indent-bars won't work on Emacs 29 with PGTK.

[jdtsmith]

Great thanks for pushing this through. Updated the README.

[jdtsmith]

@magthe you may want to acknowledge the fix back to emacs-bugs.

[skrat]

I made it! Built the latest (30) from sources and it's working... kinda

indent.webm

indent2.webm

[jdtsmith]

I have pushed changes that add support for drawing in terminal with a box char of your choice (e.g. │). This also works in graphical displays if you enable indent-bars-prefer-character. Please test and let me know of any issues.

[jdtsmith]

@magthe or anyone: do you use --with-cairo, which I guess is now the default? @minad is having no-stipple issues and we're wondering if that could be the culprit.

[minad]

@jdtsmith --with-cairo is enabled by default on Emacs 28 and newer if available. Cairo is known to have issues with bitmap fonts. But there is not really a way around Cairo + Harfbuzz since multiple features are only available with that combination, e.g., image manipulation or multi-color emoji fonts.

NEWS.28:

The Cairo graphics library is now used by default if present. Building with Cairo is known to cause some problems with bitmap fonts. This may require you to adjust your font settings, or to build with Xft support instead.

libXft is unmaintained, and causes a number of problems with modern fonts including but not limited to crashes; support for it may be removed in a future version of Emacs. Please consider using Cairo + HarfBuzz instead.

NEWS.27:

Multicolor fonts such as "Noto Color Emoji" can be displayed on Emacs configured with Cairo drawing and linked with cairo >= 1.16.0.

Emacs now supports resizing and rotating images without ImageMagick. All modern systems support this feature. (On GNU and Unix systems, Cairo drawing or the XRender extension to X11 is required for this to be available; the configure script will test for it and, if found, enable scaling.)

[magthe]

@magthe or anyone: do you use --with-cairo, which I guess is now the default? @minad is having no-stipple issues and we're wondering if that could be the culprit.

No, I'm still running with the same options as before, no --with-cairo.

[minad]

Am I still the only one with this issue? My system-configuration-features currently are:

CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG JSON LIBOTF LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XPM LUCID ZLIB

I assume that the problem could be due to HARFBUZZ in combination with CAIRO. Any HARFBUZZ users? Besides that I am using the lightweight X11 LUCID toolkit.

[jdtsmith]

On linux, I haven't heard from anyone besides PGTK users, for whom stipples did display, but incorrectly. The only builds where I know stipples do not display at all are Win and NS ports. So I wonder how prevalent Cairo is, or if it is the culprit at all. It wouldn't be a total surprise for stipple to have been incorrectly ported to a new display system, since that very thing has happened in other ports. But I'd guess 2/3rds of indent-bars users are on linux, so not hearing from anyone else seems... strange. If it's simple to produce a build with Cairo, that would be definitive. Might also be worth taking up on emacs-devel; they resolved the PGTK stipple issue very quickly.

[minad]

Cairo is very prevalent since it sits below the gtk/pgtk displays. It is enabled by default if available, see my other comment. Also harfbuzz is recommended afaik. I really don't know what is so odd about my configuration. Have to try various settings or look into the stipple code paths.

[jdtsmith]

I agree it is mysterious, and worth looking into.

[jdtsmith]

@minad did you ever get a chance to try a build without Cairo to see if that's the culprit? Surprising if so.

[minad]

On 10/7/23 22:03, JD Smith wrote: @minad <https://github.com/minad> did you ever get a chance to try a build without Cairo to see if that's the culprit? Surprising if so.

Not yet.

[minad]

@jdtsmith I compiled Emacs in a few different configurations and got the following results:

FAIL --with-cairo    --with-cairo-xcb    --without-harfbuzz
FAIL --with-cairo    --without-cairo-xcb --with-harfbuzz
GOOD --without-cairo --without-cairo-xcb --without-harfbuzz

I don't know what is wrong with my Cairo, since apparently it works correctly for others.

[jdtsmith]

Thanks for the report; I've added some information to the Compatibility section of the README. Sounds like Cairo is the culprit. It doesn't totally surprise me given the PGTK issue, but I don't know much about Cairo. Worth reporting as a bug; problems were corrected quickly in the case of PGTK.

[minad]

Do you know if the aformentioned PGTK (which also relies on Cairo) fix landed in Emacs 29 or Emacs master, which will become Emacs 30? I am "still" running Emacs 29, so it could very well be that stipples will work with Cairo in Emacs 30 in other configurations too.

[jdtsmith]

It was too late for Emacs 29, so I believe it's on master. Maybe worth testing with that fix, but the misbehavior was different with PGTK (stipples showed, but incorrectly).