From: Felipe Contreras <felipe.contreras@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh-workers@zsh.org
Subject: Re: zle messes up 'words' variable?
Date: Tue, 3 May 2011 11:05:32 +0300 [thread overview]
Message-ID: <BANLkTiktPbzZ4v=NSNkP5CV78ctSTQ9gsg@mail.gmail.com> (raw)
In-Reply-To: <110502184235.ZM14465@torch.brasslantern.com>
On Tue, May 3, 2011 at 4:42 AM, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On May 2, 9:11pm, Felipe Contreras wrote:
> } I am using bashcompinit, but the issue appears without it.
>
> Without bashcompinit, there is by definition not an issue. Or, if you
> prefer, you should have expected this issue to appear, because words is
> documented as a special variable in completion function context.
The fact that it's documented as a special variable doesn't mean that
the behavior should be totally unexpected.
1) Without modifier
Then 'words' can be re-used like any other variable.
2) With 'local' modifier
Then modifying 'words' has an impact only on the current function, not
on the scope where the variable was defined as local.
2.1) When using #compdef tag
Then 'words' can be modified like any other variable.
3) With 'typedef -h'
Then 'words' can be modified like any other variable.
I was expecting an explanation of these discrepancies, and a way to
globally make 'words' work as expected without having to replace each
use of 'local' by 'typedef -h'.
I don't think anybody knows what's going on, so nobody knows how to do
that. In fact, this is probably a bug.
> If what you want to discuss is ways to fix bashcompinit so that the
> functions in bash completion work as expected, that's one thing. If
> what you're asking is for the special-ness of "words" to be undone
> for completion in general, that's so unlikely to happen as to not be
> worth continuing.
You are not good at compartmentalizing aren't you? If you fix the
issue with my example, you fix the issue with bashcompinit. It's the
same issue. Or "riddle" if that word makes you more comfortable.
But if you want to mix the two things together, fine:
---
#!bash
autoload -U +X bashcompinit && bashcompinit
set_vars ()
{
cur="foo"
words="foo"
cwords="foo"
}
_foo ()
{
local cur words cwords
set_vars
echo "cur=${cur} words=${words} cwords=${cwords}" >> /tmp/comp_test.txt
}
complete -F _foo foo
---
cur=foo words= cwords=foo
Now that is clearly a bug.
--
Felipe Contreras
next prev parent reply other threads:[~2011-05-03 8:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-27 8:26 Felipe Contreras
2011-04-27 9:02 ` Jérémie Roquet
2011-04-27 9:11 ` Felipe Contreras
2011-04-27 9:51 ` Felipe Contreras
2011-04-27 15:06 ` Bart Schaefer
2011-04-28 20:19 ` Felipe Contreras
2011-04-29 3:31 ` Bart Schaefer
2011-05-02 18:11 ` Felipe Contreras
2011-05-03 1:42 ` Bart Schaefer
2011-05-03 8:05 ` Felipe Contreras [this message]
2011-05-03 14:39 ` Bart Schaefer
2011-05-03 15:04 ` Bart Schaefer
2011-05-03 17:41 ` Felipe Contreras
2011-05-04 0:39 ` Bart Schaefer
2011-05-05 14:39 ` Felipe Contreras
2011-05-05 16:24 ` Bart Schaefer
2011-05-05 16:40 ` Felipe Contreras
2011-05-05 19:38 ` Bart Schaefer
2011-05-05 20:14 ` Felipe Contreras
2011-05-05 21:12 ` Nikolai Weibull
2011-05-03 17:36 ` Felipe Contreras
2011-05-04 0:56 ` Bart Schaefer
2011-05-05 14:48 ` Felipe Contreras
2011-05-05 15:50 ` Bart Schaefer
2011-05-05 15:55 ` Felipe Contreras
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='BANLkTiktPbzZ4v=NSNkP5CV78ctSTQ9gsg@mail.gmail.com' \
--to=felipe.contreras@gmail.com \
--cc=schaefer@brasslantern.com \
--cc=zsh-workers@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).