[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed"
From: |
Eli Zaretskii |
Subject: |
bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed" |
Date: |
Sun, 26 Nov 2017 17:53:05 +0200 |
> From: Pierre Neidhardt <ambrevar@gmail.com>
> Cc: npostavs@users.sourceforge.net, 29157@debbugs.gnu.org
> Date: Sun, 26 Nov 2017 10:17:30 +0100
>
> > But the answer to that question depends on the arguments and sometimes
> > on the switches, doesn't it? E.g., Eshell's 'rm' can delete processes
> > and buffers, and unintern symbols, in addition to deleting files.
> > What exactly it does depends on the arguments. And if you invoke it
> > with -d switch, it will call the external program, but if you invoke
> > with -f or -i or -n, it will use the built-in. So just given the
> > verb, I don't see how you can have that indication.
>
> Wow, I did not know that. This is not documented in the docstring, but
> I just saw it is mentioned in the help message.
>
> That maybe it the root of the issue: what's the standard way of
> documenting 'eshell/*' commands?
>
> I think both `-h' and `C-h f' should document the same thing, it's
> confusing otherwise.
Patches to that effect are welcome.
> > So you want to have an indication when there's _no_ built-in
> > implementation at all, is that it?
>
> No. Basically if I write "rm" in Eshell, Eshell will _always_ call
> eshell/rm. Only afterwards it will make a call to /bin/rm, depending on
> the arguments.
> As a user, what I want to know is what Eshell will call _first_, because
> then I can know the starting point of what Eshell is going to do.
>
> Basically, my idea is simple:
>
> - If 'eshell/foo' exists, use some eshell-builtin face on "foo". The
> user will then know that s/he should lookup the documentation of
> eshell/foo.
>
> - Otherwise use the normal face. The user will then refer to the man
> page and the like.
Well, I think you said the same thing I did, just from a different
POV. So we are in agreement. Feel free to work on such a feature.
- bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed", (continued)
- bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed", John Wiegley, 2017/11/25
- bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed", Eli Zaretskii, 2017/11/26
- bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed", John Wiegley, 2017/11/26
- bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed", Eli Zaretskii, 2017/11/25
- bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed", Pierre Neidhardt, 2017/11/25
- bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed", Eli Zaretskii, 2017/11/25
- bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed", Pierre Neidhardt, 2017/11/26
- bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed",
Eli Zaretskii <=
- bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed", John Wiegley, 2017/11/25
- bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed", Eli Zaretskii, 2017/11/26
- bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed", John Wiegley, 2017/11/26
- bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed", Eli Zaretskii, 2017/11/26
bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed", Andreas Schwab, 2017/11/05