Case-insensitive completion

Case-insensitive completion

[Jesper Holmberg]

I'm trying to find a way where completion of file names is case-insensitive
but where the case-insensitive matches are suggested after the case-sensitive
ones.

To test this, I've created to directories, called "Nic" and "nik".

If I use these two lines:

zstyle ':completion:*' completer _expand _complete _ignored
zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}'

I get case-insensitive matching, so that typing "cd ni<tab>" gives me
first "Nic", then "nik". This is fine, but as I said, I would like the
case-sensitive completions matching first, so that "nik" would be
suggested before "Nic".

As I interpret the manual, the following lines:

zstyle ':completion:*' completer _expand _complete _complete:jhcase _ignored
zstyle ':completion:*:jhcase:*' matcher-list 'm:{a-z}={A-Z}'

would achieve what I want. However, now typing "cd ni<tab>" gives me only
"nik", and apparently "Nic" no longer matches. I suppose my jhcase-completion
completer is never called.

What am I missing?

TIA,

Jesper

Re: Case-insensitive completion

[Bart Schaefer]

On Sep 14, 12:30pm, Jesper Holmberg wrote:
}
} As I interpret the manual, the following lines:
} 
} zstyle ':completion:*' completer _expand _complete _complete:jhcase _ignored
} zstyle ':completion:*:jhcase:*' matcher-list 'm:{a-z}={A-Z}'
} 
} would achieve what I want. However, now typing "cd ni<tab>" gives me only
} "nik", and apparently "Nic" no longer matches.
} 
} What am I missing?

Completers are called in order until one of them succeeds.  Because the
_complete call found "nik", _complete:jhcase was never called.

To get both kinds of patterns, you instead need to use a combination of
several styles that can be rather bewildering:

file-patterns and/or tag-order, to divide the matches into tagged groups;
group-order and possibly group-name, for display ordering of the groups;
matcher (not matcher-list), to control which matches are in which group.

This is a start at it:

-------
zstyle ':completion:*:ci-globbed-files' matcher 'm:{a-z}={A-Z}'
zstyle ':completion:*' file-patterns \
  '(#I)%p:globbed-files %p:ci-globbed-files' '*:all-files'
zstyle ':completion:*' group-order globbed-files ci-globbed-files all-files
zstyle ':completion:*' group-name ''
-------

The difficulties are:

- It may work differently when completing in default context than when
  completing after a command such as "ls" that has its own completion
  function defined.  E.g., "ls" somehow ignores the globbed-files group
  and goes directly to ci-globbed-files, I don't know why.

- It's quite difficult to express the concept "only files that match
  case-insensitively, not those that match case-sensitively."  Thus the
  ci-globbed-files group is a superset of globbed-files and you get a
  redundant listing.

