bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

[Campbell Barton]

With PGTK enabled (--with-pgtk) the following occurs:

- Press C-S-u
- Press a

The character 'a' is entered.

Without PGTK enabled, the following occurs:

- Press C-S-u
- Press a

The character 'aaaa' is entered 4x.

Note that PGTK seems to swallow this binding, since it's not possible to
check what the shortcut does by pressing:

C-H, K, C-S-u

Which reports without PGTK: (universal-argument)



In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.31, cairo version 1.17.4)
 of 2022-01-12 built on austpc
Repository revision: 8555a3e1ed1d34cbaa172bde86eb3b11a1cd7940
Repository branch: master
System Description: Arch Linux

Configured using:
 'configure --prefix=/opt/emacs --with-sound=no --disable-acl
 --with-file-notification=no --with-xpm --with-native-compilation
 --with-jpeg --with-tiff --with-gif --with-png --without-rsvg
 --without-lcms2 --without-libsystemd --without-gsettings
 --without-harfbuzz --without-m17n-flt --without-libotf --without-gpm
 --without-dbus --without-gsettings --without-gconf --without-selinux
 --without-gnutls --with-pgtk --without-makeinfo --without-libgmp
 --with-zlib --with-compress-install --with-threads
 --without-toolkit-scroll-bars --with-x-toolkit=gtk3 --with-xft
 --with-modules 'CFLAGS=-O3 -mtune=native -march=native -pipe
 -fomit-frame-pointer''

Configured features:
CAIRO FREETYPE GIF GLIB JPEG JSON LIBXML2 MODULES NATIVE_COMP PDUMPER
PGTK PNG SECCOMP SQLITE3 THREADS TIFF WEBP XIM GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date seq gv
subr-x byte-opt bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget keymap hashtable-print-readable backquote threads
dynamic-setting font-render-setting cairo move-toolbar gtk x-toolkit
pgtk multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 45508 6842)
 (symbols 48 5609 1)
 (strings 32 18557 3267)
 (string-bytes 1 622864)
 (vectors 16 10816)
 (vector-slots 8 157953 15748)
 (floats 8 25 28)
 (intervals 56 255 0)
 (buffers 992 11))

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Campbell Barton <ideasman42@gmail.com> writes:

> With PGTK enabled (--with-pgtk) the following occurs:
>
> - Press C-S-u
> - Press a
>
> The character 'a' is entered.
>
> Without PGTK enabled, the following occurs:
>
> - Press C-S-u
> - Press a
>
> The character 'aaaa' is entered 4x.
>
> Note that PGTK seems to swallow this binding, since it's not possible to
> check what the shortcut does by pressing:
>
> C-H, K, C-S-u
>
> Which reports without PGTK: (universal-argument)

This has been reported at least twice already.  Someone should volunteer
to find and merge all those bugs, but in short: most GTK input method
modules stupidly eat the shift modifier, and the only workaround is to
disable the use of GTK input methods by setting `pgtk-use-im-context' to
nil.

This is really a bug in the various input modules and should be reported
to their developers instead instead.  If you're using ibus, for example,
complain to ibus developers about their IM context not setting the shift
modifier mask in an event sent by the filter.

Alternatively, you can use the regular X build, which is a much superior
experience over the PGTK port as long as you're not using Wayland.

Thanks, and please let us know about the progress of your complaining to
the IM module developers.  It would be greatly appreciated.

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> This has been reported at least twice already.  Someone should volunteer
> to find and merge all those bugs

I found bug#49211, which seems to be the same problem, so I've merged
this with that one.

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

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I found bug#49211, which seems to be the same problem, so I've merged
> this with that one.

Great, thanks!

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

[Morgan Smith]

Hello,

I'd like to report that my super key stopped registering.  I 
suspected commit 1404e16975 caused it so I did a quick `git revert 
1404e16975` ontop of 807682de1e and that fixed it.

I'm running pgtk on wayland with (pgtk-use-im-context nil) 
(although that doesn't seem to affect this issue). 

Thanks,

Morgan

PGTK-related misconceptions

[Po Lu]

Morgan Smith <morgan.j.smith@outlook.com> writes:

> I'd like to report that my super key stopped registering.  I suspected
> commit 1404e16975 caused it so I did a quick `git revert 1404e16975`
> ontop of 807682de1e and that fixed it.

Crystal ball says you are using X Windows, and have to put

  remove mod4 = Hyper_L

in your ~/.Xmodmap file, because GTK doesn't try as hard as regular X11
Emacs to work around the common kind of virtual modifier
misconfiguration.

People using X should _never_ use PGTK.  The regular X build does a much
better job at supporting that than PGTK ever will.

It is completely pointless to put up with half-working child frames,
random keyboard-related lossage, random frame placement/resizing
failures, so the actual fix is to delete `--with-pgtk' from your calls
to configure.

