bug#61637: 30.0.50; Fix Eglot tests that need HOME=~USER

[Eli Zaretskii <eliz@gnu.org>]

> From: João Távora <joaotavora@gmail.com>
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>,  61637@debbugs.gnu.org
> Date: Sat, 04 Mar 2023 01:04:45 +0000
> 
> I installed some language servers like clangd, rust-analyzer and pylsp,
> and they need to a valid HOME to be able to function.

Please tell more about this: what exactly do these servers need from
the home directory?

> diff --git a/test/lisp/progmodes/eglot-tests.el b/test/lisp/progmodes/eglot-tests.el
> index 5d5de59a19a..ad994915c52 100644
> --- a/test/lisp/progmodes/eglot-tests.el
> +++ b/test/lisp/progmodes/eglot-tests.el
> @@ -116,9 +116,7 @@ eglot--call-with-fixture
>                     ;; installations for LSP servers like pylsp, making
>                     ;; these tests mostly useless, so we hack around it
>                     ;; here with a great big hack.
> -                   ,(format "HOME=%s"
> -                            (if (file-exists-p home) home
> -                              (format "/home/%s" (getenv "USER")))))
> +                   ,(format "HOME=%s" (or (getenv "EGLOT_REAL_HOME") (getenv "HOME"))))
>                   process-environment))
>                 ;; Prevent "Can't guess python-indent-offset ..." messages.
>                 (python-indent-guess-indent-offset-verbose . nil)
> 
> This is acceptable for Eglot devs like me, but other devs that don't
> know about this variable will still be confused. WDYT?

As I said, I don't like the idea of using the user's real home
directory for test purposes.  We could end up clobbering precious
files there.  We could also have tests fail because some user setting
in the home directory makes the test results unpredictable.

> > Why not do this the other way around: trick Eglot to think the home
> > directory doesn't exist (as I understand it already knows how to
> > handle this)?
> 
> I don't understand what you mean: this is entirely constrained to how
> certain language servers work, so eglot.el itself can't handle it.

In the original report, Basil sais:

> The main problem is that:
> 0. test/Makefile.in sets HOME=/nonexistent
> 1. lisp/emacs-lisp/ert-x.el sets HOME=/tmp :(
> 2. eglot--call-with-fixture tries to detect when HOME is nonexistent,
>    but /tmp exists, so that's left unchanged
> 3. The Rust tools look under HOME=/tmp for which toolchain to use, but
>    the answer is under ~USER, so they give up

I interpreted item 2 as meaning that eglot--call-with-fixture can cope
with the situation where the user's home directory doesn't exist, and
suggested to trick Eglot into thinking it doesn't exist in the cases
in point, as the means of solving the problem.

If my understanding is incorrect, or if what you describe here is a
different problem (thus item 2 is no longer relevant), I'd like to
better understand the details, so we could see if there are better
alternatives than to use the real home directory of the user running
the tests.