Closed ghost closed 6 years ago
Steven Penny wrote:
#ifndef ALWAYS_USE_GUI mch_msg(_("Vim: Reading from stdin...\n")); #endif
http://github.com/vim/vim/blob/47ffb90/src/fileio.c#L830-L832
Shouldn’t this be printing to stderr? Otherwise it prevents command like this from being of any use:
$ echo hello | vi - -esc '%p|q!' Vim: Reading from stdin... hello
Currently you have to hi-jack stderr to silence the message:
$ echo hello | vi - -esc 'wq!/dev/stderr' 2>&1 >/dev/null hello
When starting a GUI program from the desktop or any other way that's not in a terminal, the warning goes missing. The idea is that Vim shows it in the GUI, but that can happen only after it has started up.
Dropping the message causes other problems, such as the user not being aware why Vim is stuck waiting.
-- Laughing helps. It's like jogging on the inside.
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\ \\ an exciting new programming language -- http://www.Zimbu.org /// \\ help me help AIDS victims -- http://ICCF-Holland.org ///
He's just answered about it few comments above 😎 And, AFAIK, it is Vim is upstream for NeoVim, but not vice versa. So, 2+2 = I very doubt @brammool will consider dropping it just because NeoVim considered.
And, btw, I still having problems on getting rid of unneded newline after hiding this message in Vim, and also I still very busy at work, so have no time ATM to implement what @brammool asked in #1564 😒
I'm not sure how dumb I'm being, but isn't the purpose of this message to tell some "luser" that they have to type something when they enter a bare vim -
command.
That is:
1) The message should only show if the user hasn't redirected stdin
$ gunzip -
gzip: compressed data not read from a terminal.
2) The message should probably be more descriptive.
$ vim -
Vim: Reading from terminal, enter text then press Ctrl-D...
So this patch would do enough.
diff --git a/src/fileio.c b/src/fileio.c
index 87a46b1..939403b 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -825,7 +825,7 @@ readfile(
* still be running, don't move the cursor to the last line, unless
* always using the GUI.
*/
- if (read_stdin)
+ if (read_stdin && isatty(0))
{
#ifndef ALWAYS_USE_GUI
mch_msg(_("Vim: Reading from stdin...\n"));
I don't agree that the message should only appear if the user hasn't redirected stdin.
When I use Vim as a pager, by ending a command-line with | view -
, the message Reading from stdin…
confirms that I didn't goof, and that Vim is indeed going to display, from its stdin, the redirected output of the previous command.
Similarly, when I give two or more filenames on the Vim command-line, Vim tells me how many files it's going to edit. This is of course hidden when Console Vim swaps the main and alternate tty buffers, but it reappears at end-of-run. I like it.
Best regards, Tony.
What? That doesn't seem very useful. You never see the message until after (if you're using the alt-screen) because VIM wipes the screen ...
...
Ah, yes, VIM really isn't a good pager is it. That sort of slow trickle of status information from the pipeline should appear on the screen as it's running. Personally, I don't put that sort of stuff in a pager at all, that's what a 200000 line scrollback is for. But in the event that I'm unsure if I want to save it I may use less
with it's follow and save commands. (and forget to redirect stderr too)
Anyway, assuming you're using bash
as your line editor (most people seem to) a better way of slurping up a slow pipe would seem be to use something like view <(sh doit)
. But even with that you can't see it happening and you usually have the standard error redirection issue so a shell alias is needed to fix it too.
@eromoe Your issue is different. Please create a new ticket for that. If it's solved, remove your messages.
I also expect the message to come from stderr, so I expect the following command to suppress the warning:
$ echo hello | vi - -esc '%p|q!' 2> /dev/null
Vim: Reading from stdin...
hello
But the message is still there.
Another test:
$ echo hello | vi - -esc '%p|q!' > out.txt
$ cat out.txt
Vim: Reading from stdin...
hello
Related:
It's a warning no error. So it is okay that the message occurs on stdout.
ah yes, however, note that vim is no batch processor and mainly intended for interactive use.
what is not true?
Look, vim is meant for interactive use. Using it as a stream editor is not its primary purpose. There are ways around it as you found out, but I do consider the warning to be useful in general case. Second, since Vim supports several platforms and GUIs, how does it affect GUIs? Will it then still be displayed to the user? I think it should.
just because vim is mainly interactive (its not)
That is a bold statement. I think this is wrong.
who cares? this question isnt about the GUI
We as developers care. Just because you don't doesn't make it invalid.
In general I think I don't like your bold tone. It is not going to convince. Please be nice. Thanks.
The ex
is symlinked to vim
executable binary and sharing the same codebase. Please note that originally ex
editor was a command line oriented, then after given a full-screen visual interface become the vi
text editor as per Wiki page:
ex
was eventually given a full-screen visual interface (adding to its command line oriented operation), thereby becoming thevi
text editor.
So I think Vim (as IMproved version of Vi) should support both interactive and non-interactive modes (Ex mode) equally as it's originally coming from non-interactive background as the history shows.
Going back to the original problem, this command should work by using Ex editor (which suppose to be support non-interactive editing):
echo hello | ex - -sc '%p|q!'
but it's not (prints nothing). Fixing this issue could solve the initial problem by using ex
instead of vim
. I've created for this separate issue at #2342
http://github.com/vim/vim/blob/47ffb90/src/fileio.c#L830-L832
Shouldn’t this be printing to stderr? Otherwise it prevents command like this from being of any use:
Currently you have to use /dev/stdin to silence the message:
Or hi-jack /dev/stderr:
Ideally the message could be totally suppressed with -V0 or similar, but stderr would be a start.
http://vi.stackexchange.com/q/4682/suppress-the-reading-from-stdin-message