- file-patterns are not tried after the first one that has the pattern
  '*:...' which is why the (#I) is thrown in on globbed-files, to force
  attempting both globbed-files and ci-globbed-files even if the match
  pattern substituted by %p is '*'.

Also note that there was at least one dev release where %p was not
handled properly.  I don't recall whether 4.0.7 has that bug.  I tried
the above only with the current CVS incarnation of 4.1.1-dev-1.

Re: Case-insensitive completion

[Jesper Holmberg]

* On Sun Sep 14, Bart Schaefer wrote:
> On Sep 14, 12:30pm, Jesper Holmberg wrote:
> Completers are called in order until one of them succeeds.  Because the
> _complete call found "nik", _complete:jhcase was never called.

Thank you for your reply, Bart. I thought that all the completers were
called, each appending to the previous list. I realize now that what I'm
trying to achieve is quite difficult with the way it really works. I'll
have a try with your suggested solution.

However, perhaps I better state my original problem here, instead of
trying to solve it with the wrong solution.

I have been using case-insensitive completion of file names for a while
now, with the generic:

zstyle ':completion:*' matcher-list 'm:{a-zåäö}={A-ZÅÄÖ}'

This works well, but - as is the essence of case-insensitivity - one loses
some precision in specifying ones needs: it is difficult to express that
in this particular instance I want to really match with case sensitivity.

Say for example I have the following files:

aac.txt aAa.txt Aaa.txt aAb.txt

If I want to complete for "Aaa.txt", it works well, I just put capital "A"
and hit tab, and since the matching is only one-way, the completer knows
that I really want a capital A, and gives me Aaa.txt.

If, on the other hand, I wanted aac.txt, hitting "aa" would not really
help me, since "aAa.txt", "Aaa.txt" and "aAb.txt" would all be proposed
before my aac.txt. I am thus looking for an easy way to specify that 
*this time* I really want to match on literally "aa".

Perhaps what I want is unachievable, but has anyone solved this in a smart
way?

TIA,

Jesper

Re: Case-insensitive completion

[Oliver Kiddle]

Bart wrote:

> This is a start at it:
> 
> -------
> zstyle ':completion:*:ci-globbed-files' matcher 'm:{a-z}={A-Z}'
> zstyle ':completion:*' file-patterns \
>   '(#I)%p:globbed-files %p:ci-globbed-files' '*:all-files'
> zstyle ':completion:*' group-order globbed-files ci-globbed-files all-files
> zstyle ':completion:*' group-name ''
> -------
> 
> The difficulties are:
> 
> - It may work differently when completing in default context than when
>   completing after a command such as "ls" that has its own completion
>   function defined.  E.g., "ls" somehow ignores the globbed-files group
>   and goes directly to ci-globbed-files, I don't know why.

Problem is related to nested tag loops and the old problem of ordering
of options passed down versus those determined further down.

In this case, all matches are going into an argument-rest group thanks
to _arguments and the more specific group names get ignored. I can't
see a way round it using styles because you can't avoid the -default-
group.

Not easy to solve more generally either. Long term we probably need to
keep track of the whole chain of tags used along the way.

> - It's quite difficult to express the concept "only files that match
>   case-insensitively, not those that match case-sensitively."  Thus the
>   ci-globbed-files group is a superset of globbed-files and you get a
>   redundant listing.

This is a bit unfortunate. Matching control probably needs a way to
specify that only matches which needed the rule should be matched.
Handling ordering for pure menu completion users is simply something
which was never particularly considered.

> - file-patterns are not tried after the first one that has the pattern
>   '*:...' which is why the (#I) is thrown in on globbed-files, to force
>   attempting both globbed-files and ci-globbed-files even if the match
>   pattern substituted by %p is '*'.

Yuk. Could you see if there was a good reason for that? If it is just
for efficency it should perhaps be removed. Will fall down with other
styles like ignored-patterns and ignore-line.

> Also note that there was at least one dev release where %p was not
> handled properly.  I don't recall whether 4.0.7 has that bug.  I tried
> the above only with the current CVS incarnation of 4.1.1-dev-1.

I think that bug is in 4.0.7 which is quite bad really.

Oliver

Re: Case-insensitive completion

[Peter Stephenson]

Bart wrote:
> This is a start at it:
> 
> -------
> zstyle ':completion:*:ci-globbed-files' matcher 'm:{a-z}={A-Z}'
> zstyle ':completion:*' file-patterns \
>   '(#I)%p:globbed-files %p:ci-globbed-files' '*:all-files'
> zstyle ':completion:*' group-order globbed-files ci-globbed-files all-files
> zstyle ':completion:*' group-name ''
> -------

You know you can do
  zstyle blah matcher-list '' 'm:{a-z}={A-Z}
to try out no modifications first?  I suppose the problem is that
matcher-list is too early to try for each context separately, but I
wouldn't have thought that was too hard to fix.

pws


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Case-insensitive completion

[Oliver Kiddle]

Peter wrote:
> 
> You know you can do
>   zstyle blah matcher-list '' 'm:{a-z}={A-Z}
> to try out no modifications first?  I suppose the problem is that
> matcher-list is too early to try for each context separately, but I
> wouldn't have thought that was too hard to fix.

That's not the same. That is just a shorter way of doing what the
original _complete _complete:jhcase completer style was doing.

If I'm understanding the problem correctly, it relates to the order in
which matches are cycled through in menu completion and not the order in
which sets of matches are tried.

Oliver

Re: Case-insensitive completion

[Jesper Holmberg]

Right, I realize that I've stated my real problem too vaguely. Several of
my recent postings to this list are based on the fact that I'm using menu
completion, and that I'm concerned about in which order completions are
suggested, as that is a major convenience factor when stepping through the
suggestions.

Jesper


* On Tue Sep 16, Oliver Kiddle wrote:
> Peter wrote:
> > 
> > You know you can do
> >   zstyle blah matcher-list '' 'm:{a-z}={A-Z}
> > to try out no modifications first?  I suppose the problem is that
> > matcher-list is too early to try for each context separately, but I
> > wouldn't have thought that was too hard to fix.
> 
> That's not the same. That is just a shorter way of doing what the
> original _complete _complete:jhcase completer style was doing.
> 
> If I'm understanding the problem correctly, it relates to the order in
> which matches are cycled through in menu completion and not the order in
> which sets of matches are tried.
> 
> Oliver

Re: Case-insensitive completion

[Bart Schaefer]

On Sep 15,  9:08pm, Jesper Holmberg wrote:
} Subject: Re: Case-insensitive completion
}
} aac.txt aAa.txt Aaa.txt aAb.txt
} 
} If I want to complete for "Aaa.txt", it works well, I just put capital "A"
} and hit tab, and since the matching is only one-way, the completer knows
} that I really want a capital A, and gives me Aaa.txt.
} 
} If, on the other hand, I wanted aac.txt, hitting "aa" would not really
} help me, since "aAa.txt", "Aaa.txt" and "aAb.txt" would all be proposed
} before my aac.txt. I am thus looking for an easy way to specify that 
} *this time* I really want to match on literally "aa".
} 
} Perhaps what I want is unachievable, but has anyone solved this in a smart
} way?

Normally the way to do that would be to use different keybindings for
"complete case-insensitively" vs. "complete case-sensitively" and tell
zsh your preference by which of them you invoke.

Start with zstyles something like this:

  zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}'
  zstyle ':completion:*:case-sensitive:*' matcher-list ''
  zstyle ':completion:*' completer _expand _complete _ignored