Similarly, people building packages with PGTK enabled that are labeled
"enhanced" are doing their users a disservice.  No packager should
enable PGTK by default, and every package should ideally come with a big
disclaimer warning against using PGTK on window systems otherwise
supported by Emacs, since time and experience shows that Emacs generally
does a much better job at their support than GTK.

Many people are also being mislead by articles on the internet claiming
that PGTK leads to faster redisplay, such as this one:
http://www.cesarolea.com/posts/emacs-native-compile

That is not true, since regular Emacs with cairo uses more-or-less the
same rendering path as PGTK, except when PGTK runs on Wayland, where it
uses software rendering and does image compositing in software, and is
thus slower than everything else.  Scrolling on PGTK is also not as
efficient as XCopyArea requests.

But the difference in speed even on Wayland is negligible, not easy to
benchmark, and not at all visible to the human eye.

Re: PGTK-related misconceptions

[Byung-Hee HWANG]

Po Lu <luangruo@yahoo.com> writes:

> (...thanks...)
> People using X should _never_ use PGTK.  ...

+9999; REALLY, i am of the same opinion!

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _救濟蒼生_ 감사합니다_^))//

Re: PGTK-related misconceptions

[Eric Abrahamsen]

Po Lu <luangruo@yahoo.com> writes:

> Morgan Smith <morgan.j.smith@outlook.com> writes:
>
>> I'd like to report that my super key stopped registering.  I suspected
>> commit 1404e16975 caused it so I did a quick `git revert 1404e16975`
>> ontop of 807682de1e and that fixed it.
>
> Crystal ball says you are using X Windows, and have to put
>
>   remove mod4 = Hyper_L
>
> in your ~/.Xmodmap file, because GTK doesn't try as hard as regular X11
> Emacs to work around the common kind of virtual modifier
> misconfiguration.
>
> People using X should _never_ use PGTK.  The regular X build does a much
> better job at supporting that than PGTK ever will.

Hey, thanks for this! I'd set --with-pgtk on my X11 machine ages ago,
not even knowing why, and reconfiguring without that flag solved my
problems with "C-;" being received as plain ";" (and some other funky
key misreadings). This is why we don't copy-n-paste config!

Thanks again,
Eric

Re: PGTK-related misconceptions

[Sean Whitton]

Hello,

On Fri 15 Apr 2022 at 10:29am +08, Po Lu wrote:

> People using X should _never_ use PGTK.  The regular X build does a much
> better job at supporting that than PGTK ever will.

The discussion of pgtk in INSTALL doesn't say this.  If I was packaging
Emacs for a distro I think I could be misled into thinking I should
replace my gtk package with pgtk.  But in fact I should supply both.

Here is a very simple suggested addition:

> diff --git a/INSTALL b/INSTALL
> index b1e3c72c4b..6cbd74ed55 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -253,6 +253,10 @@ to force GTK+ to run under Broadway, start Emacs like this:
>
>  (where '...' denotes any further options you may want to pass to Emacs).
>
> +If you use X exclusively, do not use the PGTK port.  There are a
> +number of respects in which the regular --with-x-toolkit=gtk build
> +works better.
> +
>  The GNUstep build also supports the Wayland window system.  If that is
>  what you want, see nextstep/INSTALL.

-- 
Sean Whitton

Re: PGTK-related misconceptions

[Po Lu]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> On Fri 15 Apr 2022 at 10:29am +08, Po Lu wrote:
>
>> People using X should _never_ use PGTK.  The regular X build does a much
>> better job at supporting that than PGTK ever will.
>
> The discussion of pgtk in INSTALL doesn't say this.  If I was packaging
> Emacs for a distro I think I could be misled into thinking I should
> replace my gtk package with pgtk.  But in fact I should supply both.

INSTALL already recommends PGTK only for using alternative window
systems, not X, which is explained first.

Thanks.

Re: PGTK-related misconceptions

[Sean Whitton]

Hello,

On Mon 18 Apr 2022 at 01:31pm +08, Po Lu wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> Hello,
>>
>> On Fri 15 Apr 2022 at 10:29am +08, Po Lu wrote:
>>
>>> People using X should _never_ use PGTK.  The regular X build does a much
>>> better job at supporting that than PGTK ever will.
>>
>> The discussion of pgtk in INSTALL doesn't say this.  If I was packaging
>> Emacs for a distro I think I could be misled into thinking I should
>> replace my gtk package with pgtk.  But in fact I should supply both.
>
> INSTALL already recommends PGTK only for using alternative window
> systems, not X, which is explained first.

