Re: Getting "parse error" from _path_files

Re: Getting "parse error" from _path_files

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jun 5, 10:04am, Sven Wischnowsky wrote:
> } Subject: Re: Getting "parse error" from _path_files
> }
> } Bart Schaefer wrote:
> } 
> } >     (( PENDING )) && compstate[insert]=tab
> } > 
> } > near the top of _main_complete, right after curcontext is set up, and that
> } > seems to help a bit, but I'm rather leery of that solution.  It does need
> } > to use PENDING somehow, though.
> } 
> } It should then immediately return, too (to really avoid calling all
> } that completion code).
> 
> Actually, it does return immediately, because of:
> 
> if [[ "$compstate[insert]" = tab* && "$WIDGET" != *list* ]]; then
>   { zstyle -T ":completion:${curcontext}:" insert-tab &&
>     { [[ "$curcontext" != :* || -z "$compstate[vared]" ]] ||
> 	zstyle -t ":completion:vared${curcontext}:" insert-tab } } && return 0
> 
> Which reminds me to wonder why insert-tab is tested for *not* being set,
> at that point?

Err...? It is tested for being set (to true), with different defaults for
not-in-vared and in-vared.

> } > Returning to the original issue:  Perhaps it would be possible to special-
> } > case parsing within ${(e)...} so that errors of this sort simply return an
> } > empty value for the parameter rather than aborting the whole call chain?
> }
> } How about a parameter flag, the opposite of `X', but used for `e' to
> } make it ignore parse errors and return an empty string in such cases?
> } 
> } Or make `e' not report errors normally and use `X' for `e', too, to
> } make it report errors?
> 
> I'd forgotten about (X); yes, I think the latter (have (e) ignore errors
> unless (X) is given) is the right solution.
> 
> It doesn't even have to ignore the errors silently; redirecting 2> is fine.
> It just has to not abort the surrounding parse.

No time now... maybe I'll be able to do that this evening (I'll then
make it behave like (Q), etc).

Bye
 Sven


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

insert-tab (Re: Getting "parse error" from _path_files)

[Bart Schaefer]

On Jun 5,  4:33pm, Sven Wischnowsky wrote:
} Subject: Re: Getting "parse error" from _path_files
}
} Bart Schaefer wrote:
} 
} > if [[ "$compstate[insert]" = tab* && "$WIDGET" != *list* ]]; then
} >   { zstyle -T ":completion:${curcontext}:" insert-tab &&
} >     { [[ "$curcontext" != :* || -z "$compstate[vared]" ]] ||
} > 	zstyle -t ":completion:vared${curcontext}:" insert-tab } } && return 0
} > 
} > Which reminds me to wonder why insert-tab is tested for *not* being set,
} > at that point?
} 
} Err...? It is tested for being set (to true), with different defaults for
} not-in-vared and in-vared.

zagzig[38] zstyle ':completion:*' insert-tab true
zagzig[39] ls x<TAB>
Completing `file'

According to the doc for insert-tab, I should have gotten a tab inserted,
because there is a non-blank character to the left of the cursor.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Getting "parse error" from _path_files

[Bart Schaefer]

On Jun 5, 10:04am, Sven Wischnowsky wrote:
} Subject: Re: Getting "parse error" from _path_files
}
} Bart Schaefer wrote:
} 
} >     (( PENDING )) && compstate[insert]=tab
} > 
} > near the top of _main_complete, right after curcontext is set up, and that
} > seems to help a bit, but I'm rather leery of that solution.  It does need
} > to use PENDING somehow, though.
} 
} It should then immediately return, too (to really avoid calling all
} that completion code).

Actually, it does return immediately, because of:

if [[ "$compstate[insert]" = tab* && "$WIDGET" != *list* ]]; then
  { zstyle -T ":completion:${curcontext}:" insert-tab &&
    { [[ "$curcontext" != :* || -z "$compstate[vared]" ]] ||
	zstyle -t ":completion:vared${curcontext}:" insert-tab } } && return 0

Which reminds me to wonder why insert-tab is tested for *not* being set,
at that point?

} > Returning to the original issue:  Perhaps it would be possible to special-
} > case parsing within ${(e)...} so that errors of this sort simply return an
} > empty value for the parameter rather than aborting the whole call chain?
}
} How about a parameter flag, the opposite of `X', but used for `e' to
} make it ignore parse errors and return an empty string in such cases?
} 
} Or make `e' not report errors normally and use `X' for `e', too, to
} make it report errors?

