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

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: