From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.bugs Subject: bug#9160: 24.0.50; Emacs freezes in *shell* buffer. Date: Tue, 20 Sep 2011 14:16:27 +0900 Message-ID: References: <87wrf7dgqt.fsf@m17n.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1316495828 11608 80.91.229.12 (20 Sep 2011 05:17:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 20 Sep 2011 05:17:08 +0000 (UTC) Cc: 9160@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 20 07:17:04 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R5sha-0003jf-Vs for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Sep 2011 07:17:03 +0200 Original-Received: from localhost ([::1]:49436 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5sha-0000r1-9v for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Sep 2011 01:17:02 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:45043) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5shW-0000qs-VI for bug-gnu-emacs@gnu.org; Tue, 20 Sep 2011 01:16:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5shV-00026a-JS for bug-gnu-emacs@gnu.org; Tue, 20 Sep 2011 01:16:58 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53924) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5shV-00026W-Hw for bug-gnu-emacs@gnu.org; Tue, 20 Sep 2011 01:16:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R5smQ-0007MO-4f for bug-gnu-emacs@gnu.org; Tue, 20 Sep 2011 01:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Kenichi Handa Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Sep 2011 05:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9160 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9160-submit@debbugs.gnu.org id=B9160.131649610628269 (code B ref 9160); Tue, 20 Sep 2011 05:22:02 +0000 Original-Received: (at 9160) by debbugs.gnu.org; 20 Sep 2011 05:21:46 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R5smA-0007Lu-7W for submit@debbugs.gnu.org; Tue, 20 Sep 2011 01:21:46 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R5sm5-0007Lh-Sp for 9160@debbugs.gnu.org; Tue, 20 Sep 2011 01:21:44 -0400 Original-Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id p8K5GSWU008939; Tue, 20 Sep 2011 14:16:31 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id p8K5GSDv004349; Tue, 20 Sep 2011 14:16:28 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp2.aist.go.jp with ESMTP id p8K5GRsZ008755; Tue, 20 Sep 2011 14:16:27 +0900 (JST) env-from (handa@m17n.org) In-Reply-To: (message from Stefan Monnier on Mon, 19 Sep 2011 21:10:58 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 20 Sep 2011 01:22:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:51518 Archived-At: In article , Stefan Monnier writes: > That's a known (to me) bug. > Making escaping (aka quoting) interact correctly with completion styles > like partial-completion and substring is actually a nasty problem. > The old code used to escape the strings returned by all-completions (so > the *Completions* buffer would show the escaped names), which solves > some of the problematic cases, but has the following downsides: > - it's aesthetically unpleasant (the *Completions* buffer does not need > that kind of escaping). > - it's inefficient (requires escaping all elements of all-completions). > - more problematic: it doesn't actually solve the problem in all cases, > because the user may have typed "a\bc" but the escaping code cannot > know that the user decided to (unnecessarily) escape "b" so it won't > escape "b" and we're back at the problem that the completion will fail > because the output from all-completions doesn't actually match the > user's input, even tho it should. > We have related problems with $ escaping in find-file (they manifest in > different ways because we half-solved the issues differently). > I'm still not quite sure yet how to best solve those problems, but it > seems that a real solution will have to handle a more general problem, > e.g. cases such as "/u-$b-c" in find-file, where "$b" is an env var that > expands to (say) "c/d". I agree that there are many problems behind. But, my testcase is a fairly simple one. Even if we can't solve all the related problem at the moment, I think there should be some workaround for such a simple case as far as it's a regression. For instance, is it difficult to escape all necessary characters on inserting a clicked item into *shell* buffer? > > (2) The second arg to rm command is not completed. > > % mkdir tmp > > % cd tmp > > % touch abc def > > % rm a > > % rm abc d > > Now just "No match" is shown instead of "d" completed to > > "def". This DOES NOT happen with 'ls' command. > I think I just fixed it with the patch below. I confirmed that it's fixed, thank you. > > (3) Error in post-command-hook for *.tar.gz file. > > % mkdir tmp > > % cd tmp > > % echo abc > abc > > % echo def > def > > % tar cfz temp.tar.gz abc def > > % tar tfz temp > > Now the command line is correctly completed to: > > % tar tfz temp.tar.gz > > But, this error is signaled: > > Error in post-command-hook (completion-in-region--postch): > > (wrong-type-argument listp [tar-header # > temp.tar.gz*> abc 436 8308 8308 4 (20069 47563) 4380 nil ustar handa handa > > 0 0 nil]) > I cannot reproduce this error. Has it been fixed in the mean time? No. I still see that error with the above testcase. --- Kenichi Handa handa@m17n.org