emacs-bug-tracker
[Top][All Lists]
Advanced

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

[debbugs-tracker] bug#32647: closed (26.1; shell-resync-dirs prints "com


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#32647: closed (26.1; shell-resync-dirs prints "command dirs" in the buffer)
Date: Fri, 07 Sep 2018 17:56:02 +0000

Your message dated Fri, 07 Sep 2018 12:55:30 -0500
with message-id <address@hidden>
and subject line Re: bug#32647: 26.1; shell-resync-dirs prints "command dirs" 
in the buffer
has caused the debbugs.gnu.org bug report #32647,
regarding 26.1; shell-resync-dirs prints "command dirs" in the buffer
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
32647: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=32647
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 26.1; shell-resync-dirs prints "command dirs" in the buffer Date: Thu, 06 Sep 2018 10:07:50 -0500 User-agent: mu4e 1.0; emacs 26.1
>From emacs -Q:

M-x shell
M-RET

and it prints "command dirs" literally into the shell buffer.

That comes from this line:

      ;; If the process echoes commands, don't insert a fake command in
      ;; the buffer or it will appear twice.
      (unless comint-process-echoes
        (insert shell-dirstack-query) (insert "\n"))


and shell-dirstack-query is defined above as:

    (defvar shell-dirstack-query nil
      "Command used by `shell-resync-dirs' to query the shell.")


Thanks,
Alex



--- End Message ---
--- Begin Message --- Subject: Re: bug#32647: 26.1; shell-resync-dirs prints "command dirs" in the buffer Date: Fri, 07 Sep 2018 12:55:30 -0500 User-agent: mu4e 1.0; emacs 26.1
On Fri 07 Sep 2018 at 12:33, Glenn Morris <address@hidden> wrote:

> Alex Branham wrote:
>
>> Maybe I'm misunderstanding what M-RET does, but shouldn't it do that
>> invisibly?
>
> No, I don't think so. All it does is run dirs and parse the output as it
> appears in the shell buffer. It would look odd to have the shell output
> without the input being visible. It's behaved like this "forever".

Alrighty, I'm closing this report then. Thanks!


--- End Message ---

reply via email to

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