From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#29157: 25.3; Eshell parsing fails sometimes, e.g. "date" and "sed" Date: Sun, 26 Nov 2017 17:53:05 +0200 Message-ID: <83indx6nq6.fsf@gnu.org> References: <87tvy9rm5z.fsf@gmail.com> <87lgjk7rpd.fsf@users.sourceforge.net> <87lgjkoloe.fsf@gmail.com> <87shd5znzf.fsf@users.sourceforge.net> <87po891o1t.fsf@gmail.com> <87po89ywv5.fsf@users.sourceforge.net> <8360a1arlf.fsf@gnu.org> <87lgiui6qc.fsf@gmail.com> <83y3mu6ttn.fsf@gnu.org> <87indyi20r.fsf@gmail.com> <83vahy6si5.fsf@gnu.org> <87mv39v1p1.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1511711655 9457 195.159.176.226 (26 Nov 2017 15:54:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Nov 2017 15:54:15 +0000 (UTC) Cc: 29157@debbugs.gnu.org, npostavs@users.sourceforge.net To: Pierre Neidhardt Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 26 16:54:08 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIzFr-0001ai-I5 for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Nov 2017 16:54:03 +0100 Original-Received: from localhost ([::1]:57080 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIzFy-0008Kf-Up for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Nov 2017 10:54:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54911) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIzFt-0008JI-2l for bug-gnu-emacs@gnu.org; Sun, 26 Nov 2017 10:54:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eIzFp-0006ee-WE for bug-gnu-emacs@gnu.org; Sun, 26 Nov 2017 10:54:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50818) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eIzFp-0006eO-Sm for bug-gnu-emacs@gnu.org; Sun, 26 Nov 2017 10:54:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eIzFp-0007ZO-LK for bug-gnu-emacs@gnu.org; Sun, 26 Nov 2017 10:54:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Nov 2017 15:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29157 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29157-submit@debbugs.gnu.org id=B29157.151171161029059 (code B ref 29157); Sun, 26 Nov 2017 15:54:01 +0000 Original-Received: (at 29157) by debbugs.gnu.org; 26 Nov 2017 15:53:30 +0000 Original-Received: from localhost ([127.0.0.1]:59499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIzFK-0007Yd-A7 for submit@debbugs.gnu.org; Sun, 26 Nov 2017 10:53:30 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:35675) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIzFI-0007YR-C8 for 29157@debbugs.gnu.org; Sun, 26 Nov 2017 10:53:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eIzF9-0006Ux-P6 for 29157@debbugs.gnu.org; Sun, 26 Nov 2017 10:53:22 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIzF9-0006Ut-Kq; Sun, 26 Nov 2017 10:53:19 -0500 Original-Received: from [176.228.60.248] (port=4930 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eIzF9-0002uu-0N; Sun, 26 Nov 2017 10:53:19 -0500 In-reply-to: <87mv39v1p1.fsf@gmail.com> (message from Pierre Neidhardt on Sun, 26 Nov 2017 10:17:30 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:140416 Archived-At: > From: Pierre Neidhardt > 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.