* bug#7883: [PATCH] comint history expansion fails to process :N or $ modifier
@ 2011-01-21 18:10 Roland McGrath
2011-01-21 20:56 ` Stefan Monnier
0 siblings, 1 reply; 5+ messages in thread
From: Roland McGrath @ 2011-01-21 18:10 UTC (permalink / raw)
To: 7883
This has been driving me nuts since I started using 23 and I only just now
bothered to find and fix it. This worked correctly in 22 and was broken,
apparently just by a careless change.
In a comint/shell buffer, type:
echo foo bar RET
and then type:
echo !$ TAB
and you get the expansion:
echo echo foo bar
i.e., the whole line as if !$ had been !!.
The expansion you should get is just:
echo bar
The following trivial patch fixes the bug, restoring the behavior of v22
with similar code to what it had originally. I tested the fix in 23.2.1,
but the relevant comint.el code in the trunk has not changed since then.
Thanks,
Roland
2011-01-21 Roland McGrath <roland@frob.com>
* comint.el (comint-replace-by-expanded-history-before-point):
Fix expansion of !$ and !!:N syntax to pick the indicated word.
--- lisp/comint.el 2011-01-20 22:36:12 +0000
+++ lisp/comint.el 2011-01-21 18:03:09 +0000
@@ -1294,7 +1294,9 @@ than the logical beginning of line."
(message "Relative reference exceeds input history size"))))
((or (looking-at "!!?:?\\([0-9^$*-]+\\)") (looking-at "!!"))
;; Just a number of args from the previous input line.
- (replace-match (comint-previous-input-string 0) t t)
+ (replace-match (comint-args (comint-previous-input-string 0)
+ (match-beginning 1) (match-end 1))
+ t t)
(message "History item: previous"))
((looking-at
"!\\??\\({\\(.+\\)}\\|\\(\\sw+\\)\\)\\(:?[0-9^$*-]+\\)?")
^ permalink raw reply [flat|nested] 5+ messages in thread* bug#7883: [PATCH] comint history expansion fails to process :N or $ modifier
2011-01-21 18:10 bug#7883: [PATCH] comint history expansion fails to process :N or $ modifier Roland McGrath
@ 2011-01-21 20:56 ` Stefan Monnier
2011-02-15 1:36 ` Glenn Morris
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2011-01-21 20:56 UTC (permalink / raw)
To: Roland McGrath; +Cc: 7883-done
> The following trivial patch fixes the bug, restoring the behavior of v22
> with similar code to what it had originally. I tested the fix in 23.2.1,
> but the relevant comint.el code in the trunk has not changed since then.
Thanks. I installed it in the emacs-23 branch.
Stefan
^ permalink raw reply [flat|nested] 5+ messages in thread* bug#7883: [PATCH] comint history expansion fails to process :N or $ modifier
2011-01-21 20:56 ` Stefan Monnier
@ 2011-02-15 1:36 ` Glenn Morris
2011-02-15 1:56 ` Roland McGrath
0 siblings, 1 reply; 5+ messages in thread
From: Glenn Morris @ 2011-02-15 1:36 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 7883, Roland McGrath
Stefan Monnier wrote:
>> The following trivial patch fixes the bug, restoring the behavior of v22
>> with similar code to what it had originally. I tested the fix in 23.2.1,
>> but the relevant comint.el code in the trunk has not changed since then.
>
> Thanks. I installed it in the emacs-23 branch.
This just undoes the fix installed for
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1795
(Although it wasn't really fixed anyway.)
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#7883: [PATCH] comint history expansion fails to process :N or $ modifier
2011-02-15 1:36 ` Glenn Morris
@ 2011-02-15 1:56 ` Roland McGrath
2011-02-15 2:00 ` Glenn Morris
0 siblings, 1 reply; 5+ messages in thread
From: Roland McGrath @ 2011-02-15 1:56 UTC (permalink / raw)
To: Glenn Morris; +Cc: 7883, Stefan Monnier
> This just undoes the fix installed for
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1795
>
> (Although it wasn't really fixed anyway.)
The change was not a fix for that problem at all, as you say. That problem
continues to exist in various forms (that also exist in v22) and is a bug
in entirely different parts of the code. I noticed the gratuitous
insertion of spaces long ago, but it didn't really irk me quite enough to
look into it. I see no reason whatsoever why expansion should be looking
for metacharacters and fiddling things around like that at all. I always
assumed it was a dismally misguided attempt at pretty-printing, which, even
it weren't completely broken (as it is), is not a proper thing to be doing
implicitly during history expansion at all.
This misfeature appears to be fixed by:
(setq comint-delimiter-argument-list nil) ;buffer-local
The buffer-local setting comes from the global value of
shell-delimiter-argument-list, which I've just set to nil in my init files.
I really can't tell what the thinking behind the default setting of that
was, since it's not commented particularly well. It seems just entirely
wrong-headed to me. As far as I can tell, the only uses of the things it
affects (comint-delimiter-argument-list, comint-arguments, comint-args)
are in this history expansion stuff, where it is just thoroughly wrong if
you either want to have history expansion work anything like it does in
the shell (which is largely immune to any details of shell syntax, though
bash's is not so immune to quoting as is csh's, which is the original and
One True definition of ! history's meaning), or you know much of anything
about shell syntax.
Thanks,
Roland
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-02-15 2:00 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-21 18:10 bug#7883: [PATCH] comint history expansion fails to process :N or $ modifier Roland McGrath
2011-01-21 20:56 ` Stefan Monnier
2011-02-15 1:36 ` Glenn Morris
2011-02-15 1:56 ` Roland McGrath
2011-02-15 2:00 ` Glenn Morris
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).