Re: Expanding interactively aliases

Re: Expanding interactively aliases

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> My real point is that the existing _expand appears to be expanding global
> aliases already. I wouldn't have expected this because -U is used when
> autoloading _expand. A quick check reveals that this is with the
> substitute style and is due to the fact that the aliases are expanded
> within eval.

Now that you say that... I seem to have a very faint memory of a
discussion about this (not in _expand, I think, we had the problem
somewhere else). I think we found a solution which I can't think of
now and I don't know where to search for it either.

And the maling list archive seems to be defunct -- I always get zero
metches no matter what I'm searching for.

Hm. Anyone else remember this?

> I don't think it is ideal that autoload -U functions are subject to
> aliases within eval and you could probably break a few bits of completion
> with certain global aliases. Would it be easy to avoid this somehow? The
> other solution would be a -U argument to eval which probably isn't a great
> idea because eval currently takes no options.

That aliases-inside--U-functions isn't that easy, I think (and there
may be cases where the function wants to have them expanded but the
user loaded it with -U, without thinking about this side-effect).

Bye
 Sven


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

RE: Expanding interactively aliases

[Andrej Borsenkow]

> 
> And the maling list archive seems to be defunct -- I always get zero
> metches no matter what I'm searching for.
> 

Disk full again? At least, it was the reason last time ...

Re: Expanding interactively aliases

[Geoff Wing]

Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru> typed:
:> And the maling list archive seems to be defunct -- I always get zero
:> metches no matter what I'm searching for.
:Disk full again? At least, it was the reason last time ...

Sorry, it was the workers search which was down due to resource limits -
it hit the fd limit.  users was still up.  Searching zsh-workers is going
again now.

Regards,
-- 
Geoff Wing : <gcw@pobox.com>
Rxvt Stuff : <gcw@rxvt.org>
Zsh Stuff  : <gcw@zsh.org>

Global aliases, eval, and completion (Re: Expanding interactively aliases)

[Bart Schaefer]

On Feb 21,  9:19am, Sven Wischnowsky wrote:
} Subject: Re: Expanding interactively aliases
} 
} Oliver Kiddle wrote:
} 
} > My real point is that the existing _expand appears to be expanding global
} > aliases already. I wouldn't have expected this because -U is used when
} > autoloading _expand. A quick check reveals that this is with the
} > substitute style and is due to the fact that the aliases are expanded
} > within eval.
} 
} Now that you say that... I seem to have a very faint memory of a
} discussion about this (not in _expand, I think, we had the problem
} somewhere else). I think we found a solution which I can't think of
} now and I don't know where to search for it either.

You may be thinking of the thread that led to invention of "autoload -U"
in the first place.

There was another thread last March with the subject "Default fpath" that
made a brief mention of the issue of aliases being expanded by "eval" and
by "source", but that was a very brief sideline of the main topic.

Of course it's entirely reasonable to _want_ aliases expanded by eval:

	foo() {
	    if [[ $1 == --debug ]]
	    then
		shift
	    	alias somecommand='print -u2 somecommand'
	    fi
	    # ... possibly much intervening code ...
	    eval 'somecommand "$@"'
	}

Because of the way functions are "compiled", using eval is the only way
to create/use such a conditional alias.

} > I don't think it is ideal that autoload -U functions are subject to
} > aliases within eval and you could probably break a few bits of completion
} > with certain global aliases.

Yeah, particularly because _arguments does things like

	eval ws\=\( "${action[2,-2]}" \)
and
	eval "action=( $action )"

There are a number of other completion functions that use eval for similar
purposes.

} > Would it be easy to avoid this somehow?