It recommends it /for/ using alternative window systems, not /only for/
using alternative window systems, so far as I can tell.  For example

    With the PGTK build, you will be able to switch between running
    Emacs on X, Wayland and Broadway using the 'GDK_BACKEND' environment
    variable.

really makes it sound like it's find to use it if you're using only X.

-- 
Sean Whitton

Re: PGTK-related misconceptions

[Po Lu]

Sean Whitton <spwhitton@spwhitton.name> writes:

> It recommends it /for/ using alternative window systems, not /only for/
> using alternative window systems, so far as I can tell.  For example
>
>     With the PGTK build, you will be able to switch between running
>     Emacs on X, Wayland and Broadway using the 'GDK_BACKEND' environment
>     variable.
>
> really makes it sound like it's find to use it if you're using only X.

I don't see a difference between "for" and "only for" in this case,
because above the section talking about PGTK (and also in the details
below) is a large amount of commentary discussing the regular X build.

Re: PGTK-related misconceptions

[Sean Whitton]

Hello,

On Mon 18 Apr 2022 at 01:57PM +08, Po Lu wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> It recommends it /for/ using alternative window systems, not /only for/
>> using alternative window systems, so far as I can tell.  For example
>>
>>     With the PGTK build, you will be able to switch between running
>>     Emacs on X, Wayland and Broadway using the 'GDK_BACKEND' environment
>>     variable.
>>
>> really makes it sound like it's find to use it if you're using only X.
>
> I don't see a difference between "for" and "only for" in this case,
> because above the section talking about PGTK (and also in the details
> below) is a large amount of commentary discussing the regular X build.

Well, I can only reiterate that on my reading the file does not clearly
express the idea that PGTK should be avoided if you don't absolutely
require it.  And I'm someone relatively familiar with PGTK.  I can
easily imagine us seeing distros replacing the package emacs-gtk with
emacs-pgtk on the assumption that it is a straight upgrade.  It will be
hard to undo that.

You mentioned that various blog posts give people the wrong idea.  We
could decide to make the point extra clearly in INSTALL for the sake of
counteracting a misconception that is continuing to spread, and is
showing no signs of stopping.

-- 
Sean Whitton

Re: PGTK-related misconceptions

[Jim Porter]

On 4/17/2022 10:57 PM, Po Lu wrote:
> Sean Whitton <spwhitton@spwhitton.name> writes:
> 
>> It recommends it /for/ using alternative window systems, not /only for/
>> using alternative window systems, so far as I can tell.  For example
>>
>>      With the PGTK build, you will be able to switch between running
>>      Emacs on X, Wayland and Broadway using the 'GDK_BACKEND' environment
>>      variable.
>>
>> really makes it sound like it's find to use it if you're using only X.
> 
> I don't see a difference between "for" and "only for" in this case,
> because above the section talking about PGTK (and also in the details
> below) is a large amount of commentary discussing the regular X build.

Reading through these sections of INSTALL, I found it very easy to 
assume that PGTK was a direct upgrade that would just let me "switch 
between running Emacs on X, Wayland and Broadway". An extremely-careful 
reader might then wonder why "--with-pgtk" isn't enabled by default on 
systems with the necessary dependencies, but that only *implies* that 
there are downsides to PGTK rather than stating it.

I think it would be best to state explicitly that there are problems 
with the PGTK build, though INSTALL probably doesn't need to go into any 
more detail than that. In practice, a lot of people will probably just 
skim the documentation, so they might miss some of the more subtle 
points unless they're very clearly called out.

Re: PGTK-related misconceptions

[Po Lu]

Jim Porter <jporterbugs@gmail.com> writes:

> Reading through these sections of INSTALL, I found it very easy to
> assume that PGTK was a direct upgrade that would just let me "switch
> between running Emacs on X, Wayland and Broadway". An
> extremely-careful reader might then wonder why "--with-pgtk" isn't
> enabled by default on systems with the necessary dependencies, but
> that only *implies* that there are downsides to PGTK rather than
> stating it.
>
> I think it would be best to state explicitly that there are problems
> with the PGTK build, though INSTALL probably doesn't need to go into
> any more detail than that. In practice, a lot of people will probably
> just skim the documentation, so they might miss some of the more
> subtle points unless they're very clearly called out.

Sure, I won't insist if everyone else seems to agree this should be
mentioned (again) in INSTALL.

Feel free to install changes to that effect.

Re: PGTK-related misconceptions

[Sean Whitton]

Hello,

On Tue 19 Apr 2022 at 09:02AM +08, Po Lu wrote:

