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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#55838: 29.0.50; [PATCH] Eshell string-split subscript indexing split


From: Eli Zaretskii
Subject: bug#55838: 29.0.50; [PATCH] Eshell string-split subscript indexing splits too much
Date: Wed, 08 Jun 2022 16:38:59 +0300

> 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?





reply via email to

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