GNU bug report logs -
#58771
29.0.50; context submenu can not click when run emacs lucid build.
Previous Next
Reported by: Feng Shu <tumashu <at> 163.com>
Date: Tue, 25 Oct 2022 05:45:01 UTC
Severity: normal
Merged with 57320,
57518,
59733
Found in version 29.0.50
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58771 in the body.
You can then email your comments to 58771 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Tue, 25 Oct 2022 05:45:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Feng Shu <tumashu <at> 163.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 25 Oct 2022 05:45:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Today I find that Context submenu can not click.
In GNU Emacs 29.0.50 (build 25, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.16.0, Xaw3d scroll bars) of 2022-10-24 built on Tumashu
Repository revision: f7816c94b61f87919afccbedbea5270ca5db4e15
Repository branch: feng-emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)
Configured using:
'configure --with-x-toolkit=lucid --with-json'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XAW3D XDBE XIM XINPUT2 XPM LUCID ZLIB
Important settings:
value of $LANG: zh_CN.UTF-8
value of $XMODIFIERS: @im=fcitx
locale-coding-system: utf-8-unix
Major mode: Group
Minor modes in effect:
projectile-mode: t
global-git-commit-mode: t
magit-auto-revert-mode: t
emms-playing-time-display-mode: t
emms-playing-time-mode: t
cnfonts-mode: t
gnus-undo-mode: t
corfu-history-mode: t
global-corfu-mode: t
corfu-mode: t
org-super-agenda-mode: t
pyim-isearch-mode: t
vertico-mode: t
savehist-mode: t
global-tab-line-mode: t
tab-line-mode: t
global-so-long-mode: t
electric-pair-mode: t
pixel-scroll-precision-mode: t
shell-dirtrack-mode: t
recentf-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
context-menu-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/home/feng/projects/emacs-packages/cnfonts/cnfonts hides /home/feng/.emacs.d/elpa-29/cnfonts-20221019.159/cnfonts
/home/feng/projects/emacs-packages/cnfonts/cnfonts-ui hides /home/feng/.emacs.d/elpa-29/cnfonts-20221019.159/cnfonts-ui
/home/feng/projects/emacs-packages/ebdb/ebdb-test hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-test
/home/feng/projects/emacs-packages/ebdb/ebdb-snarf hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-snarf
/home/feng/projects/emacs-packages/ebdb/ebdb-rmail hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-rmail
/home/feng/projects/emacs-packages/ebdb/ebdb-pgp hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-pgp
/home/feng/projects/emacs-packages/ebdb/ebdb-org hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-org
/home/feng/projects/emacs-packages/ebdb/ebdb-notmuch hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-notmuch
/home/feng/projects/emacs-packages/ebdb/ebdb-mua hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-mua
/home/feng/projects/emacs-packages/ebdb/ebdb-mu4e hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-mu4e
/home/feng/projects/emacs-packages/ebdb/ebdb-migrate hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-migrate
/home/feng/projects/emacs-packages/ebdb/ebdb-mhe hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-mhe
/home/feng/projects/emacs-packages/ebdb/ebdb-message hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-message
/home/feng/projects/emacs-packages/ebdb/ebdb-latex hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-latex
/home/feng/projects/emacs-packages/ebdb/ebdb-ispell hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-ispell
/home/feng/projects/emacs-packages/ebdb/ebdb hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb
/home/feng/projects/emacs-packages/ebdb/ebdb-i18n hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-i18n
/home/feng/projects/emacs-packages/ebdb/ebdb-i18n-test hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-i18n-test
/home/feng/projects/emacs-packages/ebdb/ebdb-i18n-basic hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-i18n-basic
/home/feng/projects/emacs-packages/ebdb/ebdb-wl hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-wl
/home/feng/projects/emacs-packages/ebdb/ebdb-html hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-html
/home/feng/projects/emacs-packages/ebdb/ebdb-helm hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-helm
/home/feng/projects/emacs-packages/ebdb/ebdb-gnus hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-gnus
/home/feng/projects/emacs-packages/ebdb/ebdb-format hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-format
/home/feng/projects/emacs-packages/ebdb/ebdb-vm hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-vm
/home/feng/projects/emacs-packages/ebdb/ebdb-counsel hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-counsel
/home/feng/projects/emacs-packages/ebdb/ebdb-vcard hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-vcard
/home/feng/projects/emacs-packages/ebdb/ebdb-complete hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-complete
/home/feng/projects/emacs-packages/ebdb/ebdb-com hides /home/feng/.emacs.d/elpa-29/ebdb-0.8.14/ebdb-com
/home/feng/projects/emacs-packages/pyim/pyim hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim
/home/feng/projects/emacs-packages/pyim/pyim-scheme hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-scheme
/home/feng/projects/emacs-packages/pyim/pyim-pymap hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-pymap
/home/feng/projects/emacs-packages/pyim/pyim-pymap-utils hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-pymap-utils
/home/feng/projects/emacs-packages/pyim/pyim-punctuation hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-punctuation
/home/feng/projects/emacs-packages/pyim/pyim-pinyin hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-pinyin
/home/feng/projects/emacs-packages/pyim/pyim-page hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-page
/home/feng/projects/emacs-packages/pyim/pyim-outcome hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-outcome
/home/feng/projects/emacs-packages/pyim/pyim-liberime hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-liberime
/home/feng/projects/emacs-packages/pyim/pyim-indicator hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-indicator
/home/feng/projects/emacs-packages/pyim/pyim-imobjs hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-imobjs
/home/feng/projects/emacs-packages/pyim/pyim-entered hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-entered
/home/feng/projects/emacs-packages/pyim/pyim-dregcache hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-dregcache
/home/feng/projects/emacs-packages/pyim/pyim-dict hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-dict
/home/feng/projects/emacs-packages/pyim/pyim-dict-manager hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-dict-manager
/home/feng/projects/emacs-packages/pyim/pyim-dhashcache hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-dhashcache
/home/feng/projects/emacs-packages/pyim/pyim-dcache hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-dcache
/home/feng/projects/emacs-packages/pyim/pyim-cstring hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-cstring
/home/feng/projects/emacs-packages/pyim/pyim-cstring-utils hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-cstring-utils
/home/feng/projects/emacs-packages/pyim/pyim-cregexp hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-cregexp
/home/feng/projects/emacs-packages/pyim/pyim-cregexp-utils hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-cregexp-utils
/home/feng/projects/emacs-packages/pyim/pyim-common hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-common
/home/feng/projects/emacs-packages/pyim/pyim-codes hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-codes
/home/feng/projects/emacs-packages/pyim/pyim-cloudim hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-cloudim
/home/feng/projects/emacs-packages/pyim/pyim-candidates hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-candidates
/home/feng/projects/emacs-packages/pyim/pyim-autoselector hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-autoselector
/home/feng/projects/emacs-packages/pyim/pyim-process hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-process
/home/feng/projects/emacs-packages/pyim/pyim-probe hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-probe
/home/feng/projects/emacs-packages/pyim/pyim-preview hides /home/feng/.emacs.d/elpa-29/pyim-20221019.44/pyim-preview
/home/feng/projects/emacs-packages/pyim-basedict/pyim-basedict hides /home/feng/.emacs.d/elpa-29/pyim-basedict-0.5.4/pyim-basedict
/home/feng/projects/emacs-packages/pyim-basedict/pyim-basedict-utils hides /home/feng/.emacs.d/elpa-29/pyim-basedict-0.5.4/pyim-basedict-utils
/home/feng/.emacs.d/elpa-29/xr-1.23/xr hides ~/projects/emacs-packages/pyim/.deps/xr
/home/feng/projects/emacs-packages/pyim-basedict/pyim-basedict hides ~/projects/emacs-packages/pyim/.deps/pyim-basedict
/home/feng/projects/emacs-packages/emacs-popon/popon hides ~/projects/emacs-packages/pyim/.deps/popon
/home/feng/.emacs.d/elpa-29/async-20221014.2225/async hides ~/projects/emacs-packages/pyim/.deps/async
/home/feng/.emacs.d/elpa-29/transient-20221020.1019/transient hides /home/feng/emacs/emacs29/lisp/transient
Features:
(shadow mule-util emacsbug qp shr-color mm-archive textsec uni-scripts
idna-mapping ucs-normalize uni-confusable textsec-check gnus-async
gnus-bcklg mail-extr gnus-ml hl-line disp-table network-stream nsm pop3
nndraft nnmh nnml org-archive tabify cursor-sensor org-clock diary-lib
diary-loaddefs cal-iso citre citre-global org-eldoc ol-eww ol-rmail
ol-mhe ol-irc ol-info ol-gnus ol-docview doc-view jka-compr image-mode
exif ol-bibtex ol-bbdb ol-w3m ol-doi org-link-doi face-remap warnings
emacs-helper eh-guix skeleton guix geiser-guile info-look geiser-repl
geiser-image geiser-capf geiser-doc geiser-menu geiser-autodoc
geiser-edit etags fileloop xref geiser-completion geiser-eval
geiser-connection geiser-syntax scheme geiser-log geiser-popup view
geiser eh-misc vundo projectile lisp-mnt grep compile ibuf-ext ibuffer
ibuffer-loaddefs magit-bookmark magit-submodule magit-obsolete
magit-popup magit-blame magit-stash magit-reflog magit-bisect magit-push
magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log which-func imenu edebug
debug backtrace magit-diff smerge-mode diff diff-mode git-commit
log-edit pcvs-util add-log magit-core magit-autorevert magit-margin
magit-transient magit-process with-editor server magit-mode transient
edmacro magit-git magit-base magit-section compat-27 compat-26
aggressive-indent eh-emms emms-librefm-stream emms-librefm-scrobbler
emms-playlist-limit emms-i18n emms-history emms-score emms-stream-info
emms-metaplaylist-mode emms-bookmarks emms-cue emms-mode-line-icon
emms-player-xine emms-player-mpd tq emms-lyrics emms-url emms-streams
emms-show-all emms-tag-editor emms-tag-tracktag emms-mark emms-mode-line
emms-info-tinytag emms-info-metaflac emms-info-opusinfo
emms-info-ogginfo emms-info-mp3info emms-player-vlc emms-player-mpv
emms-playing-time emms-player-mplayer emms-player-simple emms-browser
emms-playlist-sort emms-last-played emms-volume emms-volume-sndioctl
emms-volume-mixerctl emms-volume-pulse emms-volume-amixer
emms-playlist-mode emms-source-playlist emms-source-file locate
emms-cache emms-info-native bindat emms-info-exiftool emms-info
emms-later-do emms-setup emms emms-compat el2org cnfonts easy-mmode
tempel citre-config citre-lang-fileref citre-tags citre-ctags
citre-readtags citre-readtags-tables citre-backend-interface
citre-ui-peek color citre-ui-jump citre-common-tag citre-common-util
eh-gnus-common ebdb-message ebdb-gnus nnselect ebdb-mua ebdb-complete
ebdb-com crm ebdb-format ebdb-i18n-chn ebdb-i18n ebdb-i18n-basic ebdb
inline eieio-base timezone eww xdg url-queue thingatpt mm-url gnus-demon
gnus-search eieio-opt speedbar ezimage dframe gnus-agent gnus-srvr
gnus-score score-mode nnvirtual gnus-msg nntp gnus-cite gnus-art mm-uu
mml2015 mm-view mml-smime smime gnutls dig gnus-cache gnus-sum shr
pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start
gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo
gnus-spec gnus-int gnus-range message sendmail yank-media puny rfc822
mml mml-sec epa derived epg rfc6068 epg-config mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev
gmm-utils mailheader gnus-win gnus nnheader gnus-util mail-utils range
mm-util mail-prsvr eh-complete cape corfu-history corfu eh-org org-ql
peg org-super-agenda ts ht s dash org-habit org-capture ob-python python
project ob-org ox-md ox-org ox-odt rng-loc rng-uri rng-parse rng-match
rng-dt rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util
ox-latex ox-icalendar org-agenda ox-html table ox-ascii ox-publish ox
org-element avl-tree generator autorevert filenotify pcase org-attach
org-id org-refile org ob ob-tangle ob-ref ob-lob ob-table ob-exp
org-macro org-footnote org-src ob-comint org-pcomplete org-list
org-faces org-entities noutline outline org-version ob-emacs-lisp
ob-core ob-eval org-table oc-basic bibtex ol org-keys oc org-compat
advice org-macs org-loaddefs find-func eh-functions eh-theme
modus-vivendi-theme modus-operandi-theme modus-themes eh-basic
cal-china-x cal-china lunar solar cal-dst holidays holiday-loaddefs
cal-menu calendar cal-loaddefs pyim-basedict pyim-cregexp-utils pyim
pyim-cloudim pyim-probe pyim-preview pyim-page popup cl-extra posframe
pyim-indicator pyim-dregcache pyim-dhashcache sort pyim-dict async
pyim-autoselector pyim-process pyim-punctuation pyim-outcome
pyim-candidates pyim-cstring pyim-cregexp xr pyim-codes pyim-imobjs
pyim-pinyin pyim-entered pyim-dcache pyim-pymap pyim-scheme pyim-common
wdired dired dired-loaddefs vc vc-dispatcher consult-vertico consult
compat-28 compat compat-macs kmacro orderless vertico-directory vertico
savehist tab-line switch-window switch-window-mvborder
switch-window-asciiart quail so-long elec-pair bookmark
text-property-search pixel-scroll cua-base tramp-cache time-stamp
tramp-sh tramp tramp-loaddefs trampver tramp-integration cus-edit pp
cus-load icons files-x tramp-compat rx shell pcomplete comint ansi-osc
ansi-color parse-time iso8601 time-date ls-lisp format-spec recentf
tree-widget wid-edit elpa-mirror finder-inf adaptive-wrap-autoloads
aggressive-indent-autoloads autopair-autoloads cal-china-x-autoloads
cape-autoloads citre-autoloads cnfonts-autoloads consult-autoloads
corfu-autoloads dired-ranger-autoloads dired-hacks-utils-autoloads
ebdb-i18n-chn-autoloads ef-themes-autoloads el2org-autoloads
elpa-mirror-autoloads emms-autoloads flycheck-autoloads
geiser-guile-autoloads geiser-impl help-fns radix-tree help-mode
geiser-custom geiser-base ring guix-autoloads edit-indirect-autoloads
bui-autoloads geiser-autoloads magit-autoloads git-commit-autoloads
magit-section-autoloads marginalia-autoloads markdown-mode-autoloads
modus-themes-autoloads orderless-autoloads org-contrib-autoloads
org-download-autoloads org-ql-autoloads f-autoloads
org-super-agenda-autoloads ht-autoloads ov-autoloads ox-gfm-autoloads
package-lint-autoloads paredit-autoloads peg-autoloads
pkg-info-autoloads epl-autoloads pos-tip-autoloads projectile-autoloads
pyim-autoloads async-autoloads pyim-basedict-autoloads
rainbow-delimiters-autoloads rainbow-mode-autoloads
recentf-ext-autoloads switch-window-autoloads tempel-autoloads
transient-autoloads ts-autoloads s-autoloads vertico-autoloads
vundo-autoloads wgrep-autoloads with-editor-autoloads compat-autoloads
wrap-region-autoloads info dash-autoloads xmlgen-autoloads xr-autoloads
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
password-cache json subr-x map byte-opt gv bytecomp byte-compile cconv
url-vars cl-loaddefs cl-lib china-util rmc iso-transl tooltip eldoc
paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
mwheel term/x-win x-win term/common-win x-dnd 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 nadvice seq simple cl-generic
indonesian philippine 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 abbrev obarray oclosure cl-preloaded button loaddefs
theme-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 dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)
Memory information:
((conses 16 1214383 167213)
(symbols 48 55710 93)
(strings 32 599259 28832)
(string-bytes 1 10429298)
(vectors 16 128198)
(vector-slots 8 14018747 128153)
(floats 8 1340 1508)
(intervals 56 963 553)
(buffers 1000 30))
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Tue, 25 Oct 2022 07:45:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Feng Shu <tumashu <at> 163.com> writes:
> Today I find that Context submenu can not click.
What context menu? Could you please describe how to obtain the buggy
menu, and how you are trying to click it, step-by-step?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Tue, 25 Oct 2022 08:36:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 58771 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Po Lu <luangruo <at> yahoo.com> writes:
> Feng Shu <tumashu <at> 163.com> writes:
>
>> Today I find that Context submenu can not click.
>
> What context menu? Could you please describe how to obtain the buggy
> menu, and how you are trying to click it, step-by-step?
[截图_2022-10-25_16-31-59.png (image/png, attachment)]
[Message part 3 (text/plain, inline)]
just right click in emacs buffer.
>
> Thanks.
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Tue, 25 Oct 2022 10:31:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Feng Shu <tumashu <at> 163.com> writes:
> just right click in emacs buffer.
I managed to reproduce a hang trying to click on the submenu item, but
then killed Emacs in an attempt to reproduce the problem again, and it
stopped happening. Since that, I haven't been able to reproduce the
hang.
So it would be nice if you could try to find a way to reproduce this bug
from "emacs -Q", because I'm really lost.
Thanks in advance.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Tue, 25 Oct 2022 14:00:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 58771 <at> debbugs.gnu.org (full text, mbox):
On Tue, 25 Oct 2022 18:30:36 +0800 Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> wrote:
> Feng Shu <tumashu <at> 163.com> writes:
>
>> just right click in emacs buffer.
>
> I managed to reproduce a hang trying to click on the submenu item, but
> then killed Emacs in an attempt to reproduce the problem again, and it
> stopped happening. Since that, I haven't been able to reproduce the
> hang.
>
> So it would be nice if you could try to find a way to reproduce this bug
> from "emacs -Q", because I'm really lost.
I can reliably reproduce the bug, but for me it's a sympton of broader
buggy behavior with menus in the Lucid build, which I've observed since
I started regularly building with the Lucid toolkit some months ago
(after not doing so for many years previously, so I don't know how old
this behavior is).
So while the items of a context menu (but not those of a submenu) can be
scrolled with the mouse, context menus are completely unresponsive to
keyboard events. In contrast, with menus from the menu bar (whether
open via mouse click for with the F10 key binding), I can both navigate
and select (also in submenus) with the keyboard but other than opening
and closing, the menu bar menus are completely unresponsive to the
mouse.
Here's my current build info:
In GNU Emacs 29.0.50 (build 15, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.17.6, Xaw scroll bars) of 2022-10-25 built on strobelfs2
Repository revision: 92ec31a48c7fa2a700eb3a5c618fe015843e6875
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Linux From Scratch r11.0-165
Configured using:
'configure -C --with-x-toolkit=lucid --with-xinput2 'CFLAGS=-Og -g3'
PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
XINPUT2 XPM LUCID ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Wed, 26 Oct 2022 00:44:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> I can reliably reproduce the bug, but for me it's a sympton of broader
> buggy behavior with menus in the Lucid build, which I've observed since
> I started regularly building with the Lucid toolkit some months ago
> (after not doing so for many years previously, so I don't know how old
> this behavior is).
>
> So while the items of a context menu (but not those of a submenu) can be
> scrolled with the mouse, context menus are completely unresponsive to
> keyboard events. In contrast, with menus from the menu bar (whether
> open via mouse click for with the F10 key binding), I can both navigate
> and select (also in submenus) with the keyboard but other than opening
> and closing, the menu bar menus are completely unresponsive to the
> mouse.
Could you please try to find out what this call to XtGrabPointer in
xlwmenu.c returns when you pop up a menu?
#ifdef emacs
x_catch_errors (display);
#endif
if (XtGrabPointer ((Widget)mw, False,
(PointerMotionMask
| PointerMotionHintMask
| ButtonReleaseMask
| ButtonPressMask),
GrabModeAsync, GrabModeAsync, None,
mw->menu.cursor_shape,
event->time) == Success) <-----------------
{
if (true
If you're going to be using a debugger, then please do the debugging
remotely from a different machine. Otherwise, you will either lock up
your X server or waste a lot of time when the bug simply vanishes once
you try to debug it.
Either way, we have to get this fixed before Emacs 29 is released, so
please try to be fast here. Thanks a lot.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Wed, 26 Oct 2022 02:15:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> Feng Shu <tumashu <at> 163.com> writes:
>
>> Today I find that Context submenu can not click.
>
> What context menu? Could you please describe how to obtain the buggy
> menu, and how you are trying to click it, step-by-step?
>
> Thanks.
Today, I git pull and force rebuild emacs, submenu can click now, I do not
know the reason.
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Wed, 26 Oct 2022 08:01:03 GMT)
Full text and
rfc822 format available.
Message #26 received at 58771 <at> debbugs.gnu.org (full text, mbox):
On Wed, 26 Oct 2022 08:42:58 +0800 Po Lu <luangruo <at> yahoo.com> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> I can reliably reproduce the bug, but for me it's a sympton of broader
>> buggy behavior with menus in the Lucid build, which I've observed since
>> I started regularly building with the Lucid toolkit some months ago
>> (after not doing so for many years previously, so I don't know how old
>> this behavior is).
>>
>> So while the items of a context menu (but not those of a submenu) can be
>> scrolled with the mouse, context menus are completely unresponsive to
>> keyboard events. In contrast, with menus from the menu bar (whether
>> open via mouse click for with the F10 key binding), I can both navigate
>> and select (also in submenus) with the keyboard but other than opening
>> and closing, the menu bar menus are completely unresponsive to the
>> mouse.
>
> Could you please try to find out what this call to XtGrabPointer in
> xlwmenu.c returns when you pop up a menu?
>
> #ifdef emacs
> x_catch_errors (display);
> #endif
> if (XtGrabPointer ((Widget)mw, False,
> (PointerMotionMask
> | PointerMotionHintMask
> | ButtonReleaseMask
> | ButtonPressMask),
> GrabModeAsync, GrabModeAsync, None,
> mw->menu.cursor_shape,
> event->time) == Success) <-----------------
> {
> if (true
>
> If you're going to be using a debugger, then please do the debugging
> remotely from a different machine. Otherwise, you will either lock up
> your X server or waste a lot of time when the bug simply vanishes once
> you try to debug it.
>
> Either way, we have to get this fixed before Emacs 29 is released, so
> please try to be fast here. Thanks a lot.
I've done only elementary debugging with gdb and never from a different
machine, so I will need explicit instructions for how to set it up and
what to enter, and if it's not straightforward, I probably can't do it
soon.
But there may be a (for me) quicker way to investigate the issue: I'm in
the process of building a new system on this machine, which is an
updated version of my current system (on a different partition), and one
of the first programs I built after installing the basic system is
Emacs, first before installing X, then again with X but before
installing GTK. On this system, the X build used the Lucid toolkit, and
with it I did not observe the menu problems I described. Aside from
different versions of system libraries like glibc and build tools like
gcc, the two builds differ in their Emacs-specific configurations. The
build with the menu problems used
configure -C --with-x-toolkit=lucid --with-xinput2 CFLAGS='-Og -g3'
while the build on the newer system without the menu problems used
configure -C --with-jpeg=ifavailable --with-gif=ifavailable --with-tiff=ifavailable
I'll try using the other configuration on the new system and see if that
makes a difference (though I probably won't get to that till this
evening.)
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Wed, 26 Oct 2022 08:20:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Isn't this yet another duplicate of bug#57320?
[பà¯à®¤à®©à¯ à®
à®à¯à®à¯à®ªà®°à¯ 26, 2022] Stephen Berman wrote:
> I've done only elementary debugging with gdb and never from a different
> machine, so I will need explicit instructions for how to set it up and
> what to enter, and if it's not straightforward, I probably can't do it
> soon.
I ssh'd into my laptop from my phone to do the debugging. More info on
what I did can be found in bug#57320, and specific instructions are in
https://yhetil.org/emacs-bugs/87k06gby3w.fsf <at> gmail.com. HTH.
> But there may be a (for me) quicker way to investigate the issue: I'm in
> the process of building a new system on this machine, which is an
> updated version of my current system (on a different partition), and one
> of the first programs I built after installing the basic system is
> Emacs, first before installing X, then again with X but before
> installing GTK. On this system, the X build used the Lucid toolkit, and
> with it I did not observe the menu problems I described. Aside from
> different versions of system libraries like glibc and build tools like
> gcc, the two builds differ in their Emacs-specific configurations. The
> build with the menu problems used
IME, this bug goes away when you re-./configure Emacs so there's no
surprise this disappeared in your case. It would be of help if I could
run the debug build all the time and wait for the menu bug to eventually
show up but alas it is far too slow for me to use it daily...
> [configure lines.]
> I'll try using the other configuration on the new system and see if that
> makes a difference (though I probably won't get to that till this
> evening.)
I don't think the specifics of the configuration options matter as long
as you run the Lucid build.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Wed, 26 Oct 2022 08:21:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> I've done only elementary debugging with gdb and never from a different
> machine, so I will need explicit instructions for how to set it up and
> what to enter, and if it's not straightforward, I probably can't do it
> soon.
>
> But there may be a (for me) quicker way to investigate the issue: I'm in
> the process of building a new system on this machine, which is an
> updated version of my current system (on a different partition), and one
> of the first programs I built after installing the basic system is
> Emacs, first before installing X, then again with X but before
> installing GTK. On this system, the X build used the Lucid toolkit, and
> with it I did not observe the menu problems I described. Aside from
> different versions of system libraries like glibc and build tools like
> gcc, the two builds differ in their Emacs-specific configurations. The
> build with the menu problems used
>
> configure -C --with-x-toolkit=lucid --with-xinput2 CFLAGS='-Og -g3'
>
> while the build on the newer system without the menu problems used
>
> configure -C --with-jpeg=ifavailable --with-gif=ifavailable --with-tiff=ifavailable
>
> I'll try using the other configuration on the new system and see if that
> makes a difference (though I probably won't get to that till this
> evening.)
The only difference I can think of in that case is which Athena widgets
variant is used, since XInput 2 is now enabled by default. What do the
scroll bars look like in either of those builds?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Wed, 26 Oct 2022 09:41:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 58771 <at> debbugs.gnu.org (full text, mbox):
On Wed, 26 Oct 2022 13:48:57 +0530 Visuwesh <visuweshm <at> gmail.com> wrote:
> Isn't this yet another duplicate of bug#57320?
Possibly. I vaguely remember reading it but I'll look again when I have
time.
> [பà¯à®¤à®©à¯ à®
à®à¯à®à¯à®ªà®°à¯ 26, 2022] Stephen Berman wrote:
>
>> I've done only elementary debugging with gdb and never from a different
>> machine, so I will need explicit instructions for how to set it up and
>> what to enter, and if it's not straightforward, I probably can't do it
>> soon.
>
> I ssh'd into my laptop from my phone to do the debugging. More info on
> what I did can be found in bug#57320, and specific instructions are in
> https://yhetil.org/emacs-bugs/87k06gby3w.fsf <at> gmail.com. HTH.
>
>> But there may be a (for me) quicker way to investigate the issue: I'm in
>> the process of building a new system on this machine, which is an
>> updated version of my current system (on a different partition), and one
>> of the first programs I built after installing the basic system is
>> Emacs, first before installing X, then again with X but before
>> installing GTK. On this system, the X build used the Lucid toolkit, and
>> with it I did not observe the menu problems I described. Aside from
>> different versions of system libraries like glibc and build tools like
>> gcc, the two builds differ in their Emacs-specific configurations. The
>> build with the menu problems used
>
> IME, this bug goes away when you re-./configure Emacs so there's no
> surprise this disappeared in your case. It would be of help if I could
> run the debug build all the time and wait for the menu bug to eventually
> show up but alas it is far too slow for me to use it daily...
>
>> [configure lines.]
>> I'll try using the other configuration on the new system and see if that
>> makes a difference (though I probably won't get to that till this
>> evening.)
>
> I don't think the specifics of the configuration options matter as long
> as you run the Lucid build.
Thanks for the feedback and advice, I'll try to follow up on it.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Wed, 26 Oct 2022 09:41:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 58771 <at> debbugs.gnu.org (full text, mbox):
On Wed, 26 Oct 2022 16:20:08 +0800 Po Lu <luangruo <at> yahoo.com> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> I've done only elementary debugging with gdb and never from a different
>> machine, so I will need explicit instructions for how to set it up and
>> what to enter, and if it's not straightforward, I probably can't do it
>> soon.
>>
>> But there may be a (for me) quicker way to investigate the issue: I'm in
>> the process of building a new system on this machine, which is an
>> updated version of my current system (on a different partition), and one
>> of the first programs I built after installing the basic system is
>> Emacs, first before installing X, then again with X but before
>> installing GTK. On this system, the X build used the Lucid toolkit, and
>> with it I did not observe the menu problems I described. Aside from
>> different versions of system libraries like glibc and build tools like
>> gcc, the two builds differ in their Emacs-specific configurations. The
>> build with the menu problems used
>>
>> configure -C --with-x-toolkit=lucid --with-xinput2 CFLAGS='-Og -g3'
>>
>> while the build on the newer system without the menu problems used
>>
>> configure -C --with-jpeg=ifavailable --with-gif=ifavailable
>> --with-tiff=ifavailable
>>
>> I'll try using the other configuration on the new system and see if that
>> makes a difference (though I probably won't get to that till this
>> evening.)
>
> The only difference I can think of in that case is which Athena widgets
> variant is used, since XInput 2 is now enabled by default. What do the
> scroll bars look like in either of those builds?
I can't check right now because I'm on the older system and need to do
work there. But it occurred to it that I can try compiling the Lucid
build here as I did on the new system, i.e. only --with-x-toolkit=lucid,
and it still has the menu problems, so the build configuration does not
account for the difference.
But I also have a number of emacs executables of the Lucid build and I
found that menu problems do not occur in my build from commit
177811ac0c0e5e41d4f661e8e5553e46f0019b9a (Sept 2) but do occur in my
next build, from commit c6fc00f5d75a28fd4e99050ccc1af9ad82f66b2b (Sept
15, more recently than I remembered). In the build from Sept 2 the
context menu seems to hang for several seconds, during which there is no
response, but then it seems to work ok, as do the menu bar menus, while
the build from Sept 15 has the problems I still see now. When I have
more time I can try bisecting.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Wed, 26 Oct 2022 09:56:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> I can't check right now because I'm on the older system and need to do
> work there. But it occurred to it that I can try compiling the Lucid
> build here as I did on the new system, i.e. only --with-x-toolkit=lucid,
> and it still has the menu problems, so the build configuration does not
> account for the difference.
>
> But I also have a number of emacs executables of the Lucid build and I
> found that menu problems do not occur in my build from commit
> 177811ac0c0e5e41d4f661e8e5553e46f0019b9a (Sept 2) but do occur in my
> next build, from commit c6fc00f5d75a28fd4e99050ccc1af9ad82f66b2b (Sept
> 15, more recently than I remembered). In the build from Sept 2 the
> context menu seems to hang for several seconds, during which there is no
> response, but then it seems to work ok, as do the menu bar menus, while
> the build from Sept 15 has the problems I still see now. When I have
> more time I can try bisecting.
>
> Steve Berman
Please do that, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Wed, 11 Jan 2023 09:48:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Mike Kupfer <kupfer <at> rawbw.com> writes:
> I don't even need to rerun configure. I just added a debug fprintf to
> pop_up_menu(), rebuilt Emacs, and the problem vanished.
Would you please send me the two different binaries?
(Off-list, please, if you're worried about the binaries containing
private information.)
> I still have the binary that fails. On a hunch, I added a breakpoint at
> the start of pop_up_menu(). When the breakpoint triggered, I checked
> the value of lucid__menu_grab_keyboard. gdb says
>
> (gdb) print lucid__menu_grab_keyboard
> $2 = false
>
> Yet *Help* says that the value of lucid--menu_grab_keyboard is t.
>
> If I do
>
> M-: (setq lucid--menu_grab_keyboard t)
>
> and press F10, gdb says lucid__menu_grab_keyboard is still false.
>
> I did a little more poking around with gdb and found that
> lucid__menu_grab_keyboard moves around inside "globals".
>
> Broken binary:
>
> (gdb) print &globals.f_lucid__menu_grab_keyboard
> $3 = (_Bool *) 0x555555d54a98 <globals+4152>
>
> Working binary:
>
> (gdb) print &globals.f_lucid__menu_grab_keyboard
> $2 = (_Bool *) 0x555555d54ad0 <globals+4208>
>
> This strikes me as more than a little odd. Given that all I did was
> add a couple fprintfs, I'd expect the layout of "globals" to stay the
> same.
I have a hunch. If you touch globals.h in src, does it result in files
under the lwlib directory being rebuilt?
My guess is globals.h changed but lwlib was not incrementally rebuilt.
I guess this means lwlib/*.o has to be made to depend on
$(top_builddir)/globals.stamp or somesuch. Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Wed, 11 Jan 2023 11:13:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Visuwesh wrote:
> Isn't this yet another duplicate of bug#57320?
Looks like it, yes.
> IME, this bug goes away when you re-./configure Emacs so there's no
> surprise this disappeared in your case.
I don't even need to rerun configure. I just added a debug fprintf to
pop_up_menu(), rebuilt Emacs, and the problem vanished.
I still have the binary that fails. On a hunch, I added a breakpoint at
the start of pop_up_menu(). When the breakpoint triggered, I checked
the value of lucid__menu_grab_keyboard. gdb says
(gdb) print lucid__menu_grab_keyboard
$2 = false
Yet *Help* says that the value of lucid--menu_grab_keyboard is t.
If I do
M-: (setq lucid--menu_grab_keyboard t)
and press F10, gdb says lucid__menu_grab_keyboard is still false.
I did a little more poking around with gdb and found that
lucid__menu_grab_keyboard moves around inside "globals".
Broken binary:
(gdb) print &globals.f_lucid__menu_grab_keyboard
$3 = (_Bool *) 0x555555d54a98 <globals+4152>
Working binary:
(gdb) print &globals.f_lucid__menu_grab_keyboard
$2 = (_Bool *) 0x555555d54ad0 <globals+4208>
This strikes me as more than a little odd. Given that all I did was
add a couple fprintfs, I'd expect the layout of "globals" to stay the
same.
If I look at globals+4208 in the broken binary, it does have the value
true.
(gdb) print &globals.f_lucid__menu_grab_keyboard
$1 = (_Bool *) 0x555555d54a98 <globals+4152>
(gdb) print 4208-4152
$2 = 56
(gdb) print 0x555555d54a98 + 56
$3 = 93825000622800
(gdb) print /x 56
$4 = 0x38
(gdb) print *(_Bool *) 93825000622800
$5 = true
Not sure what to make of that. I'm reluctant to conclude that there's a
toolchain problem. But FWIW, I'm building on Debian 11 (amd64) and "gcc
--version" reports "gcc (Debian 10.2.1-6) 10.2.1 20210110". emacs-29
branch (git hash a14821d615, plus some changes to MH-E).
mike
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Thu, 12 Jan 2023 01:23:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Mike Kupfer <kupfer <at> rawbw.com> writes:
> Po Lu wrote:
>
>> Mike Kupfer <kupfer <at> rawbw.com> writes:
>>
>> > I don't even need to rerun configure. I just added a debug fprintf to
>> > pop_up_menu(), rebuilt Emacs, and the problem vanished.
>>
>> Would you please send me the two different binaries?
>
> Hmm, the binary is 36MB (and the pdmp file is 12MB). That's too big, I
> think, to send by email.
>
>> I have a hunch. If you touch globals.h in src, does it result in files
>> under the lwlib directory being rebuilt?
>
> Good call. Nothing in lwlib gets rebuilt:
>
> -----8<-----8<-----
> -*- mode: compilation; default-directory: "~/src/emacs-git/" -*-
> Compilation started at Wed Jan 11 12:33:43
>
> make
> make actual-all || make advice-on-failure make-target=all exit-status=$?
> make[1]: Entering directory '/home/kupfer/src/emacs-git'
> make -C lib all
> make[2]: Entering directory '/home/kupfer/src/emacs-git/lib'
> make[2]: Nothing to be done for 'all'.
> make[2]: Leaving directory '/home/kupfer/src/emacs-git/lib'
> make -C lib-src all
> make[2]: Entering directory '/home/kupfer/src/emacs-git/lib-src'
> make[2]: Nothing to be done for 'all'.
> make[2]: Leaving directory '/home/kupfer/src/emacs-git/lib-src'
> make -C src BIN_DESTDIR=''/usr/new/bin/'' \
> ELN_DESTDIR='/usr/new/lib/emacs/29.0.60/' all
> make[2]: Entering directory '/home/kupfer/src/emacs-git/src'
> make -C ../lwlib/ liblw.a
> make[3]: Entering directory '/home/kupfer/src/emacs-git/lwlib'
> make[3]: 'liblw.a' is up to date.
> make[3]: Leaving directory '/home/kupfer/src/emacs-git/lwlib'
> CC dispnew.o
> CC frame.o
> CC scroll.o
> CC xdisp.o
> CC menu.o
> CC xmenu.o
> ...
> ----->8----->8-----
I guess that's the problem then. Emacs is using lwlib compiled with an
out of date libgnu.a.
So what I'd like to do is to remove the reference to
`lucid__menu_grab_keyboard' in the first place, and replace it with a
define. Any objections?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Thu, 12 Jan 2023 03:45:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Mike Kupfer <kupfer <at> rawbw.com> writes:
> Would this also involve removing f_lucid__menu_grab_keyboard from the
> emacs_globals struct and removing the corresponding DEFVAR_BOOL in
> keyboard.c? pop_up_menu() is the only place lucid__menu_grab_keyboard
> is used.
Ah, globals.h is automatically generated by make-docfile from the
various *.[cm] files during the build process. This is why it is very
easy to end up with subtle differences in globals.h. Especially in
lwlib, which has no business accessing Lisp anyway.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Thu, 12 Jan 2023 08:05:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 58771 <at> debbugs.gnu.org (full text, mbox):
> Cc: Feng Shu <tumashu <at> 163.com>, Stephen Berman <stephen.berman <at> gmx.net>,
> 58771 <at> debbugs.gnu.org, Visuwesh <visuweshm <at> gmail.com>
> Date: Thu, 12 Jan 2023 11:44:17 +0800
> From: Po Lu via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> Mike Kupfer <kupfer <at> rawbw.com> writes:
>
> > Would this also involve removing f_lucid__menu_grab_keyboard from the
> > emacs_globals struct and removing the corresponding DEFVAR_BOOL in
> > keyboard.c? pop_up_menu() is the only place lucid__menu_grab_keyboard
> > is used.
>
> Ah, globals.h is automatically generated by make-docfile from the
> various *.[cm] files during the build process. This is why it is very
> easy to end up with subtle differences in globals.h. Especially in
> lwlib, which has no business accessing Lisp anyway.
I don't think I understand the problem you are trying to fix, and the
messages recorded by debbugs don't help (maybe some were lost or sent
in private email?). Can you explain the relevance of globals.h to the
subject of this bug report?
Dependencies for header files are supposed to be recorded
automatically in the deps subdirectory, as part of compilation of C
source files, so how come something is not recompiled when its
dependency header file changes? And I have _never_ seen any problems
with how we generate globals.h or detect that its contents changed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Thu, 12 Jan 2023 08:41:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Po Lu wrote:
> Mike Kupfer <kupfer <at> rawbw.com> writes:
>
> > I don't even need to rerun configure. I just added a debug fprintf to
> > pop_up_menu(), rebuilt Emacs, and the problem vanished.
>
> Would you please send me the two different binaries?
Hmm, the binary is 36MB (and the pdmp file is 12MB). That's too big, I
think, to send by email.
> I have a hunch. If you touch globals.h in src, does it result in files
> under the lwlib directory being rebuilt?
Good call. Nothing in lwlib gets rebuilt:
-----8<-----8<-----
-*- mode: compilation; default-directory: "~/src/emacs-git/" -*-
Compilation started at Wed Jan 11 12:33:43
make
make actual-all || make advice-on-failure make-target=all exit-status=$?
make[1]: Entering directory '/home/kupfer/src/emacs-git'
make -C lib all
make[2]: Entering directory '/home/kupfer/src/emacs-git/lib'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/kupfer/src/emacs-git/lib'
make -C lib-src all
make[2]: Entering directory '/home/kupfer/src/emacs-git/lib-src'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/kupfer/src/emacs-git/lib-src'
make -C src BIN_DESTDIR=''/usr/new/bin/'' \
ELN_DESTDIR='/usr/new/lib/emacs/29.0.60/' all
make[2]: Entering directory '/home/kupfer/src/emacs-git/src'
make -C ../lwlib/ liblw.a
make[3]: Entering directory '/home/kupfer/src/emacs-git/lwlib'
make[3]: 'liblw.a' is up to date.
make[3]: Leaving directory '/home/kupfer/src/emacs-git/lwlib'
CC dispnew.o
CC frame.o
CC scroll.o
CC xdisp.o
CC menu.o
CC xmenu.o
...
----->8----->8-----
mike
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Thu, 12 Jan 2023 08:41:03 GMT)
Full text and
rfc822 format available.
Message #62 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Po Lu wrote:
> So what I'd like to do is to remove the reference to
> `lucid__menu_grab_keyboard' in the first place, and replace it with a
> define. Any objections?
Would this also involve removing f_lucid__menu_grab_keyboard from the
emacs_globals struct and removing the corresponding DEFVAR_BOOL in
keyboard.c? pop_up_menu() is the only place lucid__menu_grab_keyboard
is used.
mike
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Thu, 12 Jan 2023 08:56:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 58771 <at> debbugs.gnu.org (full text, mbox):
> Cc: Feng Shu <tumashu <at> 163.com>, Stephen Berman <stephen.berman <at> gmx.net>,
> 58771 <at> debbugs.gnu.org, Visuwesh <visuweshm <at> gmail.com>
> From: Mike Kupfer <kupfer <at> rawbw.com>
> Date: Wed, 11 Jan 2023 12:44:40 -0800
>
> Po Lu wrote:
>
> > I have a hunch. If you touch globals.h in src, does it result in files
> > under the lwlib directory being rebuilt?
>
> Good call. Nothing in lwlib gets rebuilt:
Which files in lwlib should be rebuilt? And what do you see in
lwlib/deps/ for those files?
Could it be that the root cause for this is that ALLOBJS is not
defined in lwlib/Makefile.in? And also the fact that lwlib/deps.mk is
outdated?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Thu, 12 Jan 2023 10:35:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: Feng Shu <tumashu <at> 163.com>, Stephen Berman <stephen.berman <at> gmx.net>,
>> 58771 <at> debbugs.gnu.org, Visuwesh <visuweshm <at> gmail.com>
>> Date: Thu, 12 Jan 2023 11:44:17 +0800
>> From: Po Lu via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> Mike Kupfer <kupfer <at> rawbw.com> writes:
>>
>> > Would this also involve removing f_lucid__menu_grab_keyboard from the
>> > emacs_globals struct and removing the corresponding DEFVAR_BOOL in
>> > keyboard.c? pop_up_menu() is the only place lucid__menu_grab_keyboard
>> > is used.
>>
>> Ah, globals.h is automatically generated by make-docfile from the
>> various *.[cm] files during the build process. This is why it is very
>> easy to end up with subtle differences in globals.h. Especially in
>> lwlib, which has no business accessing Lisp anyway.
>
> I don't think I understand the problem you are trying to fix, and the
> messages recorded by debbugs don't help (maybe some were lost or sent
> in private email?). Can you explain the relevance of globals.h to the
> subject of this bug report?
>
> Dependencies for header files are supposed to be recorded
> automatically in the deps subdirectory, as part of compilation of C
> source files, so how come something is not recompiled when its
> dependency header file changes? And I have _never_ seen any problems
> with how we generate globals.h or detect that its contents changed.
I thought only src had the AUTO_DEPENDS blurb. Seems that I'm wrong.
Mike, what are the contents of lwlib/deps/xlwmenu.d on your system?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Fri, 13 Jan 2023 07:20:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Mike Kupfer <kupfer <at> rawbw.com> writes:
> Po Lu wrote:
>
>> Mike, what are the contents of lwlib/deps/xlwmenu.d on your system?
>
> I've attached the version from my most recent backup. Its mtime
> predates when I built the broken binary. The contents are the same as
> what's currently in my build tree.
>
> mike
>
> xlwmenu.o: xlwmenu.c ../src/config.h ../src/conf_post.h ../src/lisp.h \
> ../lib/alloca.h ../lib/string.h ../lib/inttypes.h ../lib/attribute.h \
> ../lib/intprops.h ../lib/intprops-internal.h ../lib/verify.h \
> ../src/globals.h ../src/comp.h ../src/dynlib.h ../src/thread.h \
> ../src/regex-emacs.h ../src/lisp.h ../src/sysselect.h \
> ../lib/sys/select.h ../src/systhread.h ../lib/stdio.h xlwmenuP.h \
> xlwmenu.h lwlib.h lwlib-widget.h ../src/lisp.h lwlib-utils.h \
> ../src/xterm.h ../src/dispextern.h ../src/character.h ../lib/c-strcase.h \
> ../src/fontset.h ../src/termhooks.h ../src/systime.h ../lib/timespec.h \
> ../lib/arg-nonnull.h ../src/bitmaps/gray.xbm
> ../src/config.h:
> ../src/conf_post.h:
> ../src/lisp.h:
> ../lib/alloca.h:
> ../lib/string.h:
> ../lib/inttypes.h:
> ../lib/attribute.h:
> ../lib/intprops.h:
> ../lib/intprops-internal.h:
> ../lib/verify.h:
> ../src/globals.h:
> ../src/comp.h:
> ../src/dynlib.h:
> ../src/thread.h:
> ../src/regex-emacs.h:
> ../src/lisp.h:
> ../src/sysselect.h:
> ../lib/sys/select.h:
> ../src/systhread.h:
> ../lib/stdio.h:
> xlwmenuP.h:
> xlwmenu.h:
> lwlib.h:
> lwlib-widget.h:
> ../src/lisp.h:
> lwlib-utils.h:
> ../src/xterm.h:
> ../src/dispextern.h:
> ../src/character.h:
> ../lib/c-strcase.h:
> ../src/fontset.h:
> ../src/termhooks.h:
> ../src/systime.h:
> ../lib/timespec.h:
> ../lib/arg-nonnull.h:
> ../src/bitmaps/gray.xbm:
Here xlwmenu.o does depend on globals.h. But I think lwlib is being
built before make-docfile is run, so we will need to make it depend on
make-docfile being run.
Does anyone have a better idea?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Fri, 13 Jan 2023 07:33:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 58771 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, tumashu <at> 163.com, stephen.berman <at> gmx.net,
> 58771 <at> debbugs.gnu.org, visuweshm <at> gmail.com
> Date: Fri, 13 Jan 2023 15:19:31 +0800
>
> Mike Kupfer <kupfer <at> rawbw.com> writes:
> > Could it be that the root cause for this is that ALLOBJS is not
> > defined in lwlib/Makefile.in?
>
> I think you've identified the problem. I tried hacking lwlib/Makefile
> as follows:
>
> --- Makefile~ 2022-12-29 17:42:05.288751298 -0800
> +++ Makefile 2023-01-12 21:08:24.717146041 -0800
> @@ -57,6 +57,8 @@
>
> OBJS = lwlib.o $(TOOLKIT_OBJS) lwlib-utils.o
>
> +ALLOBJS = $(OBJS)
> +
> -include ${top_builddir}/src/verbose.mk
>
> AUTO_DEPEND = yes
>
> Now, when I touch src/globals.h and run "make", xlwmenu.o does get
> rebuilt.
> > Po Lu wrote:
> >
> >> Mike, what are the contents of lwlib/deps/xlwmenu.d on your system?
> >
> > I've attached the version from my most recent backup. Its mtime
> > predates when I built the broken binary. The contents are the same as
> > what's currently in my build tree.
> >
> > mike
> >
> > xlwmenu.o: xlwmenu.c ../src/config.h ../src/conf_post.h ../src/lisp.h \
> > ../lib/alloca.h ../lib/string.h ../lib/inttypes.h ../lib/attribute.h \
> > ../lib/intprops.h ../lib/intprops-internal.h ../lib/verify.h \
> > ../src/globals.h ../src/comp.h ../src/dynlib.h ../src/thread.h \
> > ../src/regex-emacs.h ../src/lisp.h ../src/sysselect.h \
> > ../lib/sys/select.h ../src/systhread.h ../lib/stdio.h xlwmenuP.h \
> > xlwmenu.h lwlib.h lwlib-widget.h ../src/lisp.h lwlib-utils.h \
> > ../src/xterm.h ../src/dispextern.h ../src/character.h ../lib/c-strcase.h \
> > ../src/fontset.h ../src/termhooks.h ../src/systime.h ../lib/timespec.h \
> > ../lib/arg-nonnull.h ../src/bitmaps/gray.xbm
> > ../src/config.h:
> > ../src/conf_post.h:
> > ../src/lisp.h:
> > ../lib/alloca.h:
> > ../lib/string.h:
> > ../lib/inttypes.h:
> > ../lib/attribute.h:
> > ../lib/intprops.h:
> > ../lib/intprops-internal.h:
> > ../lib/verify.h:
> > ../src/globals.h:
> > ../src/comp.h:
> > ../src/dynlib.h:
> > ../src/thread.h:
> > ../src/regex-emacs.h:
> > ../src/lisp.h:
> > ../src/sysselect.h:
> > ../lib/sys/select.h:
> > ../src/systhread.h:
> > ../lib/stdio.h:
> > xlwmenuP.h:
> > xlwmenu.h:
> > lwlib.h:
> > lwlib-widget.h:
> > ../src/lisp.h:
> > lwlib-utils.h:
> > ../src/xterm.h:
> > ../src/dispextern.h:
> > ../src/character.h:
> > ../lib/c-strcase.h:
> > ../src/fontset.h:
> > ../src/termhooks.h:
> > ../src/systime.h:
> > ../lib/timespec.h:
> > ../lib/arg-nonnull.h:
> > ../src/bitmaps/gray.xbm:
>
> Here xlwmenu.o does depend on globals.h. But I think lwlib is being
> built before make-docfile is run, so we will need to make it depend on
> make-docfile being run.
>
> Does anyone have a better idea?
I think the dependency is the correct idea, yes.
Paul, is it true that lwlib/Makefile.in needs to define ALLOBJS for
the deps stuff to work correctly?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Fri, 13 Jan 2023 08:28:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 58771 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Po Lu wrote:
> Mike, what are the contents of lwlib/deps/xlwmenu.d on your system?
I've attached the version from my most recent backup. Its mtime
predates when I built the broken binary. The contents are the same as
what's currently in my build tree.
mike
[xlwmenu.d (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Fri, 13 Jan 2023 08:28:03 GMT)
Full text and
rfc822 format available.
Message #80 received at 58771 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> > Cc: Feng Shu <tumashu <at> 163.com>, Stephen Berman <stephen.berman <at> gmx.net>,
> > 58771 <at> debbugs.gnu.org, Visuwesh <visuweshm <at> gmail.com>
> > From: Mike Kupfer <kupfer <at> rawbw.com>
> > Date: Wed, 11 Jan 2023 12:44:40 -0800
> >
> > Po Lu wrote:
> >
> > > I have a hunch. If you touch globals.h in src, does it result in files
> > > under the lwlib directory being rebuilt?
> >
> > Good call. Nothing in lwlib gets rebuilt:
>
> Which files in lwlib should be rebuilt? And what do you see in
> lwlib/deps/ for those files?
We're particularly interested in seeing that lwlib/xlwmenu.o get rebuilt
when globals.h changes. pop_up_menu() will not call XtGrabKeyboard() or
XtSetKeyboardFocus() if globals.f_lucid__menu_grab_keyboard is false.
And that seems to be what's behind all these intermittent problems with
Lucid popup menus.
lwlib/deps/xlwmenu.d looks okay to me, as it has:
xlwmenu.o: xlwmenu.c ../src/config.h ../src/conf_post.h ../src/lisp.h \
../lib/alloca.h ../lib/string.h ../lib/inttypes.h ../lib/attribute.h \
../lib/intprops.h ../lib/intprops-internal.h ../lib/verify.h \
../src/globals.h ../src/comp.h ../src/dynlib.h ../src/thread.h \
../src/regex-emacs.h ../src/lisp.h ../src/sysselect.h \
../lib/sys/select.h ../src/systhread.h ../lib/stdio.h xlwmenuP.h \
> Could it be that the root cause for this is that ALLOBJS is not
> defined in lwlib/Makefile.in?
I think you've identified the problem. I tried hacking lwlib/Makefile
as follows:
--- Makefile~ 2022-12-29 17:42:05.288751298 -0800
+++ Makefile 2023-01-12 21:08:24.717146041 -0800
@@ -57,6 +57,8 @@
OBJS = lwlib.o $(TOOLKIT_OBJS) lwlib-utils.o
+ALLOBJS = $(OBJS)
+
-include ${top_builddir}/src/verbose.mk
AUTO_DEPEND = yes
Now, when I touch src/globals.h and run "make", xlwmenu.o does get
rebuilt.
...
make[2]: Entering directory '/home/kupfer/src/emacs-git/src'
make -C ../lwlib/ liblw.a
make[3]: Entering directory '/home/kupfer/src/emacs-git/lwlib'
CC lwlib.o
CC lwlib-Xlw.o
CC xlwmenu.o
CC lwlib-Xaw.o
CC lwlib-utils.o
GEN liblw.a
make[3]: Leaving directory '/home/kupfer/src/emacs-git/lwlib'
...
mike
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Fri, 13 Jan 2023 11:18:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 58771 <at> debbugs.gnu.org (full text, mbox):
I remember having same problem, and that problem was cleared after
clean or make bootstrap.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Sat, 14 Jan 2023 02:29:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 58771 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2023-01-12 23:32, Eli Zaretskii wrote:
> Paul, is it true that lwlib/Makefile.in needs to define ALLOBJS for
> the deps stuff to work correctly?
Although that should work, the attached proposed emacs-29 fix is a bit
cleaner.
I've been bitten by the bug myself but never found the time to report or
fix it until now. Although the bug is not a regression its symptoms are
mysterious and the patch is simple and obvious. Your call as to which
branch it should go into.
[0001-Fix-dependency-bug-when-building-lwlib.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#58771; Package
emacs.
(Sat, 14 Jan 2023 07:27:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 58771 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 13 Jan 2023 18:28:23 -0800
> Cc: kupfer <at> rawbw.com, tumashu <at> 163.com, stephen.berman <at> gmx.net,
> 58771 <at> debbugs.gnu.org, visuweshm <at> gmail.com, Po Lu <luangruo <at> yahoo.com>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2023-01-12 23:32, Eli Zaretskii wrote:
> > Paul, is it true that lwlib/Makefile.in needs to define ALLOBJS for
> > the deps stuff to work correctly?
>
> Although that should work, the attached proposed emacs-29 fix is a bit
> cleaner.
>
> I've been bitten by the bug myself but never found the time to report or
> fix it until now. Although the bug is not a regression its symptoms are
> mysterious and the patch is simple and obvious. Your call as to which
> branch it should go into.
Please install on emacs-29, and thanks.
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Sat, 14 Jan 2023 07:49:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Feng Shu <tumashu <at> 163.com>:
bug acknowledged by developer.
(Sat, 14 Jan 2023 07:49:03 GMT)
Full text and
rfc822 format available.
Message #96 received at 58771-done <at> debbugs.gnu.org (full text, mbox):
On 2023-01-13 23:25, Eli Zaretskii wrote:
> Please install on emacs-29, and thanks.
Done. I'm closing bug#57320, bug#57518, bug#58711, and bug#59733.
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Sat, 14 Jan 2023 07:49:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Stefan <monnier <at> iro.umontreal.ca>:
bug acknowledged by developer.
(Sat, 14 Jan 2023 07:49:03 GMT)
Full text and
rfc822 format available.
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Sat, 14 Jan 2023 07:49:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Jean Louis <bugs <at> gnu.support>:
bug acknowledged by developer.
(Sat, 14 Jan 2023 07:49:03 GMT)
Full text and
rfc822 format available.
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Sat, 14 Jan 2023 07:49:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Madhu <enometh <at> meer.net>:
bug acknowledged by developer.
(Sat, 14 Jan 2023 07:49:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 11 Feb 2023 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 68 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.