gmane.comp.shells.zsh.user

Re: completion oddity

Bart Schaefer — 2012-05-24T03:39:14

}
} You did run the setopt line I had included in the setup section right?

Aha.  I thought so, but had not.

Setting completeinword is the key here.  With that not set, it's always
moving the cursor to the end of the word and then completing from there.
That's the underlying reason why it doesn't detect the ambiguity in the
original (way back in Derek's first post) example.

Re: globbing in assignment

Han Pingtian — 2012-05-24T01:59:30

Thanks. Now I got it.

Re: completion oddity

Greg Klanderman — 2012-05-23T18:48:32



Hmmm I'm not fully up to date with CVS:

phl% echo $ZSH_VERSION $ZSH_PATCHLEVEL 
4.3.17-dev-0 1.5607

but only by a couple months.  I'll update and see if anything changes.
But I just tried again with this version and see exactly as I posted.
Also tried 4.3.11-dev-1 1.5222 and 4.3.17-dev-0 1.5600 with same
result.

You did run the setopt line I had included in the setup section right?

Greg

Re: Autocomplete for umount with space

Mikael Magnusson — 2012-05-23T10:32:14

You can find all the ml archives here:
http://www.zsh.org/mla/
You don't need to be subscribed to send mail there, but if you're not
i recommend asking to be CC'd in the mails you send. If you do
subscribe, note that all announce mails are sent to users, and all
users mails are sent to workers, so you only need to subscribe to one
of them.

Re: globbing in assignment

Peter Stephenson — 2012-05-23T10:30:56

On Wed, 23 May 2012 18:08:46 +0800
Han Pingtian <hanpt< at >linux.vnet.ibm.com> wrote:

Ah, you're misunderstanding what's going on.

GLOB_ASSIGN has the effect that

v=*

expands * at this point.  The value of v contains all the files.

GLOB_SUBST has the effect that a variable is expanded at the point where
it's substituted.  So without GLOB_ASSIGN, or equivalently quoting the
value assigned to v,

% v='*'
% setopt globsubst
% print $v
<files>
% unsetopt globsubt
% print $v
*

Re: Autocomplete for umount with space

David Lee — 2012-05-23T10:29:04

So that's why I didn't get a response!
I'm not subscribed to zsh-workers… do I have to be subscribed there to post questions?

Also, Mikael, could you kindly forward the thread to me, or send me a link to the thread archives?

Thanks, and sorry for the double post.

On May 23, 2012, at 3:24 AM, Mikael Magnusson wrote:

Re: Autocomplete for umount with space

Mikael Magnusson — 2012-05-23T10:24:32

Deja vu? You sent this mail to -workers recently and there was a
followup discussion resulting in a fix. Are you not subscribed? It
looks like you weren't CC'd on the followup.

On 23/05/2012, David Lee <davidomundo< at >gmail.com> wrote:

Re: globbing in assignment

Han Pingtian — 2012-05-23T10:08:46

Thanks for reply. I don't set globassign in the interactive shell but
the globbing is working in assigment. And finally I find out it's
"glob_subst" which also has the same effect of "glob_assign". Maybe
something is wrong?


Looks like ther

Autocomplete for umount with space

David Lee — 2012-05-23T10:10:55

Hi ZSH users,

Autocompletion for umount lists mount points clipped at the first space. For example, if I have "/Volumes/Media Drive" and "/Volumes/Media Disk", autocomplete for amount will only list a single "/Volumes/Media".

Is there a fix or workaround for this?

--David

Re: globbing in assignment

Peter Stephenson — 2012-05-23T09:10:43

On Wed, 23 May 2012 14:18:59 +0800
Han Pingtian <hanpt< at >linux.vnet.ibm.com> wrote:

I would guess you don't have the option set in one case, but do in
another.  Try putting "setopt globassign" at the start of the script,
which seems to do what I expect here.  There's no explicit code to stop
it working in scripts.

Re: completion oddity

Bart Schaefer — 2012-05-23T06:31:55

}
} So if I set up my own style processing in order to override this
} behavior (both the earliness and the use of the empty value) as you
} suggested to Greg, would it be kosher to use the matcher-list style,
} or would I want to use my own style name?

Doesn't really matter.  Using the matcher-list name means that any
definition of that for any less-specific context will end up applying 
to your more specific situation, but if you're planning always to
provide the most specific definition then that won't matter.

} > }     gtar --show--names<TAB>
} > } 
} > } and it beeps and moves me to between the second double-hyphen,
} > } then after another beep, starts cycling between the two. If I
} > } just have "--show" there, then it ends up cycling among four
} > } alternatives.
} 
}     --show-defaults
}     --show-omitted-dirs
}     --show-transformed-names
}     --show-stored-names

Oh, well, that all makes sense.  When you have all four possibilities
there are no common suffixes, and when you do have a common suffix
there are the same number of words; in neither case is there the
possibility of resolving the ambiguity.

On May 22,  6:03pm, Danek Duvall wrote:
} Subject: Re: completion oddity
}
} ... is there some way, either in a user's configuration or within
} a single completion function, to turn off the "end with the same
} substring" completion, while maintaining the dash-separates-words
} aspect of the completion [...?]

In fact, there is, and it's at once so obvious and so unintuitive
that I'm quite sure it wasn't done on purpose.

Define _k this way:

    _k() { _arguments --really-r1-word --r1-word }

The specifications passed to _arguments are tried in order, so if
the longer one (which I suspect means the one having the most words
rather than the most characters) is tried first, the ambiguity is
re-discovered and you get menu completion.

globbing in assignment

Han Pingtian — 2012-05-23T06:18:59

Hello,

I just notice filename globbing doesn't occur in my script, like 

v=*

