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

[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.





reply via email to

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