menu-bar/menu problems and label/help text purecopy guidelines

menu-bar/menu problems and label/help text purecopy guidelines

[Geek4AllSeasons]

The menu-bar started having episodes (standard menus fading out/disappearing
when clicked; toolbar tooltips displayed on mouse-hover on menu-bar) about a
week ago.

Emacs 23.1.50.cvs090630/EmacsW32 1.58 patched installed 09/23/09 had worked
fine previously. Upgrading to Emacs 23.1.50.cvs091103/EmacsW32 1.58 didn't
help.

A few menu text/purecopy bug reports and thread postings referencing the
switch to gtk+ reduced the search space. Inserting purecopy wrappers for
menu text corrects the problem menu by menu. 

Use of purecopy for menu text is inconsistent for core distribution and
add-on/contributed libraries. In many, maybe, most cases GC menu text works.
A comment in an Emacs-Dev thread indicated library pre-loading (loaddefs.el)
building Emacs as determining the need/use of pure/GC storage.

Are guidelines available? If so, corrections could be made accordingly and
patches created/submitted.

Based on search results there seems to be an increasing number of
potentially related issues/problems reported. Variability of symptoms makes
searching for solutions/workarounds more difficult. Time and effort would be
saved if general/less incident specific posting/descriptions were available.

Please let me know if there is a better list.

Thanks.

david
-- 
View this message in context: http://old.nabble.com/menu-bar-menu-problems-and-label-help-text-purecopy-guidelines-tp26634810p26634810.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: menu-bar/menu problems and label/help text purecopy guidelines

[Lennart Borgman]

On Thu, Dec 3, 2009 at 11:57 PM, Geek4AllSeasons
<Geek4AllSeasons@hotmail.com> wrote:
>
> The menu-bar started having episodes (standard menus fading out/disappearing
> when clicked; toolbar tooltips displayed on mouse-hover on menu-bar) about a
> week ago.
>
> Emacs 23.1.50.cvs090630/EmacsW32 1.58 patched installed 09/23/09 had worked
> fine previously. Upgrading to Emacs 23.1.50.cvs091103/EmacsW32 1.58 didn't
> help.


Could you please test with an unpatched Emacs? I suspect the problem
may be difficult to reproduce there because the menus are harder to
reach from the keyboard. Or are you using the mouse?

In any case please try to reproduce it with an unpatched Emacs and
send a bug report.


> A few menu text/purecopy bug reports and thread postings referencing the
> switch to gtk+ reduced the search space. Inserting purecopy wrappers for
> menu text corrects the problem menu by menu.
>
> Use of purecopy for menu text is inconsistent for core distribution and
> add-on/contributed libraries. In many, maybe, most cases GC menu text works.
> A comment in an Emacs-Dev thread indicated library pre-loading (loaddefs.el)
> building Emacs as determining the need/use of pure/GC storage.
>
> Are guidelines available? If so, corrections could be made accordingly and
> patches created/submitted.


According to the elisp manual purecopy does not do anything except
when building and dumping Emacs so it should not be the problem here,
see

  (info "(elisp) Pure Storage")


> Based on search results there seems to be an increasing number of
> potentially related issues/problems reported. Variability of symptoms makes
> searching for solutions/workarounds more difficult. Time and effort would be
> saved if general/less incident specific posting/descriptions were available.
>
> Please let me know if there is a better list.
>
> Thanks.
>
> david
> --
> View this message in context: http://old.nabble.com/menu-bar-menu-problems-and-label-help-text-purecopy-guidelines-tp26634810p26634810.html
> Sent from the Emacs - Help mailing list archive at Nabble.com.
>
>
>
>

Re: menu-bar/menu problems and label/help text purecopy guidelines

[Geek4AllSeasons]

Lennart Borgman (gmail) wrote:
> 
> Could you please test with an unpatched Emacs? I suspect the problem
> may be difficult to reproduce there because the menus are harder to
> reach from the keyboard. Or are you using the mouse?
> 
> According to the elisp manual purecopy does not do anything except
> when building and dumping Emacs so it should not be the problem here,
> see
> In any case please try to reproduce it with an unpatched Emacs and
> send a bug report.

An unpatched test produced the same behavior. Binaries from
emacs-from-cvs-091015.zip downloaded from OurComments (unpatched) directory
were used. That is the EmacsW32/OurComments version preceding the current
(patched) installation. Separate unpatched binaries corresponding to the
installed version were not present.

The apparent cause of the menu-bar not working differs from the prior
description. A menu-bar mode menu includes an imenu sub-menu:

imenu-create-index-function =semantic-create-imenu-index

The parse directory option is on. The menu-bar problem occurs for
buffer/files in directories containing large numbers of files, e.g.
emacs/lisp. A message has been observed reporting that a semantic table
entry for a file was empty. Opening each file appearing in those messages
corrected the problem and the menu-bar was fully functional.

It was not intended to suggest purecopy semantics are at issue. There seems
to be a correlation between what menu label/tooltip text is and is not in
pure storage.
http://old.nabble.com/Emacs-cvs-purecopy%28%29-td26245381.html#a26245381
Emacs CVS purecopy() 
http://old.nabble.com/Use-of-purecopy%28%29-td26177841.html#a26177841 Use of
purecopy 
http://old.nabble.com/bug-4429%3A-purecopy-calls-needed-for-%3Ahelp-and-in-menu-bar.el-td25441688.html#a26175618
bug#4429: purecopy calls needed for :help and in menu-bar.el 
I'm using many of Drew Adams' libraries. Some make extensive changes to the
menu-bar. Some possibly many of them don't use purecopy without problem. The
imenu/semantic issue above produces similar/the same behavior. It is likely
not related to purecopy since there is no problem if the directory index is
completely loaded.

