unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#37007: Problem with the menu-bars in mode "org" and "auctex"
@ 2019-08-11 14:31 Anders Rydvall
  2019-08-12  8:59 ` martin rudalics
  2022-04-30 16:59 ` Lars Ingebrigtsen
  0 siblings, 2 replies; 14+ messages in thread
From: Anders Rydvall @ 2019-08-11 14:31 UTC (permalink / raw)
  To: 37007

Working with a Dell LTS laptop with factory-installed Ubuntu 18.04 LTS

Emacs 26.2 installed with the Ubuntu graphic installer. Auxtex was 
automatically installed according to package list. Emacs identifies the 
.tex file and presents the adequate main menu items. But .. instead of 
the alternatives coming down for "latex" and "command" it comes a black 
bar. I thought this was a problem in auxtex but now I have installed 
"org" and "org-journal" and the same problem comes up.

In org mode. the menu items "tbl" and "text" delivers black bars in the 
same fashion as it was from auctex.

Therefore I presume a bug in Emacs GUI interface.

Regards

Anders Rydvall






^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#37007: Problem with the menu-bars in mode "org" and "auctex"
  2019-08-11 14:31 bug#37007: Problem with the menu-bars in mode "org" and "auctex" Anders Rydvall
@ 2019-08-12  8:59 ` martin rudalics
       [not found]   ` <812b33b4-5a21-302b-9791-a3c00f21c7b7@rydvall.com>
  2022-04-30 16:59 ` Lars Ingebrigtsen
  1 sibling, 1 reply; 14+ messages in thread
From: martin rudalics @ 2019-08-12  8:59 UTC (permalink / raw)
  To: Anders Rydvall, 37007

 > Emacs 26.2 installed with the Ubuntu graphic installer. Auxtex was
 > automatically installed according to package list. Emacs identifies
 > the .tex file and presents the adequate main menu items. But
 > .. instead of the alternatives coming down for "latex" and "command"
 > it comes a black bar. I thought this was a problem in auxtex but now
 > I have installed "org" and "org-journal" and the same problem comes
 > up.

Does the problem also happen when you maximize the Emacs frame before
opening a .tex file?

martin





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#37007: Problem with the menu-bars in mode "org" and "auctex"
       [not found]       ` <b77b67a5-6ee6-1762-ee15-5ea5510353b4@rydvall.com>
@ 2019-08-14  9:19         ` martin rudalics
  2019-08-14 11:34           ` Anders Rydvall
  0 siblings, 1 reply; 14+ messages in thread
From: martin rudalics @ 2019-08-14  9:19 UTC (permalink / raw)
  To: Anders Rydvall; +Cc: 37007

 > In dired "operate, "Mark", "regexp", "immediate", "subdir" give the
 > same black bar and absent submenus. The other submenus come down as
 > expected.

The "Help" menu as well?

 > GTK seems to be 3.22.30. Attached is a print-screen from synaptic package manager.

To make sure: What does clicking on About Emacs in the Help menu tell
about the version used for building Emacs?

 > Thanks for engaging in the problem. Have you been able to reproduce it?

No.  But I'm with GTK 3.22.11 which suffers from what is cited in
etc/PROBLEMS as

*** Emacs built with GTK+ toolkit can unexpectedly widen frames

Maybe GTK changed their behavior that instead of auto-widening the
window they now black out the menus.  When you start Emacs from the
console or a text terminal do you see something like the

Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed

mentioned in that entry?

Also, please keep <37007@debbugs.gnu.org> in the list of recipients so
that others see your answers as well (using Reply To All in your MUA
should suffice).

