zsh-users
 help / color / mirror / code / Atom feed
From: Ray Andrews <rayandrews@eastlink.ca>
To: zsh-users@zsh.org
Subject: Re: completion is over thinking things.
Date: Sun, 29 Sep 2019 08:11:02 -0700	[thread overview]
Message-ID: <3894eb29-b17a-0bf3-21f9-f9c44cb37428@eastlink.ca> (raw)
In-Reply-To: <CAHYJk3Qs1yzH+YEXvVfCRAX=_1ErxUX0VFEwRQTLho0w=p-Geg@mail.gmail.com>

On 2019-09-29 6:09 a.m., Mikael Magnusson wrote:
>
> Claiming that completion not completing invalid arguments for your
> command is an "issue" seems pretty far fetched to me. If you always
> want to complete files, don't run compinit in your startup files.
>
I appreciate the sophistication of that, but there are times when I 
really do want to complete on a filename even if it might seem like an 
invalid argument superficially.  I thought that compinit was the entire 
completion system!  Commenting it out and restarting, just as you say, I 
get 'dumb' file completions just as wanted.  Can we have it both ways?  
That is, tweak compinit so that perhaps on a final press of the TAB key 
it  will fall back to dumb file completion even if a kosher match has 
not been found?  Or some sort of temporary fallback to dumb completion?  
Most of the time it seems that file completion is all that's happening 
and anyway this sort of issue is very rare here, but short of restarting 
it would be nice to have dumb completion 'override' when wanted.  
Perhaps if a final press of TAB was used then instead of this:

Completing package

... we'd see:

Fallback to completing file

... or something like that.

I looked at zcompdump and there's nothing in there that looks 
promising.  I know that completion is the most inscrutable part of zsh, 
so I won't even attempt to understand it, and any tweak will be taken 
without question and on authority.  Or is there an approachable 
document?  Or some workaround?




  reply	other threads:[~2019-09-29 15:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-28 17:05 Ray Andrews
2019-09-28 17:13 ` Roman Perepelitsa
2019-09-28 17:36   ` Ray Andrews
2019-09-29  4:47     ` dana
2019-09-29 15:29       ` Ray Andrews
2019-09-29 16:44         ` Bart Schaefer
2019-09-29 18:41           ` Ray Andrews
2019-09-29 19:06             ` Bart Schaefer
2019-09-29 19:35               ` Ray Andrews
2019-09-29 13:09     ` Mikael Magnusson
2019-09-29 15:11       ` Ray Andrews [this message]
2019-09-29 15:19         ` Pier Paolo Grassi
2019-09-28 17:14 ` gmail

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=3894eb29-b17a-0bf3-21f9-f9c44cb37428@eastlink.ca \
    --to=rayandrews@eastlink.ca \
    --cc=zsh-users@zsh.org \
    /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 public inbox

	https://git.vuxu.org/mirror/zsh/

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 NNTP newsgroup(s).