From: Eli Zaretskii <eliz@gnu.org>
To: Jim Porter <jporterbugs@gmail.com>
Cc: 55838@debbugs.gnu.org
Subject: bug#55838: 29.0.50; [PATCH] Eshell string-split subscript indexing splits too much
Date: Wed, 08 Jun 2022 16:38:59 +0300 [thread overview]
Message-ID: <83edzz5l70.fsf@gnu.org> (raw)
In-Reply-To: <ec8ceb92-c93e-7ff7-5e59-4b88b088e2d9@gmail.com> (message from Jim Porter on Tue, 7 Jun 2022 18:41:30 -0700)
> From: Jim Porter <jporterbugs@gmail.com>
> Date: Tue, 7 Jun 2022 18:41:30 -0700
>
> > The first command is normal, and just shows that Eshell outputs the
> > string with no manipulation. In the second command, we split the string
> > on ":" and get the 0th element. However, that gets split *again* (on
> > newlines) and returns a list.
>
> Here's a patch for this. It changes the behavior of
> `eshell-apply-indices' to use `eshell-convert-to-number' (when the
> expansion isn't wrapped in double-quotes) instead of the more-aggressive
> `eshell-convert'. I think `eshell-convert-to-number' is the right thing
> here, since Eshell already converts number-like strings to actual
> numbers in most cases.
>
> As a note, if you wanted the old behavior, you could do something like this:
>
> ~ $ echo $foo[: 0][0 1]
> ("a" "b")
>
> There's also a suggestion in the "Bugs and ideas" section of the Eshell
> manual to add "*" as a subscript to mean "all indices", so you could do
> the above in a more generic fashion like:
>
> ~ $ echo $foo[: 0][*]
> ;; Doesn't currently work, but it could.
I don't have any objections based on actual experience, and I don't
know what was the original design goals of this feature in Eshell.
However, please note that you are changing the behavior significantly,
and the only reason is that it doesn't make much sense to you. I
wonder whether this is a strong enough motivation to make such
incompatible behavior changes. Eshell is not a "normal" shell, in
that it attempts to make sense even if Lisp expressions are mixed with
Posix-ish shell features, so what may not make sense in Bash, Zsh, and
their ilk is not necessarily nonsensical in Eshell.
So maybe we should raise the bar for considering reasons for behavior
changes as valid?
next prev parent reply other threads:[~2022-06-08 13:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-08 1:36 bug#55838: 29.0.50; Eshell string-split subscript indexing splits too much Jim Porter
2022-06-08 1:41 ` bug#55838: 29.0.50; [PATCH] " Jim Porter
2022-06-08 12:11 ` bug#55838: 29.0.50; " Lars Ingebrigtsen
2022-06-08 13:38 ` Eli Zaretskii [this message]
2022-06-08 23:06 ` bug#55838: 29.0.50; [PATCH] " Jim Porter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83edzz5l70.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=55838@debbugs.gnu.org \
--cc=jporterbugs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).