Tomasz Gajewski writes:
> David Engster <deng@...> writes:
>> Nikita, I owe you an apology. I'm sorry for being rude. I will
>> investigate why this happens. And thank you Thomas for correcting me.
>
> I haven't seen this either but it was so similar to main menu I
> remember from time when I had this visible on screen all the time that
> made me to investigate it a little. :-)
The really awkward thing is that I work with a disabled menu-bar, so I
must at least have enabled that global-menu from time to time, simply by
accident, but somehow it didn't stick...
Anyway, I've just pushed a workaround which should hopefully fix
this. I'm pretty sure this can be considered a bug in Emacs, since both
menus should behave the same. I could reproduce it with Emacs proper as
well as CEDET trunk, but not always. I guess it's a race condition:
sometimes the global menu shows the enabled Development item from EDE,
and sometimes the disabled one from Semantic.
I'll report this eventually if no one beats me to it. The tedious thing
is to come up with a nice isolated test case which is less convoluted
than the CEDET Development menu.
-David

David Engster <deng@...> writes:
> Tomasz Gajewski writes:
>> David Engster <deng@...> writes:
>>
>>> Nikita, since you apparently do not believe me, there's no sense in
>>> discussing this further. Go ahead and file an Emacs bug report (M-x
>>> report-emacs-bug).
>>
>> David, I think this time you haven't read thoroughly enough what Nikita
>> wrote.
>>
>> He wrote that "global menu" from his screenshots doesn't have anything
>> common with Unity global menu.
>>
>> I can confirm that I can see open popup menu with "Global menu" caption
>> even on windows. You have to run emacs with 'Emacs*menuBar:off' x
>> property and/or with menu-bar-mode nil (I have both) and open menu with
>> Control mouse 2/3 (normal popup menu click).
>
> I've been using Emacs for 20 years, and have never seen this
> before. Consider me flabbergasted.
>
> Nikita, I owe you an apology. I'm sorry for being rude. I will
> investigate why this happens. And thank you Thomas for correcting me.
I haven't seen this either but it was so similar to main menu I
remember from time when I had this visible on screen all the time that
made me to investigate it a little. :-)
Regards
Tomasz Gajewski

Tomasz Gajewski writes:
> David Engster <deng@...> writes:
>
>> Nikita, since you apparently do not believe me, there's no sense in
>> discussing this further. Go ahead and file an Emacs bug report (M-x
>> report-emacs-bug).
>
> David, I think this time you haven't read thoroughly enough what Nikita
> wrote.
>
> He wrote that "global menu" from his screenshots doesn't have anything
> common with Unity global menu.
>
> I can confirm that I can see open popup menu with "Global menu" caption
> even on windows. You have to run emacs with 'Emacs*menuBar:off' x
> property and/or with menu-bar-mode nil (I have both) and open menu with
> Control mouse 2/3 (normal popup menu click).
I've been using Emacs for 20 years, and have never seen this
before. Consider me flabbergasted.
Nikita, I owe you an apology. I'm sorry for being rude. I will
investigate why this happens. And thank you Thomas for correcting me.
-David

David Engster <deng@...> writes:
> Nikita, since you apparently do not believe me, there's no sense in
> discussing this further. Go ahead and file an Emacs bug report (M-x
> report-emacs-bug).
David, I think this time you haven't read thoroughly enough what Nikita
wrote.
He wrote that "global menu" from his screenshots doesn't have anything
common with Unity global menu.
I can confirm that I can see open popup menu with "Global menu" caption
even on windows. You have to run emacs with 'Emacs*menuBar:off' x
property and/or with menu-bar-mode nil (I have both) and open menu with
Control mouse 2/3 (normal popup menu click).
I can also observe that 'Development' menu is disabled if ede is enabled
and is available if I disable global ede mode from tools menu exactly
like Nikita described it. And the issue exists with menu open with F10:
Possible completions are:
f==>File e==>Edit o==>Options b==>Buffers
t==>Tools c==>C++ ---Development h==>Help
I hope this will allow you to reproduce this problem.
Regards
Tomasz Gajewski
BTW.
I'm using GNU Emacs 24.1.1 from ubuntu and cedet from bzr about month
ago.
cedet-version gives:
CEDET Version: 2.0
Requested File Loaded
Package Version Version Version
----------------------------------------------------------
cedet: 2.0 ok ok
eieio: 1.4 ok ok
semantic: 2.2 ok ok
srecode: 1.2 ok ok
ede: 1.2 ok ok
speedbar: 1.0.4 nil 1.0
cogre: 1.2 ok Not Loaded
cedet-contrib: 1.2 nil Not Loaded
C-h f cedet-version RET
for details on output format.

