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

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

bug#18960: Fwd: bug#18960: 24.4; Eshell history substitution causes erro


From: Samer Masterson
Subject: bug#18960: Fwd: bug#18960: 24.4; Eshell history substitution causes error
Date: Tue, 9 Dec 2014 14:49:40 -0800

On Tue, Dec 9, 2014 at 2:16 PM, Stefan Monnier <address@hidden> wrote:
> Modified   lisp/eshell/em-hist.el
> diff --git a/lisp/eshell/em-hist.el b/lisp/eshell/em-hist.el
> index b721b5d..e7e9a1e 100644
> --- a/lisp/eshell/em-hist.el
> +++ b/lisp/eshell/em-hist.el
> @@ -724,7 +724,7 @@ matched."
>   (setq nth (eshell-hist-word-reference nth)))
>        (unless (numberp mth)
>   (setq mth (eshell-hist-word-reference mth)))
> -      (cons (mapconcat 'identity (eshell-sublist textargs nth mth) "")
> +      (cons (mapconcat 'identity (eshell-sublist textargs nth mth) " ")
>      end))))

Can you explain why this is needed?

(eshell-sublist) will return a sublist of textargs, which might look like ("ehco" "hi" "there"). The call to mapconcat would join that list without adding whitespace between the args previously, e.g. into "echohithere", which is incorrect. This then gets fed into eshell-hist-parse-modifier as event on line 663. eshell-hist-parse-modifier would then make the substitution on "echohithere".
 

> @@ -737,7 +737,7 @@ matched."
>    (goto-char (point-min))
>    (let ((modifiers (cdr (eshell-parse-modifiers))))
>      (dolist (mod modifiers)
> -      (setq hist (funcall mod hist)))
> +      (setq hist (car (funcall mod (list hist)))))
>      hist))
>        (delete-region here (point)))))

The docstring of eshell-parse-modifiers says:

   Parse value modifiers and predicates at point.
   If ALLOW-PREDS is non-nil, predicates will be parsed as well.
   Return a cons cell of the form

     (PRED-FUNC-LIST . MOD-FUNC-LIST)

   NEW-STRING is STRING minus any modifiers.  PRED-FUNC-LIST is a list of
   predicate functions.  MOD-FUNC-LIST is a list of result modifier
   functions.  PRED-FUNCS take a filename and return t if the test
   succeeds; MOD-FUNCS take any string and preform a modification,
   returning the resultant string.

If I read this right, `mod' (which is one of MOD-FUNCS) should take
a string and return a string, IIUC.  So, maybe the right fix is not to
change this code but to change the functions returned by
`eshell-parse-modifiers'.
 Ah, I should have read the docstring for eshell-parse-modifiers instead of simply looking at the function it returns :) I'll make that change. Also, I assume that NEW-STRING and ALLOW-PREDS both refer to variables that were removed when this file was made lexically scoped, and will remove them from the docstring.



        Stefan



reply via email to

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