IMO there are new implicit dependencies/requirements which library
configurations. individually and/or in combination violate. There may not be
a "bug" in code. What happens if a menu-map is preloaded into pure storage
then "overlayed" with a new key-map in GC storage? In the imenu/semantic
case are menu-map transactions atomic, kinda? Are maps always left in a
consistent state. i.e. usable by the display front end?

The most significant issue is lack of error reporting. The search space is
far too large for indirect debugging methods. I fumbled around attempting
unsuccessfully to use Edebug and/or gdb to identify specific point(s) of
failure. It appears the c code primitives are silently choking on related
elisp data structures. It seems like it's time for the training wheels to
come off and start rolling my own binaries. The lack of any visibility into
c code is frustrating and unproductive.

I'll repeat the test with unpatched binaries and submit a bug report.

david
-- 
View this message in context: http://old.nabble.com/menu-bar-menu-problems-and-label-help-text-purecopy-guidelines-tp26634810p26780209.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: menu-bar/menu problems and label/help text purecopy guidelines

[Lennart Borgman]

On Mon, Dec 14, 2009 at 11:10 PM, Geek4AllSeasons
<Geek4AllSeasons@hotmail.com> wrote:
>
>
> Lennart Borgman (gmail) wrote:
>>
>> Could you please test with an unpatched Emacs? I suspect the problem
>> may be difficult to reproduce there because the menus are harder to
>> reach from the keyboard. Or are you using the mouse?
>>
>> According to the elisp manual purecopy does not do anything except
>> when building and dumping Emacs so it should not be the problem here,
>> see
>> In any case please try to reproduce it with an unpatched Emacs and
>> send a bug report.
>
> An unpatched test produced the same behavior. Binaries from
> emacs-from-cvs-091015.zip downloaded from OurComments (unpatched) directory
> were used. That is the EmacsW32/OurComments version preceding the current
> (patched) installation. Separate unpatched binaries corresponding to the
> installed version were not present.


Ok, fine. Then we know a bit more.


> The apparent cause of the menu-bar not working differs from the prior
> description. A menu-bar mode menu includes an imenu sub-menu:
>
> imenu-create-index-function =semantic-create-imenu-index
>
> The parse directory option is on. The menu-bar problem occurs for
> buffer/files in directories containing large numbers of files, e.g.
> emacs/lisp. A message has been observed reporting that a semantic table
> entry for a file was empty. Opening each file appearing in those messages
> corrected the problem and the menu-bar was fully functional.
>
> It was not intended to suggest purecopy semantics are at issue. There seems
> to be a correlation between what menu label/tooltip text is and is not in
> pure storage.
> http://old.nabble.com/Emacs-cvs-purecopy%28%29-td26245381.html#a26245381
> Emacs CVS purecopy()
> http://old.nabble.com/Use-of-purecopy%28%29-td26177841.html#a26177841 Use of
> purecopy
> http://old.nabble.com/bug-4429%3A-purecopy-calls-needed-for-%3Ahelp-and-in-menu-bar.el-td25441688.html#a26175618
> bug#4429: purecopy calls needed for :help and in menu-bar.el


I know very little about this, but I know the elisp manual says that
purecopy only makes difference for the dumped Emacs, ie not for
libraries loaded later when you as a user runs Emacs.


> I'm using many of Drew Adams' libraries. Some make extensive changes to the
> menu-bar. Some possibly many of them don't use purecopy without problem. The
> imenu/semantic issue above produces similar/the same behavior. It is likely
> not related to purecopy since there is no problem if the directory index is
> completely loaded.
>
> IMO there are new implicit dependencies/requirements which library
> configurations. individually and/or in combination violate. There may not be
> a "bug" in code. What happens if a menu-map is preloaded into pure storage
> then "overlayed" with a new key-map in GC storage? In the imenu/semantic
> case are menu-map transactions atomic, kinda? Are maps always left in a
> consistent state. i.e. usable by the display front end?


No. There are some bugs there, but they are hard to nail down.


> The most significant issue is lack of error reporting. The search space is
> far too large for indirect debugging methods. I fumbled around attempting
> unsuccessfully to use Edebug and/or gdb to identify specific point(s) of
> failure. It appears the c code primitives are silently choking on related
> elisp data structures. It seems like it's time for the training wheels to
> come off and start rolling my own binaries. The lack of any visibility into
> c code is frustrating and unproductive.


The unpatched binaries are compiled with debug information so you
should be able to debug it using them.

Or perhaps you should that since there might be unforseen problems due
to that the menu code is not running in the elisp thread.
Unfortunately I know little about how to debug this, but hopefully
someone else can guide you (if you need assistance).



> I'll repeat the test with unpatched binaries and submit a bug report.


Thanks. That is very good.


> david
> --
> View this message in context: http://old.nabble.com/menu-bar-menu-problems-and-label-help-text-purecopy-guidelines-tp26634810p26780209.html
> Sent from the Emacs - Help mailing list archive at Nabble.com.
>
>
>
>