Checked again with cedet, builtint to all three emacs versions. Bug
doesn't appear even with emacs-snapshot, where cedet 2.0 is included
(same as cedet-bzr). Emacs command:
$ UBUNTU_MENUPROXY= emacs-snapshot -q # Variable is set to disable
$ # integration with appmenu
I'm in a maze, why it happened before. If file "cedet-devel-load.el"
is loaded (emacs is started by same command and nothing changed before
cedet-devel-load), bug appear.
В Tue, 19 Mar 2013 19:33:00 -0400
"Eric M. Ludlam" <eric@...> пишет:
> On 03/16/2013 09:23 AM, Nikita Zlobin wrote:
> > Activating both semantic and ede makes Development item of popup
> > "Global menu" looking like deactivated non-submenu item. But i
> > still may disable any of two modes, and submenu is available igain.
> >
> > Appears with cedet-bzr, but doesn't with included to emacs (of all
> > three versions). Also no difference - do i it by M-x or from Tools
> > menu. And affects only popup Global menu, called by C-Mouse3 when
> > menu bar is disabled; same item in enabled menu bar works as well.
> >
> > Tried under ubuntu 12.04 with emacs-23.4 (compiled from manually,
> > since in distro only 23.3 was packaged), 24.2.1 and snapshot from
> > cassou ppa
> > - ≈24.3 or higher (which is recommended in article about Emacs
> > Snapshot on Debian).
> >
> > I don't know, is it bug of some cedet package (may be even eieio) or
> > emacs itself, so reporting there for now.
>
> I'm not familiar with the Global menu, nor really how EDE and
> Semantic were updated to tweak the Development menu. I do know that
> as these packages get enabled, items are added and removed from that
> menu.
>
> For example, here is the snippet from Semantic:
>
> ;; This hack avoids showing the CEDET menu twice if
> ede-minor-mode ;; and Semantic are both enabled. Is there a better
> way? (define-key map [menu-bar cedet-menu]
> (list 'menu-item "Development" cedet-menu-map
> :enable (quote (not (bound-and-true-p global-ede-mode)))))
>
> Perhaps someone on the list is familiar with the kind of menu hacking
> going on here?
>
> > Screenshots are attached.
>
> Thanks!
>
> Eric

В Wed, 20 Mar 2013 17:38:02 +0100
David Engster <deng@...> пишет:
> Nikita Zlobin writes:
> > Not that! I meand emacs main menu, which may be activated by f10
> > (activating text-mode-menu without menu-bar, which btw, is also
> > affected by this bug in same situation, and doesn't have it in
> > terminal mode - i.e., when emacs is started with -nw option), and
> > with gui, but with menu-bar off - with C-Mouse3. In last case
> > appearing menu has caption with text "Global Menu" :)
>
> Emacs has no such thing as a "Global Menu". This is a Unity thing
> which exports a GTK menu bar via DBus and is apparently incompatible
> with Emacs.
>
> -David
> Nikita Zlobin writes:
> > ......and with gui, but with menu-bar off - with C-Mouse3. In last
> > case appearing menu has caption with text "Global Menu" :)
(replay)
> > caption with text "Global Menu"
Also followed by two separators. For completeness look screenshots from
initial message.

On 03/04/2013 08:45 PM, Eric M. Ludlam wrote:
>
> Thanks for your patience in explaining.
>
> This final patch is something I understand with the needed backstory. I
> was hesitant to do full directory lookups in this function. The ".*" is
> always scary. I suppose it is no worse that several shorter lookups.
> Perhaps this will be faster in the end.
>
> Your patch is currently passing tests, but I don't think we have any
> tests that explicitly try this out idle routine out.
>
> Instead, I'm going to run with this for a little bit and see how it goes.
>
> Fortunately, this patch is smaller than 10 lines of new code, so I don't
> need any special papers to accept contributions such as this.
Hi Tomasz,
Your patch was too close to the edge of being "small", so I re-wrote it
to avoid copyright issues, and checked in the change.
Hopefully this version satisfies your particular use case.
I found that when I was running, the defaults had changed to not parse
neighboring files by default, so all that intermediate time was wasted.
Bummer. I tested by hand instead to make sure the logic was ok.
Thanks
Eric