[Top][All Lists]

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

bug#30280: async-shell-command-display-buffer doesn't work anymore

From: Tino Calancha
Subject: bug#30280: async-shell-command-display-buffer doesn't work anymore
Date: Thu, 10 May 2018 11:13:44 +0900 (JST)
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

Thank you Basil for your prompt response!

Your patches LGTM.
Let's wait few more days if some people want to make further comments.
Otherwise, I will push them in your name into the master branch.

On Wed, 9 May 2018, Basil L. Contovounesios wrote:

+(declare-function comint-output-filter "comint" (process string))
What is the purpose of this? AFICT no warning is shown when compiling
the file.

On my end, removing the function declaration and invoking 'make' results
in the following output:

make[2]: Entering directory '/home/blc/.local/src/emacs/lisp'
 ELC      ../lisp/simple.elc
Reloading stale loaddefs.el
Loading /home/blc/.local/src/emacs/lisp/loaddefs.el (source)...

In end of data:
simple.el:9030:1:Warning: the function ‘comint-output-filter’ is not known to
   be defined.

Note that this warning is only emitted when comint-output-filter is
#'-quoted.  This is in line with the usual behaviour of the
byte-compiler that I am accustomed to, i.e. I don't see anything out of
the ordinary here.
Oh, I see.  I overlooked the fact that we changed `quote' with `function'.
make bootstrap
there is no warning.
I am OK with clearing the warning in all cases.

* We require `shell.el' inside `shell-coomand'.
* `shell.el' requires `comint.el'.

Yes, I understand that using comint-output-filter at this point in the
program is kosher, but the byte-compiler evidently does not.

Is the purpose to serve as documentation? In that case I don't think we
need it (the prefix 'comint-' already makes obvious where this function
belongs to).

No, the only intention is to pacify the byte-compiler.

It's better to keep consistent with the indentation of the function you
are modifying:  here, `shell-command' is indenting with TAB.

You can see the tabs searching them with:
C-s C-q C-I
or you can persistenly highlight them with:
M-s h r C-I RET RET

Thanks for the tip.  I personally prefer to use [global-]whitespace-mode
with a whitespace-style setting which includes (face tab-mark).
I additionally avoid accidentally committing tabs by configuring the git
option core.whitespace to include tab-in-indent.

For instance, here you are changing:
1) ' ---> #'
;; and
2) \t\t\s\s 000> \s\s\s\s...\s (18 white spaces)

Please, do not change 2).

I have no strong feeling on this; I was merely going along with the
(emacs-lisp-mode . ((indent-tabs-mode . nil))) setting in the project's
toplevel dir-locals-file, as well what I had inferred to be accepted
policy (as Noam mentions in a separate email) from following Emacs
development for the last couple of years.

If it weren't for the above and the fact that most everything I have
come across in the Emacs tree has Frankindentation (including the target
function shell-command), I would be more inclined to remain consistent
with the surrounding source.

Let me know if it's still a problem and I'll gladly resend the patches
with indent-tabs-mode enabled.
It's OK, Frankenstein is a glorious novel after all; I recommend anyone to revisit such classical masterpiece :-)
reply via email to

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