GNU bug report logs -
#39181
27.0.50; [PATCH] Allow users to store & restore gdb-mi layout
Previous Next
Reported by: Yuan Fu <casouri <at> gmail.com>
Date: Sat, 18 Jan 2020 20:58:02 UTC
Severity: normal
Tags: patch
Found in version 27.0.50
Done: Yuan Fu <casouri <at> gmail.com>
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 39181 in the body.
You can then email your comments to 39181 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#39181; Package
emacs.
(Sat, 18 Jan 2020 20:58:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Yuan Fu <casouri <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 18 Jan 2020 20:58:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Right now if a user wants to use gdb with many windows, the only layout option is the default 6-window layout. This patch allows a user to save her own layout, and use this layout in gdb-mi sessions. I also included my layout (`default-rearrange`) Maybe we can even ship with some default layouts that a user can choose from?
[default-rearrange.png (image/png, inline)]
[Message part 3 (text/plain, inline)]
[store-window-new.patch (application/octet-stream, attachment)]
[default-rearrange (application/octet-stream, attachment)]
[Message part 6 (text/plain, inline)]
In GNU Emacs 27.0.50 (build 3, x86_64-apple-darwin19.0.0, NS appkit-1894.10 Version 10.15.1 (Build 19B88))
of 2019-11-30 built on missSilver
Repository revision: e2828795d73637577c7726965974a047fe2d7119
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1894
System Description: Mac OS X 10.15.2
Recent messages:
Checking 71 files in /Users/yuan/attic/emacs/lisp/erc...
Checking 34 files in /Users/yuan/attic/emacs/lisp/emulation...
Checking 180 files in /Users/yuan/attic/emacs/lisp/emacs-lisp...
Checking 24 files in /Users/yuan/attic/emacs/lisp/cedet...
Checking 59 files in /Users/yuan/attic/emacs/lisp/calendar...
Checking 87 files in /Users/yuan/attic/emacs/lisp/calc...
Checking 113 files in /Users/yuan/attic/emacs/lisp/obsolete...
Checking for load-path shadows...done
Auto-saving...
Buffer *unsent mail to bug-gnu-emacs <at> gnu.org*<2> modified; kill anyway? (y or n) y
Configured using:
'configure --with-modules --with-pdumper=yes
--oldincludedir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/libxml2/'
Configured features:
NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES
THREADS PDUMPER LCMS2
Important settings:
value of $LC_CTYPE: UTF-8
value of $LANG: en_CN.UTF-8
locale-coding-system: utf-8-unix
Major mode: Emacs-Lisp
Minor modes in effect:
magit-todos-mode: t
bug-reference-prog-mode: t
desktop-save-mode: t
ghelp-global-minor-mode: t
minibuffer-electric-default-mode: t
flymake-mode: t
global-magit-file-mode: t
magit-file-mode: t
global-git-commit-mode: t
async-bytecomp-package-mode: t
shell-dirtrack-mode: t
flyspell-mode: t
outshine-mode: t
ws-butler-global-mode: t
ws-butler-mode: t
minions-mode: t
eyebrowse-mode: t
savehist-mode: t
global-hl-todo-mode: t
hl-todo-mode: t
global-highlight-parentheses-mode: t
highlight-parentheses-mode: t
rainbow-delimiters-mode: t
global-undo-tree-mode: t
undo-tree-mode: t
electric-pair-mode: t
winner-mode: t
aggressive-indent-mode: t
ivy-prescient-mode: t
prescient-persist-mode: t
recentf-mode: t
which-key-mode: t
general-override-mode: t
outline-minor-mode: t
ivy-mode: t
company-mode: t
override-global-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-quote-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
transient-mark-mode: t
hs-minor-mode: t
Load-path shadows:
/Users/yuan/.emacs.d/ranch/winman/windman hides /Users/yuan/.emacs.d/ranch/windman/windman
/Users/yuan/.emacs.d/ranch/nerd-font/test/test-helper hides /Users/yuan/.emacs.d/ranch/doom-themes/test/test-helper
/Users/yuan/.emacs.d/ranch/julia-mode/julia-mode hides /Users/yuan/.emacs.d/package/julia-mode-20190813.1326/julia-mode
/Users/yuan/.emacs.d/ranch/julia-mode/julia-latexsubs hides /Users/yuan/.emacs.d/package/julia-mode-20190813.1326/julia-latexsubs
/Users/yuan/.emacs.d/ranch/matlab-emacs/mlint hides /Users/yuan/.emacs.d/package/matlab-mode-20180928.1526/mlint
/Users/yuan/.emacs.d/ranch/matlab-emacs/company-matlab-shell hides /Users/yuan/.emacs.d/package/matlab-mode-20180928.1526/company-matlab-shell
/Users/yuan/.emacs.d/ranch/matlab-emacs/linemark hides /Users/yuan/.emacs.d/package/matlab-mode-20180928.1526/linemark
/Users/yuan/.emacs.d/ranch/matlab-emacs/semanticdb-matlab hides /Users/yuan/.emacs.d/package/matlab-mode-20180928.1526/semanticdb-matlab
/Users/yuan/.emacs.d/ranch/matlab-emacs/semantic-matlab hides /Users/yuan/.emacs.d/package/matlab-mode-20180928.1526/semantic-matlab
/Users/yuan/.emacs.d/ranch/matlab-emacs/srecode-matlab hides /Users/yuan/.emacs.d/package/matlab-mode-20180928.1526/srecode-matlab
/Users/yuan/.emacs.d/ranch/matlab-emacs/matlab hides /Users/yuan/.emacs.d/package/matlab-mode-20180928.1526/matlab
/Users/yuan/.emacs.d/ranch/matlab-emacs/cedet-matlab hides /Users/yuan/.emacs.d/package/matlab-mode-20180928.1526/cedet-matlab
/Users/yuan/.emacs.d/ranch/matlab-emacs/tlc hides /Users/yuan/.emacs.d/package/matlab-mode-20180928.1526/tlc
/Users/yuan/.emacs.d/ranch/matlab-emacs/matlab-publish hides /Users/yuan/.emacs.d/package/matlab-mode-20180928.1526/matlab-publish
/Users/yuan/.emacs.d/ranch/matlab-emacs/matlab-mode-pkg hides /Users/yuan/.emacs.d/package/matlab-mode-20180928.1526/matlab-mode-pkg
/Users/yuan/.emacs.d/package/faceup-20170925.1946/faceup hides /Users/yuan/attic/emacs/lisp/emacs-lisp/faceup
Features:
(magit-todos pcre2el rxt re-builder grep checkdoc lisp-mnt bug-reference
vc-mtn vc-hg ffap tramp tramp-loaddefs trampver tramp-integration
files-x tramp-compat parse-time iso8601 ls-lisp shadow sort mail-extr
emacsbug sendmail vc-git vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs vc
vc-dispatcher magit-bookmark bookmark company-oddmuse company-keywords
company-etags etags fileloop company-gtags company-dabbrev-code
company-dabbrev company-files company-capf company-cmake company-xcode
company-clang company-semantic company-eclim company-template
company-bbdb hideshow desktop frameset trivial-copy ghelp-eglot
ghelp-helpful ghelp-builtin ghelp cus-edit cus-start cus-load
luna-publish utility pause luna-general-config minibuf-eldef eglot array
jsonrpc ert pp ewoc debug flymake-proc flymake warnings url-util
magit-submodule magit-obsolete 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 magit-diff
smerge-mode diff-mode magit-core magit-autorevert autorevert filenotify
magit-margin magit-transient magit-process magit-mode transient
git-commit magit-git magit-section magit-utils crm log-edit message rmc
puny rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr
mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log with-editor
async-bytecomp async shell server flyspell ispell outshine
outshine-org-cmds outorg isolate inline expand-region
text-mode-expansions the-org-mode-expansions er-basic-expansions
thingatpt expand-region-core expand-region-custom ws-butler minions
eyebrowse savehist buffer-move windmove hl-todo highlight-parentheses
rainbow-delimiters doom-cyberpunk-theme undo-tree diff
doom-one-light-theme elec-pair winner doom-themes doom-themes-base
windman aggressive-indent find-char ivy-prescient prescient recentf-ext
recentf tree-widget wid-edit which-key general helpful imenu trace
edebug backtrace info-look f dash-functional help-fns radix-tree
elisp-refs s loop dash org-element avl-tree generator org advice
org-macro org-footnote org-pcomplete pcomplete org-list org-faces
org-entities time-date noutline outline org-version ob-emacs-lisp ob
ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint
ob-core ob-eval org-compat org-macs org-loaddefs format-spec find-func
cal-menu calendar cal-loaddefs counsel xdg xref project dired
dired-loaddefs compile comint ansi-color swiper cl-extra help-mode ivy
delsel ring colir color ivy-overlay company edmacro kmacro pcase
use-package use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key easy-mmode use-package-core finder-inf
tex-site info cowboy package easymenu browse-url url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars cl-loaddefs cl-lib lunary
lunary-ui luna-f rx seq byte-opt gv bytecomp byte-compile cconv tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
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 charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads kqueue cocoa ns
lcms2 multi-tty make-network-process emacs)
Memory information:
((conses 16 198008 22858)
(symbols 48 9376 47)
(strings 32 38332 2464)
(string-bytes 1 1117094)
(vectors 16 24687)
(vector-slots 8 290292 27848)
(floats 8 516 434)
(intervals 56 14668 1334)
(buffers 1000 28))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Fri, 31 Jan 2020 10:15:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 39181 <at> debbugs.gnu.org (full text, mbox):
> From: Yuan Fu <casouri <at> gmail.com>
> Date: Sat, 18 Jan 2020 15:57:32 -0500
>
> Right now if a user wants to use gdb with many windows, the only layout option is the default 6-window layout.
This is not entirely accurate. The user could start "M-x gdb"
normally, then selectively display some of the other windows via the
Gud->GDB-Windows or Gud->GDB-Frames menus.
> This patch allows a user to save her own layout, and use this layout in gdb-mi sessions.
I'd prefer to extend the existing capability by adding a feature, both
in the menu bar and as a command, to save and restore the window
configuration set via the above-mentioned existing facilities. WDYT?
Please also fix all the minor nits I mentioned in review of your
previous patches: quoting, 2 blanks between sentences, complete
sentences in comments and log messages, etc. Last, but not least,
please don't break a single patch into several separate ones, unless
each one of the separate patches can make sense if applied on its own.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Sun, 02 Feb 2020 14:23:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 39181 <at> debbugs.gnu.org (full text, mbox):
> On Jan 31, 2020, at 5:13 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Sat, 18 Jan 2020 15:57:32 -0500
>>
>> Right now if a user wants to use gdb with many windows, the only layout option is the default 6-window layout.
>
> This is not entirely accurate. The user could start "M-x gdb"
> normally, then selectively display some of the other windows via the
> Gud->GDB-Windows or Gud->GDB-Frames menus.
>
>> This patch allows a user to save her own layout, and use this layout in gdb-mi sessions.
>
> I'd prefer to extend the existing capability by adding a feature, both
> in the menu bar and as a command, to save and restore the window
> configuration set via the above-mentioned existing facilities. WDYT?
Thanks makes sense; will do. I’ll put them in GUD windows menu.
> Please also fix all the minor nits I mentioned in review of your
> previous patches: quoting, 2 blanks between sentences, complete
> sentences in comments and log messages, etc. Last, but not least,
> please don't break a single patch into several separate ones, unless
> each one of the separate patches can make sense if applied on its own.
Will do.
Yuan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Fri, 07 Feb 2020 22:29:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Here is the new patch. New-store-window.patch contains the one allowing user store/restore window config. I added the two menu items. And I changed the name to gdb-save-window-layout and gdb-load-window-layout because I think they are shorter and easier to understand; WDYT?
Restore-after-quit.patch contain the patch which restores the original window configuration after gdb quits. Maybe I should send it as a separate patch?
BTW, It used to be three commits, I merged the first one on window.el into new-restore-window.patch.
Yuan
[new-store-window.patch (application/octet-stream, attachment)]
[restore-after-quit.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Mon, 10 Feb 2020 04:57:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I updated my patch according to your suggestion in the memory patch.
Yuan
[restore-after-quit.patch (application/octet-stream, attachment)]
[new-store-window.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Sat, 15 Feb 2020 08:09:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 39181 <at> debbugs.gnu.org (full text, mbox):
> From: Yuan Fu <casouri <at> gmail.com>
> Date: Sun, 9 Feb 2020 23:56:47 -0500
> Cc: 39181 <at> debbugs.gnu.org
>
> I updated my patch according to your suggestion in the memory patch.
Thanks.
Martin, any comments?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Sat, 15 Feb 2020 09:56:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 39181 <at> debbugs.gnu.org (full text, mbox):
> Martin, any comments?
IMHO "restoring the previous window layout when gdb quits" should be
opt-in (or at least opt-out). Maybe it also should restore the layout
only when 'gdb-many-windows' is non-nil, so we'd have the three option
values nil, t, and if-gdb-many-windows (in a menu entry).
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Sat, 15 Feb 2020 10:20:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 39181 <at> debbugs.gnu.org (full text, mbox):
> Cc: 39181 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sat, 15 Feb 2020 10:55:34 +0100
>
> > Martin, any comments?
>
> IMHO "restoring the previous window layout when gdb quits" should be
> opt-in (or at least opt-out). Maybe it also should restore the layout
> only when 'gdb-many-windows' is non-nil, so we'd have the three option
> values nil, t, and if-gdb-many-windows (in a menu entry).
I had the same thoughts myself, and I agree on both counts.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Sat, 15 Feb 2020 20:38:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On Feb 15, 2020, at 5:19 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> Cc: 39181 <at> debbugs.gnu.org
>> From: martin rudalics <rudalics <at> gmx.at>
>> Date: Sat, 15 Feb 2020 10:55:34 +0100
>>
>>> Martin, any comments?
>>
>> IMHO "restoring the previous window layout when gdb quits" should be
>> opt-in (or at least opt-out). Maybe it also should restore the layout
>> only when 'gdb-many-windows' is non-nil, so we'd have the three option
>> values nil, t, and if-gdb-many-windows (in a menu entry).
>
> I had the same thoughts myself, and I agree on both counts.
I agree. I made it into a custom variable with choices, is that what you mean by menu entry?
Yuan
[Message part 2 (text/html, inline)]
[restore-after-quit-new.patch (application/octet-stream, attachment)]
[Message part 4 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Sun, 16 Feb 2020 10:01:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 39181 <at> debbugs.gnu.org (full text, mbox):
> I agree. I made it into a custom variable with choices,
That's the first part of what I meant.
> is that what you mean by menu entry?
The menu entry could be written on top of the 'defcustom' and appear as
a toggle somewhere near the "Restore Window Layout" menu entry. Also we
should explain the differences between that entry and your new option
since otherwise users might get confused.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Tue, 03 Mar 2020 23:42:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Sorry for the delay, I missed the mail and was waiting for your reply. I added a toggle button in the menu with help echos. How does it look? Since there are more than two options, I make the button to toggle between the two basic ones. Also I combined two patches into one.
Yuan
[new-window.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Wed, 04 Mar 2020 13:29:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 39181 <at> debbugs.gnu.org (full text, mbox):
Actually, it is more intuitive to _alwaya_ save the original window layout on startup and restore when quit depending on the toggle variable. Let me fix that tonight. Sorry for the fuzz.
Yuan
> 在 2020年3月3日，下午6:41，Yuan Fu <casouri <at> gmail.com> 写道：
>
> Sorry for the delay, I missed the mail and was waiting for your reply. I added a toggle button in the menu with help echos. How does it look? Since there are more than two options, I make the button to toggle between the two basic ones. Also I combined two patches into one.
>
> Yuan
>
>
> <new-window.patch>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Thu, 05 Mar 2020 06:13:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Here is the patch.
Yuan
[new-window.patch (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Thu, 05 Mar 2020 09:15:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 39181 <at> debbugs.gnu.org (full text, mbox):
> Here is the patch.
Thanks. It gets me here the following warnings when building on master
(sorry, I'm a complete ignorant of the 'cl-' snafu):
ELC progmodes/gdb-mi.elc
In toplevel form:
../../lisp/progmodes/gdb-mi.el:4738:1: Warning: Unused lexical variable
‘window-config’
In end of data:
../../lisp/progmodes/gdb-mi.el:5069:1: Warning: the following functions might
not be defined at runtime: cl-delete-if, cl-find-if, cl-mapcar
A few remarks:
+ "If non-nil, gdb loads this window layout file on startup.
+If not absolute, GDB will look under `gdb-window-layout-directory'."
We should settle in descriptions on whether we write gdb or GDB. Also,
"if not absolute" is too terse IMHO.
+ (define-key menu [load-layout] '("Load window layout" "Load GDB window layout from a file" . gdb-load-window-layout))
+ (define-key menu [save-layout] '("Save window layout" "Save current GDB window layout to a file" . gdb-save-window-layout))
I think we could omit the "window" in these which should allow us to,
instead of
+ '(menu-item "Restore window layout"
say
+ '(menu-item "Restore layout after quit"
so it becomes more clear that "load" and "save" act _immediately_ on the
current state while "restore" is a more general setting that becomes
effective only when the user quits. (Note also that in general we
cannot guarantee that menu tooltips are always shown on each and every
system where Emacs runs.)
Also, I would mention all four possible values of
'gdb-restore-window-layout-after-quit' (currently "toggle" indicates
that there are only two of them) like, for example, with the side values
for tool-bar mode.
+ "Return a buffer displaying source file or nil.
+
+The source file would be the most relevant file or the main file."
This is IMHO too terse in every respect. Neither "source file" nor
"main file" are canonical terms in the context of GDB so we should
explain here how they are set up (what is nil in this context?).
+E.g., locals buffer, registers buffer, but don't include the main
I would say "Function buffers are locals buffers, ...".
+(defun gdb--buffer-type (buffer)
+ "Return the buffer type of BUFFER or nil.
Maybe
"Return the type of BUFFER if it is a GDB function buffer."
would be better.
Thanks for your work on this, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Sat, 07 Mar 2020 18:11:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On Mar 5, 2020, at 4:14 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>
> > Here is the patch.
>
> Thanks. It gets me here the following warnings when building on master
> (sorry, I'm a complete ignorant of the 'cl-' snafu):
>
> ELC progmodes/gdb-mi.elc
>
> In toplevel form:
> ../../lisp/progmodes/gdb-mi.el:4738:1: Warning: Unused lexical variable
> ‘window-config’
>
> In end of data:
> ../../lisp/progmodes/gdb-mi.el:5069:1: Warning: the following functions might
> not be defined at runtime: cl-delete-if, cl-find-if, cl-mapcar
Fixed.
>
> A few remarks:
>
> + "If non-nil, gdb loads this window layout file on startup.
> +If not absolute, GDB will look under `gdb-window-layout-directory'."
>
> We should settle in descriptions on whether we write gdb or GDB. Also,
> "if not absolute" is too terse IMHO.
>
> + (define-key menu [load-layout] '("Load window layout" "Load GDB window layout from a file" . gdb-load-window-layout))
> + (define-key menu [save-layout] '("Save window layout" "Save current GDB window layout to a file" . gdb-save-window-layout))
>
> I think we could omit the "window" in these which should allow us to,
> instead of
>
> + '(menu-item "Restore window layout"
>
> say
>
> + '(menu-item "Restore layout after quit"
>
> so it becomes more clear that "load" and "save" act _immediately_ on the
> current state while "restore" is a more general setting that becomes
> effective only when the user quits. (Note also that in general we
> cannot guarantee that menu tooltips are always shown on each and every
> system where Emacs runs.)
>
> Also, I would mention all four possible values of
> 'gdb-restore-window-layout-after-quit' (currently "toggle" indicates
> that there are only two of them) like, for example, with the side values
> for tool-bar mode.
I removed “window” in their names. I mentioned the other possible values in the help echo, is that fine? Not sure where else I can put it.
>
> + "Return a buffer displaying source file or nil.
> +
> +The source file would be the most relevant file or the main file."
>
> This is IMHO too terse in every respect. Neither "source file" nor
> "main file" are canonical terms in the context of GDB so we should
> explain here how they are set up (what is nil in this context?).
>
> +E.g., locals buffer, registers buffer, but don't include the main
>
> I would say "Function buffers are locals buffers, ...".
>
> +(defun gdb--buffer-type (buffer)
> + "Return the buffer type of BUFFER or nil.
>
> Maybe
>
> "Return the type of BUFFER if it is a GDB function buffer."
>
> would be better.
I added some explanations. I hope they are clear now.
> Thanks for your work on this, Martin
Thanks for reviewing :-)
Here is the new patch.
Yuan
[new-window.patch (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Sat, 07 Mar 2020 19:08:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 39181 <at> debbugs.gnu.org (full text, mbox):
On Sat, 7 Mar 2020 13:09:53 -0500
Yuan Fu wrote:
[...]
> diff --git a/lisp/window.el b/lisp/window.el
> index bd825c09e1..229400966a 100644
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -278,6 +278,19 @@ with-displayed-buffer-window
> (funcall ,vquit-function ,window ,value)
> ,value)))))
>
> +(defmacro with-selected-window-undedicated (&rest body)
> + "Run BODY in the selected window temporarily undedicated."
> + (let ((window-dedicated-sym (gensym)))
> + `(let ((,window-dedicated-sym (window-dedicated-p)))
> + (when ,window-dedicated-sym
> + (set-window-dedicated-p nil nil))
> + ,@body
> + (when ,window-dedicated-sym
> + ;; `window-dedicated-p' returns the value set by
> + ;; `set-window-dedicated-p', which differentiates
> + ;; non-nil and t, so we cannot simply set to t.
> + (set-window-dedicated-p nil ,window-dedicated-sym)))))
> +
> ;; The following two functions are like `window-next-sibling' and
> ;; `window-prev-sibling' but the WINDOW argument is _not_ optional (so
> ;; they don't substitute the selected window for nil), and they return
I'm sorry, I only skimmed through your patch, but shouldn't this use
'unwind-protect'? Otherwise the "temporarily" won't hold in case of
abnormal exit from BODY, unless I'm missing something.
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Sat, 07 Mar 2020 19:18:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On Mar 7, 2020, at 2:07 PM, Štěpán Němec <stepnem <at> gmail.com> wrote:
>
> On Sat, 7 Mar 2020 13:09:53 -0500
> Yuan Fu wrote:
>
> [...]
>
>> diff --git a/lisp/window.el b/lisp/window.el
>> index bd825c09e1..229400966a 100644
>> --- a/lisp/window.el
>> +++ b/lisp/window.el
>> @@ -278,6 +278,19 @@ with-displayed-buffer-window
>> (funcall ,vquit-function ,window ,value)
>> ,value)))))
>>
>> +(defmacro with-selected-window-undedicated (&rest body)
>> + "Run BODY in the selected window temporarily undedicated."
>> + (let ((window-dedicated-sym (gensym)))
>> + `(let ((,window-dedicated-sym (window-dedicated-p)))
>> + (when ,window-dedicated-sym
>> + (set-window-dedicated-p nil nil))
>> + ,@body
>> + (when ,window-dedicated-sym
>> + ;; `window-dedicated-p' returns the value set by
>> + ;; `set-window-dedicated-p', which differentiates
>> + ;; non-nil and t, so we cannot simply set to t.
>> + (set-window-dedicated-p nil ,window-dedicated-sym)))))
>> +
>> ;; The following two functions are like `window-next-sibling' and
>> ;; `window-prev-sibling' but the WINDOW argument is _not_ optional (so
>> ;; they don't substitute the selected window for nil), and they return
>
> I'm sorry, I only skimmed through your patch, but shouldn't this use
> 'unwind-protect'? Otherwise the "temporarily" won't hold in case of
> abnormal exit from BODY, unless I'm missing something.
>
> —
> Štěpán
Thanks for spotting that. I added the unwind-protext form.
Yuan
[new-window.patch (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Mon, 09 Mar 2020 09:03:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 39181 <at> debbugs.gnu.org (full text, mbox):
>> I'm sorry, I only skimmed through your patch, but shouldn't this use
>> 'unwind-protect'? Otherwise the "temporarily" won't hold in case of
>> abnormal exit from BODY, unless I'm missing something.
>>
>> —
>> Štěpán
>
> Thanks for spotting that. I added the unwind-protext form.
If we want to be more strict about this macro then how about the
following forms:
(with-selected-window-undedicated
(set-window-dedicated-p nil t))
will leave the selected window dedicated which does not really violate
the contract of the macro but is unexpected at least.
The following is more serious: Suppose a user has a >= 2 windows layout
and does
(set-window-dedicated-p nil t)
(with-selected-window-undedicated
(other-window 1))
which will have the macro make some other window dedicated and the
initially selected window undedicated. A similar thing happens with
(set-window-dedicated-p nil t)
(with-selected-window-undedicated
(delete-window))
The macro should be named 'with-window-undedicated', take a WINDOW (nil
for the selected one) as first argument and BODY as second. It should
restore the dedicated status of WINDOW to what it was before running
BODY and leave the dedicated status of all other windows alone. IMHO.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Mon, 09 Mar 2020 18:00:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On Mar 9, 2020, at 5:01 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>
> >> I'm sorry, I only skimmed through your patch, but shouldn't this use
> >> 'unwind-protect'? Otherwise the "temporarily" won't hold in case of
> >> abnormal exit from BODY, unless I'm missing something.
> >>
> >> —
> >> Štěpán
> >
> > Thanks for spotting that. I added the unwind-protext form.
>
> If we want to be more strict about this macro then how about the
> following forms:
>
> (with-selected-window-undedicated
> (set-window-dedicated-p nil t))
>
> will leave the selected window dedicated which does not really violate
> the contract of the macro but is unexpected at least.
>
> The following is more serious: Suppose a user has a >= 2 windows layout
> and does
>
> (set-window-dedicated-p nil t)
> (with-selected-window-undedicated
> (other-window 1))
>
> which will have the macro make some other window dedicated and the
> initially selected window undedicated. A similar thing happens with
>
> (set-window-dedicated-p nil t)
> (with-selected-window-undedicated
> (delete-window))
>
> The macro should be named 'with-window-undedicated', take a WINDOW (nil
> for the selected one) as first argument and BODY as second. It should
> restore the dedicated status of WINDOW to what it was before running
> BODY and leave the dedicated status of all other windows alone. IMHO.
>
> Martin
>
I updated the patch accordingly. Could you have a look at the docsting? I had a hard time writing it.
Yuan
[new-window.patch (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Mon, 09 Mar 2020 19:19:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 39181 <at> debbugs.gnu.org (full text, mbox):
Again, having little experience with gdb(-mi) I have mostly checked the
doc strings; I hope Martin will provide better feedback.
Other than the nit picks below, I have one question: is there any
difference between "window layout" and "window configuration" in this
context? You seem to be using both interchangeably, both in
documentation and the function/variable names. There seems to be some
prior usage of "layout" in gdb-mi, but the general Emacs term AFAIK is
"configuration". Wouldn't it make sense to unify the usage somewhat, at
least in the new code? Just an observation (I found it confusing.)
On Mon, 09 Mar 2020 13:59:31 -0400
Yuan Fu wrote:
> From c27f39a3e321a7a1111f71dd95573104f025c89c Mon Sep 17 00:00:00 2001
> From: Yuan Fu <casouri <at> gmail.com>
> Date: Tue, 3 Mar 2020 18:30:03 -0500
> Subject: [PATCH] Add window streo/restore feature for gdb-mi
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Add a feature that allows a user to save a gdb window layout to a file
> with 'gdb-save-window-layout' and load it back it with
^^
Typo?
[...]
> +(defcustom gdb-restore-window-layout-after-quit nil
> + "Specify whether to restore the window layout the user had before gdb starts.
> +
> +Possible values are:
> + t -- Always restore.
> + nil -- Don't restore.
> + 'if-show-main -- Restore only if `gdb-show-main' is non-nil
> + 'if-many-windows -- Restore only if variable `gdb-many-windows' is non-nil."
^^^^^^^^^^^^^^^^
The documented symbols don't match the actual ones below. Also, if you
want to quote them in the doc string, the convention (which you do
follow elsewhere) is `like-this', 'this is confusing.
> + :type '(choice
> + (const :tag "Always restore" t)
> + (const :tag "Don't restore" nil)
> + (const :tag "Depends on `gdb-show-main'" 'if-gdb-show-main)
> + (const :tag "Depends on `gdb-many-windows'" 'if-gdb-many-windows))
^^^^^^^^^^^^^^^^^^^
[...]
> +(defun gdb-toggle-restore-window-layout ()
> + "Toggle whether to restore window layout when GDB quit."
^^^^
quits
> + (interactive)
> + (setq gdb-restore-window-layout-after-quit
> + (not gdb-restore-window-layout-after-quit)))
> +
> +(defun gdb-get-source-buffer ()
> + "Return a buffer displaying source file or nil if we can't find one.
> +
> +The source file is the file that contains the code at where GDB
^^^^^^^^
Just "where", or perhaps "source location where"?
> +stops. There could be multiple source files during a debugging
> +session, we get the most recently showed one. If program hasn't
> +start running yet, the source file is the \"main file\" at where
^^^^^^^^
Same as above.
> +the GDB session starts (see `gdb-main-file')."
[...]
> +(defun gdb-function-buffer-p (buffer)
> + "Return t if BUFFER is a GDB function buffer.
> +
> +Function buffers are locals buffer, registers buffer, etc, but
> +not including main command buffer (the one in where you type GDB
^^^^^^^^
Again, just "where".
> +commands) or source buffers (that displays program source code)."
^
"display"
[...]
> +(defun gdb-load-window-layout (file)
> + "Restore window layout (window configuration) from FILE.
> +
> +FILE should be a window layout file saved by
> +`gdb-save-window-layout'."
> + (interactive (list (read-file-name
> + "Restore window configuration from file: "
> + (or gdb-window-layout-directory default-directory))))
> + ;; Basically, we restore window configuration and go through each
> + ;; window and restore the function buffers.
> + (let* ((placeholder (get-buffer-create " *gdb-placeholder*")))
> + (unwind-protect ; Don't leak buffer.
> + (let ((window-config (with-temp-buffer
> + (insert-file-contents file)
> + ;; We need to go to point-min even we
> + ;; are reading the whole buffer.
I can't understand this comment. Maybe "even" should have been "so that"?
> + (goto-char (point-min))
> + (read (current-buffer))))
[...]
> @@ -4659,6 +4847,9 @@ gdb-many-windows
> (defun gdb-restore-windows ()
> "Restore the basic arrangement of windows used by gdb.
> This arrangement depends on the value of option `gdb-many-windows'."
> + ;; This function is used when the user messed up window
> + ;; configuration and want to "reset to default". The function that
^^^^
"wants"
[...]
> +(defmacro with-window-undedicated (window &rest body)
> + "Select WINDOW, set it to be undedicated and execute BODY.
> +
> +WINDOW is only set to be undedicated temporarily while executing
> +BODY. That is, the original value of WINDOW's dedication is
> +restored after executing BODY. If WINDOW is nil, use the
> +selected window. The value returned is the value of the last
> +form in BODY.
The "temporarily" thing is actually expected/understood with with-
macros, so I think it could be simplified to something like the
following (BTW, while there are occurences or "non-dedicated" in Emacs
sources, there are no occurences of "undedicated". Another thing to
maybe consider for the sake of consistency/least surprise.):
"Evaluate BODY with WINDOW selected and temporarily made non-dedicated.
If WINDOW is nil, use the selected window. Return the value of the last
form in BODY."
Thank you,
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Mon, 09 Mar 2020 20:19:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On Mar 9, 2020, at 3:18 PM, Štěpán Němec <stepnem <at> gmail.com> wrote:
>
>
> Other than the nit picks below, I have one question: is there any
> difference between "window layout" and "window configuration" in this
> context? You seem to be using both interchangeably, both in
> documentation and the function/variable names. There seems to be some
> prior usage of "layout" in gdb-mi, but the general Emacs term AFAIK is
> "configuration". Wouldn't it make sense to unify the usage somewhat, at
> least in the new code? Just an observation (I found it confusing.)
>
No, not really, that’s my fault. Before I go in and change every word, which one do you think I should use: configuration or layout? Configuration is the conventional Emacs term but I felt that layout is easier to understand for a user. If you are find with both I guess I will change all to configuration.
Yuan
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Mon, 09 Mar 2020 20:55:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 39181 <at> debbugs.gnu.org (full text, mbox):
On Mon, 09 Mar 2020 16:17:59 -0400
Yuan Fu wrote:
>> On Mar 9, 2020, at 3:18 PM, Štěpán Němec <stepnem <at> gmail.com> wrote:
>>
>>
>> Other than the nit picks below, I have one question: is there any
>> difference between "window layout" and "window configuration" in this
>> context? You seem to be using both interchangeably, both in
>> documentation and the function/variable names. There seems to be some
>> prior usage of "layout" in gdb-mi, but the general Emacs term AFAIK is
>> "configuration". Wouldn't it make sense to unify the usage somewhat, at
>> least in the new code? Just an observation (I found it confusing.)
>>
>
> No, not really, that’s my fault. Before I go in and change every word,
> which one do you think I should use: configuration or layout?
> Configuration is the conventional Emacs term but I felt that layout is
> easier to understand for a user. If you are find with both I guess I
> will change all to configuration.
If they mean the same thing, then I'd say "configuration" is definitely
the way to go.
It is true that some Emacs terms might be unfamiliar to new users, but
thanks to the excellent documentation capabilities it's very easy to
learn the respective definitions (e.g., in this case 'C-h r i
configuration' will display the relevant manual entries). It is
important to stay consistent.
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Tue, 10 Mar 2020 08:50:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 39181 <at> debbugs.gnu.org (full text, mbox):
> I updated the patch accordingly. Could you have a look at the docsting? I had a hard time writing it.
Please don't select WINDOW in 'with-window-undedicated'. In general,
try to avoid selecting a window unless it is really needed. This is
particularly important when WINDOW can be on another frame where
selecting WINDOW entails switching to that frame with all its overhead.
I would use something like the untested below. This could be then
useful for 'ffap-other-frame' or 'ffap-dired-other-frame' as well.
martin
(defmacro with-window-undedicated (window &rest body)
"Execute BODY with WINDOW temporarily undedicated.
WINDOW must be a live window and defaults to the selected one."
(declare (indent 1) (debug t))
(let ((window-dedicated-sym (gensym))
(window-sym (gensym)))
`(let* ((,window-sym (window-normalize-window window t))
(,window-dedicated-sym (window-dedicated-p ,window-sym)))
(set-window-dedicated-p ,window-sym nil)
(unwind-protect
(progn ,@body)
(set-window-dedicated-p ,window-sym ,window-dedicated-sym)))))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Tue, 10 Mar 2020 08:50:03 GMT)
Full text and
rfc822 format available.
Message #74 received at 39181 <at> debbugs.gnu.org (full text, mbox):
> No, not really, that’s my fault. Before I go in and change every word,
> which one do you think I should use: configuration or layout?
> Configuration is the conventional Emacs term but I felt that layout is
> easier to understand for a user. If you are find with both I guess I
> will change all to configuration.
While I agree with Štěpán that we should use a unified nomenclature
wherever possible, most GDB users will probably prefer "layout" here.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Tue, 10 Mar 2020 18:07:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 39181 <at> debbugs.gnu.org (full text, mbox):
Hmmm, so what is the best approach here? Use layout in button names (in the menu bar) and configuration everywhere else? And maybe mention the equivalence between layout and configuration in help echo?
Yuan
> 在 2020年3月10日，上午4:49，martin rudalics <rudalics <at> gmx.at> 写道：
>
> > No, not really, that’s my fault. Before I go in and change every word,
> > which one do you think I should use: configuration or layout?
> > Configuration is the conventional Emacs term but I felt that layout is
> > easier to understand for a user. If you are find with both I guess I
> > will change all to configuration.
>
> While I agree with Štěpán that we should use a unified nomenclature
> wherever possible, most GDB users will probably prefer "layout" here.
>
> martin
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Wed, 11 Mar 2020 08:53:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 39181 <at> debbugs.gnu.org (full text, mbox):
> Hmmm, so what is the best approach here? Use layout in button names
> (in the menu bar) and configuration everywhere else?
I think so. Štěpán?
> And maybe mention
> the equivalence between layout and configuration in help echo?
I'd mention it in section 27.6.5.1 GDB User Interface Layout of the
Emacs manual.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Wed, 11 Mar 2020 09:27:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 39181 <at> debbugs.gnu.org (full text, mbox):
On Wed, 11 Mar 2020 09:52:37 +0100
martin rudalics wrote:
> > Hmmm, so what is the best approach here? Use layout in button names
> > (in the menu bar) and configuration everywhere else?
>
> I think so. Štěpán?
That certainly sounds better, thank you, although I'm still wondering if
the "layout" gdb-mi speaks of really corresponds exactly to the usual
window configuration (the object/data structure)? And if it does, it
still seems to me that it would be better to just use the Emacs term,
for the reasons I explained in my previous message, but as an only very
occasional GDB user I don't feel I should be pushing for such a change.
> > And maybe mention
> > the equivalence between layout and configuration in help echo?
>
> I'd mention it in section 27.6.5.1 GDB User Interface Layout of the
> Emacs manual.
FWIW, I found that section confusing for other reasons as well, e.g. it
seems to even mix "frame layout" and "window layout" in apparently the
same sense? I think fixing _that_ at least should be uncontroversial. :-)
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Thu, 12 Mar 2020 08:23:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 39181 <at> debbugs.gnu.org (full text, mbox):
> That certainly sounds better, thank you, although I'm still wondering if
> the "layout" gdb-mi speaks of really corresponds exactly to the usual
> window configuration (the object/data structure)? And if it does, it
> still seems to me that it would be better to just use the Emacs term,
> for the reasons I explained in my previous message, but as an only very
> occasional GDB user I don't feel I should be pushing for such a change.
I would use the term "layout" for what is visible on screen and
"configuration" for the underlying data structure.
>> I'd mention it in section 27.6.5.1 GDB User Interface Layout of the
>> Emacs manual.
>
> FWIW, I found that section confusing for other reasons as well, e.g. it
> seems to even mix "frame layout" and "window layout" in apparently the
> same sense? I think fixing _that_ at least should be uncontroversial. :-)
Let alone the fact that "frame" in the context of GDB and Emacs has two
quite different meanings ...
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Thu, 12 Mar 2020 08:49:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 39181 <at> debbugs.gnu.org (full text, mbox):
On Thu, 12 Mar 2020 09:22:23 +0100
martin rudalics wrote:
> > That certainly sounds better, thank you, although I'm still wondering if
> > the "layout" gdb-mi speaks of really corresponds exactly to the usual
> > window configuration (the object/data structure)? And if it does, it
> > still seems to me that it would be better to just use the Emacs term,
> > for the reasons I explained in my previous message, but as an only very
> > occasional GDB user I don't feel I should be pushing for such a change.
>
> I would use the term "layout" for what is visible on screen and
> "configuration" for the underlying data structure.
Yes, I think I understood that, and would consider it an improvement.
All I was trying to reiterate is that _if_ the layout means exactly the
same as "window configuration", then I would prefer to call it just that
even in the UI, to avoid cognitive overhead (AKA head scratching) for
Emacs users used to that term, while not causing significant
inconvenience for those not familiar with the Emacs term (it's
consistently used and the documentation readily accessible). But of
course I defer to your decision.
> >> I'd mention it in section 27.6.5.1 GDB User Interface Layout of the
> >> Emacs manual.
> >
> > FWIW, I found that section confusing for other reasons as well, e.g. it
> > seems to even mix "frame layout" and "window layout" in apparently the
> > same sense? I think fixing _that_ at least should be uncontroversial. :-)
>
> Let alone the fact that "frame" in the context of GDB and Emacs has two
> quite different meanings ...
Yeah, I had double-checked the GDB docs and there is no evidence of
"frame" being used in any non-stack-related sense. The confusion
probably stems from the Info manual writer trying to use the Emacs
terms while not being quite familiar with them themselves.
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Thu, 12 Mar 2020 19:22:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 39181 <at> debbugs.gnu.org (full text, mbox):
Then I’ll use “layout” in the menu bar buttons and “window configuration” in other places. A plus for “layout” in UI is that it’s shorter.
Yuan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Fri, 13 Mar 2020 20:10:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Here’s the patch that addresses Štěpán and Martin’s review:
Apart from fixing all the mentioned issues, I also moved “Restore Window Layout” button from “GDB-MI” menu to “GDB-WINDOWS” menu, since it fits there better; I also mentioned that this button works for the new user-supplied default layout, too, if a user sets `gdb-default-window-configuration-file’.
As for the layout vs configuration, I used “layout” in UI buttons, and used “window configuration (i.e. window layout)” in help echos. Hopefully the user will understand that we use “window configuration” internally but it’s (almost) the same as a window layout in gdb. This also plays well with existing UI that uses “layout”. The window layout that we save to a file in gdb is a window configuration structure with some small differences: simply loading that window configuration with `window-state-put' doesn’t give back your gdb layout. (because all the buffers (local, breakpoint, etc) are different from session to session.) `gdb-load-window-configuration` does some trick to recreate each buffers. Apart from that the layout and window configuration is the same thing.
Martin suggests to mention the layout vs window configuration in the manual, should I also document this new feature in the same section? (Let me learn texinfo first ;-)
Yuan
[Message part 2 (text/html, inline)]
[new-window.patch (application/octet-stream, attachment)]
[Message part 4 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Fri, 13 Mar 2020 21:13:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[resending to Cc: Martin and the bug list, sorry]
On Fri, 13 Mar 2020 16:09:06 -0400
Yuan Fu wrote:
> Apart from fixing all the mentioned issues,
Almost... :-)
> The window layout that we save to a file in gdb is a window
> configuration structure with some small differences: simply loading
> that window configuration with `window-state-put' doesn’t give back
> your gdb layout. (because all the buffers (local, breakpoint, etc) are
> different from session to session.) `gdb-load-window-configuration`
> does some trick to recreate each buffers. Apart from that the layout
> and window configuration is the same thing.
Thank you for the clarification! It would be nice to have that in the
documentation as well.
> @@ -253,6 +255,25 @@ gdb-output-sink
> disposition of output generated by commands that
> gdb mode sends to gdb on its own behalf.")
>
> +(defvar gdb--window-configuration-before nil
> + "Stores the window configuration before starting gdb.")
> +
> +(defcustom gdb-restore-window-configuration-after-quit nil
> + "Whether to restore the window configuration the user had before gdb starts.
Probably better stick to the standard "If non-nil, restore...".
> @@ -4491,6 +4538,15 @@ gdb-preempt-existing-or-display-buffer
> (define-key gud-menu-map [displays]
> `(menu-item "GDB-Windows" ,menu
> :visible (eq gud-minor-mode 'gdbmi)))
> + (define-key menu [gdb-restore-windows]
> + '(menu-item "Restore Default Layout" gdb-restore-windows
> + :help "Restore standard layout for debug session. I.e., the layout we get when session starts."))
How about just "Restore standard layout for debug session (the layout we
get when session starts)." Or, even more concisely, "Restore the initial
GDB window layout"?
> + (define-key menu [load-layout] '("Load Layout" "Load GDB window configuration (i.e. window layout) from a file" . gdb-load-window-configuration))
You can omit the "i.e.". Actually, even better perhaps just "window
configuration (layout)"? Similarly below.
> @@ -4606,41 +4659,174 @@ gdb-set-window-buffer
> (set-window-buffer window (get-buffer name))
> (set-window-dedicated-p window t))
>
> +(defun gdb-toggle-restore-window-configuration ()
> + "Toggle whether to restore window configuration when GDB quit."
^^^^
quits
> + (interactive)
> + (setq gdb-restore-window-configuration-after-quit
> + (not gdb-restore-window-configuration-after-quit)))
> +
> +(defun gdb-get-source-buffer ()
> + "Return a buffer displaying source file or nil if we can't find one.
> +
> +The source file is the file that contains the source location
> +where GDB stops. There could be multiple source files during a
> +debugging session, we get the most recently showed one. If
> +program hasn't start running yet, the source file is the \"main
^^^^^
started
> +file\" where the GDB session starts (see `gdb-main-file')."
> + (if gud-last-last-frame
> + (gud-find-file (car gud-last-last-frame))
> + (when gdb-main-file
> + (gud-find-file gdb-main-file))))
> +
> (defun gdb-setup-windows ()
> "Layout the window pattern for option `gdb-many-windows'."
^^^^^^
"Lay out" (verb)
> @@ -4658,7 +4844,12 @@ gdb-many-windows
>
> (defun gdb-restore-windows ()
> "Restore the basic arrangement of windows used by gdb.
> -This arrangement depends on the value of option `gdb-many-windows'."
> +This arrangement depends on the value of option
> +`gdb-many-windows' and `gdb-default-window-configuration-file'."
How about "This arrangement depends on the values of `gdb-many-windows'
and `gdb-default-window-configuration-file'."
> diff --git a/lisp/window.el b/lisp/window.el
> index bd825c09e1..d774d906cd 100644
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -278,6 +278,24 @@ with-displayed-buffer-window
> (funcall ,vquit-function ,window ,value)
> ,value)))))
>
> +(defmacro with-window-non-dedicated (window &rest body)
> + "Evaluate BODY with WINDOW selected and temporarily made non-dedicated.
^^^^^^^^^^^^
This is now no longer true.
Thank you,
Štěpán
P.S.: This time your patch somehow ended up hidden as
application/ocet-stream after the HTML part, instead of inline in plain
text.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Fri, 13 Mar 2020 21:41:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
>> The window layout that we save to a file in gdb is a window
>> configuration structure with some small differences: simply loading
>> that window configuration with `window-state-put' doesn’t give back
>> your gdb layout. (because all the buffers (local, breakpoint, etc) are
>> different from session to session.) `gdb-load-window-configuration`
>> does some trick to recreate each buffers. Apart from that the layout
>> and window configuration is the same thing.
>
> Thank you for the clarification! It would be nice to have that in the
> documentation as well.
I added some comments in the menu-map code. Hope that’s helps.
>> @@ -253,6 +255,25 @@ gdb-output-sink
>> disposition of output generated by commands that
>> gdb mode sends to gdb on its own behalf.")
>>
>> +(defvar gdb--window-configuration-before nil
>> + "Stores the window configuration before starting gdb.")
>> +
>> +(defcustom gdb-restore-window-configuration-after-quit nil
>> + "Whether to restore the window configuration the user had before gdb starts.
>
> Probably better stick to the standard "If non-nil, restore...".
>
>> @@ -4491,6 +4538,15 @@ gdb-preempt-existing-or-display-buffer
>> (define-key gud-menu-map [displays]
>> `(menu-item "GDB-Windows" ,menu
>> :visible (eq gud-minor-mode 'gdbmi)))
>> + (define-key menu [gdb-restore-windows]
>> + '(menu-item "Restore Default Layout" gdb-restore-windows
>> + :help "Restore standard layout for debug session. I.e., the layout we get when session starts."))
>
> How about just "Restore standard layout for debug session (the layout we
> get when session starts)." Or, even more concisely, "Restore the initial
> GDB window layout"?
>
>> + (define-key menu [load-layout] '("Load Layout" "Load GDB window configuration (i.e. window layout) from a file" . gdb-load-window-configuration))
>
> You can omit the "i.e.". Actually, even better perhaps just "window
> configuration (layout)"? Similarly below.
>
>> @@ -4606,41 +4659,174 @@ gdb-set-window-buffer
>> (set-window-buffer window (get-buffer name))
>> (set-window-dedicated-p window t))
>>
>> +(defun gdb-toggle-restore-window-configuration ()
>> + "Toggle whether to restore window configuration when GDB quit."
> ^^^^
> quits
>
>> + (interactive)
>> + (setq gdb-restore-window-configuration-after-quit
>> + (not gdb-restore-window-configuration-after-quit)))
>> +
>> +(defun gdb-get-source-buffer ()
>> + "Return a buffer displaying source file or nil if we can't find one.
>> +
>> +The source file is the file that contains the source location
>> +where GDB stops. There could be multiple source files during a
>> +debugging session, we get the most recently showed one. If
>> +program hasn't start running yet, the source file is the \"main
> ^^^^^
> started
>
>> +file\" where the GDB session starts (see `gdb-main-file')."
>> + (if gud-last-last-frame
>> + (gud-find-file (car gud-last-last-frame))
>> + (when gdb-main-file
>> + (gud-find-file gdb-main-file))))
>> +
>> (defun gdb-setup-windows ()
>> "Layout the window pattern for option `gdb-many-windows'."
> ^^^^^^
> "Lay out" (verb)
All fixed.
>
>> @@ -4658,7 +4844,12 @@ gdb-many-windows
>>
>> (defun gdb-restore-windows ()
>> "Restore the basic arrangement of windows used by gdb.
>> -This arrangement depends on the value of option `gdb-many-windows'."
>> +This arrangement depends on the value of option
>> +`gdb-many-windows' and `gdb-default-window-configuration-file'."
>
> How about "This arrangement depends on the values of `gdb-many-windows'
> and `gdb-default-window-configuration-file'."
>
I changed “option” to “variable”, I have to keep “variable” otherwise the byte compiler complains about there existing function and variable “gdb-many-windows”.
>> diff --git a/lisp/window.el b/lisp/window.el
>> index bd825c09e1..d774d906cd 100644
>> --- a/lisp/window.el
>> +++ b/lisp/window.el
>> @@ -278,6 +278,24 @@ with-displayed-buffer-window
>> (funcall ,vquit-function ,window ,value)
>> ,value)))))
>>
>> +(defmacro with-window-non-dedicated (window &rest body)
>> + "Evaluate BODY with WINDOW selected and temporarily made non-dedicated.
> ^^^^^^^^^^^^
> This is now no longer true.
>
Fixed.
> Thank you,
>
> Štěpán
Thanks for catching all the issues.
>
> P.S.: This time your patch somehow ended up hidden as
> application/ocet-stream after the HTML part, instead of inline in plain
> text.
I’m not sure what causes that. I’ve been using Apple Mail and I just copy the patch file into my reply. It actually surprises me that they showed up in plain text before. This time I made the mail plain text, hopefully that makes the patch also in plain text.
Yuan
[new-window.patch (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Fri, 13 Mar 2020 22:13:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 39181 <at> debbugs.gnu.org (full text, mbox):
On Fri, 13 Mar 2020 17:40:30 -0400
Yuan Fu wrote:
> I added some comments in the menu-map code. Hope that’s helps.
Thanks.
> All fixed.
Confirmed, thank you.
>> P.S.: This time your patch somehow ended up hidden as
>> application/ocet-stream after the HTML part, instead of inline in plain
>> text.
> I’m not sure what causes that. I’ve been using Apple Mail and I just
> copy the patch file into my reply. It actually surprises me that they
> showed up in plain text before. This time I made the mail plain text,
> hopefully that makes the patch also in plain text.
Yeah, actually the difference wasn't in the patch MIME type per se, but
in the fact that it was included in a multipart/mixed section together
with the HTML part (all that in one big multipart/alternative), so it
wasn't visible in the text/plain part. This one is same as your previous
e-mails again (text/plain), thanks.
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Sun, 15 Mar 2020 15:56:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 39181 <at> debbugs.gnu.org (full text, mbox):
I pushed your patch to master, tweaking the change log, some doc-strings
and breaking a couple of lines so they fit into our line length limits.
Please have a look at whether anything has been broken by these tweaks.
We certainly need a few NEWS entries for this. Kindly supply them.
Thanks again for your work and to Štěpán for the comments, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Mon, 16 Mar 2020 00:14:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 39181 <at> debbugs.gnu.org (full text, mbox):
> On Mar 15, 2020, at 11:55 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>
> I pushed your patch to master, tweaking the change log, some doc-strings
> and breaking a couple of lines so they fit into our line length limits.
> Please have a look at whether anything has been broken by these tweaks.
>
> We certainly need a few NEWS entries for this. Kindly supply them.
Thanks. I’ll prepare a patch for etc/news. Should I also update the manual?
Yuan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Mon, 16 Mar 2020 09:25:03 GMT)
Full text and
rfc822 format available.
Message #113 received at 39181 <at> debbugs.gnu.org (full text, mbox):
> Thanks. I’ll prepare a patch for etc/news. Should I also update the manual?
Please do.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Fri, 20 Mar 2020 20:04:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On Mar 16, 2020, at 5:24 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>
> > Thanks. I’ll prepare a patch for etc/news. Should I also update the manual?
>
> Please do.
>
> Thanks, martin
>
Here it is.
Yuan
[news.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Fri, 20 Mar 2020 20:59:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 39181 <at> debbugs.gnu.org (full text, mbox):
On Fri, 20 Mar 2020 16:03:45 -0400
Yuan Fu wrote:
> Here it is.
Thank you! A few comments:
> diff --git a/doc/emacs/building.texi b/doc/emacs/building.texi
> index 38963f225c..130abc41e8 100644
> --- a/doc/emacs/building.texi
> +++ b/doc/emacs/building.texi
> @@ -568,7 +568,7 @@ Starting GUD
>
> @item M-x gud-gdb
> @findex gud-gdb
> -Run GDB, using a GUD interaction buffer for input and output to the
> +Run GDB, using a GUD action buffer for input and output to the
^^^^^^
Is there really any reason for this change? If the buffer is "for
input and output", isn't "interaction" more fitting than "action"?
[...]
> + You can customize the window layout bese on the one above, and save
^^^^
"based"?
> +the custom layout to a file by @code{gdb-save-window-configuration}.
^^
I think "using" would be better here.
> +Then you can later load this layout back by
^^
same here
> +@code{gdb-load-window-configuration}. (Simply put, window
[...]
> +@code{gdb-default-window-configuration-file}. If it is not an
> +absolute path, GDB looks under
> +@code{gdb-window-configuration-directory} (default to
> +@file{~/.emacs.d}) for the file.
"(which defaults to user-emacs-directory)" (ideally with a proper
reference to that variable).
[...]
> +premium. If you choose to start GDB in the same frame, consider
> +setting @code{gdb-restore-window-configuration-after-quit} to
> +non-@code{nil}. Then GDB restores your original window layout after
"to a non-nil value. Your original window layout will then be restored
after GDB quits."
> +it quits. Set to @code{t} to always restore; set to
^^^^^^
"Set it to" or "Use", similarly for the following ones.
> +@code{if-gdb-many-windows} to restore only when
> +@code{gdb-many-windows} is @code{t}; set to @code{if-gdb-show-main} to
> +restore only when @code{gdb-show-main} is @code{t}.
IIUC, these two `t's for gdb-show-main and gdb-many-windows should
really be "non-nil"s, i.e., there is no special treatment of the symbol
`t' as opposed to generalized boolean.
> diff --git a/etc/NEWS b/etc/NEWS
> index 87e634f2c1..692ecf7f0a 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -174,6 +174,22 @@ key binding
> / v package-menu-filter-by-version
> / / package-menu-filter-clear
>
> +** gdb-mi
> +
> +*** gdb-mi can now store and restore window configurations.
> +Use 'gdb-save-window-configuration' to save window configuration to a
> +file, and 'gdb-load-window-configuration' to load from a file. They
^^^^
"These commands"?
> +can also be accessed through menu bar under Gud -- GDB-Windows.
[...]
> +*** gdb-mi can now restore window configuration after finished.
^^^^^^^^^^^^^^
"when finished" or "after quit"
> +Set 'gdb-restore-window-configuration-after-quit' to non-nil and GDB
^^^
Better say "Emacs": at that point GDB is gone. :-)
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Sat, 21 Mar 2020 18:02:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks for reviewing! Almost all fixed with some comments:
>> +@code{gdb-default-window-configuration-file}. If it is not an
>> +absolute path, GDB looks under
>> +@code{gdb-window-configuration-directory} (default to
>> +@file{~/.emacs.d}) for the file.
>
> "(which defaults to user-emacs-directory)" (ideally with a proper
> reference to that variable).
The whole Emacs user manual only referenced user-emacs-directory once when talking about ~/.emacs.d. OTOH ~/.emacs.d is used across the manual. I think ~/.emacs.d is better.
>> +premium. If you choose to start GDB in the same frame, consider
>> +setting @code{gdb-restore-window-configuration-after-quit} to
>> +non-@code{nil}. Then GDB restores your original window layout after
>
> "to a non-nil value. Your original window layout will then be restored
> after GDB quits."
I prefer active voice than passive voice but don’t object the latter. So I changed it accordingly.
Yuan
[news.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Sat, 21 Mar 2020 18:39:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 39181 <at> debbugs.gnu.org (full text, mbox):
On Sat, 21 Mar 2020 14:00:56 -0400
Yuan Fu wrote:
>>> +@code{gdb-default-window-configuration-file}. If it is not an
>>> +absolute path, GDB looks under
>>> +@code{gdb-window-configuration-directory} (default to
>>> +@file{~/.emacs.d}) for the file.
>>
>> "(which defaults to user-emacs-directory)" (ideally with a proper
>> reference to that variable).
>
> The whole Emacs user manual only referenced user-emacs-directory once when talking about ~/.emacs.d. OTOH ~/.emacs.d is used across the manual. I think ~/.emacs.d is better.
Saying "defaults to ~/.emacs.d" is strictly speaking incorrect, because
it really defaults to user-emacs-directory, which might or might not be
"~/.emacs.d". It is true that the same could probably be argued about
some other occurences in the manuals (most of which probably go back
even before the introduction of user-emacs-directory in Emacs 23, let
alone the recent XDG-compliance efforts), though, so if you insist, at
least it will be incorrect somewhat _consistently_ (and can be fixed
later together with the other places) :-D.
>>> +premium. If you choose to start GDB in the same frame, consider
>>> +setting @code{gdb-restore-window-configuration-after-quit} to
>>> +non-@code{nil}. Then GDB restores your original window layout after
>>
>> "to a non-nil value. Your original window layout will then be restored
>> after GDB quits."
>
> I prefer active voice than passive voice but don’t object the latter. So I changed it accordingly.
The real issue here was more the semantics than the grammar, similarly
to the NEWS correction: it's really Emacs, not GDB, that restores the
windows after GDB quits.
Thanks!
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Sat, 21 Mar 2020 21:04:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On Mar 21, 2020, at 2:39 PM, Štěpán Němec <stepnem <at> gmail.com> wrote:
>
> On Sat, 21 Mar 2020 14:00:56 -0400
> Yuan Fu wrote:
>
>>>> +@code{gdb-default-window-configuration-file}. If it is not an
>>>> +absolute path, GDB looks under
>>>> +@code{gdb-window-configuration-directory} (default to
>>>> +@file{~/.emacs.d}) for the file.
>>>
>>> "(which defaults to user-emacs-directory)" (ideally with a proper
>>> reference to that variable).
>>
>> The whole Emacs user manual only referenced user-emacs-directory once when talking about ~/.emacs.d. OTOH ~/.emacs.d is used across the manual. I think ~/.emacs.d is better.
>
> Saying "defaults to ~/.emacs.d" is strictly speaking incorrect, because
> it really defaults to user-emacs-directory, which might or might not be
> "~/.emacs.d". It is true that the same could probably be argued about
> some other occurences in the manuals (most of which probably go back
> even before the introduction of user-emacs-directory in Emacs 23, let
> alone the recent XDG-compliance efforts), though, so if you insist, at
> least it will be incorrect somewhat _consistently_ (and can be fixed
> later together with the other places) :-D.
>
>>>> +premium. If you choose to start GDB in the same frame, consider
>>>> +setting @code{gdb-restore-window-configuration-after-quit} to
>>>> +non-@code{nil}. Then GDB restores your original window layout after
>>>
>>> "to a non-nil value. Your original window layout will then be restored
>>> after GDB quits."
>>
>> I prefer active voice than passive voice but don’t object the latter. So I changed it accordingly.
>
> The real issue here was more the semantics than the grammar, similarly
> to the NEWS correction: it's really Emacs, not GDB, that restores the
> windows after GDB quits.
>
>
I changed to user-emacs-directory. I hope I get the xref right :-)
Yuan
[news.patch (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Sat, 21 Mar 2020 21:50:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 39181 <at> debbugs.gnu.org (full text, mbox):
On Sat, 21 Mar 2020 17:03:11 -0400
Yuan Fu wrote:
> I changed to user-emacs-directory. I hope I get the xref right :-)
Well, you could have just tested it, like I did, and... turns out you
didn't. :-D
> +@code{gdb-window-configuration-directory} defaults to
> +@code{user-emacs-directory} (@pxref{How Emacs Finds Your Init File,,,
> +custom.texi, Customization}).
It's actually the same manual, albeit compiled from multiple files, so,
just @pxref{Find Init} appears to work.
Thanks,
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Tue, 24 Mar 2020 16:15:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 39181 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On Mar 21, 2020, at 5:49 PM, Štěpán Němec <stepnem <at> gmail.com> wrote:
>
> On Sat, 21 Mar 2020 17:03:11 -0400
> Yuan Fu wrote:
>
>> I changed to user-emacs-directory. I hope I get the xref right :-)
>
> Well, you could have just tested it, like I did, and... turns out you
> didn't. :-D
>
>> +@code{gdb-window-configuration-directory} defaults to
>> +@code{user-emacs-directory} (@pxref{How Emacs Finds Your Init File,,,
>> +custom.texi, Customization}).
>
> It's actually the same manual, albeit compiled from multiple files, so,
> just @pxref{Find Init} appears to work.
Didn’t thought of that, sorry. I’ll remember to test it next time. Here’s the new patch.
Thanks.
Yuan
[news.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Fri, 27 Mar 2020 09:02:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 39181 <at> debbugs.gnu.org (full text, mbox):
> Here’s the new patch.
Installed now with a few tweaks. Please have a look.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Fri, 27 Mar 2020 16:29:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 39181 <at> debbugs.gnu.org (full text, mbox):
> On Mar 27, 2020, at 5:01 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>
> > Here’s the new patch.
>
> Installed now with a few tweaks. Please have a look.
>
> Thanks, martin
>
Thanks.
Yuan
Reply sent
to
Yuan Fu <casouri <at> gmail.com>:
You have taken responsibility.
(Tue, 14 Apr 2020 01:19:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Yuan Fu <casouri <at> gmail.com>:
bug acknowledged by developer.
(Tue, 14 Apr 2020 01:19:01 GMT)
Full text and
rfc822 format available.
Message #145 received at 39181-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Begin forwarded message:
>
> From: Mail Delivery Subsystem <mailer-daemon <at> googlemail.com>
> Subject: Delivery Status Notification (Failure)
> Date: April 13, 2020 at 9:17:28 PM GMT-4
> To: casouri <at> gmail.com
>
>
> Address not found
> Your message wasn't delivered to <>39181-done <at> debuggs.gnu.org <mailto:39181-done <at> debuggs.gnu.org> because the domain debuggs.gnu.org <http://debuggs.gnu.org/>couldn't be found. Check for typos or unnecessary spaces and try again.
> The response was:
> DNS Error: 11672847 DNS type 'mx' lookup of debuggs.gnu.org <http://debuggs.gnu.org/> responded with code NXDOMAIN Domain name not found: debuggs.gnu.org <http://debuggs.gnu.org/>Reporting-MTA: dns; googlemail.com <http://googlemail.com/>
> Received-From-MTA: dns; casouri <at> gmail.com <mailto:casouri <at> gmail.com>
> Arrival-Date: Mon, 13 Apr 2020 18:17:26 -0700 (PDT)
> X-Original-Message-ID: <27D34924-67A4-4C59-8DD4-160465E9CC4D <at> gmail.com <mailto:27D34924-67A4-4C59-8DD4-160465E9CC4D <at> gmail.com>>
>
> Final-Recipient: rfc822; 39181-done <at> debuggs.gnu.org <mailto:39181-done <at> debuggs.gnu.org>
> Action: failed
> Status: 4.0.0
> Diagnostic-Code: smtp; DNS Error: 11672847 DNS type 'mx' lookup of debuggs.gnu.org <http://debuggs.gnu.org/> responded with code NXDOMAIN
> Domain name not found: debuggs.gnu.org <http://debuggs.gnu.org/>
> Last-Attempt-Date: Mon, 13 Apr 2020 18:17:28 -0700 (PDT)
>
> From: Yuan Fu <casouri <at> gmail.com <mailto:casouri <at> gmail.com>>
> Subject: Fwd: Delivery Status Notification (Failure)
> Date: April 13, 2020 at 9:17:25 PM GMT-4
> To: 39181-done <at> debuggs.gnu.org <mailto:39181-done <at> debuggs.gnu.org>
>
>
>
> --Apple-Mail=_04B0AE11-8C4E-4FBB-9A28-93028C1DEC54
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/html;
> charset=utf-8
>
> <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
> charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
> -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
> class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
> class=3D"">Begin forwarded message:</div><br =
> class=3D"Apple-interchange-newline"><div style=3D"margin-top: 0px; =
> margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=3D""><span=
> style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, =
> sans-serif; color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">From: =
> </b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
> Neue, Helvetica, sans-serif;" class=3D"">Mail Delivery Subsystem <<a =
> href=3D"mailto:mailer-daemon <at> googlemail.com <mailto:mailer-daemon <at> googlemail.com>" =
> class=3D"">mailer-daemon <at> googlemail.com <mailto:mailer-daemon <at> googlemail.com></a>><br =
> class=3D""></span></div><div style=3D"margin-top: 0px; margin-right: =
> 0px; margin-bottom: 0px; margin-left: 0px;" class=3D""><span =
> style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, =
> sans-serif; color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">Subject: =
> </b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
> Neue, Helvetica, sans-serif;" class=3D""><b class=3D"">Delivery Status =
> Notification (Failure)
> ----- Message truncated -----
[Message part 2 (text/html, inline)]
[icon.png (image/png, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#39181; Package
emacs.
(Tue, 14 Apr 2020 08:06:02 GMT)
Full text and
rfc822 format available.
Message #148 received at 39181-done <at> debbugs.gnu.org (full text, mbox):
tags 39181 fixed
close 39181 28.1
quit
Hopefully marked as done now.
martin
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 12 May 2020 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 343 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.