Thanks, martin





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#37007: Problem with the menu-bars in mode "org" and "auctex"
  2019-08-14  9:19         ` martin rudalics
@ 2019-08-14 11:34           ` Anders Rydvall
  2019-08-15  8:12             ` martin rudalics
  0 siblings, 1 reply; 14+ messages in thread
From: Anders Rydvall @ 2019-08-14 11:34 UTC (permalink / raw)
  To: martin rudalics; +Cc: 37007

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

Martin!

The "Help" menu is OK in all modi.

GTK version is 3.22.30(about-emacs.png)

There is no message in the console when starting emacs from terminal and 
no difference in behavior.

Today I noted very odd behavior. Suddenly i got all the menus in 
org-mode(org-mode.png). When opening a .tex file there was opened most 
of the menus but "command" is obviously inherited from 
org-mode(latex1.png)! and "math"and "ref" were still absent(latex2.png). 
I hope this will give a clue to the solution!

Den 2019-08-14 kl. 11:19, skrev martin rudalics:
> > In dired "operate, "Mark", "regexp", "immediate", "subdir" give the
> > same black bar and absent submenus. The other submenus come down as
> > expected.
>
> The "Help" menu as well?
>
> > GTK seems to be 3.22.30. Attached is a print-screen from synaptic 
> package manager.
>
> To make sure: What does clicking on About Emacs in the Help menu tell
> about the version used for building Emacs?
>
> > Thanks for engaging in the problem. Have you been able to reproduce it?
>
> No.  But I'm with GTK 3.22.11 which suffers from what is cited in
> etc/PROBLEMS as
>
> *** Emacs built with GTK+ toolkit can unexpectedly widen frames
>
> Maybe GTK changed their behavior that instead of auto-widening the
> window they now black out the menus.  When you start Emacs from the
> console or a text terminal do you see something like the
>
> Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 
> 'extra_space >= 0' failed
>
> mentioned in that entry?
>
> Also, please keep <37007@debbugs.gnu.org> in the list of recipients so
> that others see your answers as well (using Reply To All in your MUA
> should suffice).
>
> Thanks, martin

[-- Attachment #2: about-emacs.png --]
[-- Type: image/png, Size: 340898 bytes --]

[-- Attachment #3: latex1.png --]
[-- Type: image/png, Size: 196304 bytes --]

[-- Attachment #4: latex2.png --]
[-- Type: image/png, Size: 180748 bytes --]

[-- Attachment #5: org-mode.png --]
[-- Type: image/png, Size: 189679 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#37007: Problem with the menu-bars in mode "org" and "auctex"
  2019-08-14 11:34           ` Anders Rydvall
@ 2019-08-15  8:12             ` martin rudalics
       [not found]               ` <f9604ae8-d702-db7d-ea80-321cb6e6c681@rydvall.com>
  0 siblings, 1 reply; 14+ messages in thread
From: martin rudalics @ 2019-08-15  8:12 UTC (permalink / raw)
  To: Anders Rydvall; +Cc: 37007

 > Today I noted very odd behavior. Suddenly i got all the menus in
 > org-mode(org-mode.png).

Can you trigger both behaviors (the one with and the one without the
bug) using org-mode alone?  So far we can rule out only that length or
number of menu bar entries matter much.

 > When opening a .tex file there was opened most of the menus but
 > "command" is obviously inherited from org-mode(latex1.png)! and
 > "math"and "ref" were still absent(latex2.png). I hope this will give
 > a clue to the solution!

Hardly.  I don't have Auctex installed but I doubt that math and ref
would contain any special entries your toolkit can't display (in
particular without any warning).  You could try to play with the font
or size of menu text if you find a knob to do that on your system.

martin





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#37007: Problem with the menu-bars in mode "org" and "auctex"
       [not found]               ` <f9604ae8-d702-db7d-ea80-321cb6e6c681@rydvall.com>
@ 2019-08-17  8:24                 ` martin rudalics
  2019-08-19 11:38                   ` Anders Rydvall
  0 siblings, 1 reply; 14+ messages in thread
From: martin rudalics @ 2019-08-17  8:24 UTC (permalink / raw)
  To: Anders Rydvall; +Cc: 37007

 > It seems to be by random(I am maybe not enough systematic). At one
 > occasion all menus came up correctly in
 > latexmode((latexOK.png). Next try came with obviously corrupted
 > command-menu(latex_wrongCommand.png). I get those by dragging the
 > mouse from "tools" upwards and then down to "preview". But not every
 > time.

I suppose you mean just "moving" the mouse, here we use "dragging" for
moving the mouse with one of its buttons pressed.  Are "tools" and
"peview" submenus of the latex menu?

 > Today I cant get the correct menues for org-mode
 > directly(0rg1.org2,org3) but, at one occasion, skifting from
 > latexmode after I got the menus there the menues come also in
 > org-mode though not the correct "text"(org4.png).

Are all wrong entries somewhat related to latex?  From the text above
it sounds so.  But since you earlier said that 'dired' had similar
problems ...

I would try to isolate the problematic modes first, if there are any.
For example, if you start Emacs with -Q and invoke 'dired', can you
produce the problem?

 > Downgrading Emacs?? In that case to what version? Is it in that case
 > necessary also to downgrade GTK??

It depends.  If the problem is in the GTK version, it might help to
downgrade GTK only (not really advisable if other applications depend
on a GTK library).  In either case, downgrading anything should be the
last option to try.

martin





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#37007: Problem with the menu-bars in mode "org" and "auctex"
  2019-08-17  8:24                 ` martin rudalics
