>> I've removed the lambda, but I wasn't able to use a string directly, I
>> had to set the value elsewhere using a defconst. This is due to how
>> `eshell-get-variable' interprets string values associated to
>> variables.
>
> Oh, a string is actually taken as an environment variable to alias.  I
> guess that does justify the name.  I think we might actually be better
> off with the lambda, what do you think?

Hmm, actually now it's working fine - the value associated with
INSIDE_EMACS is the symbol `eshell-inside-emacs'.  Then
`eshell-get-variable' is returning that symbol's value, which is what we
want. The `$$', `$?' and `$0' variables are also set to symbols.

(But the lambda would also work, of course. No preferences here.)

>>    "This list provides aliasing for variable references.
>> -It is very similar in concept to what `eshell-user-aliases-list' does
>> -for commands.  Each member of this defines the name of a command,
>> -and the Lisp value to return for that variable if it is accessed
>> -via the syntax `$NAME'.
>> +Each member defines the name of a variable, and the Lisp value to
>> +return for that variable if it is accessed via the syntax `$NAME'.
>
> Again, not a problem introduced by your patch, but "Lisp value to
> return" seem pretty inaccurate (if you don't feel like fixing this, it's
> okay, I think describing it correctly is somewhat non-trivial).

Aaah sorry, I hadn't read your comment correctly. I've rewritten that
part and expanded a bit upon it. I think the most confusing part is that
when a user does `$foobar', if "foobar" is not in
eshell-variable-aliases-list, then "foobar" itself is used as a "value"
(which may or may not end up pointing to an env var, or a Lisp var). But
I don't think this is relevant when explaining what
eshell-variable-aliases-list should contain.

(I've attached a new patch!)