GNU bug report logs - #25496
25.1.91; INSIDE_EMACS env variable is not set in eshell

Previous Next

Package: emacs;

Reported by: Alex Hutcheson <alexhutcheson <at> google.com>

Date: Fri, 20 Jan 2017 22:33:02 UTC

Severity: minor

Tags: fixed, patch

Merged with 39596

Found in versions 25.1.91, 26.3

Fixed in version 28.1

Done: Noam Postavsky <npostavs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #34 received at 25496 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: 25496 <at> debbugs.gnu.org
Subject: Re: bug#25496: 25.1.91; INSIDE_EMACS env variable is not set in eshell
Date: Mon, 30 Mar 2020 19:11:04 -0400
Federico Tedin <federicotedin <at> 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.





This bug report was last modified 5 years and 72 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.