I'd forgotten about (X); yes, I think the latter (have (e) ignore errors
unless (X) is given) is the right solution.

It doesn't even have to ignore the errors silently; redirecting 2> is fine.
It just has to not abort the surrounding parse.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Getting "parse error" from _path_files

[Sven Wischnowsky]

Bart Schaefer wrote:

> Cut'n'paste the following into a zsh-3.1.7:
> 
> echo "${(@)${(@s:|:)${(@)${(@f)$(< /etc/printcap)}:#[ 	\#]*}%%:*}%%[ 	]*}"
>                                          
> Note that inside each pair of [ ] are a space and a tab.
> 
> I get, at each tab:
> 
> _path_files:249: parse error
> 
> This is mildly annoying, as it aborts completion without giving the system a
> chance to clean up (e.g., it's another case where very bad things happen if
> it is _complete_debug that's called).  I vaguely recall forcing something
> into a $(...) in some other completer to avoid a similar problem.
> 
> There are actually two things at issue here.  The second is that I'd rather
> that completion didn't happen when I'm doing cut'n'paste.  I tried putting:
> 
>     (( PENDING )) && compstate[insert]=tab
> 
> near the top of _main_complete, right after curcontext is set up, and that
> seems to help a bit, but I'm rather leery of that solution.  It does need
> to use PENDING somehow, though.

It should then immediately return, too (to really avoid calling all
that completion code).

> Returning to the original issue:  Perhaps it would be possible to special-
> case parsing within ${(e)...} so that errors of this sort simply return an
> empty value for the parameter rather than aborting the whole call chain?
> This would correspond to what happens when you use `eval', as in:
> 
> function fail() {
>     local x y z
>     x='${y'
>     eval 'z=${(e)x}'
>     echo got here
>     z=${(e)x}
>     echo did not get here
> }
> 
> Alternately, of course, we could use `eval' on line 249 of _path_files and
> in similar spots, but the quoting may sometimes get messy ...

How about a parameter flag, the opposite of `X', but used for `e' to
make it ignore parse errors and return an empty string in such cases?

Or make `e' not report errors normally and use `X' for `e', too, to
make it report errors?

Bye
 Sven


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

Getting "parse error" from _path_files

[Bart Schaefer]

Cut'n'paste the following into a zsh-3.1.7:

echo "${(@)${(@s:|:)${(@)${(@f)$(< /etc/printcap)}:#[ 	\#]*}%%:*}%%[ 	]*}"
                                         
Note that inside each pair of [ ] are a space and a tab.

I get, at each tab:

_path_files:249: parse error

This is mildly annoying, as it aborts completion without giving the system a
chance to clean up (e.g., it's another case where very bad things happen if
it is _complete_debug that's called).  I vaguely recall forcing something
into a $(...) in some other completer to avoid a similar problem.

There are actually two things at issue here.  The second is that I'd rather
that completion didn't happen when I'm doing cut'n'paste.  I tried putting:

    (( PENDING )) && compstate[insert]=tab

near the top of _main_complete, right after curcontext is set up, and that
seems to help a bit, but I'm rather leery of that solution.  It does need
to use PENDING somehow, though.

Returning to the original issue:  Perhaps it would be possible to special-
case parsing within ${(e)...} so that errors of this sort simply return an
empty value for the parameter rather than aborting the whole call chain?
This would correspond to what happens when you use `eval', as in:

function fail() {
    local x y z
    x='${y'
    eval 'z=${(e)x}'
    echo got here
    z=${(e)x}
    echo did not get here
}

Alternately, of course, we could use `eval' on line 249 of _path_files and
in similar spots, but the quoting may sometimes get messy ...

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net