Re: zsh - new user with questions

Re: zsh - new user with questions

[Sven Wischnowsky]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]


Peter Stephenson wrote:

> 
> "Stephen Riehm" wrote:
> >      extreme short cuts. ie: with tcsh's enhanced completions, to complete
> > the file named: ReadMe.First
> >      all I would type id: r.f<tab> - is there a way to do this sort of
> > thing in zsh?
> 
> You can write your own function.  See Functions/multicomp in the
> source distribution for examples.  If you really can't type uppercase
> characters, you're going to have to redo the globbing there so
> that every lowercase character becomes e.g. [rR], then you'll
> need to handle .'s in the way /'s are handled there.  Ignoring case
> may happen one day, but I doubt there's ever going to be a built-in
> way of saying 'look and see if there are any characters preceeding a
> dot to be added earlier on in the completion'. 

Ahem. I already said this... I had a patch for this which Zefram
didn't include, combining a simple partial-word-completion mechanism,
cas fold completions and the autoglob option (which gave the
possibility requested by Johan Sundström some time ago).
Most people think of completion functions when thinking about that,
but that, of course, would solve the problem only for one kind of
completions (one function for files, one for options, ...) which I
consider unacceptable.
I don't want to make that old patch of mine be accepted now (I even
don't know if we can get it applied nowadays). But I am really
thinking about making the matching mechanism definable in a way that
at least gives us the possibility to get case-fold completions, the
partial-word-completion mentioned above and some other goodies.
There are still some open questions I have to think about, but since I 
should have some time in this and the next week, I may be able to
offer you an implementation to play with.

Bye
 Sven

P.S.: The fact that tcsh can do this has been nagging at me for quite some
      time now ;-)


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: zsh - new user with questions

[Sven Wischnowsky]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]


Bart Schaefer wrote:

> 
> On Aug 19,  7:35pm, Goran Larsson wrote:
> } Subject: Re: zsh - new user with questions
> }
> } 1. If we have a filename with the name "Strasse" and one with the
> }    name "Straße". Both filenames are created when the English
> }    language is selected. If the German language is selected later,
> }    wich one of them should be accessed as "STRASSE"?
> } 
> } 2. If we have a filename with the name "Straße" you can access it
> }    as "STRASSE" if you select German, but not if you select English.
> 
> He's not suggesting changing the behavior of the file system, he's
> suggesting changing the behavior of completion.  That is, if in zsh
> you typed
> 
> zsh% ls STRASSE<TAB>
> 
> then zsh would complete case-insensitively and you'd see
> 
> zsh% ls Straße
>               ^
> 	      cursor here
> 
> The actual _access_ to the file still has to use its "real" name.
> 
> Now, it's a bit more difficult to deal with cases where two characters
> maps onto one like that, because zsh normally assumes that completion
> can only produce longer words ... but otherwise it's neither impossible
> nor a problem for file creation or access.
> 

Well, *this* example is even worse: in most cases people wouldn't type 
the uppercase version, but the lowercase one, agreed? Now, the full
rule for `ß (es-zet) in an all-uppercase word' is: use `SS' if that
doesn't make the word ambiguous. E.g `Masse' becomes `MASSE' and
`Maße' becomes `MAßE', even if it looks ugly.

So, a `ß' on the line would have to match `ß' and sometimes `SS'.


Bye
 Sven

P.S.: The new orthography rules for German remove the ß entirely ;-)

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de