all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Kenichi Handa <handa@m17n.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 9160@debbugs.gnu.org
Subject: bug#9160: 24.0.50; Emacs freezes in *shell* buffer.
Date: Tue, 20 Sep 2011 14:16:27 +0900	[thread overview]
Message-ID: <tl71uvbvln8.fsf@m17n.org> (raw)
In-Reply-To: <jwv4o08jkpf.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Mon, 19 Sep 2011 21:10:58 -0400)

In article <jwv4o08jkpf.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> 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<tab>
> > % rm abc d<tab>
> > 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<tab>
> > 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 #<marker at 513 in  *tar-data
> > 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





  reply	other threads:[~2011-09-20  5:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-24 12:07 bug#9160: 24.0.50; Emacs freezes in *shell* buffer Kenichi Handa
2011-08-23  4:49 ` Stefan Monnier
2011-08-25  0:52   ` Kenichi Handa
2011-08-28  5:16     ` Stefan Monnier
2011-09-06  6:19       ` Kenichi Handa
2011-09-20  1:10         ` Stefan Monnier
2011-09-20  5:16           ` Kenichi Handa [this message]
2011-10-17 17:12             ` Stefan Monnier
2011-12-02 12:06               ` Kenichi Handa
2011-12-02 14:45                 ` Stefan Monnier
2011-12-04 13:41                   ` Kenichi Handa
2011-12-04 15:38                     ` Stefan Monnier

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tl71uvbvln8.fsf@m17n.org \
    --to=handa@m17n.org \
    --cc=9160@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.