GNU bug report logs -
#49632
[PATCH] Ensure that M-x gdb populates gud-repeat-map
Previous Next
Reported by: Brian Leung <leungbk <at> mailfence.com>
Date: Mon, 19 Jul 2021 03:38:01 UTC
Severity: normal
Tags: fixed, patch
Fixed in version 28.0.50
Done: Juri Linkov <juri <at> linkov.net>
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 49632 in the body.
You can then email your comments to 49632 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#49632
; Package
emacs
.
(Mon, 19 Jul 2021 03:38:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Brian Leung <leungbk <at> mailfence.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 19 Jul 2021 03:38:01 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)]
See attached.
--
Mailfence.com
Private and secure email
[0001-Ensure-that-M-x-gdb-populates-gud-repeat-map.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Mon, 19 Jul 2021 13:07:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 49632 <at> debbugs.gnu.org (full text, mbox):
Brian Leung <leungbk <at> mailfence.com> writes:
> * lisp/progmodes/gdb-mi.el (gdb): Populate gud-repeat-map. This is
> copied from the gud-gdb command.
Instead of copying the code, perhaps it should be separated out into its
own function and then called from both places?
But I don't quite understand why gud-repeat-map is populated in the
normal way -- i.e., in `gud-repeat-map' so that users can
redefine/override entries as usual.
Juri?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Mon, 19 Jul 2021 13:15:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 49632 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Mon, 19 Jul 2021 15:06:31 +0200
> Cc: 49632 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
>
> Brian Leung <leungbk <at> mailfence.com> writes:
>
> > * lisp/progmodes/gdb-mi.el (gdb): Populate gud-repeat-map. This is
> > copied from the gud-gdb command.
>
> Instead of copying the code, perhaps it should be separated out into its
> own function and then called from both places?
>
> But I don't quite understand why gud-repeat-map is populated in the
> normal way -- i.e., in `gud-repeat-map' so that users can
> redefine/override entries as usual.
I admit I don't understand the rationale for the patch at all.
"M-x gdb" already repeats these commands when you type just RET
into the interaction buffer, so what exactly does this change
do, and how can I see its effect?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Mon, 19 Jul 2021 14:52:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 49632 <at> debbugs.gnu.org (full text, mbox):
> But I don't quite understand why gud-repeat-map is populated in the
> normal way -- i.e., in `gud-repeat-map' so that users can
> redefine/override entries as usual.
I think it is presently done this way because things like M-x gdb, M-x pdb, etc. all use their own debugger commands, so we need to re-bind exactly the right ones each time. For example, in M-x perldb, gud-finish, gud-up, and gud-down are all commented out even though gdb clearly supports those functions.
> ----------------------------------------
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Sent: Mon Jul 19 15:06:31 CEST 2021
> To: Brian Leung <leungbk <at> mailfence.com>
> Cc: <49632 <at> debbugs.gnu.org>, Juri Linkov <juri <at> linkov.net>
> Subject: Re: bug#49632: [PATCH] Ensure that M-x gdb populates gud-repeat-map
>
>
> Brian Leung <leungbk <at> mailfence.com> writes:
>
> > * lisp/progmodes/gdb-mi.el (gdb): Populate gud-repeat-map. This is
> > copied from the gud-gdb command.
>
> Instead of copying the code, perhaps it should be separated out into its
> own function and then called from both places?
>
> But I don't quite understand why gud-repeat-map is populated in the
> normal way -- i.e., in `gud-repeat-map' so that users can
> redefine/override entries as usual.
>
> Juri?
>
> --
> (domestic pets only, the antidote for overdose, milk.)
> bloggy blog: http://lars.ingebrigtsen.no
--
Sent with https://mailfence.com
Secure and private email
--
Mailfence.com
Private and secure email
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Mon, 19 Jul 2021 14:58:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 49632 <at> debbugs.gnu.org (full text, mbox):
> I admit I don't understand the rationale for the patch at all.
> "M-x gdb" already repeats these commands when you type just RET
> into the interaction buffer, so what exactly does this change
> do, and how can I see its effect?
RET can repeat only the last command (afaik). If instead I want to run, in order:
1. continue
2. next
3. next
4. stepi
then without this patch, I would need to press
1. C-x C-a C-r
2. C-x C-a C-n
3. C-x C-a C-n
4. C-x C-a C-i
if using M-x gdb.
With the patch, I can press:
1. C-x C-a C-r
2. n
3. n
4. i
since the new repeat-mode defines the appropriate repeat map.
> ----------------------------------------
> From: Eli Zaretskii <eliz <at> gnu.org>
> Sent: Mon Jul 19 15:13:52 CEST 2021
> To: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: <leungbk <at> mailfence.com>, <49632 <at> debbugs.gnu.org>, <juri <at> linkov.net>
> Subject: Re: bug#49632: [PATCH] Ensure that M-x gdb populates gud-repeat-map
>
>
> > From: Lars Ingebrigtsen <larsi <at> gnus.org>
> > Date: Mon, 19 Jul 2021 15:06:31 +0200
> > Cc: 49632 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
> >
> > Brian Leung <leungbk <at> mailfence.com> writes:
> >
> > > * lisp/progmodes/gdb-mi.el (gdb): Populate gud-repeat-map. This is
> > > copied from the gud-gdb command.
> >
> > Instead of copying the code, perhaps it should be separated out into its
> > own function and then called from both places?
> >
> > But I don't quite understand why gud-repeat-map is populated in the
> > normal way -- i.e., in `gud-repeat-map' so that users can
> > redefine/override entries as usual.
>
> I admit I don't understand the rationale for the patch at all.
> "M-x gdb" already repeats these commands when you type just RET
> into the interaction buffer, so what exactly does this change
> do, and how can I see its effect?
--
Sent with https://mailfence.com
Secure and private email
--
Mailfence.com
Private and secure email
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Mon, 19 Jul 2021 15:45:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 49632 <at> debbugs.gnu.org (full text, mbox):
>> But I don't quite understand why gud-repeat-map is populated in the
>> normal way -- i.e., in `gud-repeat-map' so that users can
>> redefine/override entries as usual.
>
> I think it is presently done this way because things like M-x gdb, M-x pdb,
> etc. all use their own debugger commands, so we need to re-bind exactly the
> right ones each time. For example, in M-x perldb, gud-finish, gud-up, and
> gud-down are all commented out even though gdb clearly supports
> those functions.
Exactly. But this means that you need to populate a new separate map
'gdb-repeat-map' specific to 'gdb' commands. Also I noticed that the
current name of 'gud-repeat-map' is wrong. It should be renamed to
'gud-gdb-repeat-map'. So other debuggers could populate own repeat-maps
named e.g. 'sdb-repeat-map', 'jdb-repeat-map', 'perldb-repeat-map', etc.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Mon, 19 Jul 2021 15:53:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 49632 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> Exactly. But this means that you need to populate a new separate map
> 'gdb-repeat-map' specific to 'gdb' commands. Also I noticed that the
> current name of 'gud-repeat-map' is wrong. It should be renamed to
> 'gud-gdb-repeat-map'. So other debuggers could populate own repeat-maps
> named e.g. 'sdb-repeat-map', 'jdb-repeat-map', 'perldb-repeat-map', etc.
I see. Then Brian's patch is functionally correct, but it shouldn't be
copy-and-pasted -- instead separating it out into a helper function and
using it both places seems like the correct thing to do.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Mon, 19 Jul 2021 16:06:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 49632 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 19 Jul 2021 16:57:11 +0200 (CEST)
> From: Brian Leung <leungbk <at> mailfence.com>
> Cc: 49632 <at> debbugs.gnu.org, juri <at> linkov.net
>
> RET can repeat only the last command (afaik). If instead I want to run, in order:
>
> 1. continue
> 2. next
> 3. next
> 4. stepi
>
> then without this patch, I would need to press
>
> 1. C-x C-a C-r
> 2. C-x C-a C-n
> 3. C-x C-a C-n
> 4. C-x C-a C-i
>
> if using M-x gdb.
I would instead use M-p (one or more times), then RET. Isn't it
better, especially since it works when using GDB's own CLI prompt?
Or did you mean you want to invoke these commands in the program
source buffer, not in the GUD interaction buffer? But in that case,
how do I exit the repeat-mode, to be able to edit the sources?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Mon, 19 Jul 2021 22:02:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 49632 <at> debbugs.gnu.org (full text, mbox):
>> RET can repeat only the last command (afaik). If instead I want to run, in order:
>>
>> 1. continue
>> 2. next
>> 3. next
>> 4. stepi
>>
>> then without this patch, I would need to press
>>
>> 1. C-x C-a C-r
>> 2. C-x C-a C-n
>> 3. C-x C-a C-n
>> 4. C-x C-a C-i
>>
>> if using M-x gdb.
>
> I would instead use M-p (one or more times), then RET. Isn't it
> better, especially since it works when using GDB's own CLI prompt?
>
> Or did you mean you want to invoke these commands in the program
> source buffer, not in the GUD interaction buffer? But in that case,
> how do I exit the repeat-mode, to be able to edit the sources?
'repeat-mode' provides several ways to exit it:
1. type a non-repeatable key (like a non-isearch key exits isearch-mode);
2. customize repeat-exit-key e.g. to RET (then RET exits like in isearch-mode);
3. customize repeat-exit-timeout to exit after a timeout.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Sat, 24 Jul 2021 03:35:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 49632 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
OK, I've updated the patch following Juri's suggestions.
> ----------------------------------------
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Sent: Mon Jul 19 17:52:43 CEST 2021
> To: Juri Linkov <juri <at> linkov.net>
> Cc: Brian Leung <leungbk <at> mailfence.com>, <49632 <at> debbugs.gnu.org>
> Subject: Re: bug#49632: [PATCH] Ensure that M-x gdb populates gud-repeat-map
>
>
> Juri Linkov <juri <at> linkov.net> writes:
>
> > Exactly. But this means that you need to populate a new separate map
> > 'gdb-repeat-map' specific to 'gdb' commands. Also I noticed that the
> > current name of 'gud-repeat-map' is wrong. It should be renamed to
> > 'gud-gdb-repeat-map'. So other debuggers could populate own repeat-maps
> > named e.g. 'sdb-repeat-map', 'jdb-repeat-map', 'perldb-repeat-map', etc.
>
> I see. Then Brian's patch is functionally correct, but it shouldn't be
> copy-and-pasted -- instead separating it out into a helper function and
> using it both places seems like the correct thing to do.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
> bloggy blog: http://lars.ingebrigtsen.no
--
Sent with https://mailfence.com
Secure and private email
--
Mailfence.com
Private and secure email
[0001-Ensure-that-gud-commands-for-M-x-gdb-are-handled-by-.patch (text/x-diff, attachment)]
[0002-Ensure-that-gud-commands-for-non-GDB-debuggers-are-h.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Sun, 25 Jul 2021 06:28:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 49632 <at> debbugs.gnu.org (full text, mbox):
Brian Leung <leungbk <at> mailfence.com> writes:
> OK, I've updated the patch following Juri's suggestions.
Skimming the patch, it looks good to me. Juri, do you have any
comments?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Sun, 25 Jul 2021 20:59:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 49632 <at> debbugs.gnu.org (full text, mbox):
>> OK, I've updated the patch following Juri's suggestions.
>
> Skimming the patch, it looks good to me. Juri, do you have any
> comments?
There is one thing that I don't understand: is the
helper function gud-set-repeat-map-property really needed?
If e.g. the defvar gud-gdb-repeat-map uses such symbols as 'gud-next',
could it put the 'repeat-map' property on the same symbols
with reference to the variable 'map' directly in these defvars?
Then only defvars will be needed, and no changes in gud-gdb, gdb.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Sun, 25 Jul 2021 21:29:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 49632 <at> debbugs.gnu.org (full text, mbox):
> There is one thing that I don't understand: is the
> helper function gud-set-repeat-map-property really needed?
>
> If e.g. the defvar gud-gdb-repeat-map uses such symbols as 'gud-next',
> could it put the 'repeat-map' property on the same symbols
> with reference to the variable 'map' directly in these defvars?
> Then only defvars will be needed, and no changes in gud-gdb, gdb.
If we assign the repeat-map property within the defvars and avoid doing so in the M-x gdb commands, then after gud.el gets loaded, the repeat-map property on (say) gud-next will be 'jdb, since jdb-repeat-map is the last such foo-repeat-map defvar appearing in gud.el. In that case, calling M-x perldb and then running gud-next when repeat-mode is on will bring up the jdb-repeat-map, which contains some commands that aren't defined for perldb. So I think the gud-set-repeat-map-property macro (or something like it) is necessary.
> ----------------------------------------
> From: Juri Linkov <juri <at> linkov.net>
> Sent: Sun Jul 25 22:53:31 CEST 2021
> To: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Brian Leung <leungbk <at> mailfence.com>, <49632 <at> debbugs.gnu.org>
> Subject: Re: bug#49632: [PATCH] Ensure that M-x gdb populates gud-repeat-map
>
>
> >> OK, I've updated the patch following Juri's suggestions.
> >
> > Skimming the patch, it looks good to me. Juri, do you have any
> > comments?
>
> There is one thing that I don't understand: is the
> helper function gud-set-repeat-map-property really needed?
>
> If e.g. the defvar gud-gdb-repeat-map uses such symbols as 'gud-next',
> could it put the 'repeat-map' property on the same symbols
> with reference to the variable 'map' directly in these defvars?
> Then only defvars will be needed, and no changes in gud-gdb, gdb.
--
Sent with https://mailfence.com
Secure and private email
--
Mailfence.com
Private and secure email
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Mon, 26 Jul 2021 23:01:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 49632 <at> debbugs.gnu.org (full text, mbox):
>> There is one thing that I don't understand: is the
>> helper function gud-set-repeat-map-property really needed?
>>
>> If e.g. the defvar gud-gdb-repeat-map uses such symbols as 'gud-next',
>> could it put the 'repeat-map' property on the same symbols
>> with reference to the variable 'map' directly in these defvars?
>> Then only defvars will be needed, and no changes in gud-gdb, gdb.
>
> If we assign the repeat-map property within the defvars and avoid doing so
> in the M-x gdb commands, then after gud.el gets loaded, the repeat-map
> property on (say) gud-next will be 'jdb, since jdb-repeat-map is the last
> such foo-repeat-map defvar appearing in gud.el. In that case, calling M-x
> perldb and then running gud-next when repeat-mode is on will bring up the
> jdb-repeat-map, which contains some commands that aren't defined for
> perldb. So I think the gud-set-repeat-map-property macro (or something like
> it) is necessary.
You are right. Then I have only minor comments:
1. I thought that you want to create two separate maps for gud-gdb and gdb.
This is the reason why I suggested to rename gud-repeat-map to gud-gdb-repeat-map.
But since you use only one map for gbd and gud-gdb, then the name
gud-repeat-map is fine.
2. Is there a reason why gud-set-repeat-map-property should be a macro,
but not a function? When it's a macro, there are problems such that
when the user modifies the map, then the function that uses the macro
needs to be recompiled.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Tue, 27 Jul 2021 04:10:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 49632 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Is there a reason why gud-set-repeat-map-property should be a macro,
> but not a function? When it's a macro, there are problems such that
> when the user modifies the map, then the function that uses the macro
> needs to be recompiled.
When I wrote initially wrote gud-set-repeat-map-property, I couldn't figure out how to make gud-set-repeat-map-property work as a function since the repeat-map property needed to be a symbol corresponding to a keymap, and not an evaluated keymap.
I've updated the patch with a change to the repeat-post-hook function in repeat.el to accept an evaluated keymap, which permits a function version of gud-set-repeat-map-property.
> ----------------------------------------
> From: Juri Linkov <juri <at> linkov.net>
> Sent: Tue Jul 27 00:48:20 CEST 2021
> To: Brian Leung <leungbk <at> mailfence.com>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, <49632 <at> debbugs.gnu.org>
> Subject: Re: bug#49632: [PATCH] Ensure that M-x gdb populates gud-repeat-map
>
>
> >> There is one thing that I don't understand: is the
> >> helper function gud-set-repeat-map-property really needed?
> >>
> >> If e.g. the defvar gud-gdb-repeat-map uses such symbols as 'gud-next',
> >> could it put the 'repeat-map' property on the same symbols
> >> with reference to the variable 'map' directly in these defvars?
> >> Then only defvars will be needed, and no changes in gud-gdb, gdb.
> >
> > If we assign the repeat-map property within the defvars and avoid doing so
> > in the M-x gdb commands, then after gud.el gets loaded, the repeat-map
> > property on (say) gud-next will be 'jdb, since jdb-repeat-map is the last
> > such foo-repeat-map defvar appearing in gud.el. In that case, calling M-x
> > perldb and then running gud-next when repeat-mode is on will bring up the
> > jdb-repeat-map, which contains some commands that aren't defined for
> > perldb. So I think the gud-set-repeat-map-property macro (or something like
> > it) is necessary.
>
> You are right. Then I have only minor comments:
>
> 1. I thought that you want to create two separate maps for gud-gdb and gdb.
> This is the reason why I suggested to rename gud-repeat-map to gud-gdb-repeat-map.
> But since you use only one map for gbd and gud-gdb, then the name
> gud-repeat-map is fine.
>
> 2. Is there a reason why gud-set-repeat-map-property should be a macro,
> but not a function? When it's a macro, there are problems such that
> when the user modifies the map, then the function that uses the macro
> needs to be recompiled.
--
Sent with https://mailfence.com
Secure and private email
--
Mailfence.com
Private and secure email
[0001-Ensure-that-gud-commands-for-M-x-gdb-are-handled-by-.patch (text/x-diff, attachment)]
[0002-Ensure-that-gud-commands-for-non-GDB-debuggers-are-h.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Tue, 27 Jul 2021 06:47:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 49632 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I found a way to make gud-set-repeat-map-property a function without having to change repeat.el. See attached for an updated patch.
> ----------------------------------------
> From: Brian Leung <leungbk <at> mailfence.com>
> Sent: Tue Jul 27 06:09:14 CEST 2021
> To: Juri Linkov <juri <at> linkov.net>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, <49632 <at> debbugs.gnu.org>
> Subject: Re: bug#49632: [PATCH] Ensure that M-x gdb populates gud-repeat-map
>
>
> > Is there a reason why gud-set-repeat-map-property should be a macro,
> > but not a function? When it's a macro, there are problems such that
> > when the user modifies the map, then the function that uses the macro
> > needs to be recompiled.
>
> When I wrote initially wrote gud-set-repeat-map-property, I couldn't figure out how to make gud-set-repeat-map-property work as a function since the repeat-map property needed to be a symbol corresponding to a keymap, and not an evaluated keymap.
>
> I've updated the patch with a change to the repeat-post-hook function in repeat.el to accept an evaluated keymap, which permits a function version of gud-set-repeat-map-property.
>
> > ----------------------------------------
> > From: Juri Linkov <juri <at> linkov.net>
> > Sent: Tue Jul 27 00:48:20 CEST 2021
> > To: Brian Leung <leungbk <at> mailfence.com>
> > Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, <49632 <at> debbugs.gnu.org>
> > Subject: Re: bug#49632: [PATCH] Ensure that M-x gdb populates gud-repeat-map
> >
> >
> > >> There is one thing that I don't understand: is the
> > >> helper function gud-set-repeat-map-property really needed?
> > >>
> > >> If e.g. the defvar gud-gdb-repeat-map uses such symbols as 'gud-next',
> > >> could it put the 'repeat-map' property on the same symbols
> > >> with reference to the variable 'map' directly in these defvars?
> > >> Then only defvars will be needed, and no changes in gud-gdb, gdb.
> > >
> > > If we assign the repeat-map property within the defvars and avoid doing so
> > > in the M-x gdb commands, then after gud.el gets loaded, the repeat-map
> > > property on (say) gud-next will be 'jdb, since jdb-repeat-map is the last
> > > such foo-repeat-map defvar appearing in gud.el. In that case, calling M-x
> > > perldb and then running gud-next when repeat-mode is on will bring up the
> > > jdb-repeat-map, which contains some commands that aren't defined for
> > > perldb. So I think the gud-set-repeat-map-property macro (or something like
> > > it) is necessary.
> >
> > You are right. Then I have only minor comments:
> >
> > 1. I thought that you want to create two separate maps for gud-gdb and gdb.
> > This is the reason why I suggested to rename gud-repeat-map to gud-gdb-repeat-map.
> > But since you use only one map for gbd and gud-gdb, then the name
> > gud-repeat-map is fine.
> >
> > 2. Is there a reason why gud-set-repeat-map-property should be a macro,
> > but not a function? When it's a macro, there are problems such that
> > when the user modifies the map, then the function that uses the macro
> > needs to be recompiled.
>
>
> --
> Sent with https://mailfence.com
> Secure and private email
>
> --
> Mailfence.com
> Private and secure email
--
Sent with https://mailfence.com
Secure and private email
--
Mailfence.com
Private and secure email
[0001-Ensure-that-gud-commands-for-M-x-gdb-are-handled-by-.patch (text/x-diff, attachment)]
[0002-Ensure-that-gud-commands-for-non-GDB-debuggers-are-h.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Tue, 27 Jul 2021 21:17:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 49632 <at> debbugs.gnu.org (full text, mbox):
tags 49632 fixed
close 49632 28.0.50
thanks
> I found a way to make gud-set-repeat-map-property a function without
> having to change repeat.el. See attached for an updated patch.
Thanks, using a symbol is the correct way to implement this indeed.
So now pushed to master.
Added tag(s) fixed.
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org
.
(Tue, 27 Jul 2021 21:17:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 28.0.50, send any further explanations to
49632 <at> debbugs.gnu.org and Brian Leung <leungbk <at> mailfence.com>
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org
.
(Tue, 27 Jul 2021 21:17:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Wed, 28 Jul 2021 11:31:01 GMT)
Full text and
rfc822 format available.
Message #60 received at 49632 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Date: Wed, 28 Jul 2021 00:15:46 +0300
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 49632 <at> debbugs.gnu.org
>
> > I found a way to make gud-set-repeat-map-property a function without
> > having to change repeat.el. See attached for an updated patch.
>
> Thanks, using a symbol is the correct way to implement this indeed.
> So now pushed to master.
This causes the following unwanted side-effect:
GEN loaddefs.el
Not registering prefix "gu" from gud. Affects: ("guiler-repeat-map" "gud-val" "gud-last-frame" "gud-last-last-frame" "gud-last-speedbar-stackframe" "gud-query-cmdline" "gud-xdb-history" "gud-xdb-directories" "gud-xdb-massage-args" "gud-xdb-marker-filter" "gud-goto-info" "gud-gdb-history" "gud-gdb-marker-regexp" "gud-gdb-marker-filter" "gud-gdb-completions" "gud-gdb-completions-1" "gud-gdb-completion-function" "gud-gdb-completion-at-point" "gud-gdb-fetch-lines-filter" "gud-gdb-fetched-stack-frame" "gud-gdb-goto-stackframe" "gud-gdb-get-stackframe" "gud-gdb-repeat-map" "gud-gdb-run-command-fetch-lines" "gud-gud-gdb-command-name" "gud-guiler-history" "gud-guiler-lastfile" "gud-guiler-marker-filter" "gud-guiler-command-name" "gud-jdb-use-classpath" "gud-jdb-history" "gud-jdb-directories" "gud-jdb-sourcepath" "gud-jdb-source-files" "gud-jdb-skip-traditional-or-documentation-comment" "gud-jdb-skip-whitespace" "gud-jdb-skip-whitespace-and-comments" "gud-jdb-skip-id-ish-thing" "gud-jdb-skip-single-line-comment" "gud-jdb-skip-string-literal" "gud-jdb-skip-character-literal" "gud-jdb-skip-block" "gud-jdb-analysis-buffer" "gud-jdb-analyze-source" "gud-jdb-build-source-files-list" "gud-jdb-build-class-source-alist" "gud-jdb-build-class-source-alist-for-file" "gud-jdb-lowest-stack-level" "gud-jdb-find-source" "gud-jdb-find-source-file" "gud-jdb-find-source-using-classpath" "gud-jdb-parse-classpath-string" "gud-jdb-massage-args" "gud-jdb-marker-filter" "gud-jdb-class-source-alist" "gud-jdb-classpath" "gud-jdb-classpath-string" "gud-jdb-command-name" "gud-marker-filter" "gud-marker-acc" "gud-marker-acc-max-length" "gud-mode" "gud-mode-map" "gud-mips-p" "gud-mipsdbx-marker-filter" "gud-minor-mode" "gud-minor-mode-type" "gud-overlay-arrow-position" "gud-symbol" "gud-stop-subjob" "gud-speedbar-key-map" "gud-speedbar-item-info" "gud-speedbar-menu-items" "gud-speedbar-buttons" "gud-sdb-history" "gud-sdb-needs-tags" "gud-sdb-lastfile" "gud-sdb-marker-filter" "gud-sdb-find-file" "gud-set-repeat-map-property" "gud-set-buffer" "gud-sentinel" "gud-key-prefix" "gud-keep-buffer" "gud-kill-buffer-hook" "gud-dbx-history" "gud-dbx-directories" "gud-dbx-massage-args" "gud-dbx-marker-filter" "gud-dbx-command-name" "gud-dbx-use-stopformat-p" "gud-dguxdbx-marker-filter" "gud-def" "gud-delete-prompt-marker" "gud-display-frame" "gud-display-line" "gud-chdir-before-run" "gud-comint-buffer" "gud-common-init" "gud-call" "gud-running" "gud-reset" "gud-read-address" "gud-refresh" "gud-irix-p" "gud-irixdbx-marker-filter" "gud-install-speedbar-variables" "gud-innermost-expr" "gud-basic-call" "gud-backward-sexp" "gud-perldb-history" "gud-perldb-massage-args" "gud-perldb-marker-filter" "gud-perldb-command-name" "gud-pdb-history" "gud-pdb-marker-regexp" "gud-pdb-marker-regexp-line-group" "gud-pdb-marker-regexp-file-group" "gud-pdb-marker-regexp-fnname-group" "gud-pdb-marker-regexp-start" "gud-pdb-marker-filter" "gud-pdb-command-name" "gud-prev-expr" "gud-next-expr" "gud-expansion-speedbar-buttons" "gud-expr-compound" "gud-expr-compound-sep" "gud-format-command" "gud-forward-sexp" "gud-file-name" "gud-filter" "gud-filter-pending-text" "gud-filter-defer-flag" "gud-find-file" "gud-find-expr" "gud-find-expr-function" "gud-find-c-expr" "gud-find-class" "gud-target-name" "gud-tool-bar-item-visible-no-fringe" "gud-tool-bar-map" "gud-tooltip-change-major-mode" "gud-tooltip-activate-mouse-motions" "gud-tooltip-activate-mouse-motions-if-enabled" "gud-tooltip-modes" "gud-tooltip-mouse-motion" "gud-tooltip-mouse-motions-active" "gud-tooltip-echo-area" "gud-tooltip-event" "gud-tooltip-display" "gud-tooltip-dereference" "gud-tooltip-process-output" "gud-tooltip-print-command" "gud-tooltip-tips")
Can we please avoid this regression?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Wed, 28 Jul 2021 16:28:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 49632 <at> debbugs.gnu.org (full text, mbox):
> This causes the following unwanted side-effect:
>
> GEN loaddefs.el
> Not registering prefix "gu" from gud. Affects: ("guiler-repeat-map" "gud-val" "gud-last-frame" "gud-last-last-frame" "gud-last-speedbar-stackframe" "gud-query-cmdline" "gud-xdb-history" "gud-xdb-directories" "gud-xdb-massage-args" "gud-xdb-marker-filter" "gud-goto-info" "gud-gdb-history" "gud-gdb-marker-regexp" "gud-gdb-marker-filter" "gud-gdb-completions" "gud-gdb-completions-1" "gud-gdb-completion-function" "gud-gdb-completion-at-point" "gud-gdb-fetch-lines-filter" "gud-gdb-fetched-stack-frame" "gud-gdb-goto-stackframe" "gud-gdb-get-stackframe" "gud-gdb-repeat-map" "gud-gdb-run-command-fetch-lines" "gud-gud-gdb-command-name" "gud-guiler-history" "gud-guiler-lastfile" "gud-guiler-marker-filter" "gud-guiler-command-name" "gud-jdb-use-classpath" "gud-jdb-history" "gud-jdb-directories" "gud-jdb-sourcepath" "gud-jdb-source-files" "gud-jdb-skip-traditional-or-documentation-comment" "gud-jdb-skip-whitespace" "gud-jdb-skip-whitespace-and-comments" "gud-jdb-skip-id-ish-thing" "gud-jdb-
sk
> ip-single-line-comment" "gud-jdb-skip-string-literal" "gud-jdb-skip-character-literal" "gud-jdb-skip-block" "gud-jdb-analysis-buffer" "gud-jdb-analyze-source" "gud-jdb-build-source-files-list" "gud-jdb-build-class-source-alist" "gud-jdb-build-class-source-alist-for-file" "gud-jdb-lowest-stack-level" "gud-jdb-find-source" "gud-jdb-find-source-file" "gud-jdb-find-source-using-classpath" "gud-jdb-parse-classpath-string" "gud-jdb-massage-args" "gud-jdb-marker-filter" "gud-jdb-class-source-alist" "gud-jdb-classpath" "gud-jdb-classpath-string" "gud-jdb-command-name" "gud-marker-filter" "gud-marker-acc" "gud-marker-acc-max-length" "gud-mode" "gud-mode-map" "gud-mips-p" "gud-mipsdbx-marker-filter" "gud-minor-mode" "gud-minor-mode-type" "gud-overlay-arrow-position" "gud-symbol" "gud-stop-subjob" "gud-speedbar-key-map" "gud-speedbar-item-info" "gud-speedbar-menu-items" "gud-speedbar-buttons" "gud-sdb-history" "gud-sdb-needs-tags" "gud-sdb-lastfile" "gud-sdb-marker-filter" "gud-sdb-find-file
"
> "gud-set-repeat-map-property" "gud-set-buffer" "gud-sentinel" "gud-key-prefix" "gud-keep-buffer" "gud-kill-buffer-hook" "gud-dbx-history" "gud-dbx-directories" "gud-dbx-massage-args" "gud-dbx-marker-filter" "gud-dbx-command-name" "gud-dbx-use-stopformat-p" "gud-dguxdbx-marker-filter" "gud-def" "gud-delete-prompt-marker" "gud-display-frame" "gud-display-line" "gud-chdir-before-run" "gud-comint-buffer" "gud-common-init" "gud-call" "gud-running" "gud-reset" "gud-read-address" "gud-refresh" "gud-irix-p" "gud-irixdbx-marker-filter" "gud-install-speedbar-variables" "gud-innermost-expr" "gud-basic-call" "gud-backward-sexp" "gud-perldb-history" "gud-perldb-massage-args" "gud-perldb-marker-filter" "gud-perldb-command-name" "gud-pdb-history" "gud-pdb-marker-regexp" "gud-pdb-marker-regexp-line-group" "gud-pdb-marker-regexp-file-group" "gud-pdb-marker-regexp-fnname-group" "gud-pdb-marker-regexp-start" "gud-pdb-marker-filter" "gud-pdb-command-name" "gud-prev-expr" "gud-next-expr" "gud-expansio
n-
> speedbar-buttons" "gud-expr-compound" "gud-expr-compound-sep" "gud-format-command" "gud-forward-sexp" "gud-file-name" "gud-filter" "gud-filter-pending-text" "gud-filter-defer-flag" "gud-find-file" "gud-find-expr" "gud-find-expr-function" "gud-find-c-expr" "gud-find-class" "gud-target-name" "gud-tool-bar-item-visible-no-fringe" "gud-tool-bar-map" "gud-tooltip-change-major-mode" "gud-tooltip-activate-mouse-motions" "gud-tooltip-activate-mouse-motions-if-enabled" "gud-tooltip-modes" "gud-tooltip-mouse-motion" "gud-tooltip-mouse-motions-active" "gud-tooltip-echo-area" "gud-tooltip-event" "gud-tooltip-display" "gud-tooltip-dereference" "gud-tooltip-process-output" "gud-tooltip-print-command" "gud-tooltip-tips")
>
> Can we please avoid this regression?
I haven't noticed this warning because it's not highlighted with the
warning face. Now fixed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49632
; Package
emacs
.
(Wed, 28 Jul 2021 16:31:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 49632 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: leungbk <at> mailfence.com, larsi <at> gnus.org, 49632 <at> debbugs.gnu.org
> Date: Wed, 28 Jul 2021 19:23:27 +0300
>
> > Can we please avoid this regression?
>
> I haven't noticed this warning because it's not highlighted with the
> warning face. Now fixed.
Thanks.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 26 Aug 2021 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 216 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.