Having already implemented `autoload -U', we could now easily add a zsh
option `noalias' akin to `noglob', and then add that to $_comp_options.
Then completion functions that specifically wanted aliases could restore
the `alias' option in the scope where they wanted it.

Which incidentally leads me to wonder if bufferwords() doesn't have a
potential bug in that it forces the C variable `noaliases' to 1 and 0
without saving/restoring it?  I suppose as currently used `noaliases'
can't possibly be anything other than 0 during bufferwords() ...

} > The other solution would be a -U argument to eval which probably isn't
} > a great idea because eval currently takes no options.

I said exactly the same thing about "source -U" in the aforementioned
year-ago thread.

-- 
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: Global aliases, eval, and completion (Re: Expanding interactively aliases)

[Bart Schaefer]

On Feb 26,  7:25am, Bart Schaefer wrote:
}
} } > My real point is that the existing _expand appears to be expanding
} } > global aliases already. [...] A quick check reveals that this is
} } > with the substitute style and is due to the fact that the aliases
} } > are expanded within eval.
} } 
} } Now that you say that... I seem to have a very faint memory of a
} } discussion about this (not in _expand, I think, we had the problem
} } somewhere else). I think we found a solution which I can't think of
} } now and I don't know where to search for it either.

I was just diffing some backup copies I'd made of things like minor changes
to _arguments against the current sources, and I found the solution I think
you're thinking about.

} [...] _arguments does things like
} 
} 	eval ws\=\( "${action[2,-2]}" \)
} and
} 	eval "action=( $action )"
} 
} There are a number of other completion functions that use eval for similar
} purposes.

We can replace all `eval's of that particular form with

	set -A ws ${=~action[2,-2]}
or
	set -A action ${=~action}

etc., which also gives us liberty to remove the wordsplitting or globbing
when appropriate (I think wordsplitting always is, but globbing might better
be left off in a few cases).

-- 
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: Global aliases, eval, and completion (Re: Expanding interactively aliases)

[Oliver Kiddle]

