1. Forum
  2. Usenet
  3. COMP.EMACS

  • meta-x shell behavior changed

    From Bob@21:1/5 to All on Mon Mar 5 20:09:06 2018
    Hi,

    I have been running Emacs 24.something for years. Finally installed a new
    box and am running 25.3.1. When I type meta-x shell, I get a split screen
    with a shell in the new buffer.

    In 24, the shell started in the current buffer. I don't like the "new"
    behavior because it screws up my buffers. I have the screen split in a few different ways and have all the content I want where I want it. I don't want the shell buffer to wind up anywhere except where I enter meta-x shell.

    Can somebody please explain how to restore the original (previous) behavior?

    Thanks,

    Bob

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ivan Shmakov@21:1/5 to All on Tue Mar 6 02:32:32 2018
    Bob <[email protected]> writes:

    [...]

    When I type meta-x shell, I get a split screen with a shell in the
    new buffer.

    In 24, the shell started in the current buffer. I don't like the
    "new" behavior because it screws up my buffers. I have the screen
    split in a few different ways and have all the content I want where I
    want it.

    I guess you may find it convenient to save your desired window
    configuration to a register with C-x r w and restore it when
    needed with C-x r j (jump-to-register.)

    I don't want the shell buffer to wind up anywhere except where I
    enter meta-x shell.

    Can somebody please explain how to restore the original (previous)
    behavior?

    First of all, I believe you've meant "window" in the above, not
    "buffer." Then, the behavior you observe is implemented by a call
    to pop-to-buffer from M-x shell, which has an ACTION argument:

    pop-to-buffer is an interactive compiled Lisp function in 'window.el'.

    ...

    This uses 'display-buffer' as a subroutine. The optional ACTION
    argument is passed to 'display-buffer' as its ACTION argument.
    See 'display-buffer' for more information.

    Looking up display-buffer's documentation reveals
    display-buffer-same-window, which seems to implement the
    behavior you're looking for:

    If ACTION is non-nil, it should have the form (FUNCTION . ALIST),
    where FUNCTION is either a function or a list of functions, and
    ALIST is an arbitrary association list (alist).

    ...

    Available action functions include:
    'display-buffer-same-window'
    ...

    Now, the same documentation refers to the display-buffer-alist
    variable, which can be set as follows for the desired result:

    (setq display-buffer-alist
    '(("^\\*shell\\*$" display-buffer-same-window)))

    --
    FSF associate member #7257 http://am-1.org/~ivan/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob@21:1/5 to Ivan Shmakov on Sat Mar 10 21:33:39 2018
    On 2018-03-06, Ivan Shmakov <[email protected]> wrote:
    Bob <[email protected]> writes:

    [...]
    [...]

    First of all, I believe you've meant "window" in the above, not
    "buffer." Then, the behavior you observe is implemented by a call
    to pop-to-buffer from M-x shell, which has an ACTION argument:

    Thanks for the clarification. I believe you are correct.

    (setq display-buffer-alist
    '(("^\\*shell\\*$" display-buffer-same-window)))

    Thanks! It works. I have no idea if I would ever have figured it out by
    myself.

    Gratefully and sorry for the delay in responding. Perils of business travels.

    Bob

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?Q?Johan_Bockg=C3=A5rd?=@21:1/5 to Bob on Tue Mar 13 22:13:06 2018
    Bob <[email protected]> writes:

    (setq display-buffer-alist
    '(("^\\*shell\\*$" display-buffer-same-window)))

    Thanks! It works. I have no idea if I would ever have figured it out by myself.

    User visible changes in the defaults usually come with documentation in
    the NEWS file (try C-h n) telling you how to get back to the old
    behavior.

    If you search for "shell", you will find this:

    ** Shell

    When you invoke 'shell' interactively, the '*shell*' buffer will now
    display in a new window. However, you can customize this behavior via
    the 'display-buffer-alist' variable. For example, to get
    the old behavior -- '*shell*' buffer displays in current window -- use
    (add-to-list 'display-buffer-alist
    '("^\\*shell\\*$" . (display-buffer-same-window))).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob@21:1/5 to [email protected] on Sun Mar 18 20:59:32 2018
    On 2018-03-13, Johan Bockgård <[email protected]> wrote:
    Bob <[email protected]> writes:

    (setq display-buffer-alist
    '(("^\\*shell\\*$" display-buffer-same-window)))

    Thanks! It works. I have no idea if I would ever have figured it out by
    myself.

    User visible changes in the defaults usually come with documentation in
    the NEWS file (try C-h n) telling you how to get back to the old
    behavior.

    Thanks. I don't track updates and was running a pretty old version. Brought
    up a new Linux box and got future shock.

    If you search for "shell", you will find this:

    ** Shell

    When you invoke 'shell' interactively, the '*shell*' buffer will now
    display in a new window. However, you can customize this behavior via
    the 'display-buffer-alist' variable. For example, to get
    the old behavior -- '*shell*' buffer displays in current window -- use
    (add-to-list 'display-buffer-alist
    '("^\\*shell\\*$" . (display-buffer-same-window))).

    I think it's kinda dumb to change things like this. Really, the same
    behavior should be expected forever. When a feature or added or somebody
    comes with a dumb idea to change long standing behavior, the _new behavior_ should be the option...

    Thank you,

    Bob

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)