search

syl20bnr / spacemacs

A community-driven Emacs distribution - The best editor is neither Emacs nor Vim, it's Emacs *and* Vim!
http://spacemacs.org
GNU General Public License v3.0
23.69k stars 4.9k forks source link

gud-gdb fails to start on develop branch #11087

Closed andreiltd closed 2 years ago

andreiltd commented 6 years ago

Description :octocat:

gud-gdb is not working on develop branch, master working as expected

Reproduction guide :beetle:

Observed behaviour: :eyes: :broken_heart: gdb fails to start with an error message wrong-type-argument listp display-buffer-in-previous-window

Expected behaviour: :heart: :smile: I expect gdb window to show up

System Info :computer:

Backtrace :paw_prints:

Debugger entered--Lisp error: (wrong-type-argument listp display-buffer-in-previous-window)
  purpose-alist-combine((display-buffer-in-previous-window display-buffer-same-window display-buffer-pop-up-window) ((user-action-sequence display-buffer-reuse-window)))
  purpose--action-function(#<buffer *gud-a.out*> (display-buffer-in-previous-window display-buffer-same-window display-buffer-pop-up-window))
  #f(compiled-function (buffer-or-name &optional action frame) "Display BUFFER-OR-NAME in some window, without selecting it.\nBUFFER-OR-NAME must be a buffer or the nam...
  purpose-display-buffer-advice(#f(compiled-function (buffer-or-name &optional action frame) "Display BUFFER-OR-NAME in some window, without selecting it.\nBUFFER-OR-NA...
  apply(purpose-display-buffer-advice #f(compiled-function (buffer-or-name &optional action frame) "Display BUFFER-OR-NAME in some window, without selecting it.\nBUFFER...
  display-buffer(#<buffer *gud-a.out*> (display-buffer-reuse-window display-buffer-in-previous-window display-buffer-same-window display-buffer-pop-up-window))
  gud-common-init("gdb --fullname a.out" nil gud-gdb-marker-filter)
  gud-gdb("gdb --fullname a.out")
  funcall-interactively(gud-gdb "gdb --fullname a.out")
  call-interactively(gud-gdb record nil)
  command-execute(gud-gdb record)
  helm-M-x(nil #("gud-gdb" 0 7 (match-part "gud-gdb")))
  funcall-interactively(helm-M-x nil #("gud-gdb" 0 7 (match-part "gud-gdb")))
  call-interactively(helm-M-x nil nil)
  command-execute(helm-M-x)
larebsyed commented 6 years ago

I am also facing this issue, any resolution?

larebsyed commented 6 years ago

@andreiltd were you able to resolve this?

andreiltd commented 6 years ago

Unfortunately not. I switched to realgud.

smile13241324 commented 6 years ago

@andreiltd I have just had a look at your stack trace and remembered purpose-mode having sometimes problems with modes manipulating buffers. Would you mind checking whether the same issue appears when purpose is deactivated?

larebsyed commented 6 years ago

@smile13241324 I tried doing that still got the same error at my end

smile13241324 commented 6 years ago

Tried that out today, compiled below file with g++ -Wall main.cpp and did run gud-gdb using gdb --fullname ./a.out and gdb was correctly started on develop.

// my first program in C++
#include <iostream>

int main ()
{
    std::cout << "Hello World!" << std::endl;
}

My system config is:

System Info :computer:

@larebsyed could you please update your spacemacs version on develop, update all your packages and try this out again. If this does not help please deactivate your user config and see whether the error still appears. If this also doesn't help please provide more information on how to reproduce your error.

smile13241324 commented 6 years ago

@larebsyed @andreiltd ups, just had another look at your layers config and it looks like you have forgotten to add c++ layer which is configuring all C, C++ related modes.

Layers: (helm emacs-lisp neotree)

Please add the following to your layers list and retry:

     (c-c++ :variables
            c-c++-default-mode-for-headers 'c++-mode
            c-c++-enable-clang-support t
            c-c++-enable-clang-format-on-save t
            c-c++-enable-auto-newline t)
andreiltd commented 6 years ago

@smile13241324 I have tried develop again just now. It is still entering the same error. I used fresh install of spacemcs.

Here is what I did:

mv .emacs.d .emacs.d.bak mv .spacemacs .spacemacs.bak mv .spacemacs.env .spacemacs.env.bak git clone -b develop https://github.com/syl20bnr/spacemacs ~/.emacs.d

After starting spacemacs I add c/c++ layer as described in your previous post to .spacemacs file and reload the config with SPC f e R.

Then running gud-gdb produces:

Lisp error: (wrong-type-argument listp display-buffer-in-previous-window)

Also disabling purpose-mode doesn't help. I'm using an edge version of emacs 27.0.50 can this cause issues?

Thanks for looking into this.

smile13241324 commented 6 years ago

Possibly, I once experienced a lot of issues with company when I was moving from 25 to 26 emacs. Would you mind trying a 26 version? Also do you use a special executable for running gdb, just want to make sure that this is not caused by any special executable.

Can you also tell which version of gdb you are using? I have used 8.1-1.

smile13241324 commented 6 years ago

@andreiltd I have analysed your stacktrace, the problem comes from display-buffer-in-previous-window having the wrong type. When I am looking for this variable in my elpa directory by a simple helm search I cannot find it. Can it be that this is an interface change in emacs 27?

Can you please check the variable display-buffer-in-previous-window in emacs 27 and post whether it is defined and where. Please also retry with emacs 26 and post the results.

andreiltd commented 6 years ago

@smile13241324 I have tried emacs 26 and gdb starts with no issues:

GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2018-07-05

In emacs 27 display-buffer-in-previous-window is a function described as follow:

display-buffer-in-previous-window is a compiled Lisp function in ‘window.el’.

(display-buffer-in-previous-window BUFFER ALIST)

Display BUFFER in a window previously showing it.
If ALIST has a non-nil ‘inhibit-same-window’ entry, the selected
window is not eligible for reuse.

If ALIST contains a ‘reusable-frames’ entry, its value determines
which frames to search for a reusable window:
  nil -- the selected frame (actually the last non-minibuffer frame)
  A frame   -- just that frame
  ‘visible’ -- all visible frames
  0   -- all frames on the current terminal
  t   -- all frames.

If ALIST contains no ‘reusable-frames’ entry, search just the
selected frame if ‘display-buffer-reuse-frames’ and
‘pop-up-frames’ are both nil; search all frames on the current
terminal if either of those variables is non-nil.

If ALIST has a ‘previous-window’ entry, the window specified by
that entry will override any other window found by the methods
above, even if that window never showed BUFFER before.

But the same description can be found in emacs 26:

display-buffer-in-previous-window is a compiled Lisp function in ‘window.el’.

(display-buffer-in-previous-window BUFFER ALIST)

Display BUFFER in a window previously showing it.
If ALIST has a non-nil ‘inhibit-same-window’ entry, the selected
window is not eligible for reuse.

If ALIST contains a ‘reusable-frames’ entry, its value determines
which frames to search for a reusable window:
  nil -- the selected frame (actually the last non-minibuffer frame)
  A frame   -- just that frame
  ‘visible’ -- all visible frames
  0   -- all frames on the current terminal
  t   -- all frames.

If ALIST contains no ‘reusable-frames’ entry, search just the
selected frame if ‘display-buffer-reuse-frames’ and
‘pop-up-frames’ are both nil; search all frames on the current
terminal if either of those variables is non-nil.

If ALIST has a ‘previous-window’ entry, the window specified by
that entry will override any other window found by the methods
above, even if that window never showed BUFFER before.
smile13241324 commented 6 years ago

Yes thats true but I was asking for a variable with that name in emacs 27. The point is that in your stacktrace purpose tries to combine display-buffer-in-previous-window with other alists which fails as the variable in question is no list. In emacs 26 this does not happen.

This could now be:

Anyway as emacs 27 is not officially supported yet I would advise to consider going back to Version 26.1 except you want to use a special feature in 27 (dumping I suppose?) in this case please use realgud instead.

leezu commented 5 years ago

This is still a problem with emacs 27 and spacemacs develop branch. There is no such issue without spacemacs (emacs -q), so this seems to be due to some spacemacs configuration. I confirm everything works fine on emacs 26.1

dhanjit commented 4 years ago

Is there any workaround to this? Can't run gdb.

c02y commented 4 years ago

I got the same error, no clue.

collares commented 4 years ago

Excluding the window-purpose package (pulled in by the helm layer) by adding it to "dotspacemacs-excluded-packages" indeed solved the problem for me.

dwuggh commented 4 years ago

13693 I think this will help. It seems to be a bug in emacs 27.

github-actions[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!