Bart Schaefer wrote:
> 
> } > Would it be easy to avoid this somehow?
> 
> Having already implemented `autoload -U', we could now easily add a zsh
> option `noalias' akin to `noglob', and then add that to $_comp_options.
> Then completion functions that specifically wanted aliases could restore
> the `alias' option in the scope where they wanted it.

That seems like a good idea. The only other thing I can think of is
another precommand modifier - noalias, like noglob. 

> I said exactly the same thing about "source -U" in the aforementioned
> year-ago thread.

I remember that actually. I'm undecided on it myself because source -U
would be useful. Incidentally, tcsh has a -h option to source (but no
options to eval). I suppose a noalias option would avoid the need for a
source -U.

Oliver Kiddle

Re: Expanding interactively aliases

[Peter Stephenson]

> This is probably overkill...

It's ten years too late to worry about that.  I don't see any problem.
Space for a couple of dozen lines of shell function no-one has to use isn't
going to worry anyone (so long as the defaults make it work naturally, of
course, which they do).

> It alwasy tries to expand global aliases everywhere, maybe that should 
> be configurable, too.

I can see an argument for being able to choose via a style.  Then using tag
aliases you can effectively make _expand_aliases into different
commands/completers for completing or expanding command or global aliases.

Now if you're *really* looking for overkill, there's the feature that
aliases whose text ends with a space cause expansion of subsequent words as
aliases...

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Expanding interactively aliases

[Sven Wischnowsky]

This is probably overkill...


The _expand_alias can be used both as a completer and as a stand-alone 
command. It can be configured with three boolean styles:

  - always-regular: expand regular aliases even if not in command
                    position
  - disabled:       expand disabled aliases, too
  - complete:       (only if used as a command) if the word isn't a
                    alias, complete aliases

It alwasy tries to expand global aliases everywhere, maybe that should 
be configurable, too.

No docs because I don't know if this should go in.


_expand_alias:
------------------------------------------------------------
local word expl tmp pre sel what

setopt localoptions

if [[ -n $funcstack[2] ]]; then
  if [[ "$funcstack[2]" = _prefix ]]; then
    word="$IPREFIX$PREFIX$SUFFIX"
  else
    word="$IPREFIX$PREFIX$SUFFIX$ISUFFIX"
  fi
  pre=()
else
  local curcontext="$curcontext"

  if [[ -z "$curcontext" ]]; then
    curcontext="expand-alias-word:::"
  else
    curcontext="expand-alias-word:${curcontext#*:}"
  fi

  word="$IPREFIX$PREFIX$SUFFIX$ISUFFIX"
  pre=(_main_complete - aliases)
fi

if [[ CURRENT -eq 1 ]]; then
  sel=rg
else
  sel=g
fi

zstyle -t ":completion:${curcontext}:" always-regular && sel="${sel}r"
zstyle -t ":completion:${curcontext}:" disabled && sel="${sel}${(U)sel}"


[[ $sel = *r* ]] && tmp=$aliases[$word]
[[ -z $tmp && $sel = *g* ]] && tmp=$galiases[$word]
[[ -z $tmp && $sel = *R* ]] && tmp=$dis_aliases[$word]
[[ -z $tmp && $sel = *G* ]] && tmp=$dis_galiases[$word]


if [[ -n $tmp ]]; then
  $pre _wanted aliases expl alias compadd -UQ ${(Q)tmp}
elif (( $#pre )) && zstyle -t ":completion:${curcontext}:" complete; then
  $pre _aliases -s "$sel"
else
  return 1
fi
------------------------------------------------------------

And changing _aliases to:
------------------------------------------------------------
#compdef alias unalias

local expl sel args

zparseopts -E -D s:=sel

[[ -z $sel ]] && sel=rg

args=()
[[ $sel = *r* ]] && args=( $args 'aliases:regular alias:compadd -k aliases' )
[[ $sel = *g* ]] && args=( $args 'global-aliases:global alias:compadd -k galiases' )
[[ $sel = *R* ]] && args=( $args 'disabled-aliases:disabled regular alias:compadd -k dis_aliases' )
[[ $sel = *G* ]] && args=( $args 'disabled-global-aliases:disabled global alias:compadd -k dis_galiases' )

_alternative $args
------------------------------------------------------------



Bye
 Sven


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

Re: Expanding interactively aliases

[Peter Stephenson]

I wrote:
> expand-alias() {
>   # for safety, in case there's an = which will mess things up...
>   local alias=${LBUFFER#*=}
> 
>   if ! alias=$(alias $LBUFFER); then
>     zle beep
>     return 1
>   fi
> 
>   LBUFFER=${(Q)${alias#*=}}
> }
> zle -N expand-alias
> bindkey '^xa' expand-alias

Here's this as a completer, _expand_alias.  I decided there wasn't enough
common ground with _expand to put it there.

Could be tweaked:
 - checking for being the first word isn't good enough for knowing whether
   aliases should be expanded
 - probably need some other way of skipping it --- you may find you
   want to complete a command rather than expanding an alias
 - should probably be some style to force expansion in any position.
 - Sven can probably do it better anyway.

No documentation until all this gets decided.  Just stick it in your list
of completers around where _expand goes or would go.


## --- start --- ##
#autoload

local word tmp expl

# Completer to expand aliases.  Doesn't seem to have enough natural
# connection with normal expansion to put it in _expand.

if [[ "$funcstack[2]" = _prefix ]]; then
  word="$IPREFIX$PREFIX$SUFFIX"
else
  word="$IPREFIX$PREFIX$SUFFIX$ISUFFIX"
fi

[[ $CURRENT -eq 1 ]] || return 1

tmp="$(alias ${word#*=} 2>/dev/null)" || return 1

_wanted aliases expl alias compadd -UQ ${(Q)${tmp#*=}}
## --- end --- ##

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Expanding interactively aliases

[Oliver Kiddle]

Peter Stephenson wrote (on zsh-users):

> Quite possibly Sven has already added an option to the _expand 
> completer by now, otherwise I'll try and remember to look at that.

I had a quick look at _expand and, as I thought there is nothing to
explicitly expand aliases. I thought about adding it myself and had in
mind something along the lines of:

if zstyle -T ":completion:${curcontext}:" aliases; then
  (( CURRENT == 1 )) || exp=( "$exp[@]" "$aliases[$words[1]]" )
  exp=( "$exp[@]" "$galiases[$words[CURRENT]]" )
fi

This is fairly irrelevant and don't expect that to work because I've not
really tried it.

My real point is that the existing _expand appears to be expanding global
aliases already. I wouldn't have expected this because -U is used when
autoloading _expand. A quick check reveals that this is with the
substitute style and is due to the fact that the aliases are expanded
within eval.

I don't think it is ideal that autoload -U functions are subject to
aliases within eval and you could probably break a few bits of completion
with certain global aliases. Would it be easy to avoid this somehow? The
other solution would be a -U argument to eval which probably isn't a great
idea because eval currently takes no options.

And, BTW, alias has a -L option which you could have used in your
edit-alias function. Especially handy if you alias' name starts with '-'.

Oliver Kiddle