protesilaos / modus-themes

Highly accessible themes for GNU Emacs, conforming with the highest standard for colour contrast between background and foreground values (WCAG AAA).
https://protesilaos.com/emacs/modus-themes
GNU General Public License v3.0
549 stars 30 forks source link

Modus-Vivendi cursor wrong colour in new frame #7

Closed akoen closed 2 years ago

akoen commented 3 years ago

When using the modus-vivendi theme, making a new frame renders the cursor invisible in some buffers.

Steps to reproduce:

  1. emacs -Q

  2. M-: (load-theme 'modus-vivendi nil)

  3. Write some text in the scratch buffer. The cursor is visible (although here the window is unfocused for the screenshot). image

  4. M-x: make-frame

In the same buffer the cursor is now invisible, despite being positioned on the 'p' of 'Example text': image

I cannot reproduce the same issue with modus-operandi.

Info

protesilaos commented 3 years ago

Hello @akoen and thanks for reporting this! I can't reproduce it. Just rebuilt Emacs28 with native-comp. Following your steps, I get a visible cursor in both frames:

2021-09-03_08:12:15_1920x1080

Could this be related to ~/.Xresources? Though I have never used it for Emacs.

EDIT: add missing question mark.

akoen commented 3 years ago

Interesting. I have nothing related to Emacs in my =~/.Xresources=, and I cannot reproduce the issue with any other built-in-theme. However, if you can't reproduce then it seems likely to be an artifact of my system configuration. I'll be sure to update this issue if I find a solution, but feel free to close if there's nothing else to be done.

protesilaos commented 3 years ago

It is a strange problem and I am not sure what could be causing it---sorry about that.

I prefer to keep this issue open in case you find some more information.

In terms of the themes, modus-operandi and modus-vivendi derive from the same code (modus-themes.el), so I would expect the issue to be present in both of them.

magne-hov commented 2 years ago

Hi, I'm able to reproduce steps in the issue description.

I run emacs prebuilt from the emacs-gcc-wayland-devel-bin AUR package.

(emacs-verison)
=> "GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4) of 2021-09-21"

system-configuration-options
=> "--prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games --with-sound=alsa --with-modules --with-x-toolkit=gtk3 --with-cairo --with-xwidgets --with-native-compilation --with-pgtk --without-compress-install --without-gconf --without-gsettings --without-m17n-flt --enable-autodepend --enable-link-time-optimization CC=/usr/bin/clang '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 -g -flto' LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now 'CPP=/usr/bin/clang -E'"

system-configuration-features
=> "ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XIM XWIDGETS GTK3 ZLIB"

system-configuration
=> "x86_64-pc-linux-gnu"

I can also reproduce by creating new frames with emacsclient.

I'll post any developments.

protesilaos commented 2 years ago

Hello @magne-hov and thanks for the feedback!

I just installed that package from the AUR, logged into my Sway/Wayland session and launched emacs -Q. Then I loaded the theme with (load-theme 'modus-vivendi) (this is the version that is built into Emacs). The cursor is visible on my end. The function pgtk-backend-display-class tells me I am running the Wayland backend: GdkWaylandDisplay.

screenshot_2021-10-03-11:45:27

The details:

(pgtk-backend-display-class)
"GdkWaylandDisplay"

(emacs-version)
"GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2021-09-21"

system-configuration-options
"--prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games --with-sound=alsa --with-modules --with-x-toolkit=gtk3 --with-cairo --with-xwidgets --with-native-compilation --with-pgtk --without-compress-install --without-gconf --without-gsettings --without-m17n-flt --enable-autodepend --enable-link-time-optimization CC=/usr/bin/clang '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 -g -flto' LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now 'CPP=/usr/bin/clang -E'"

system-configuration-features
"ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XIM XWIDGETS GTK3 ZLIB"

system-configuration
"x86_64-pc-linux-gnu"

I can also reproduce by creating new frames with emacsclient.

I'll post any developments.

Please keep me posted. I am willing to help, though I first need to see the problem on my end.

alternateved commented 2 years ago

Hello, I am experiencing similar issue on NixOS 21.11 (Porcupine). I am using Emacs pgtk branch (with nix-community's emacs-overlay) with Wayland on Sway. It seems that when I create new frame and modus-vivendi is the active theme then the cursor is invisible (or in the color of active character). When I manually reload the theme, the cursor is back to its default white (and visible) state.

I noticed that when I was using just the Emacs gcc branch, I did not have that problem. After I started using the pgtk one, this issue started appearing.

My guess is that emacs-pgtk-native-comp-git package on AUR would be similar to the one I am using on Nixos now.

Details:

(pgtk-backend-display-class)
"GdkWaylandDisplay"

(emacs-version)
"GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0)"

system-configuration-options
"--prefix=/nix/store/ld18gqxb2f0vj9b1jw7k1c09mmn50hkz-emacs-pgtkgcc-20210816.0 --disable-build-details --with-modules --with-x-toolkit=gtk3 --with-cairo --with-native-compilation --with-pgtk"

system-configuration-features
"CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XIM GTK3 ZLIB"

system-configuration
"x86_64-pc-linux-gnu"
protesilaos commented 2 years ago

Thank you @alternateved for reporting this! Based on your description, this must be an upstream bug.

It seems that when I create new frame and modus-vivendi is the active theme then the cursor is invisible (or in the color of active character).

This point, in particular, indicates that something is amiss with whatever controls the Emacs frame. I know that terminal emulators have this behaviour of using the colour of the underlying character. But this was not the experience I had while using native-comp+pgtk on Sway, where the cursor always had the expected black/white colour. EDIT: I was using the Emacs GUI.

For reference, the cursor face has a very simple definition in the themes:

`(cursor ((,class :background ,fg-main)))

This basically makes it black for modus-operandi and white for modus-vivendi.

My guess is that emacs-pgtk-native-comp-git package on AUR would be similar to the one I am using on Nixos now.

I was using the native comp option with the pgtk branch for several days on a Sway session. This happened during mid to late September, as recorded in the commit log of my dotfiles: https://gitlab.com/protesilaos/dotfiles (last commit referencing Sway was on 2021-09-22 though I likely kept using it for several days afterwards). I also retried it a few days ago, as discussed in the previous message to this thread: https://github.com/protesilaos/modus-themes/issues/7#issuecomment-932891618.

I can try to install an AUR package or re-build from source, in an attempt to reproduce the issue, though at this stage I cannot see how that will change things with regard to the modus-themes.

My suggestion is that we report the bug to the Emacs maintainers. Have you tried M-x report-emacs-bug before? It populates a message composition buffer with your system's build information. And if you have not set up email inside of Emacs, you can copy that text to your mail app. If you do report it that way, you can also add my email in Cc (though I follow the Emacs bug tracker, anyhow): info@protesilaos.com.

What do you think?

alternateved commented 2 years ago

That is an excellent idea.

I have never used M-x report-emacs-bug before, therefore this might be a good opportunity to do so. As suggested, I will add your email in Cc.

Bug ID is 51161.

protesilaos commented 2 years ago

Thanks for reporting the bug upstream. Now we hope for the best.

Note that the feature/pgtk branch was last updated with commit 4c49ec7f86 on 2021-08-16: https://git.savannah.gnu.org/cgit/emacs.git/log/?h=feature/pgtk.

protesilaos commented 2 years ago

Hello again! It seems Hello again! It seems we have not heard anything about bug#51161, though the pgtk branch has been since merged into master. I am actually running my Emacs build with pgtk and have not encountered this bug.

If there are any updates on your end, I would like to know about them. Maybe we can get the maintainers to take another look at bug#51161 and, if necessary, help them by providing additional information. Or we can close this issue if it is no longer relevant.we

alternateved commented 2 years ago

Hello, thank you for tracking this issue. Currently I cannot test this issue since I am away from my personal laptop running affected environment, but I can assure that the bug was still relevant (week and a half ago) when running Emacs build with pgtk and native-comp enabled on NixOS.

alternateved commented 2 years ago

I can confirm that this issue also appears on openSUSE Tumbleweed while using this build.

protesilaos commented 2 years ago

I am not denying the existence of the bug. It just is that I have never been able to reproduce it. I have been using the pgtk build full-time since it got merged into master and have never encountered any issues. Not in my setup, not with emacs -Q.

I just rebuilt Emacs to give it another try. Still not possible to reproduce the bug.

This is the information of my system (I build Emacs with a custom PKGBUILD script on Arch Linux based on the emacs-git AUR package):

In GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.17.4)
 of 2022-01-03 built on kronos
Repository revision: ab5ee3e29e916d4009b301841e9780aad564a6a0
Repository branch: makepkg
System Description: Arch Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-sound=alsa --with-modules --without-libotf --without-m17n-flt
 --without-gconf --without-gsettings --with-native-compilation
 --with-xinput2 --with-pgtk --without-xaw3d --with-sound=no
 --without-gpm --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''

I got that information with:

(require 'emacsbug)
(emacs-bug--system-description)

Or by evaluating each of the following:

(emacs-version)
=> "GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.17.4) of 2022-01-03"

system-configuration-options
=> "--prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games --with-sound=alsa --with-modules --without-libotf --without-m17n-flt --without-gconf --without-gsettings --with-native-compilation --with-xinput2 --with-pgtk --without-xaw3d --with-sound=no --without-gpm --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'"

system-configuration-features
=> "ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP XIM GTK3 ZLIB"

system-configuration
=> "x86_64-pc-linux-gnu"

We need to find a reproducible recipe so that we can petition the maintainers about it. If I can't reproduce it, chances are that others may have a similar experience and we won't get any help.

alternateved commented 2 years ago

Yes, you are right, apologies.

What would happen if you would have an init.el file with only this line:

(add-hook 'after-init-hook (lambda () (load-theme 'modus-vivendi)))

And if you would start emacsclient with that command:

emacsclient -c -a ''

I know that for sure you already tried whatever you could to reproduce it, but maybe it is worth a go.

protesilaos commented 2 years ago

On 2022-01-03, 09:14 -0800, Tomasz Hołubowicz @.***> wrote:

Yes, you are right, apologies.

What would happen if you would have an init.el file with only this line:

(add-hook 'after-init-hook (lambda () (load-theme 'modus-vivendi)))

And if you would start emacsclient with that command:

emacsclient -c -a ''

Yes, I can reproduce the bug now. A couple of notes:

I know that for sure you already tried whatever you could to reproduce it, but maybe it is worth a go.

We have something here: that is a good step. I will continue experimenting with this and then we can report the bug against emacs.git (now that I have a recipe, I can write the report and add you in Cc or post the link to the issue tracker).

-- Protesilaos Stavrou https://protesilaos.com

protesilaos commented 2 years ago

I reported the bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53073.

The weird thing is that the cursor face is always correctly set to a white background, as I explain in the bug report. This screenshot shows exactly that:

screenshot_region_2022-01-07-12:46:50

protesilaos commented 2 years ago

The bug was fixed upstream! Please rebuild Emacs and give it a try.

alternateved commented 2 years ago

Thank you! It is amazing that this issue is not there anymore.

protesilaos commented 2 years ago

Thank you! It is amazing that this issue is not there anymore.

Indeed! I think we were a bit unlucky with the timing of this bug, because there was a point where development on the pgtk branch had stalled while preparations were made to cut the emacs-28 branch (pgtk did not make the cut). Whereas now we got the timing right and it was fixed right away.

Can @magne-hov and @akoen please confirm if this bug has been fixed on their end (this is about the invisible cursor for modus-vivendi on a pgtk build)?

chinmayanagpal commented 2 years ago

In the meantime, this makes the theme load upon each call to make-frame:

(add-to-list 'after-make-frame-functions #'(lambda (x) (load-theme 'modus-vivendi))) 
protesilaos commented 2 years ago

In the meantime, this makes the theme load upon each call to make-frame:

Do you think this is necessary? Does the problem with the cursor persist if you do not set that?

chinmayanagpal commented 2 years ago

Do you think this is necessary? Does the problem with the cursor persist if you do not set that?

Sorry, I meant until the fix is included in a release (if one is using Emacs 28 with PGTK)

protesilaos commented 2 years ago

Sorry, I meant until the fix is included in a release (if one is using Emacs 28 with PGTK)

I see. Thanks!

About the #' before the lambda, the manual states:

The read syntax ‘#'’ is a short-hand for using ‘function’.  The
following forms are all equivalent:

     (lambda (x) (* x x))
     (function (lambda (x) (* x x)))
     #'(lambda (x) (* x x))

Evaluate:

(info "(elisp) Anonymous Functions")
chinmayanagpal commented 2 years ago

Sorry, I meant until the fix is included in a release (if one is using Emacs 28 with PGTK)

I see. Thanks!

About the #' before the lambda, the manual states:

The read syntax ‘#'’ is a short-hand for using ‘function’.  The
following forms are all equivalent:

     (lambda (x) (* x x))
     (function (lambda (x) (* x x)))
     #'(lambda (x) (* x x))

Evaluate:

(info "(elisp) Anonymous Functions")

Thanks for the clarification!

iyerkri commented 1 year ago

I apologize if I am bumping an old issue, but I am facing the same issue as above and unable to figure out how to sort it out. I am on archlinux with wayland and using the modus-vivendi theme on the emacs AUR package emacs-gcc-wayland-devel-bin (https://aur.archlinux.org/packages/emacs-gcc-wayland-devel-bin). Every time a new frame is launched, the cursor color is black and hence invisible. Manually changing the cursor color works, but the color is fixed and does not match with the font-face color (not sure if this is the terminology), as in modus-operandi.

Is it that the specific emacs AUR package I am using does not yet have the above fix, and I should just wait until it gets patched? This seems unlikely, since the version is 28.2.50.

protesilaos commented 1 year ago

Hello @iyerkri!

I think the PGTK on Emacs 28 is fundamentally problematic. I advise against it. The --with-pgtk was added to Emacs 29.

The way I see it, you have two options: (i) use the emacs package from the official Arch repos as it also is on Emacs 28 and has --with-native-compilation enabled, or (ii) build Emacs from source which gives you the unreleased version 30.

EDIT: The official Emacs package with native compilation is emacs-nativecomp. I did not pay close attention to the PKGBUILD I linked to.

With Emacs 30, you can customise your build to include PGTK.

I do it this way:

Those granted, my opinion on PGTK is that it offers a minor advantage if you are striving for a pure wayland experience. Otherwise it has major issues when you run Emacs in Xorg. There may be a time you want to switch away from Wayland and which point your Emacs is subject to crashes.

As such, I ended up using emacs-git without PGTK: it works just find on Wayland and I do not mind having XWayland for this case.

iyerkri commented 1 year ago

Thank you @protesilaos. I will try out what you recommend. Although it is not necessary, it would be nice to have PGTK, since otherwise the fonts are too blurry.

protesilaos commented 1 year ago

You are welcome @iyerkri! I remember the blurry fonts. It no longer exists on Emacs 29+, though it may still do in Emacs 28 with PGTK.

endter commented 1 year ago

This bug in Modus Operandi is present in Mituharu's emacs-mac. I have tested with the releases of Emacs 28 and 29.1. PGTK (and Emacs 30, which is not available in the Mac port) won't be much help here. Any suggestions?

protesilaos commented 1 year ago

Hello @endter! From what I can tell, the PGTK should not be used on the Mac: it is a Linux-specific thing that only works with the Wayland display protocol.