> Jim Porter <jporterbugs@gmail.com> writes:
>
>> Reading through these sections of INSTALL, I found it very easy to
>> assume that PGTK was a direct upgrade that would just let me "switch
>> between running Emacs on X, Wayland and Broadway". An
>> extremely-careful reader might then wonder why "--with-pgtk" isn't
>> enabled by default on systems with the necessary dependencies, but
>> that only *implies* that there are downsides to PGTK rather than
>> stating it.
>>
>> I think it would be best to state explicitly that there are problems
>> with the PGTK build, though INSTALL probably doesn't need to go into
>> any more detail than that. In practice, a lot of people will probably
>> just skim the documentation, so they might miss some of the more
>> subtle points unless they're very clearly called out.
>
> Sure, I won't insist if everyone else seems to agree this should be
> mentioned (again) in INSTALL.
>
> Feel free to install changes to that effect.

Cool, now done.

-- 
Sean Whitton

Re: PGTK-related misconceptions

[Tim Cross]

Jim Porter <jporterbugs@gmail.com> writes:

>
> I think it would be best to state explicitly that there are problems with the
> PGTK build, though INSTALL probably doesn't need to go into any more detail than
> that. In practice, a lot of people will probably just skim the documentation, so
> they might miss some of the more subtle points unless they're very clearly
> called out.

I agree. I think this is the main point being missed by others who have
argued the existing documentation is clear enough. Like it or not,
people often don't read the documentation or NEWS file carefully. There
is also a tendency for people to believe any new feature is an
improvement and I suspect many people will think a pure GTK build is
going to be better than a hybrid X/GTK one. 

We should just add a very explicit and clear warning not to use
--with-pgtk if your running under X and put this statement right at the
beginning of the section in the NEWS file about this new option. 

It might even be worthwhile adding a warning in configure as well (like
the one we have about pop support). Like others, I expect many
distributions are going to bundle emacs-gtk believing it is an
improvement. I suspect it is going to be a bigger issue given that some
popular distributions, like fedora, will be shipping with wayland as
their default but there will likely be many who will choose to switch
back to X, but then be faced with an Emacs built with pgtk to better
support the default wayland setup. 

Re: PGTK-related misconceptions

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Date: Tue, 19 Apr 2022 12:18:07 +1000
> Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org,
>  Sean Whitton <spwhitton@spwhitton.name>
> 
> I agree. I think this is the main point being missed by others who have
> argued the existing documentation is clear enough. Like it or not,
> people often don't read the documentation or NEWS file carefully. There
> is also a tendency for people to believe any new feature is an
> improvement and I suspect many people will think a pure GTK build is
> going to be better than a hybrid X/GTK one. 
> 
> We should just add a very explicit and clear warning not to use
> --with-pgtk if your running under X and put this statement right at the
> beginning of the section in the NEWS file about this new option. 