but it works in the interactive shell. Althoug I can make it work
by "setop glob_assign" or use "v=(*)", but it looks like the behavior's
diversity is a little strange.

Any thoughts?

Thanks.

Re: completion oddity

Bart Schaefer — 2012-05-23T06:25:12

}
} % k --r-word
} # with cursor on final hyphen hit <tab>:
} # nothing inserted; the *two* options are listed
} # no matter how many times you hit <tab>

I took your word for this when I was replying before (and I didn't say
anything incorrect) but now that I try it myself I don't get this
behavior.  I get --r-word completed to --r1-word no matter which way
I put --r-word onto the line in the first place and no matter where
within the word I place the cursor.

However, see mail I'm about to send to Danek ...

Re: completion oddity

Bart Schaefer — 2012-05-23T06:08:19

}
} OK, thanks for looking into this Bart.  So _main_complete is still
} looping over zstyle matcher-list values in completing parameters but
} it's not used?  I do see that _arguments uses _description which uses
} _matcher if non-empty (as you noted earlier).

Hmm, hadn't thought about that ... _parameters calls _wanted so it does
go through _description, which means the matcher-list is also applied
to parameter names.  At this point I have no idea whether that is
intentional.

} I have to confess I cannot follow all this completion code though.

I'm not sure anyone can.
 
On May 22,  7:09pm, Greg Klanderman wrote:
}
} > You're right; in the first case the completion system has recorded a
} > list of "ambiguous positions" that distinguish what it filled

Sorry, thinko there -- it actually records UNambiguous positions, and
insert_positions which are the places that something needs to be added
or changed in order that the word on the line match one of the possible
completions.

} Oh the horrors never end.. could you be so kind as to point me to some
} of the relevant bits of code that are doing this logic and how that
} state is stored?  Please tell me it's not in the even more
} impenetrable C code..

The state is available in the compstate hash, which is actually pretty
thoroughly documented (though exactly what the internals do with the
values isn't, so much).  However, yes, the logic that figures out what
are insert_positions and what are unambiguous_positions is all deep
in the C code.  There is exactly one example of shell code making use
of one of those values:  Functions/Zle/cycle-completion-positions --
but it's not very helpful.

Re: completion oddity

Danek Duvall — 2012-05-23T01:03:22


Hm.  So maybe undoing that locally is a possibility ... is there some way,
either in a user's configuration or within a single completion function, to
turn off the "end with the same substring" completion, while maintaining
the dash-separates-words aspect of the completion, so that

    k --r<TAB>

is considered fully ambiguous, and either cycles through the options or
lists the ambiguous completions, while

    k --r-r-w<TAB>

would consider --really-r1-word unambiguous and complete only it?

I think that would be a decent compromise in my mind.

Thanks,
Danek

Re: completion oddity

Greg Klanderman — 2012-05-22T23:09:51


Oh the horrors never end.. could you be so kind as to point me to some
of the relevant bits of code that are doing this logic and how that
state is stored?  Please tell me it's not in the even more
impenetrable C code..

Greg

Re: completion oddity

Danek Duvall — 2012-05-22T23:06:46


So if I set up my own style processing in order to override this behavior
(both the earliness and the use of the empty value) as you suggested to
Greg, would it be kosher to use the matcher-list style, or would I want to
use my own style name?


No; three have two, one has one:

    --show-defaults
    --show-omitted-dirs
    --show-transformed-names
    --show-stored-names

I'm still trying to formulate a question about why the default behavior
here is user friendly, but I'm having trouble.  I can understand the logic
of each step, but it doesn't seem like it's the right thing overall.

Thanks,
Danek

Re: completion oddity

Bart Schaefer — 2012-05-22T22:57:45

Sven W. was a clever but highly suggestible university student.
Someone said, "Hey, all these possible variations end with the same
substring, why isn't completion smart enough to fill that in for me?"
and Sven responded, "OK, now it is that smart," and all the possible
side-effects were either not considered or considered to be less
important than the smarts.


You're right; in the first case the completion system has recorded a
list of "ambiguous positions" that distinguish what it filled in vs.
what the user typed.  It decides whether the match is unique based on
whether there is another ambiguous position to which it can advance.
This is all part of the aforementioned smarts.

Re: completion oddity

Greg Klanderman — 2012-05-22T22:55:53




OK, thanks for looking into this Bart.  So _main_complete is still
looping over zstyle matcher-list values in completing parameters but
it's not used?  I do see that _arguments uses _description which uses
_matcher if non-empty (as you noted earlier).  I have to confess I
cannot follow all this completion code though.

Greg

Re: completion oddity

Bart Schaefer — 2012-05-22T22:30:11

No.  The sneaky thing here is that generically, the matcher-list
zstyle is for matching file names, not command options.

Consequently _arguments doesn't use the matcher-list style itself;
it's up to the individual context completion functions (like _k in the
example) to look up the style (presumably in an option-specific style
context) and pass it to _arguments -M.

Practically speaking, the assumption is that the completion function
must "know" exactly what the command options "look like" for the
command it is completing, so there's no reason to provide a way for
the user to override it.  File names, on the other hand, could look
like anything, so the user is given hooks to tell completion about
those file names.

I can't recall any discussion of leading to a conscious decision to
have it work this way; it just fell out so from the incremental
process of making the completion system handle common cases cleverly
(without requiring the user to tweak everything).

Re: completion oddity

Greg Klanderman — 2012-05-22T16:35:41





Hi Bart,

Is there something I can put in matcher-list to effectively turn off
this default and globally get the behavior as when you added "-M ''"
below:

    _k () { _arguments -M '' --r1-word --really-r1-word }

I tried these:

% zstyle ':completion:*' matcher-list ' ' # space
% zstyle ':completion:*' matcher-list 'm:{a-z}={a-z}'

and neither seems to do the trick..

Greg