bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell

[Noam Postavsky]

Federico Tedin <federicotedin@gmail.com> writes:

>>> 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'.

Yeah, it works fine, I'm just not sure if having the extra
eshell-inside-emacs variable is better than a lambda.  But anyway, it
doesn't really matter that much.  I'll wait a couple of days (in case
there are any more suggested changes) and then push to master.

>> 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.

No, no, you read it right.  I just initially wrote the wrong thing: I
hadn't realized the docstring was wrong before (that's why I mistakenly
suggested using a string instead of a lambda).

> +If the value is a string, the value for the variable with that name in
> +the current environment will be returned.  If no variable with that
> +name exists in the environment, but if a symbol with that same name
> +exists and has a value bound to it, then that value will be used.  You
> +can prioritize symbol values over environment values by setting
> +`eshell-prefer-lisp-variables' to t.
> +
> +If the value is a symbol, the value bound to that symbol will be used.

Much better, thanks.