[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#49632: [PATCH] Ensure that M-x gdb populates gud-repeat-map

From: Juri Linkov
Subject: bug#49632: [PATCH] Ensure that M-x gdb populates gud-repeat-map
Date: Tue, 27 Jul 2021 01:48:20 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)

>> 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 
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]