unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Norman Gray <Norman.Gray@glasgow.ac.uk>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: "36090@debbugs.gnu.org" <36090@debbugs.gnu.org>
Subject: bug#36090: 26.1; Tramp hanging when writing version-controlled file
Date: Mon, 24 Jun 2019 16:21:14 +0000	[thread overview]
Message-ID: <EB734B55-FB62-4CAB-B6AE-118B6E04F4B6@glasgow.ac.uk> (raw)
In-Reply-To: <87a7ep8u4x.fsf@gmx.de>


Michael, hello.

Sorry for the delay in responding to your last message, and thanks for 
your thoughtful response.

On 10 Jun 2019, at 14:09, Michael Albinus wrote:

> The problem was discussed already in <https://debbugs.gnu.org/18940>.
> I've patched vc-hg.el to set HGPLAIN=1, and this works at least
> partly. See tramp-notes-debug-4.txt:

I've now read the discussion in that bug report.

> Well, we could try to patch vc-hg.el, again.

Myself, I think that setting HGPLAIN=1 in the hg invocation within 
vc-hg.el is by far the most elegant/straightforward/robust solution.

The hg(1) manpage explicitly documents HGPLAIN as being the preferred 
way to disable 'any configuration settings that might change Mercurial's 
default output' and notes that '[t]his can be useful when scripting 
against Mercurial in the face of existing user configuration.'  Also, 
`hg help scripting` goes further, and says of HGPLAIN 'It is highly 
recommended for machines to set this variable when invoking "hg" 
processes.'

That is, this seems to clearly indicate that, in all non-interactive 
invocations of Mercurial, HGPLAIN should be set; indeed, that this is 
set could almost be regarded as an integral part of Mercurial's 
scripting interface.  I suggest that _any_ invocation of 'hg' within 
vc-hg.el, local or remote, which does not ensure this is set, should be 
reported as a bug!  Might this require a lot more than adjusting 
vc-hg-command at the end of vc-hg.el? (possibly -- I'm not clear on just 
how/where vc-hg.el interacts with Tramp).

Re:

> But there is a more elegant
> solution, set HGPLAIN=1 yourself in Tramp. This is even explained in 
> the
> Tramp manual, for a good reason :-) See (info "(tramp) Remote 
> processes")

[and...]

> Alternatively, you could try to set in .hgrc
>
> pager = LESS='FRX' less -d
>
> as proposed in <https://mercurial.selenic.com/wiki/PagerExtension> for
> Tramp. I haven't tested this, 'tho.

I don't think it really works to resolve this by requiring specific user 
behaviour, as a large fraction of users will fail to do this (I 
deliberately avoid customising my environment too much, but even I felt 
it useful to customise this bit of Mercurial).

Similarly, I don't think it works to require users to modify their 
`process-environment` or `tramp-remote-process-environment`.  I'm a 
reasonably sophisticated emacs user -- I've written small amounts of 
elisp, but no more, and I have fairly deliberately avoided excess 
cleverness in my init.el -- and I'd have to think twice to work out how 
to do this.

Best wishes,

Norman


-- 
Norman Gray  :  https://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK

  reply	other threads:[~2019-06-24 16:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-04 13:12 bug#36090: 26.1; Tramp hanging when writing version-controlled file Norman Gray
2019-06-04 16:10 ` bug#36090: Update: A case where this isn't a problem Norman Gray
2019-06-05  9:50   ` Michael Albinus
2019-06-05  9:47 ` bug#36090: 26.1; Tramp hanging when writing version-controlled file Michael Albinus
2019-06-10 11:19   ` Norman Gray
2019-06-10 13:09     ` Michael Albinus
2019-06-24 16:21       ` Norman Gray [this message]
2019-07-16 14:44         ` Michael Albinus
2019-08-15 12:43           ` Michael Albinus
2019-09-08 10:03             ` Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EB734B55-FB62-4CAB-B6AE-118B6E04F4B6@glasgow.ac.uk \
    --to=norman.gray@glasgow.ac.uk \
    --cc=36090@debbugs.gnu.org \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).