bug#23672: 25.0.94; unitialized package specific menus

bug#23672: 25.0.94; unitialized package specific menus

[Tino Calancha]

The menus especific to one package, e.g. dired, are not
always fully initialized after loading the library:
some menus may show _anything_ after click on them.


emacs -Q
C-x C-f RET
;;; click mouse left button on Menu "Regexp"
;;  The menu doesn't appear correctly.
;;  Same happen with menus: "Mark", "Immediate" or "Subdir"
::  Menu "Operate" shows the wrong information.
;;
;;; Now click mouse left button on Menu "Tools".
;;  The previous menus are refreshed and show the correct information.


;;; Now try similar test but starting Emacs with:
emacs -Q ~
C-x C-f RET
;;; This time, all menus are initialized and show the right info.

;;; This is a general issue not something restricted to dired.
;; For instance, compare the response of menu "Mark" in I), II) and III):

I)
./emacs -Q
M-x ibuffer RET
;; "View" and "Mark" don't respond as expected; "Operate" looks wrong too.

II) ./emacs -Q --eval "(require 'ibuffer)"
M-x ibuffer RET
;; Same as I)

III) ./emacs -Q --eval '(ibuffer)'
;; All menus looks good.



In GNU Emacs 25.0.94.2 (x86_64-pc-linux-gnu, GTK+ Version 3.20.4)
Repository revision: 9c28e70b4b4b1887030e41103b5f6dd8304585e6

bug#23672: (25.0.94; Menu corrupted after being used

[Tino Calancha]

A menu initialized correctly may become corrupted after
being used:

emacs -Q ~
;;; Click left mouse on menu "Regexp"
;; choose mark %g and match something, for instance
tmp RET
;;; Click again on menu "Regexp"
;; Now menu "Regexp" menu is corrupted!


In GNU Emacs 25.0.94.2 (x86_64-pc-linux-gnu, GTK+ Version 3.20.4)
  of 2016-06-01 built on calancha-pc
Repository revision: 9c28e70b4b4b1887030e41103b5f6dd8304585e6
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description:	Debian GNU/Linux testing (stretch)

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

bug#23672: (25.0.94; Menu corrupted after being used

[Glenn Morris]

I can't reproduce these problems (this is a case where a screenshot
might be helpful). I would guess that this is due to Gtk 3.20, which
seems to cause various issues. I think this is something that it is
important to try and address before 25.1.

Tino Calancha wrote:

> In GNU Emacs 25.0.94.2 (x86_64-pc-linux-gnu, GTK+ Version 3.20.4)
>  of 2016-06-01 built on calancha-pc

bug#23672: (25.0.94; Menu corrupted after being used

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 01 Jun 2016 13:40:17 -0400
> Cc: 23672@debbugs.gnu.org
> 
> I can't reproduce these problems

Neither can I.

bug#23672: 25.0.94; unitialized package specific menus

[Paul Eggert]

I am not observing the problem on Fedora 23 x86-64. My Emacs 
configuration (see below) is similar to yours, except that Fedora 23 
uses GTK+ 3.18.9 rather than your GTK+ 3.20.4. Also, I am not running 
under Wayland and I am using the Gnome desktop manager; this may be 
relevant.

Do you observe a similar problem with Emacs 24.5 when built in your GTK+ 
3.20.4 environment?

Is the problem related to which theme you select?

In GNU Emacs 25.0.94.7 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
  of 2016-06-01 built on penguin.cs.ucla.edu
Repository revision: 9c28e70b4b4b1887030e41103b5f6dd8304585e6
Windowing system distributor 'Fedora Project', version 11.0.11803000
Configured using:
  'configure --enable-gcc-warnings'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

bug#23672: 25.0.94; unitialized package specific menus

[Tino Calancha]

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



On Wed, 1 Jun 2016, Paul Eggert wrote:

> Do you observe a similar problem with Emacs 24.5 when built in your GTK+ 
> 3.20.4 environment?
Yes i do.
I also observe same issue with older gtk+ version (see [+++] below).

> Is the problem related to which theme you select?
I keep the default theme.


[+++]
++ I have built emacs-24.5 on Debian 8.4 (which ships gtk+ 3.14)
    under several desktop environments.

++ I observe the problem with: gnome and cinnamon.
    (See the attached snapshots)

++ I tried following settings:

    * emacs-24.5
    * Debian 8.4 (jessie, latest stable)
    * gtk+: 3.14.5
    * desktop:
      I) kde: OK
      II) xfce: OK
      III) mate: OK
      IV) gnome: BAD
      V) cinnamon: BAD



In GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.5)
  of 2016-06-02 on debian
Windowing system distributor `The X.Org Foundation', version 11.0.11604000
System Description:	Debian GNU/Linux 8.4 (jessie)

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

Major mode: Dired by name

Minor modes in effect:
   tooltip-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
   buffer-read-only: t
   line-number-mode: t
   transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Marking matching files...
0 matching files marked.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils dired time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 78189 4233)
  (symbols 48 17877 0)
  (miscs 40 43 138)
  (strings 32 10320 4126)
  (string-bytes 1 283717)
  (vectors 16 9282)
  (vector-slots 8 386790 15166)
  (floats 8 63 93)
  (intervals 56 279 19)
  (buffers 960 12)
  (heap 1024 52102 971))

[-- Attachment #2: Type: image/png, Size: 364725 bytes --]

[-- Attachment #3: Type: image/png, Size: 123897 bytes --]

[-- Attachment #4: Type: image/png, Size: 192675 bytes --]

[-- Attachment #5: Type: image/png, Size: 67581 bytes --]

[-- Attachment #6: Type: image/png, Size: 340549 bytes --]

bug#23672: 25.0.94; unitialized package specific menus

[Paul Eggert]

>> Do you observe a similar problem with Emacs 24.5 when built in your GTK+
>> 3.20.4 environment?
> Yes i do.

OK, so this is not a regression in Emacs then. So it's not clear that this bug 
should block the emacs-25 release.


> [+++]
> ++ I have built emacs-24.5 on Debian 8.4 (which ships gtk+ 3.14)
>     under several desktop environments.
>
> ++ I observe the problem with: gnome and cinnamon.
>     (See the attached snapshots)

Ah, so the bug is not introduced by GTK+ 3.20 either.

We need someone versed in GTK+ (i.e., not me) to debug this sort of thing. If we 
can't find anybody, perhaps we should consider dropping GTK+ support in Emacs, 
or at least not making GTK+ the default.

bug#23672: 25.0.94; unitialized package specific menus

[Glenn Morris]

Tino Calancha wrote:

> ++ I have built emacs-24.5 on Debian 8.4 (which ships gtk+ 3.14)
>    under several desktop environments.
>
> ++ I observe the problem with: gnome and cinnamon.
>    (See the attached snapshots)
>
> ++ I tried following settings:
>
>    * emacs-24.5
>    * Debian 8.4 (jessie, latest stable)
>    * gtk+: 3.14.5
>    * desktop:
>      I) kde: OK
>      II) xfce: OK
>      III) mate: OK
>      IV) gnome: BAD
>      V) cinnamon: BAD

It seems weird that:

i) this varies between desktop environments (why would that be?)
ii) no-one has seen this before now

Does it also happen with the "emacs" package shipped by Debian, or only
with one you compile yourself?

bug#23672: 25.0.94; unitialized package specific menus

[Tino Calancha]

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



On Mon, 6 Jun 2016, Glenn Morris wrote:

> Does it also happen with the "emacs" package shipped by Debian, or only
> with one you compile yourself?

Yes, it does.
Debian ships Emacs version 24.4.1: I observe the same problem (***).

To reproduce the issue, please try as follows:

I) Boot a live image of debian 8.4.0 with desktop gnome or cinnamon;
    for example, i use:

ISO: debian-live-8.4.0-amd64-gnome-desktop.iso
MD5SUM: 2e9cb6b2deb717d4c9d8a1d252e8677d

II) Install precompiled emacs24:

     sudo su
     apt-get update && apt-get install emacs -y

III) Start emacs session; call ibuffer and check one of the menus:
Operate, View or Mark:

      emacs -Q
      M-x ibuffer RET
      ;; left mouse button on 'Operate' menu


(***) I have also look on ubuntu-16.04: This is OK.

[-- Attachment #2: Type: image/png, Size: 182416 bytes --]

[-- Attachment #3: Type: image/png, Size: 94657 bytes --]

bug#23672: 25.0.94; unitialized package specific menus

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 1 Jun 2016 15:02:40 -0700
> Cc: 23672@debbugs.gnu.org
> 
> I am not observing the problem on Fedora 23 x86-64.

And I'm not observing it on Windows.

bug#23672: 25.0.94; unitialized package specific menus

[Tino Calancha]

Tino Calancha <f92capac@gmail.com> writes:

> The menus especific to one package, e.g. dired, are not
> always fully initialized after loading the library:
> some menus may show _anything_ after click on them.
>
>
> emacs -Q
> C-x C-f RET
> ;;; click mouse left button on Menu "Regexp"
> ;;  The menu doesn't appear correctly.
> ;;  Same happen with menus: "Mark", "Immediate" or "Subdir"
> ::  Menu "Operate" shows the wrong information.
> ;;
> ;;; Now click mouse left button on Menu "Tools".
> ;;  The previous menus are refreshed and show the correct information.

I found one recipe to reproduce the issue:
*  `M-x' just followed by `C-g'.

See the video:
https://www.dropbox.com/s/5gcbi5fc3xmqpow/emacs_bug23672.mkv?dl=0

;; the version of emacs-24 showed in the video:
In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2017-09-12 on hullmann, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11902000
System Description:	Debian GNU/Linux 9.4 (stretch)

;; the version of master branch showed in the video:
In GNU Emacs 27.0.50 (build 13, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2018-07-10 built on calancha-pc.dy.bbexcite.jp
Repository revision: cc74539a19229ee7e70055b00e8334bd6abc0841
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
System Description: Debian GNU/Linux 9 (stretch)

bug#23672: 25.0.94; unitialized package specific menus

[Eli Zaretskii]

> From: Tino Calancha <tino.calancha@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, rgm@gnu.org, Paul Eggert <eggert@cs.ucla.edu>, tino.calancha@gmail.com
> Date: Mon, 16 Jul 2018 11:48:16 +0900
> 
> Tino Calancha <f92capac@gmail.com> writes:
> 
> > The menus especific to one package, e.g. dired, are not
> > always fully initialized after loading the library:
> > some menus may show _anything_ after click on them.
> >
> >
> > emacs -Q
> > C-x C-f RET
> > ;;; click mouse left button on Menu "Regexp"
> > ;;  The menu doesn't appear correctly.
> > ;;  Same happen with menus: "Mark", "Immediate" or "Subdir"
> > ::  Menu "Operate" shows the wrong information.
> > ;;
> > ;;; Now click mouse left button on Menu "Tools".
> > ;;  The previous menus are refreshed and show the correct information.
> 
> I found one recipe to reproduce the issue:
> *  `M-x' just followed by `C-g'.

And after C-g, do you type "C-x C-f RET" and click "Regexp" on the
menu bar?  Or do you do something else?

> See the video:
> https://www.dropbox.com/s/5gcbi5fc3xmqpow/emacs_bug23672.mkv?dl=0

Sorry, I cannot view MKV files here, so can you either upload a more
widespread format or describe in more details what is going on?

I also wonder whether this is GTK-specific.  Could you try reproducing
this in "emacs -Q -nw"?  If your Emacs is built without GPM support,
you should try F10 instead of a mouse click.

Thanks.

bug#23672: 25.0.94; unitialized package specific menus

[Tino Calancha]

On Fri, 20 Jul 2018, Eli Zaretskii wrote:

> And after C-g, do you type "C-x C-f RET" and click "Regexp" on the
> menu bar?  Or do you do something else?
No, that's old instructions.  I just:
1.  visit a Dired buffer
2. M-x
3. C-g
4. Click 'Regexp' menu ; nothing show up

> Sorry, I cannot view MKV files here, so can you either upload a more
> widespread format or describe in more details what is going on?
I converted to mp4:
The MPAA has rated as G.  Enjoy the movie (don't forget your popcorn!):
https://www.dropbox.com/s/ot66n0hxs9msbrx/emacs_bug23672.mp4?dl=0


> I also wonder whether this is GTK-specific.  Could you try reproducing
> this in "emacs -Q -nw"?  If your Emacs is built without GPM support,
> you should try F10 instead of a mouse click.
Yeah, it seems GTK-specific; following your suggestion I cannot reproduce 
the issue.