Aren't you contradicting yourself here?  If people don't read
documentation, how can any addition to the documentation solve this
issue?  (Of course, I don't object to saying something in INSTALL
about that, just pointing out that it's hard to have it both ways.)

> It might even be worthwhile adding a warning in configure as well (like
> the one we have about pop support).

I object to annoying people who build Emacs with such warnings.
Besides, warnings (as opposed to errors) in the configure script are
easily overlooked, because people tend to leave the build run
unattended, and do other useful things while it runs.

> Like others, I expect many distributions are going to bundle
> emacs-gtk believing it is an improvement. I suspect it is going to
> be a bigger issue given that some popular distributions, like
> fedora, will be shipping with wayland as their default but there
> will likely be many who will choose to switch back to X, but then be
> faced with an Emacs built with pgtk to better support the default
> wayland setup.

IME, there's nothing we can do against such misconceptions.  We will
get bug reports and will respond by pointing people to NEWS and
INSTALL.  Eventually, enough people will bump into this to realize the
truth, and the issue will go away.  No catastrophe that I could spot,
and no need to get too excited.

Re: PGTK-related misconceptions

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tim Cross <theophilusx@gmail.com>
>> Date: Tue, 19 Apr 2022 12:18:07 +1000
>> Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org,
>>  Sean Whitton <spwhitton@spwhitton.name>
>> 
>> I agree. I think this is the main point being missed by others who have
>> argued the existing documentation is clear enough. Like it or not,
>> people often don't read the documentation or NEWS file carefully. There
>> is also a tendency for people to believe any new feature is an
>> improvement and I suspect many people will think a pure GTK build is
>> going to be better than a hybrid X/GTK one. 
>> 
>> We should just add a very explicit and clear warning not to use
>> --with-pgtk if your running under X and put this statement right at the
>> beginning of the section in the NEWS file about this new option. 
>
> Aren't you contradicting yourself here?  If people don't read
> documentation, how can any addition to the documentation solve this
> issue?  (Of course, I don't object to saying something in INSTALL
> about that, just pointing out that it's hard to have it both ways.)
>

Eli, rather ironically you just proved my point. I didn't say they
didn't read the documentation, I said they didn't read it carefully.
Just like you did with my post, they skim read it and can easily miss
crucial points. The fact people are building with pgtk when only running
under X would tend to indicate the messaging is not adequate. Making a
clear concise statement not to use pgtk when using X early, even at the
start, would increase the likelihood skim readers see it.

>> It might even be worthwhile adding a warning in configure as well (like
>> the one we have about pop support).
>
> I object to annoying people who build Emacs with such warnings.
> Besides, warnings (as opposed to errors) in the configure script are
> easily overlooked, because people tend to leave the build run
> unattended, and do other useful things while it runs.
>

I guess there not terribly annoying if they are easily overlooked!

Just like the warning about removal of pop support and pointer
to mail utils, this warning could be at the end of the build. At any
rate, seems like a more important warning than one about no longer
supporting pop3, which few mail providers support anymore anyway. 

>> Like others, I expect many distributions are going to bundle
>> emacs-gtk believing it is an improvement. I suspect it is going to
>> be a bigger issue given that some popular distributions, like
>> fedora, will be shipping with wayland as their default but there
>> will likely be many who will choose to switch back to X, but then be
>> faced with an Emacs built with pgtk to better support the default
>> wayland setup.
>
> IME, there's nothing we can do against such misconceptions.  We will
> get bug reports and will respond by pointing people to NEWS and
> INSTALL.  Eventually, enough people will bump into this to realize the
> truth, and the issue will go away.  No catastrophe that I could spot,
> and no need to get too excited.

You do seem to like jumping to extremes. I don't think anyone has been
screaming catastrophe. All I've seen is people asking to make this more
obvious and explicit. Maybe it won't make a big difference, but then
again, maybe it will. The cost of making the limitations of pgtk more
explicit in NEWS and INSTALL is very low and even if it only stops a few
people from doing the wrorng build, reporting a 'non-bug' and getting
directed back to NEW/INSTALL and having to rebuild, I think the cost has
been justified.

Re: PGTK-related misconceptions

[Eli Zaretskii]

> From: Tim Cross <theophilusx@gmail.com>
> Cc: jporterbugs@gmail.com, luangruo@yahoo.com, emacs-devel@gnu.org,
>  spwhitton@spwhitton.name
> Date: Tue, 19 Apr 2022 18:13:03 +1000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I agree. I think this is the main point being missed by others who have
> >> argued the existing documentation is clear enough. Like it or not,
> >> people often don't read the documentation or NEWS file carefully. There
> >> is also a tendency for people to believe any new feature is an
> >> improvement and I suspect many people will think a pure GTK build is
> >> going to be better than a hybrid X/GTK one. 
> >> 
> >> We should just add a very explicit and clear warning not to use
> >> --with-pgtk if your running under X and put this statement right at the
> >> beginning of the section in the NEWS file about this new option. 
> >
> > Aren't you contradicting yourself here?  If people don't read
> > documentation, how can any addition to the documentation solve this
> > issue?  (Of course, I don't object to saying something in INSTALL
> > about that, just pointing out that it's hard to have it both ways.)
> >
> 
> Eli, rather ironically you just proved my point. I didn't say they
> didn't read the documentation, I said they didn't read it carefully.

If there's a significant difference, for the purposes of this
discussion, between "don't read" and "don't read carefully", then I'm
afraid I don't understand what you wanted to say.  Either people will
miss what we say or they won't.  In the latter case, what we already
say is enough; in the former case it doesn't matter what we will say
or add to what we did already, because both INSTALL and NEWS are large
files and contain a lot of stuff.  So I fail to see how the fine point
of "carefully" is relevant here.

> > I object to annoying people who build Emacs with such warnings.
> > Besides, warnings (as opposed to errors) in the configure script are
> > easily overlooked, because people tend to leave the build run
> > unattended, and do other useful things while it runs.
> >
> 
> I guess there not terribly annoying if they are easily overlooked!

They are easily overlooked by one part of the people (usually, those
who don't read the documentation "carefully" enough), and are annoying
to the other part, those who don't overlook the warnings (because they
usually already read the documentation and did TRT).

> Just like the warning about removal of pop support and pointer
> to mail utils, this warning could be at the end of the build.

The warning about pop support and Mailutils is at the end of the
configure script, not the end of the build.  If you build by saying
just "make" (which is the normal way of building Emacs these days),
then you won't see the warning "at the end" because Make runs the
Makefiles immediately after the configure script finishes.

> At any
> rate, seems like a more important warning than one about no longer
> supporting pop3, which few mail providers support anymore anyway. 

That's not what that warning is about, not at all.  I guess you didn't
read it "carefully" enough.

> > IME, there's nothing we can do against such misconceptions.  We will
> > get bug reports and will respond by pointing people to NEWS and
> > INSTALL.  Eventually, enough people will bump into this to realize the
> > truth, and the issue will go away.  No catastrophe that I could spot,
> > and no need to get too excited.
> 
> You do seem to like jumping to extremes. I don't think anyone has been
> screaming catastrophe.

This thread amassed 2 dozen messages already, so I think there are
some who do think it's a big deal.

> All I've seen is people asking to make this more obvious and
> explicit. Maybe it won't make a big difference, but then again,
> maybe it will. The cost of making the limitations of pgtk more
> explicit in NEWS and INSTALL is very low and even if it only stops a
> few people from doing the wrorng build, reporting a 'non-bug' and
> getting directed back to NEW/INSTALL and having to rebuild, I think
> the cost has been justified.

If you read what I wrote, I explicitly said I didn't object to adding
this stuff to INSTALL.  But I don't think it will solve the problem of
people who don't read the documentation "carefully" enough to pay
attention.

Re: PGTK-related misconceptions

[Dirk-Jan C. Binnema]

On Friday Apr 15 2022, Po Lu wrote:

> Morgan Smith <morgan.j.smith@outlook.com> writes:
>
>> I'd like to report that my super key stopped registering.  I suspected
>> commit 1404e16975 caused it so I did a quick `git revert 1404e16975`
>> ontop of 807682de1e and that fixed it.
>
> Crystal ball says you are using X Windows, and have to put
>
>   remove mod4 = Hyper_L
>
> in your ~/.Xmodmap file, because GTK doesn't try as hard as regular X11
> Emacs to work around the common kind of virtual modifier
> misconfiguration.
>
> People using X should _never_ use PGTK.  The regular X build does a much
> better job at supporting that than PGTK ever will.
>
> It is completely pointless to put up with half-working child frames,
> random keyboard-related lossage, random frame placement/resizing
> failures, so the actual fix is to delete `--with-pgtk' from your calls
> to configure.
>
> Similarly, people building packages with PGTK enabled that are labeled
> "enhanced" are doing their users a disservice.  No packager should
> enable PGTK by default, and every package should ideally come with a big
> disclaimer warning against using PGTK on window systems otherwise
> supported by Emacs, since time and experience shows that Emacs generally
> does a much better job at their support than GTK.
>
> Many people are also being mislead by articles on the internet claiming
> that PGTK leads to faster redisplay, such as this one:
> http://www.cesarolea.com/posts/emacs-native-compile
>
> That is not true, since regular Emacs with cairo uses more-or-less the
> same rendering path as PGTK, except when PGTK runs on Wayland, where it
> uses software rendering and does image compositing in software, and is
> thus slower than everything else.  Scrolling on PGTK is also not as
> efficient as XCopyArea requests.
>
> But the difference in speed even on Wayland is negligible, not easy to
> benchmark, and not at all visible to the human eye.

Appreciate the efforts on this, but the outcome seems somewhat
unsatisfactory, if I understand correctly:

- we have the "non-pure" gtk build which supports X (although gtk has a
  wayland backend, non-pure gtk assumes X)
- we have "pure" gtk, which supports X and Wayland, but now it turns
  out there's a bunch of limitations on X.

From the the time before pgtk got merged, I can't remember any wide
discussion of it being wayland-only. Perhaps I misremember.

I regularly use both X and Wayland, and having to have two emacsen (and
remember to use the right one) just for that seems sub-optimal. Wouldn't
it be better to have a single gtk3 backend? For users and developers and
distributors?

But maybe the problems is small, i.e. perhaps pgtk works fine on X, but
doesn't currently implement a handful of things, which we can document?
Then users can decide if they can live with that.

Kind regards,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl                                
gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036

Re: PGTK-related misconceptions

[Po Lu]

"Dirk-Jan C. Binnema" <djcb.bulk@gmail.com> writes:

> Appreciate the efforts on this, but the outcome seems somewhat
> unsatisfactory, if I understand correctly:
>
> - we have the "non-pure" gtk build which supports X (although gtk has a
>   wayland backend, non-pure gtk assumes X)

"Non-pure GTK" uses GTK for widgets, but directly uses X Windows APIs
for input and display, and some other features too.

> - we have "pure" gtk, which supports X and Wayland, but now it turns
>   out there's a bunch of limitations on X.

Yes.

> From the the time before pgtk got merged, I can't remember any wide
> discussion of it being wayland-only. Perhaps I misremember.

I looked over those discussions not too long ago, and it seems that
nobody really used the PGTK build on X Windows.  Those who did
immediately ran into resizing glitches, keyboard input issues, and some
features just not being implemented, such as responding to configure
events.

> I regularly use both X and Wayland, and having to have two emacsen (and
> remember to use the right one) just for that seems sub-optimal. Wouldn't
> it be better to have a single gtk3 backend? For users and developers and
> distributors?

That isn't possible, at least not without a lot of work.

> But maybe the problems is small, i.e. perhaps pgtk works fine on X, but
> doesn't currently implement a handful of things, which we can document?
> Then users can decide if they can live with that.

That list would be very long, would include serious types of
misbehavior, be liable to change at the whim of the GTK developers, so
the truth is that users should simply stay away from PGTK on X.

Re: PGTK-related misconceptions

[Phil Sainty]

On 2022-04-19 21:10, Dirk-Jan C. Binnema wrote:
> I regularly use both X and Wayland, and having to have two emacsen
> (and remember to use the right one) just for that seems sub-optimal.

I believe there's something called "X-Wayland" for running X programs
under Wayland, in case that's the missing piece of the puzzle?

IIUC you can use that to run the same (single) X build of emacs when
you're using Wayland that you use when you're not, which avoids the
problem you've described.


-Phil

Re: PGTK-related misconceptions

[Sean Whitton]

Hello,

On Tue 19 Apr 2022 at 11:53pm +12, Phil Sainty wrote:

> On 2022-04-19 21:10, Dirk-Jan C. Binnema wrote:
>> I regularly use both X and Wayland, and having to have two emacsen
>> (and remember to use the right one) just for that seems sub-optimal.
>
> I believe there's something called "X-Wayland" for running X programs
> under Wayland, in case that's the missing piece of the puzzle?
>
> IIUC you can use that to run the same (single) X build of emacs when
> you're using Wayland that you use when you're not, which avoids the
> problem you've described.

It's a compatibility layer, basically, and not a great one.  I was
having various basic focus and clipboard problems when running Lucid
Emacs under Xwayland.

-- 
Sean Whitton

Re: PGTK-related misconceptions

[Phil Sainty]

On 2022-04-20 01:58, Sean Whitton wrote:
>> On 2022-04-19 21:10, Dirk-Jan C. Binnema wrote:
>>> I regularly use both X and Wayland, and having to have two emacsen
>>> (and remember to use the right one) just for that seems sub-optimal.
>> 
>> I believe there's something called "X-Wayland" for running X programs
>> under Wayland
> 
> It's a compatibility layer, basically, and not a great one.  I was
> having various basic focus and clipboard problems when running Lucid
> Emacs under Xwayland.

Ah, ok.  In that case I guess one really would prefer to install both
builds, if using both Wayland and X at different times.

I imagine one could mostly circumvent the "remember to use the right 
one"
issue by automatically setting PATH based on which system you were using
at that time, so that "emacs" was always going to be the correct emacs.


-Phil

Re: PGTK-related misconceptions

[Stefan Monnier]

> I imagine one could mostly circumvent the "remember to use the right one"
> issue by automatically setting PATH based on which system you were using
> at that time, so that "emacs" was always going to be the correct emacs.

Ideally, it should be possible to build a single Emacs executable that
can simultaneously open frames on a tty, on an X server (some using
GNUstep and others using Lucid), and on a Wayland server.

It would/will require a fair bit of code changes, but AFAIK almost all
of it should be "simple/repetitive": it shouldn't require any
fundamental change.


        Stefan

Re: PGTK-related misconceptions

[Yuri Khan]

On Tue, 19 Apr 2022 at 18:54, Phil Sainty <psainty@orcon.net.nz> wrote:

> I believe there's something called "X-Wayland" for running X programs
> under Wayland, in case that's the missing piece of the puzzle?
>
> IIUC you can use that to run the same (single) X build of emacs when
> you're using Wayland that you use when you're not, which avoids the
> problem you've described.

If you have a HiDPI monitor, an X application on an X server gets full
resolution, a Wayland application on a Wayland compositor gets full
resolution, but an X application via Xwayland on a Wayland compositor
gets rendered at low resolution and then upscaled. It’s a non-starter.

Re: PGTK-related misconceptions

[Pankaj Jangid]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Tue, 19 Apr 2022 at 18:54, Phil Sainty <psainty@orcon.net.nz> wrote:
>
>> I believe there's something called "X-Wayland" for running X programs
>> under Wayland, in case that's the missing piece of the puzzle?
>>
>> IIUC you can use that to run the same (single) X build of emacs when
>> you're using Wayland that you use when you're not, which avoids the
>> problem you've described.
>
> If you have a HiDPI monitor, an X application on an X server gets full
> resolution, a Wayland application on a Wayland compositor gets full
> resolution, but an X application via Xwayland on a Wayland compositor
> gets rendered at low resolution and then upscaled. It’s a non-starter.

Yup. I had a very hard time without-pgtk on a HiDPI monitor. Tried all
sorts of scaling and font-sizing. Nothing worked. I am using
xwayland. Because that is now default in Debian desktop environment
(Gnome). So I started using PGTK build. And for my use-case, I have not
faced any issues till now. It has been two months. Fonts look awesome.

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

[daanturo]

> I'd like to report that my super key stopped registering.  I   
> suspected commit 1404e16975 caused it so I did a quick `git revert   
> 1404e16975` ontop of 807682de1e and that fixed it.
 
Hello,
 
I can't find commit 1404e16975 in Emacs' master tree, but even when having IM disabled via `(setq pgtk-use-im-context-on-new-connection nil)` in init.el, Emacs is unable to recognize any Super-modified keys.
 
It's reproducible in `emacs -q` then `(pgtk-use-im-context nil)`.
 
I'm on Emacs master (8f3e0ed2b99b9b2ad42693cab2b3c0c291e3c3d0).
 
--  
Daanturo.

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

[Morgan Smith]

Hello,

daanturo <daanturo@gmail.com> writes:
> Emacs is unable to recognize any Super-modified keys. 

My bad, I gave the wrong git hash.  I meant this hash: 1c1ae6ba80. 
If you want to re-enable super modified keys you have to make the 
following change.  If I remember correctly Po Lu thinks this is a 
bug in some other software and that the GDK_SUPER_MASK bit should 
be set so they don't want to add the GDK_MOD4_MASK bit. 
Personally, I think GDK_MOD4_MASK should be added and we should 
just add a todo comment to look into it more later.

I suppose the thought is that in theory someone could use MOD4 as 
a custom modifier instead of using it as super but realistically I 
think someone trying to do that would have lots of problems.  It 
would be cool if that was possible though so I do support trying 
to rid ourselves of odd grandfathered in quirks.


diff --git a/src/pgtkterm.c b/src/pgtkterm.c index 
b9d0b7b512..3ef643a075 100644 --- a/src/pgtkterm.c +++ 
b/src/pgtkterm.c @@ -5018,7 +5018,7 @@ pgtk_gtk_to_emacs_modifiers 
(struct pgtk_display_info *dpyinfo, int state) 
     mod |= mod_ctrl; 
   if (state & GDK_META_MASK || state & GDK_MOD1_MASK) 
     mod |= mod_meta; 
-  if (state & GDK_SUPER_MASK) +  if (state & GDK_SUPER_MASK || 
state & GDK_MOD4_MASK) 
     mod |= mod_super; 
   if (state & GDK_HYPER_MASK) 
     mod |= mod_hyper; 
@@ -5151,7 +5151,8 @@ key_press_event (GtkWidget *widget, GdkEvent 
*event, gpointer *user_data) 
       /* While super is pressed, the input method will always 
       always 
 	 resend the key events ignoring super.  As a workaround, don't 
 filter key events with super or hyper pressed.  */ 
-      if (!(event->key.state & (GDK_SUPER_MASK | 
GDK_HYPER_MASK))) +      if (!(event->key.state & + 
(GDK_SUPER_MASK | GDK_MOD4_MASK | GDK_HYPER_MASK))) 
 	{ if (pgtk_im_filter_keypress (f, &event->key)) return TRUE; 

bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Morgan Smith <morgan.j.smith@outlook.com> writes:

> Hello,
>
> daanturo <daanturo@gmail.com> writes:
>> Emacs is unable to recognize any Super-modified keys. 
>
> My bad, I gave the wrong git hash.  I meant this hash: 1c1ae6ba80. If
> you want to re-enable super modified keys you have to make the
> following change.  If I remember correctly Po Lu thinks this is a bug
> in some other software and that the GDK_SUPER_MASK bit should be set
> so they don't want to add the GDK_MOD4_MASK bit. Personally, I think
> GDK_MOD4_MASK should be added and we should just add a todo comment to
> look into it more later.
>
> I suppose the thought is that in theory someone could use MOD4 as a
> custom modifier instead of using it as super but realistically I think
> someone trying to do that would have lots of problems.  It would be
> cool if that was possible though so I do support trying to rid
> ourselves of odd grandfathered in quirks.

No.  It is safe to use Mod4 for something else than Super.  (On X
Windows it is often Hyper, or both at the same time, or else.)

The only modifier that is not safe to change is Mod1, which GTK always
assumes to be alt.

Please let the GTK developers know that the bug is important here:
https://gitlab.gnome.org/GNOME/gtk/-/issues/4913

Otherwise, they will keep ignoring it, as usual.