Then, in a file (name doesn't matter much) somewhere in the path where
compinit looks for completion functions, you put:

---- 8< ---- snip ---- 8< ----
#compdef -k complete-word \C-xI
_main_complete _expand _complete:case-sensitive _ignored
---- 8< ---- snip ---- 8< ----

Replace \C-xI (control x shift i) with whatever keybinding you want to
have attached to case-sensitive completion.

You could get a little fancier with the function and avoid hardwiring
the list of completers by copying some of the code from _main_complete
to get the matcher-list context, then modify that list of matchers to
attach :case-sensitive where needed, before calling _main_complete.

Warning, I didn't actually test any of the above.

Re: Case-insensitive completion

[Oliver Kiddle]

Bart wrote:

> Normally the way to do that would be to use different keybindings for
> "complete case-insensitively" vs. "complete case-sensitively" and tell
> zsh your preference by which of them you invoke.
> 
> Start with zstyles something like this:
> 
>   zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}'
>   zstyle ':completion:*:case-sensitive:*' matcher-list ''
>   zstyle ':completion:*' completer _expand _complete _ignored
> 
> Then, in a file (name doesn't matter much) somewhere in the path where
> compinit looks for completion functions, you put:
> 
> ---- 8< ---- snip ---- 8< ----
> #compdef -k complete-word \C-xI
> _main_complete _expand _complete:case-sensitive _ignored
> ---- 8< ---- snip ---- 8< ----

Would always use _generic for that type of thing myself. Avoids the need
for a separate function file:

zle -C case-sensitive complete-word _generic
zstyle ':completion:case-sensitive::::' completer _expand _complete _ignored
zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}'
zstyle ':completion:case-sensitive:*' matcher-list ''
bindkey '^XI' case-sensitive

Oliver

Re: Case-insensitive completion

[Oliver Kiddle]

On 14 Sep, Jesper Holmberg wrote:
> 
> As I interpret the manual, the following lines:
> 
> zstyle ':completion:*' completer _expand _complete _complete:jhcase _ignored
> zstyle ':completion:*:jhcase:*' matcher-list 'm:{a-z}={A-Z}'
> 
> would achieve what I want. However, now typing "cd ni<tab>" gives me only
> "nik", and apparently "Nic" no longer matches. I suppose my jhcase-completion
> completer is never called.

Here's another idea on how to do this. It's no better than Bart's
suggestion but might be closer to what you want to do. It's not specific
to filename completion and it still suffers the problem that matches
that don't need the matching control get added twice. Not compatible
with using a group-name style of '' to use the tag name but I'm supposing
that for pure menu-completion you might not care about that anyway.

_cscomplete() {
  _complete
  return 1
}
zstyle ':completion:*:cscomplete:*' group-name case-sensitive
zstyle ':completion:*:complete:*' group-name case-insensitive
zstyle ':completion:*' group-order case-sensitive case-insensitive
zstyle ':completion:*::::' completer _cscomplete _complete
zstyle ':completion:*:cscomplete:*:*' matcher-list ''
zstyle ':completion:*:complete:*' matcher-list 'm:{a-z}={A-Z}'

Re: Case-insensitive completion

[Bart Schaefer]

On Sep 17,  9:30am, Oliver Kiddle wrote:
}
} Bart wrote:
} 
} > Normally the way to do that would be to use different keybindings for
} > "complete case-insensitively" vs. "complete case-sensitively" and tell
} > zsh your preference by which of them you invoke.
}
} Would always use _generic for that type of thing myself. Avoids the need
} for a separate function file:

Ah, yes, I'd completely (ahem) forgotten about _generic.

The only advantage to using a separate file is the automatic #compdef,
which isn't much advantage at all.

} zle -C case-sensitive complete-word _generic
} zstyle ':completion:case-sensitive::::' completer _expand _complete _ignored

In fact, you don't even need that style unless using an unusual set of
completers; this one is sufficient:

} zstyle ':completion:case-sensitive:*' matcher-list ''

Re: Case-insensitive completion

[Bart Schaefer]

On Sep 17,  9:40am, Oliver Kiddle wrote:
>
> Here's another idea on how to do this. It's no better than Bart's

Except that yours is not file-completion-specific, which might be
better in some circumstances.  Just one question:

> _cscomplete() {
>   _complete
>   return 1
> }

Are completers always called with no arguments?  Or should that be

    _cscomplete() {
      _complete $*
      return 1
    }

??

Re: Case-insensitive completion

[Oliver Kiddle]

Bart wrote:
> 
> Are completers always called with no arguments?  Or should that be
> 
>     _cscomplete() {
>       _complete $*
>       return 1
>     }

They are always called with no arguments.

_approximate actually accepts a -a option to specify the number of
errors. It isn't used by anything yet. Might be useful from an _correct
like wrapper I suppose.

Oliver

Re: Case-insensitive completion

[Jesper Holmberg]

Thank you, Bart and Oliver. I now have two different solutions to my
original problem, and they both seem very good. Thanks for all the help.

Jesper