@ 2019-08-19 11:38                   ` Anders Rydvall
  2019-08-21  7:37                     ` martin rudalics
  0 siblings, 1 reply; 14+ messages in thread
From: Anders Rydvall @ 2019-08-19 11:38 UTC (permalink / raw)
  To: martin rudalics; +Cc: 37007

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

Martin!

Yes, I meant "dragging" the mouse.

Wrong entries are not only associated with latex mode. Here example on 
calender:holiday going into org-mode(cal_hol.png; org_hol.png). 
Corruption of menu from other mode.

When starting emacs -Q I cant see any different behavior. Invoking dired 
with C-x d or M-x dired give the same result - incomplete menues as 
shown in dired1. However "dragging" the mouse opens the menues shown in 
dired2.

Den 2019-08-17 kl. 10:24, skrev martin rudalics:
> > It seems to be by random(I am maybe not enough systematic). At one
> > occasion all menus came up correctly in
> > latexmode((latexOK.png). Next try came with obviously corrupted
> > command-menu(latex_wrongCommand.png). I get those by dragging the
> > mouse from "tools" upwards and then down to "preview". But not every
> > time.
>
> I suppose you mean just "moving" the mouse, here we use "dragging" for
> moving the mouse with one of its buttons pressed.  Are "tools" and
> "peview" submenus of the latex menu?
>
> > Today I cant get the correct menues for org-mode
> > directly(0rg1.org2,org3) but, at one occasion, skifting from
> > latexmode after I got the menus there the menues come also in
> > org-mode though not the correct "text"(org4.png).
>
> Are all wrong entries somewhat related to latex?  From the text above
> it sounds so.  But since you earlier said that 'dired' had similar
> problems ...
>
> I would try to isolate the problematic modes first, if there are any.
> For example, if you start Emacs with -Q and invoke 'dired', can you
> produce the problem?
>
> > Downgrading Emacs?? In that case to what version? Is it in that case
> > necessary also to downgrade GTK??
>
> It depends.  If the problem is in the GTK version, it might help to
> downgrade GTK only (not really advisable if other applications depend
> on a GTK library).  In either case, downgrading anything should be the
> last option to try.
>
> martin

[-- Attachment #2: cal_hol.png --]
[-- Type: image/png, Size: 235588 bytes --]

[-- Attachment #3: dired1.png --]
[-- Type: image/png, Size: 289822 bytes --]

[-- Attachment #4: dired2.png --]
[-- Type: image/png, Size: 290091 bytes --]

[-- Attachment #5: org_hol.png --]
[-- Type: image/png, Size: 221497 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#37007: Problem with the menu-bars in mode "org" and "auctex"
  2019-08-19 11:38                   ` Anders Rydvall
@ 2019-08-21  7:37                     ` martin rudalics
  2019-08-21 11:08                       ` Anders Rydvall
  0 siblings, 1 reply; 14+ messages in thread
From: martin rudalics @ 2019-08-21  7:37 UTC (permalink / raw)
  To: Anders Rydvall; +Cc: 37007

 > Yes, I meant "dragging" the mouse.

Why on earth would you "drag" the mouse in order to pick a menu entry?
I'm not aware of any menu entries that change their semantics when
dragging an object on them.  What happens when you hit <f10> and use the
keyboard to select a menu item?

 > When starting emacs -Q I cant see any different behavior. Invoking
 > dired with C-x d or M-x dired give the same result - incomplete
 > menues as shown in dired1. However "dragging" the mouse opens the
 > menues shown in dired2.

Maybe you should indeed try to downgrade Emacs to see if the problem
is related to the current version.  Provided you can do that ...

martin





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#37007: Problem with the menu-bars in mode "org" and "auctex"
  2019-08-21  7:37                     ` martin rudalics
@ 2019-08-21 11:08                       ` Anders Rydvall
  2019-08-22  8:07                         ` martin rudalics
  0 siblings, 1 reply; 14+ messages in thread
From: Anders Rydvall @ 2019-08-21 11:08 UTC (permalink / raw)
  To: martin rudalics; +Cc: 37007

Martin!

Dragging the mouse was one, of different, ways to test. Of course I 
normally don't drag the mouse.

Hitting F10 invokes the correct and complete menus in the different 
modes. Moreover a new mode does not any longer seem to inherit menus 
from the previous used buffer. When shifting between buffers it is 
necessary to hit F10 again to get complete menus.

The F10 command seems to correctly load the menus which does not happen 
only by shifting into a certain buffer. Thus there must be some problem 
with the invocation of the menus. However I'm, for the moment, more 
happy. I can use Emacs. Hopefully the problem will be solved in a future 
version.

Regards

Anders



Den 2019-08-21 kl. 09:37, skrev martin rudalics:
> > Yes, I meant "dragging" the mouse.
>
> Why on earth would you "drag" the mouse in order to pick a menu entry?
> I'm not aware of any menu entries that change their semantics when
> dragging an object on them.  What happens when you hit <f10> and use the
> keyboard to select a menu item?
>
> > When starting emacs -Q I cant see any different behavior. Invoking
> > dired with C-x d or M-x dired give the same result - incomplete
> > menues as shown in dired1. However "dragging" the mouse opens the
> > menues shown in dired2.
>
> Maybe you should indeed try to downgrade Emacs to see if the problem
> is related to the current version.  Provided you can do that ...
>
> martin





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#37007: Problem with the menu-bars in mode "org" and "auctex"
  2019-08-21 11:08                       ` Anders Rydvall
@ 2019-08-22  8:07                         ` martin rudalics
  2019-08-22 12:00                           ` Anders Rydvall
  0 siblings, 1 reply; 14+ messages in thread
From: martin rudalics @ 2019-08-22  8:07 UTC (permalink / raw)
  To: Anders Rydvall; +Cc: 37007

 > Dragging the mouse was one, of different, ways to test. Of course I
 > normally don't drag the mouse.

OK.  Just that here, when dragging the mouse, no menu pops up since
Emacs handles the mouse tracking itself and ignores the menu bar
during that.

 > Hitting F10 invokes the correct and complete menus in the different
 > modes. Moreover a new mode does not any longer seem to inherit menus
 > from the previous used buffer. When shifting between buffers it is
 > necessary to hit F10 again to get complete menus.

So we have two different issues: One is that the items shown on the
menu bar do not correspond to the items one should see wrt the
selected window's buffer.  The other is that popping up a specific
menu shows blacked-out entries.  I wonder whether the second issue is
a consequence of the former.  If so, some error should have been
reported.  Are you sure nothing the like shows up in *Messages*?

 > The F10 command seems to correctly load the menus which does not
 > happen only by shifting into a certain buffer. Thus there must be
 > some problem with the invocation of the menus.

What could F10 possibly do the mouse doesn't?  I'm lost.

martin





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#37007: Problem with the menu-bars in mode "org" and "auctex"
  2019-08-22  8:07                         ` martin rudalics
@ 2019-08-22 12:00                           ` Anders Rydvall
  2019-08-23  7:45                             ` martin rudalics
  0 siblings, 1 reply; 14+ messages in thread
From: Anders Rydvall @ 2019-08-22 12:00 UTC (permalink / raw)
  To: martin rudalics; +Cc: 37007

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

Martin!

"messages" doesn't capture anything related to the menus as far as I can 
see. Attached screenshot is after shifting between buffers several times 
and invoking menus with F10. And different buffers have opened with 
corrupted menu items and the black bars which at every occasion is 
corrected with F10. Apparently F10 does something different to the menus 
than the mouse.

regards

Anders

Den 2019-08-22 kl. 10:07, skrev martin rudalics:
> > Dragging the mouse was one, of different, ways to test. Of course I
> > normally don't drag the mouse.
>
> OK.  Just that here, when dragging the mouse, no menu pops up since
> Emacs handles the mouse tracking itself and ignores the menu bar
> during that.
>
> > Hitting F10 invokes the correct and complete menus in the different
> > modes. Moreover a new mode does not any longer seem to inherit menus
> > from the previous used buffer. When shifting between buffers it is
> > necessary to hit F10 again to get complete menus.
>
> So we have two different issues: One is that the items shown on the
> menu bar do not correspond to the items one should see wrt the
> selected window's buffer.  The other is that popping up a specific
> menu shows blacked-out entries.  I wonder whether the second issue is
> a consequence of the former.  If so, some error should have been
> reported.  Are you sure nothing the like shows up in *Messages*?
>
> > The F10 command seems to correctly load the menus which does not
> > happen only by shifting into a certain buffer. Thus there must be
> > some problem with the invocation of the menus.
>
> What could F10 possibly do the mouse doesn't?  I'm lost.
>
> martin

[-- Attachment #2: messages190822.png --]
[-- Type: image/png, Size: 426345 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#37007: Problem with the menu-bars in mode "org" and "auctex"
  2019-08-22 12:00                           ` Anders Rydvall
@ 2019-08-23  7:45                             ` martin rudalics
  0 siblings, 0 replies; 14+ messages in thread
From: martin rudalics @ 2019-08-23  7:45 UTC (permalink / raw)
  To: Anders Rydvall; +Cc: 37007

 > "messages" doesn't capture anything related to the menus as far as I
 > can see. Attached screenshot is after shifting between buffers
 > several times and invoking menus with F10. And different buffers
 > have opened with corrupted menu items and the black bars which at
 > every occasion is corrected with F10. Apparently F10 does something
 > different to the menus than the mouse.

It should mean that we do not update the menu bar at some decisive
moments.  Try evaluating the following noisy form with emacs -Q.

(add-hook 'menu-bar-update-hook (lambda () (ding) (message "%s..%s" (current-buffer) major-mode)))

Here I hear a "ding" and see a message whenever I split a window or
show another buffer in some window.  And I hear the ding when hitting
F10 or clicking on a menu bar item with the mouse.  Do you see any
"anomalies" when doing that?  I mean, does the message intuitively
show the "right" current buffer and its major mode when you randomly
execute some of the actions above?

Sorry, I have no better idea than applying such silly heuristics.

Thanks, martin





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#37007: Problem with the menu-bars in mode "org" and "auctex"
  2019-08-11 14:31 bug#37007: Problem with the menu-bars in mode "org" and "auctex" Anders Rydvall
  2019-08-12  8:59 ` martin rudalics
@ 2022-04-30 16:59 ` Lars Ingebrigtsen
  2022-05-29 13:19   ` Lars Ingebrigtsen
  1 sibling, 1 reply; 14+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-30 16:59 UTC (permalink / raw)
  To: Anders Rydvall; +Cc: 37007

Anders Rydvall <anders@rydvall.com> writes:

> Emacs 26.2 installed with the Ubuntu graphic installer. Auxtex was
> automatically installed according to package list. Emacs identifies
> the .tex file and presents the adequate main menu items. But
> .. instead of the alternatives coming down for "latex" and "command"
> it comes a black bar. I thought this was a problem in auxtex but now I
> have installed "org" and "org-journal" and the same problem comes up.
>
> In org mode. the menu items "tbl" and "text" delivers black bars in
> the same fashion as it was from auctex.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Do you see this issue in newer Emacs versions?

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#37007: Problem with the menu-bars in mode "org" and "auctex"
  2022-04-30 16:59 ` Lars Ingebrigtsen
@ 2022-05-29 13:19   ` Lars Ingebrigtsen
  0 siblings, 0 replies; 14+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-29 13:19 UTC (permalink / raw)
  To: Anders Rydvall; +Cc: 37007

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Do you see this issue in newer Emacs versions?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2022-05-29 13:19 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-11 14:31 bug#37007: Problem with the menu-bars in mode "org" and "auctex" Anders Rydvall
2019-08-12  8:59 ` martin rudalics
     [not found]   ` <812b33b4-5a21-302b-9791-a3c00f21c7b7@rydvall.com>
     [not found]     ` <6667a28d-c2f4-0476-62ba-9fda510bf32b@gmx.at>
     [not found]       ` <b77b67a5-6ee6-1762-ee15-5ea5510353b4@rydvall.com>
2019-08-14  9:19         ` martin rudalics
2019-08-14 11:34           ` Anders Rydvall
2019-08-15  8:12             ` martin rudalics
     [not found]               ` <f9604ae8-d702-db7d-ea80-321cb6e6c681@rydvall.com>
2019-08-17  8:24                 ` martin rudalics
2019-08-19 11:38                   ` Anders Rydvall
2019-08-21  7:37                     ` martin rudalics
2019-08-21 11:08                       ` Anders Rydvall
2019-08-22  8:07                         ` martin rudalics
2019-08-22 12:00                           ` Anders Rydvall
2019-08-23  7:45                             ` martin rudalics
2022-04-30 16:59 ` Lars Ingebrigtsen
2022-05-29 13:19   ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).