zsh-workers
 help / color / mirror / code / Atom feed
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


  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).