* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs @ 2015-10-28 19:20 Dima Kogan 2015-10-28 22:27 ` Andreas Schwab 2019-09-29 21:49 ` Stefan Kangas 0 siblings, 2 replies; 34+ messages in thread From: Dima Kogan @ 2015-10-28 19:20 UTC (permalink / raw) To: 21777 Hi. A regression occurred since 24.4.1, and gud-gdb now uses the pager by default. This means that when gdb wants to output more than N lines, it says ---Type <return> to continue, or q <return> to quit--- This is intended for gdb running in the console, but makes using gdb from emacs much less pleasant since extra user interaction becomes necessary. At worst, gdb sessions meant to be non-interactive (ones that have self-continuing breakpoint commands for instance) become forcefully interactive. Recipe: 1. emacs -Q 2. M-x gud-gdb (select any executable; it doesn't matter) 3. gdb command: show height Emacs 24.4.1 says (gdb) show height Number of lines gdb thinks are in a page is unlimited. This is good. The pager is off, and emacs will receive all gdb output without extra user interaction. Emacs from git says (gdb) show height Number of lines gdb thinks are in a page is 24. This is bad. After 24 lines of output gdb will pester the user. I haven't attempted to do any debugging here yet. Probably will look at it eventually, but if somebody knows what's wrong immediately, that'd be great ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2015-10-28 19:20 bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs Dima Kogan @ 2015-10-28 22:27 ` Andreas Schwab 2015-10-28 22:57 ` Dima Kogan 2019-09-29 21:49 ` Stefan Kangas 1 sibling, 1 reply; 34+ messages in thread From: Andreas Schwab @ 2015-10-28 22:27 UTC (permalink / raw) To: Dima Kogan; +Cc: 21777 Dima Kogan <dima@secretsauce.net> writes: > Emacs from git says > > (gdb) show height > Number of lines gdb thinks are in a page is 24. This is something that needs to be fixed in gdb, see init_page_info in gdb/utils.c. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2015-10-28 22:27 ` Andreas Schwab @ 2015-10-28 22:57 ` Dima Kogan 2015-10-29 16:16 ` Eli Zaretskii 0 siblings, 1 reply; 34+ messages in thread From: Dima Kogan @ 2015-10-28 22:57 UTC (permalink / raw) To: Andreas Schwab; +Cc: 21777 Andreas Schwab <schwab@linux-m68k.org> writes: > Dima Kogan <dima@secretsauce.net> writes: > >> Emacs from git says >> >> (gdb) show height >> Number of lines gdb thinks are in a page is 24. > > This is something that needs to be fixed in gdb, see init_page_info in > gdb/utils.c. Hi. Thanks for replying. Looking at gdb/utils.c, apparently gdb looks at the EMACS environment variable, which was set previously but is not anymore: https://github.com/emacs-mirror/emacs/commit/beaab898968caf8b243a33d24824d430fabc31fc This patch in emacs is what broke it. Options: 1. revert above patch 2. patch gdb to look at INSIDE_EMACS not EMACS 3. handle this inside emacs, not relying on gdb behavior I like 3. Emacs should be responsible for things emacs wants, not external applications, even if they're GNU applications. Also, it looks like gdb checks EMACS in a few more places, and I haven't looked at those yet. Thoughts? ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2015-10-28 22:57 ` Dima Kogan @ 2015-10-29 16:16 ` Eli Zaretskii 2015-10-29 22:58 ` Dima Kogan 0 siblings, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2015-10-29 16:16 UTC (permalink / raw) To: Dima Kogan; +Cc: 21777, schwab > From: Dima Kogan <dima@secretsauce.net> > Date: Wed, 28 Oct 2015 15:57:37 -0700 > Cc: 21777@debbugs.gnu.org > > Hi. Thanks for replying. Looking at gdb/utils.c, apparently gdb looks at > the EMACS environment variable, which was set previously but is not > anymore: > > https://github.com/emacs-mirror/emacs/commit/beaab898968caf8b243a33d24824d430fabc31fc > > This patch in emacs is what broke it. Options: > > 1. revert above patch That patch fixed a real-life bug, so I don't think reverting it is an option we should seriously consider. > 2. patch gdb to look at INSIDE_EMACS not EMACS That should be done regardless, I will submit a patch to GDB. > 3. handle this inside emacs, not relying on gdb behavior > > I like 3. Emacs should be responsible for things emacs wants, not > external applications, even if they're GNU applications. 3 is okay in principle, but you didn't show any specific suggestions. What did you have in mind? Please also keep in mind that "M-x gud-gdb" is a legacy command, and the more modern "M-x gdb" doesn't have that problem. There's also: 4. Fix this locally in your GDB init files (using GDB scripting facilities). > Also, it looks like gdb checks EMACS in a few more places, and I haven't > looked at those yet. Maybe I'm missing something, but I don't see any additional places except the one pointed out by Andreas. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2015-10-29 16:16 ` Eli Zaretskii @ 2015-10-29 22:58 ` Dima Kogan 2015-10-30 3:43 ` Dima Kogan 2015-10-30 7:54 ` Eli Zaretskii 0 siblings, 2 replies; 34+ messages in thread From: Dima Kogan @ 2015-10-29 22:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 21777, schwab Eli Zaretskii <eliz@gnu.org> writes: >> From: Dima Kogan <dima@secretsauce.net> >> >> Hi. Thanks for replying. Looking at gdb/utils.c, apparently gdb looks at >> the EMACS environment variable, which was set previously but is not >> anymore: >> >> 2. patch gdb to look at INSIDE_EMACS not EMACS > > That should be done regardless, I will submit a patch to GDB. Thanks for doing that! >> 3. handle this inside emacs, not relying on gdb behavior >> >> I like 3. Emacs should be responsible for things emacs wants, not >> external applications, even if they're GNU applications. > > 3 is okay in principle, but you didn't show any specific suggestions. > What did you have in mind? gud-gdb.el can send a "set height unlimited" command when it starts the gdb process. I'm happy to give you a patch, if you want. > Please also keep in mind that "M-x gud-gdb" is a legacy command, and > the more modern "M-x gdb" doesn't have that problem. I didn't like it when I tried it the last time; don't remember what specifically was the problem. But if we're still shipping gud-gdb, it should work properly, I think. > There's also: > > 4. Fix this locally in your GDB init files (using GDB scripting > facilities). But then it'll annoy others. >> Also, it looks like gdb checks EMACS in a few more places, and I haven't >> looked at those yet. > > Maybe I'm missing something, but I don't see any additional places > except the one pointed out by Andreas. You're right. I was looking at the readline in their tree, but that's unrelated. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2015-10-29 22:58 ` Dima Kogan @ 2015-10-30 3:43 ` Dima Kogan 2015-10-30 8:17 ` Eli Zaretskii 2015-10-30 7:54 ` Eli Zaretskii 1 sibling, 1 reply; 34+ messages in thread From: Dima Kogan @ 2015-10-30 3:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 21777, schwab Dima Kogan <dima@secretsauce.net> writes: > Eli Zaretskii <eliz@gnu.org> writes: > >>> From: Dima Kogan <dima@secretsauce.net> >>> >>> 3. handle this inside emacs, not relying on gdb behavior >> >> 3 is okay in principle, but you didn't show any specific suggestions. >> What did you have in mind? > > gud-gdb.el can send a "set height unlimited" command when it starts the > gdb process. I'm happy to give you a patch, if you want. Something like this: --------------------------------------------------------------------------- diff --git a/lisp/progmodes/gud.el b/lisp/progmodes/gud.el index 9ab0667..61ae85c 100644 --- a/lisp/progmodes/gud.el +++ b/lisp/progmodes/gud.el @@ -785,6 +785,8 @@ directory and source-file directory for your debugger." (setq gdb-first-prompt t) (setq gud-running nil) (setq gud-filter-pending-text nil) + + (gud-basic-call "set height unlimited") (run-hooks 'gud-gdb-mode-hook)) ;; The completion process filter indicates when it is finished. --------------------------------------------------------------------------- This works. The main issue is that it creates an extra "(gdb)" prompt we'd want to suppress. You get the idea, however. ^ permalink raw reply related [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2015-10-30 3:43 ` Dima Kogan @ 2015-10-30 8:17 ` Eli Zaretskii 2015-10-30 9:13 ` Dima Kogan 0 siblings, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2015-10-30 8:17 UTC (permalink / raw) To: Dima Kogan; +Cc: 21777, schwab > From: Dima Kogan <dima@secretsauce.net> > Cc: schwab@linux-m68k.org, 21777@debbugs.gnu.org > Date: Thu, 29 Oct 2015 20:43:35 -0700 > > --------------------------------------------------------------------------- > diff --git a/lisp/progmodes/gud.el b/lisp/progmodes/gud.el > index 9ab0667..61ae85c 100644 > --- a/lisp/progmodes/gud.el > +++ b/lisp/progmodes/gud.el > @@ -785,6 +785,8 @@ directory and source-file directory for your debugger." > (setq gdb-first-prompt t) > (setq gud-running nil) > (setq gud-filter-pending-text nil) > + > + (gud-basic-call "set height unlimited") > (run-hooks 'gud-gdb-mode-hook)) > > ;; The completion process filter indicates when it is finished. > --------------------------------------------------------------------------- > > > This works. The main issue is that it creates an extra "(gdb)" prompt > we'd want to suppress. You get the idea, however. What if the user has "set height 100" in their ~/.gdbinit, or in the system-wide gdbinit file? Will those settings be overridden? If so, we cannot fix the problem this way, not by default anyway. Thanks. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2015-10-30 8:17 ` Eli Zaretskii @ 2015-10-30 9:13 ` Dima Kogan 2015-10-30 9:32 ` Eli Zaretskii 0 siblings, 1 reply; 34+ messages in thread From: Dima Kogan @ 2015-10-30 9:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 21777, schwab Eli Zaretskii <eliz@gnu.org> writes: > What if the user has "set height 100" in their ~/.gdbinit, or in the > system-wide gdbinit file? Will those settings be overridden? If so, we > cannot fix the problem this way, not by default anyway. Yes. This overrides any user settings. I really can't imagine why somebody would want a pager inside emacs, but maybe I just need more imagination. What is more likely I think is that somebody would have a "set height N" in their .gdbinit, intending it to be picked up during console gdb use, and that this somebody would be annoyed that this setting persists when using gdb through gud. That somebody would want a different setting for the two use cases, which is not easily done, currently. So I'm in favor of overriding the user defaults here. Otherwise, how about this: - we have a variable 'gud-gdb-set-height-unlimited', which has 3 states: uninitialized, yes, no - when gud starts up, if it's 'uninitialized', we ask the user if they want to override, and whether to do so in the future; if they say yes, we update their .emacs.d/init.el. narrow-to-region has this type of user querying. We override only if it's 'yes' This would take care of it, but a desire to have a pager inside gud sounds so crazy to me, that I'd rather just force it. What do we do for vc-mode interaction with git? It has a similar situation where a user can configure git to use a pager. But in that case we completely override that setting, don't we? If so, that would be a precedent to handle gdb in the same way. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2015-10-30 9:13 ` Dima Kogan @ 2015-10-30 9:32 ` Eli Zaretskii 2015-10-30 14:01 ` Eli Zaretskii 2020-09-20 21:18 ` Lars Ingebrigtsen 0 siblings, 2 replies; 34+ messages in thread From: Eli Zaretskii @ 2015-10-30 9:32 UTC (permalink / raw) To: Dima Kogan; +Cc: 21777, schwab > From: Dima Kogan <dima@secretsauce.net> > Cc: schwab@linux-m68k.org, 21777@debbugs.gnu.org > Date: Fri, 30 Oct 2015 02:13:02 -0700 > > Eli Zaretskii <eliz@gnu.org> writes: > > > What if the user has "set height 100" in their ~/.gdbinit, or in the > > system-wide gdbinit file? Will those settings be overridden? If so, we > > cannot fix the problem this way, not by default anyway. > > Yes. This overrides any user settings. I really can't imagine why > somebody would want a pager inside emacs, but maybe I just need more > imagination. IME, users sometimes have some use cases that look really weird to me, but are somehow very important to them. So I'm trying to avoid stepping on their toes as much as possible, even if I cannot imagine those use cases in advance. > So I'm in favor of overriding the user defaults here. Otherwise, how > about this: > > - we have a variable 'gud-gdb-set-height-unlimited', > which has 3 states: uninitialized, yes, no > > - when gud starts up, if it's 'uninitialized', we ask the user if they > want to override, and whether to do so in the future; if they say yes, > we update their .emacs.d/init.el. narrow-to-region has this type of > user querying. We override only if it's 'yes' Why not a simpler boolean, off by default? This problem will go away soon enough, so maybe solutions that are too complicated would be over-engineering it? Btw, does gud.el know the version of GDB it runs? If so, this option should be a no-op for GDB 7.11 and later. > What do we do for vc-mode interaction with git? It has a similar > situation where a user can configure git to use a pager. But in that > case we completely override that setting, don't we? If so, that would be > a precedent to handle gdb in the same way. In vc-git.el, we don't present a CLI-like interface to Git, we just consume all the Git output and then process it. So the situation there is slightly different, I think. But I will let other chime in and express their opinions. Thanks. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2015-10-30 9:32 ` Eli Zaretskii @ 2015-10-30 14:01 ` Eli Zaretskii 2015-10-30 19:05 ` Dima Kogan 2020-09-20 21:18 ` Lars Ingebrigtsen 1 sibling, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2015-10-30 14:01 UTC (permalink / raw) To: dima; +Cc: 21777 > Date: Fri, 30 Oct 2015 11:32:47 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 21777@debbugs.gnu.org, schwab@linux-m68k.org > > > - we have a variable 'gud-gdb-set-height-unlimited', > > which has 3 states: uninitialized, yes, no > > > > - when gud starts up, if it's 'uninitialized', we ask the user if they > > want to override, and whether to do so in the future; if they say yes, > > we update their .emacs.d/init.el. narrow-to-region has this type of > > user querying. We override only if it's 'yes' > > Why not a simpler boolean, off by default? This problem will go away > soon enough, so maybe solutions that are too complicated would be > over-engineering it? I think if we have such an option, and it's by default off, we might consider not bothering about gdbinit commands that contradict the effect of that option. The option gives users enough power to decide what they want more. WDYT? ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2015-10-30 14:01 ` Eli Zaretskii @ 2015-10-30 19:05 ` Dima Kogan 2015-10-30 20:34 ` Eli Zaretskii 0 siblings, 1 reply; 34+ messages in thread From: Dima Kogan @ 2015-10-30 19:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 21777 Eli Zaretskii <eliz@gnu.org> writes: >> Date: Fri, 30 Oct 2015 11:32:47 +0200 >> From: Eli Zaretskii <eliz@gnu.org> >> Cc: 21777@debbugs.gnu.org, schwab@linux-m68k.org >> >> > - we have a variable 'gud-gdb-set-height-unlimited', >> > which has 3 states: uninitialized, yes, no >> > >> > - when gud starts up, if it's 'uninitialized', we ask the user if they >> > want to override, and whether to do so in the future; if they say yes, >> > we update their .emacs.d/init.el. narrow-to-region has this type of >> > user querying. We override only if it's 'yes' >> >> Why not a simpler boolean, off by default? This problem will go away >> soon enough, so maybe solutions that are too complicated would be >> over-engineering it? You need a third state to know whether to pester the user or not > I think if we have such an option, and it's by default off, we might > consider not bothering about gdbinit commands that contradict the > effect of that option. The option gives users enough power to decide > what they want more. Right. This was the idea. I'll send a patch at some point. Not today. Thanks ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2015-10-30 19:05 ` Dima Kogan @ 2015-10-30 20:34 ` Eli Zaretskii 0 siblings, 0 replies; 34+ messages in thread From: Eli Zaretskii @ 2015-10-30 20:34 UTC (permalink / raw) To: Dima Kogan; +Cc: 21777 > From: Dima Kogan <dima@secretsauce.net> > Cc: 21777@debbugs.gnu.org > Date: Fri, 30 Oct 2015 12:05:54 -0700 > > >> > - when gud starts up, if it's 'uninitialized', we ask the user if they > >> > want to override, and whether to do so in the future; if they say yes, > >> > we update their .emacs.d/init.el. narrow-to-region has this type of > >> > user querying. We override only if it's 'yes' > >> > >> Why not a simpler boolean, off by default? This problem will go away > >> soon enough, so maybe solutions that are too complicated would be > >> over-engineering it? > > You need a third state to know whether to pester the user or not Why pester them? Let's rely on them to know what to do, or ask. > > I think if we have such an option, and it's by default off, we might > > consider not bothering about gdbinit commands that contradict the > > effect of that option. The option gives users enough power to decide > > what they want more. > > Right. This was the idea. I'll send a patch at some point. Not today. There's no rush. Thanks in advance. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2015-10-30 9:32 ` Eli Zaretskii 2015-10-30 14:01 ` Eli Zaretskii @ 2020-09-20 21:18 ` Lars Ingebrigtsen 2020-09-21 14:03 ` Eli Zaretskii 1 sibling, 1 reply; 34+ messages in thread From: Lars Ingebrigtsen @ 2020-09-20 21:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 21777, schwab, Dima Kogan Eli Zaretskii <eliz@gnu.org> writes: > IME, users sometimes have some use cases that look really weird to me, > but are somehow very important to them. So I'm trying to avoid > stepping on their toes as much as possible, even if I cannot imagine > those use cases in advance. I worked up a patch for this, but in testing, there's a number of problems. 1) When resizing a frame, the height in gdb is overwritten. Where does that come from? I tried grepping, but couldn't find anything. 2) Sending a command this way to gdb gives us an extra prompt, which isn't nice. 3) If you start gdb with M-x gdb instead of M-x gud-gdb, the height variable in gdb is always switched off: (gdb-input "-gdb-set height 0" 'ignore) So why shouldn't gud-gdb do the same thing? diff --git a/doc/emacs/building.texi b/doc/emacs/building.texi index 7074bd45d7..ac54c570cd 100644 --- a/doc/emacs/building.texi +++ b/doc/emacs/building.texi @@ -1040,6 +1040,15 @@ GDB User Interface Layout need to check that the breakpoints in recently edited source files are still in the right places. +@vindex gud-pager-height + GDB normally uses a pager when displaying output (like backtraces). +This can be inconvenient when running inside Emacs, so the default +value of @code{gud-pager-height} is @code{unlimited}, meaning that the +pager is disabled. This variable can also be a number (which is used +as the number of lines by the pager), or @code{nil}, meaning that the +pager setting shouldn't be changed from the gdb defaults (or +@file{.gdbinit} settings). + @node Source Buffers @subsubsection Source Buffers @cindex fringes, for debugging diff --git a/etc/NEWS b/etc/NEWS index 1f52341ae4..3014eddbdd 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1034,6 +1034,10 @@ window after starting). This variable defaults to nil. ** Miscellaneous +*** New user option 'gud-pager-height' +This variable is used to set up the gdb pager, and defaults to +`unlimited', meaning that a pager won't be used. + +++ *** Interactive regular expression search now uses faces for sub-groups. E.g., 'C-M-s foo-\([0-9]+\)' will now use the 'isearch-group-1' face diff --git a/lisp/progmodes/gud.el b/lisp/progmodes/gud.el index 84c473ddb7..7acc540b01 100644 --- a/lisp/progmodes/gud.el +++ b/lisp/progmodes/gud.el @@ -67,6 +67,19 @@ gud-key-prefix :type 'key-sequence :group 'gud) +(defcustom gud-pager-height 'unlimited + "The size of a page when gdb displays output. +gdb normally uses a pager when displaying things like +backtraces (or other things that take a lot of room). This +variable allows customizing the pager when gdb is run from Emacs. + +This can be a number (the number of lines), `unlimited' (don't +use the pager at all), or nil (don't change the defaults)." + :type '(choice (const :tag "No paging" unlimited) + integer + (const :tag "Don't set" nil)) + :version "28.1") + (global-set-key (vconcat gud-key-prefix "\C-l") 'gud-refresh) ;; (define-key ctl-x-map " " 'gud-break); backward compatibility hack @@ -796,6 +809,9 @@ gud-gdb (setq gdb-first-prompt t) (setq gud-running nil) (setq gud-filter-pending-text nil) + + (when gud-pager-height + (gud-basic-call (format "set height %s" gud-pager-height))) (run-hooks 'gud-gdb-mode-hook)) ;; The completion process filter indicates when it is finished. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply related [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-20 21:18 ` Lars Ingebrigtsen @ 2020-09-21 14:03 ` Eli Zaretskii 2020-09-21 14:07 ` Lars Ingebrigtsen 0 siblings, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2020-09-21 14:03 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 21777, schwab, dima > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: Dima Kogan <dima@secretsauce.net>, 21777@debbugs.gnu.org, > schwab@linux-m68k.org > Date: Sun, 20 Sep 2020 23:18:32 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > > IME, users sometimes have some use cases that look really weird to me, > > but are somehow very important to them. So I'm trying to avoid > > stepping on their toes as much as possible, even if I cannot imagine > > those use cases in advance. > > I worked up a patch for this, but in testing, there's a number of > problems. Do you see the original problem with a recent version of GDB? In the discussion, I mentioned that the change to follow that of Emacs was installed in GDB back then, so it's reasonable to expect that we no longer have a problem described in this bug report. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-21 14:03 ` Eli Zaretskii @ 2020-09-21 14:07 ` Lars Ingebrigtsen 2020-09-22 15:46 ` Eli Zaretskii 0 siblings, 1 reply; 34+ messages in thread From: Lars Ingebrigtsen @ 2020-09-21 14:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 21777, schwab, dima Eli Zaretskii <eliz@gnu.org> writes: >> I worked up a patch for this, but in testing, there's a number of >> problems. > > Do you see the original problem with a recent version of GDB? In the > discussion, I mentioned that the change to follow that of Emacs was > installed in GDB back then, so it's reasonable to expect that we no > longer have a problem described in this bug report. No, the problem is still there -- If you say `M-x gud-gdb' and then issue a backtrace, then the gdb pager kicks in. (This problem is not present in `M-x gdb', which tells gdb to switch the pager off when it starts gdb.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-21 14:07 ` Lars Ingebrigtsen @ 2020-09-22 15:46 ` Eli Zaretskii 2020-09-22 15:51 ` Lars Ingebrigtsen 0 siblings, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2020-09-22 15:46 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 21777, schwab, dima > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: dima@secretsauce.net, 21777@debbugs.gnu.org, schwab@linux-m68k.org > Date: Mon, 21 Sep 2020 16:07:06 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> I worked up a patch for this, but in testing, there's a number of > >> problems. > > > > Do you see the original problem with a recent version of GDB? In the > > discussion, I mentioned that the change to follow that of Emacs was > > installed in GDB back then, so it's reasonable to expect that we no > > longer have a problem described in this bug report. > > No, the problem is still there -- If you say `M-x gud-gdb' and then > issue a backtrace, then the gdb pager kicks in. This is very strange. I clearly see in GDB the code to set unlimited page height. Any GDB version later than 7.10 should have this. If you invoke "M-x gud-gdb", then type "show height" at the "(gdb)" prompt in the interaction buffer, what do you see? And if you then type "show environment INSIDE_EMACS" at the "(gdb)" prompt, what do you see? ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-22 15:46 ` Eli Zaretskii @ 2020-09-22 15:51 ` Lars Ingebrigtsen 2020-09-22 15:57 ` Andreas Schwab 2020-09-22 16:09 ` Eli Zaretskii 0 siblings, 2 replies; 34+ messages in thread From: Lars Ingebrigtsen @ 2020-09-22 15:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 21777, schwab, dima Eli Zaretskii <eliz@gnu.org> writes: >> No, the problem is still there -- If you say `M-x gud-gdb' and then >> issue a backtrace, then the gdb pager kicks in. > > This is very strange. I clearly see in GDB the code to set unlimited > page height. Any GDB version later than 7.10 should have this. > > If you invoke "M-x gud-gdb", then type "show height" at the "(gdb)" > prompt in the interaction buffer, what do you see? > > And if you then type "show environment INSIDE_EMACS" at the "(gdb)" > prompt, what do you see? Aha! (gdb) show height Number of lines gdb thinks are in a page is unlimited. (gdb) show environment INSIDE_EMACS INSIDE_EMACS = 28.0.50,comint It is indeed unlimited... but if I change the size of the frame: (gdb) show height Number of lines gdb thinks are in a page is 35. So Emacs is somehow telling gdb to set the height when the frame size changes. I tried grepping for that yesterday, but I was unable to see what triggers that. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-22 15:51 ` Lars Ingebrigtsen @ 2020-09-22 15:57 ` Andreas Schwab 2020-09-22 16:09 ` Eli Zaretskii 1 sibling, 0 replies; 34+ messages in thread From: Andreas Schwab @ 2020-09-22 15:57 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 21777, dima On Sep 22 2020, Lars Ingebrigtsen wrote: > So Emacs is somehow telling gdb to set the height when the frame size > changes. I tried grepping for that yesterday, but I was unable to see > what triggers that. It's the normal SIGWINCH handling. Works the same in any resizable terminal. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-22 15:51 ` Lars Ingebrigtsen 2020-09-22 15:57 ` Andreas Schwab @ 2020-09-22 16:09 ` Eli Zaretskii 2020-09-22 16:19 ` Andreas Schwab 2020-09-23 12:53 ` Lars Ingebrigtsen 1 sibling, 2 replies; 34+ messages in thread From: Eli Zaretskii @ 2020-09-22 16:09 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 21777, schwab, dima > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: dima@secretsauce.net, 21777@debbugs.gnu.org, schwab@linux-m68k.org > Date: Tue, 22 Sep 2020 17:51:20 +0200 > > (gdb) show height > Number of lines gdb thinks are in a page is unlimited. > (gdb) show environment INSIDE_EMACS > INSIDE_EMACS = 28.0.50,comint > > It is indeed unlimited... but if I change the size of the frame: > > (gdb) show height > Number of lines gdb thinks are in a page is 35. > > So Emacs is somehow telling gdb to set the height when the frame size > changes. I tried grepping for that yesterday, but I was unable to see > what triggers that. That's a different problem, then. I think it is related to window-adjust-process-window-size-function and set-process-window-size, introduced in Emacs 25. I guess gud-gdb should disable that feature. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-22 16:09 ` Eli Zaretskii @ 2020-09-22 16:19 ` Andreas Schwab 2020-09-22 16:51 ` Eli Zaretskii 2020-09-23 12:53 ` Lars Ingebrigtsen 1 sibling, 1 reply; 34+ messages in thread From: Andreas Schwab @ 2020-09-22 16:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 21777, dima On Sep 22 2020, Eli Zaretskii wrote: > That's a different problem, then. I think it is related to > window-adjust-process-window-size-function and > set-process-window-size, introduced in Emacs 25. I guess gud-gdb > should disable that feature. It's really a bug in gdb, as just sending SIGWINCH to gdb will trigger this. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-22 16:19 ` Andreas Schwab @ 2020-09-22 16:51 ` Eli Zaretskii 2020-09-22 17:18 ` Andreas Schwab 0 siblings, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2020-09-22 16:51 UTC (permalink / raw) To: Andreas Schwab; +Cc: larsi, 21777, dima > From: Andreas Schwab <schwab@linux-m68k.org> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, dima@secretsauce.net, > 21777@debbugs.gnu.org > Date: Tue, 22 Sep 2020 18:19:54 +0200 > > On Sep 22 2020, Eli Zaretskii wrote: > > > That's a different problem, then. I think it is related to > > window-adjust-process-window-size-function and > > set-process-window-size, introduced in Emacs 25. I guess gud-gdb > > should disable that feature. > > It's really a bug in gdb, as just sending SIGWINCH to gdb will trigger > this. So you are saying that when INSIDE_EMACS is set, GDB should disable the Readline's SIGWINCH handler? ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-22 16:51 ` Eli Zaretskii @ 2020-09-22 17:18 ` Andreas Schwab 2020-09-22 17:39 ` Eli Zaretskii 0 siblings, 1 reply; 34+ messages in thread From: Andreas Schwab @ 2020-09-22 17:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, 21777, dima On Sep 22 2020, Eli Zaretskii wrote: > So you are saying that when INSIDE_EMACS is set, GDB should disable > the Readline's SIGWINCH handler? No, it should never override an unlimited height setting via SIGWINCH. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-22 17:18 ` Andreas Schwab @ 2020-09-22 17:39 ` Eli Zaretskii 2020-09-22 17:46 ` Andreas Schwab 0 siblings, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2020-09-22 17:39 UTC (permalink / raw) To: Andreas Schwab; +Cc: larsi, 21777, dima > From: Andreas Schwab <schwab@linux-m68k.org> > Cc: larsi@gnus.org, dima@secretsauce.net, 21777@debbugs.gnu.org > Date: Tue, 22 Sep 2020 19:18:54 +0200 > > On Sep 22 2020, Eli Zaretskii wrote: > > > So you are saying that when INSIDE_EMACS is set, GDB should disable > > the Readline's SIGWINCH handler? > > No, it should never override an unlimited height setting via SIGWINCH. I'm not sure I agree: how is an unlimited setting different from any other setting? Any setting can be overridden to replace it with a different setting. Anyway, this discussion belongs on the GDB mailing list, not here. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-22 17:39 ` Eli Zaretskii @ 2020-09-22 17:46 ` Andreas Schwab 0 siblings, 0 replies; 34+ messages in thread From: Andreas Schwab @ 2020-09-22 17:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, 21777, dima On Sep 22 2020, Eli Zaretskii wrote: >> From: Andreas Schwab <schwab@linux-m68k.org> >> Cc: larsi@gnus.org, dima@secretsauce.net, 21777@debbugs.gnu.org >> Date: Tue, 22 Sep 2020 19:18:54 +0200 >> >> On Sep 22 2020, Eli Zaretskii wrote: >> >> > So you are saying that when INSIDE_EMACS is set, GDB should disable >> > the Readline's SIGWINCH handler? >> >> No, it should never override an unlimited height setting via SIGWINCH. > > I'm not sure I agree: how is an unlimited setting different from any > other setting? It is special, as it never matches any real terminal size. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-22 16:09 ` Eli Zaretskii 2020-09-22 16:19 ` Andreas Schwab @ 2020-09-23 12:53 ` Lars Ingebrigtsen 2020-09-23 14:41 ` Eli Zaretskii 2020-09-24 14:16 ` Eli Zaretskii 1 sibling, 2 replies; 34+ messages in thread From: Lars Ingebrigtsen @ 2020-09-23 12:53 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 21777, schwab, dima Eli Zaretskii <eliz@gnu.org> writes: > That's a different problem, then. I think it is related to > window-adjust-process-window-size-function and > set-process-window-size, introduced in Emacs 25. I guess gud-gdb > should disable that feature. But if the user has the pager enabled, then Emacs should notify gdb about the size change... Andreas Schwab <schwab@linux-m68k.org> writes: >> I'm not sure I agree: how is an unlimited setting different from any >> other setting? > > It is special, as it never matches any real terminal size. Indeed. If gdb has disabled the pager, then Emacs telling gdb about the changed size shouldn't enable the pager. But I'm still not sure this is actually what is going on, because I'm just not finding exactly where this happens. For instance, `window--adjust-process-windows' is never called in buffers started with `M-x gud-gdb'... and adjusting the frame size in a buffer started with `M-x gdb' does not make gdb switch the pager on. And debug-on-entry on set-process-window-size isn't triggered, either. Grepping for SIGWINCH doesn't immediately give me any clues, either. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-23 12:53 ` Lars Ingebrigtsen @ 2020-09-23 14:41 ` Eli Zaretskii 2020-09-24 14:15 ` Lars Ingebrigtsen 2020-09-24 14:16 ` Eli Zaretskii 1 sibling, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2020-09-23 14:41 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 21777, schwab, dima > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: dima@secretsauce.net, 21777@debbugs.gnu.org, schwab@linux-m68k.org > Date: Wed, 23 Sep 2020 14:53:53 +0200 > > But I'm still not sure this is actually what is going on, because I'm > just not finding exactly where this happens. For instance, > `window--adjust-process-windows' is never called in buffers started with > `M-x gud-gdb'... and adjusting the frame size in a buffer started with > `M-x gdb' does not make gdb switch the pager on. The value of window-adjust-process-window-size-function in the GUD buffer is window-adjust-process-window-size-smallest. Did you try to trace that function? > Grepping for SIGWINCH doesn't immediately give me any clues, either. We don't send SIGWINCH, we use IOCTL, AFAIR. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-23 14:41 ` Eli Zaretskii @ 2020-09-24 14:15 ` Lars Ingebrigtsen 2020-09-24 15:06 ` Eli Zaretskii 0 siblings, 1 reply; 34+ messages in thread From: Lars Ingebrigtsen @ 2020-09-24 14:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 21777, schwab, dima Eli Zaretskii <eliz@gnu.org> writes: > The value of window-adjust-process-window-size-function in the GUD > buffer is window-adjust-process-window-size-smallest. Did you try to > trace that function? I tried that now, and debug-on-entry-ing that function does not result in that function giving a backtrace... AAARGH! It's, once again, the problem of the debugger not being allowed to be called when inhibit-redisplay is bound, which is seems to be here. I wish we could fix that, or at least have `debug' say "Not entering the debugger because inhibit-redisplay is set"... Anyway, set-process-window-size is indeed called in M-x gud-gdb buffers. So does M-x gdb buffers... but in that case, gdb just seems to ignore it, as it should. So M-x gdb sets up gdb in a way that gud-gdb doesn't. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-24 14:15 ` Lars Ingebrigtsen @ 2020-09-24 15:06 ` Eli Zaretskii 2020-09-25 9:55 ` Lars Ingebrigtsen 0 siblings, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2020-09-24 15:06 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 21777, schwab, dima > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: dima@secretsauce.net, 21777@debbugs.gnu.org, schwab@linux-m68k.org > Date: Thu, 24 Sep 2020 16:15:29 +0200 > > Anyway, set-process-window-size is indeed called in M-x gud-gdb > buffers. So does M-x gdb buffers... but in that case, gdb just seems > to ignore it, as it should. So M-x gdb sets up gdb in a way that > gud-gdb doesn't. Yes, "M-x gdb" doesn't start Readline in GDB, and so GDB doesn't think it runs with output to a terminal device. "M-x gud-gdb", OTOH, invokes GDB as an interactive program via PTY. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-24 15:06 ` Eli Zaretskii @ 2020-09-25 9:55 ` Lars Ingebrigtsen 0 siblings, 0 replies; 34+ messages in thread From: Lars Ingebrigtsen @ 2020-09-25 9:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 21777, schwab, dima Eli Zaretskii <eliz@gnu.org> writes: > Yes, "M-x gdb" doesn't start Readline in GDB, and so GDB doesn't think > it runs with output to a terminal device. "M-x gud-gdb", OTOH, > invokes GDB as an interactive program via PTY. Yup. Then I guess there's nothing here to be done on the Emacs side of things, and I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-23 12:53 ` Lars Ingebrigtsen 2020-09-23 14:41 ` Eli Zaretskii @ 2020-09-24 14:16 ` Eli Zaretskii 2020-09-24 14:29 ` Lars Ingebrigtsen 1 sibling, 1 reply; 34+ messages in thread From: Eli Zaretskii @ 2020-09-24 14:16 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 21777, schwab, dima > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: dima@secretsauce.net, 21777@debbugs.gnu.org, schwab@linux-m68k.org > Date: Wed, 23 Sep 2020 14:53:53 +0200 > > Andreas Schwab <schwab@linux-m68k.org> writes: > > >> I'm not sure I agree: how is an unlimited setting different from any > >> other setting? > > > > It is special, as it never matches any real terminal size. > > Indeed. If gdb has disabled the pager, then Emacs telling gdb about the > changed size shouldn't enable the pager. Such a change is already being considered for inclusion in GDB, see https://sourceware.org/pipermail/gdb-patches/2020-September/172031.html ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-24 14:16 ` Eli Zaretskii @ 2020-09-24 14:29 ` Lars Ingebrigtsen 2020-09-24 15:08 ` Eli Zaretskii 0 siblings, 1 reply; 34+ messages in thread From: Lars Ingebrigtsen @ 2020-09-24 14:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 21777, schwab, dima Eli Zaretskii <eliz@gnu.org> writes: > Such a change is already being considered for inclusion in GDB, see > > https://sourceware.org/pipermail/gdb-patches/2020-September/172031.html Great. And I'm guessing that the pager doesn't get switched on in the M-x gdb case because the communication is over a separate socket (-i=mi), and gdb just ignores the notification in that case? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2020-09-24 14:29 ` Lars Ingebrigtsen @ 2020-09-24 15:08 ` Eli Zaretskii 0 siblings, 0 replies; 34+ messages in thread From: Eli Zaretskii @ 2020-09-24 15:08 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 21777, schwab, dima > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: dima@secretsauce.net, 21777@debbugs.gnu.org, schwab@linux-m68k.org > Date: Thu, 24 Sep 2020 16:29:06 +0200 > > And I'm guessing that the pager doesn't get switched on in the M-x gdb > case because the communication is over a separate socket (-i=mi), and > gdb just ignores the notification in that case? In the -i=mi case, GDB doesn't behave as if its output is a terminal device. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2015-10-29 22:58 ` Dima Kogan 2015-10-30 3:43 ` Dima Kogan @ 2015-10-30 7:54 ` Eli Zaretskii 1 sibling, 0 replies; 34+ messages in thread From: Eli Zaretskii @ 2015-10-30 7:54 UTC (permalink / raw) To: Dima Kogan; +Cc: 21777, schwab > From: Dima Kogan <dima@secretsauce.net> > Cc: schwab@linux-m68k.org, 21777@debbugs.gnu.org > Date: Thu, 29 Oct 2015 15:58:46 -0700 > > >> 2. patch gdb to look at INSIDE_EMACS not EMACS > > > > That should be done regardless, I will submit a patch to GDB. > > Thanks for doing that! The patch is already in the GDB repository. > >> 3. handle this inside emacs, not relying on gdb behavior > >> > >> I like 3. Emacs should be responsible for things emacs wants, not > >> external applications, even if they're GNU applications. > > > > 3 is okay in principle, but you didn't show any specific suggestions. > > What did you have in mind? > > gud-gdb.el can send a "set height unlimited" command when it starts the > gdb process. I'm happy to give you a patch, if you want. Please do, but this should be done so as not to disable any "set height" commands in the init files that GDB reads when it starts. Otherwise users who do want to set that option for some reason will crucify us. If this becomes tricky, the only reasonable way out might be a user option which defaults to off. Thanks. ^ permalink raw reply [flat|nested] 34+ messages in thread
* bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs 2015-10-28 19:20 bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs Dima Kogan 2015-10-28 22:27 ` Andreas Schwab @ 2019-09-29 21:49 ` Stefan Kangas 1 sibling, 0 replies; 34+ messages in thread From: Stefan Kangas @ 2019-09-29 21:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 21777, Dima Kogan Dima Kogan <dima@secretsauce.net> writes: >> I think if we have such an option, and it's by default off, we might >> consider not bothering about gdbinit commands that contradict the >> effect of that option. The option gives users enough power to decide >> what they want more. > > Right. This was the idea. I'll send a patch at some point. Not today. Hi Dima, That was almost 4 years ago. Did you ever get around to writing that patch? Best regards, Stefan Kangas ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2020-09-25 9:55 UTC | newest] Thread overview: 34+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-10-28 19:20 bug#21777: 25.0.50; gud-gdb uses a pager, which is harmful inside emacs Dima Kogan 2015-10-28 22:27 ` Andreas Schwab 2015-10-28 22:57 ` Dima Kogan 2015-10-29 16:16 ` Eli Zaretskii 2015-10-29 22:58 ` Dima Kogan 2015-10-30 3:43 ` Dima Kogan 2015-10-30 8:17 ` Eli Zaretskii 2015-10-30 9:13 ` Dima Kogan 2015-10-30 9:32 ` Eli Zaretskii 2015-10-30 14:01 ` Eli Zaretskii 2015-10-30 19:05 ` Dima Kogan 2015-10-30 20:34 ` Eli Zaretskii 2020-09-20 21:18 ` Lars Ingebrigtsen 2020-09-21 14:03 ` Eli Zaretskii 2020-09-21 14:07 ` Lars Ingebrigtsen 2020-09-22 15:46 ` Eli Zaretskii 2020-09-22 15:51 ` Lars Ingebrigtsen 2020-09-22 15:57 ` Andreas Schwab 2020-09-22 16:09 ` Eli Zaretskii 2020-09-22 16:19 ` Andreas Schwab 2020-09-22 16:51 ` Eli Zaretskii 2020-09-22 17:18 ` Andreas Schwab 2020-09-22 17:39 ` Eli Zaretskii 2020-09-22 17:46 ` Andreas Schwab 2020-09-23 12:53 ` Lars Ingebrigtsen 2020-09-23 14:41 ` Eli Zaretskii 2020-09-24 14:15 ` Lars Ingebrigtsen 2020-09-24 15:06 ` Eli Zaretskii 2020-09-25 9:55 ` Lars Ingebrigtsen 2020-09-24 14:16 ` Eli Zaretskii 2020-09-24 14:29 ` Lars Ingebrigtsen 2020-09-24 15:08 ` Eli Zaretskii 2015-10-30 7:54 ` Eli Zaretskii 2019-09-29 21:49 ` Stefan Kangas
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.