Re: Completion: Tilde and environment variables
- From: kba <unixprog@xxxxxxxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Mon, 2 Mar 2009 14:24:17 +0100
On Mon, Mar 02, 2009 at 11:20:27PM +1100, tpgww@xxxxxxxxxxx wrote:
> > > > Is it possible to complete from shortened home dirs (~/ for $HOME,
> > > > ~john/ for /home/john etc.) directly?
> >
> > Somehow this does not work for me. When I enter '~/<Tab>' in a dir line,
> > nothing happens, whereas when I enter '/home/kba/<Tab>' I get the wanted
> > completion.
>
> Until now, things like ~ or ~john were interpreted just before a
> command is run, and not interpreted at all before a directory is
> changed, and the 'tab completer' didn't do any interpretation either.
> I've just added those missing capabilities to svn code. Perhaps you'd
> like to test that.
>
I just compiled from svn and it works great. Thank you!
> > > > Another thing I would find nice to have is expansion of environment
> > > > variables (like $HOME, $XDG_CONFIG_HOME) in dirline/commandline. Is this
> > > > possible?
> > >
> > > Yes. Also works for 'internal' variables.
> >
> > What is the right syntax for this? '$HOME' does not work, it just spits
> > out "Directory '/home/kba/$HOME/' does not exist".
> >
> > I'm using emelFM2 v. 0.5.1
>
> I forgot to mention - 0.5.1 does not cope with any $VAR in a
> commandline generally. It expects any $VAR to be distinct - at end of
> string or surrounded by whitespace. As it happens, I fixed this about
> a day after 0.5.1 release, and is now in svn. But even so, $VAR
> interpretation is not entirely structureless. If VAR is internal, we
> can check easily enough whether "$VAR<any text>" is meant to include
> that a variable. But for externals, there's too many combinations of
> variable and text to evaluate. So for externals you must use {}
> delimiters e.g. /path/${DATA}/subdir.
This also works now and I have no problem with curly braces. However, I
don't really understand, why internal variable names can contain '/'. In
the shell (bash, zsh),'/' can't be part of a variable name. Is there a
special reason to allow it in emelfm2? If every whitespace and every '/'
was an obvious variable name delimiter, wouldn't it be possible to use
'/path/$DATA/subdir' instead of '/path/${DATA}/subdir'?
Thanks for your effort :)
kba
--
Users can unsubscribe from the list by sending email to
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by
logging into the web interface.
Other related posts: