[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tramp (; compilation-auto-jump-to-first-error slowness

From: Dave Abrahams
Subject: Re: tramp (; compilation-auto-jump-to-first-error slowness
Date: Fri, 03 Mar 2017 11:29:49 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (darwin)

on Thu Mar 02 2017, Dave Abrahams <> wrote:

> on Thu Mar 02 2017, Dave Abrahams <> wrote:
>> on Wed Feb 08 2017, Michael Albinus <> wrote:
>>> Dave Abrahams <address@hidden> writes:
>>> Hi Dave,
>>>> Seems to work great!
>>> I've pushed this patch, slightly modified, to the Emacs and Tramp
>>> repos. Will appear with Emacs 26.1.
>>>> It's a little odd that I see the remote shell
>>>> prompt and a little other garbage appear in the *compilation* window
>>>> before it is replaced by the expected contents, but that's just
>>>> cosmetic.
>>> That's the case for all asynchronous processes run by Tramp. There's no
>>> chance to suppress it, but as you said, it is minor only.
>> My question is, why do I notice it only after applying the patch,
>> whereas I never saw it before applying the patch?
> Further, I note that it now takes a *really* long time to start a
> compilation process.
> Enclosing a small movie that shows the same compilation both with and
> without that patch (in the middle I make the edit, byte-recompile, and
> reload tramp.elc)

Putting the sit-for here instead *seems* to give better results, but I'm
mostly just taking potshot guesses:

(defun tramp-action-out-of-band (proc vec)
  "Check, whether an out-of-band copy has finished."
  ;; There might be pending output for the exit status.
  (sit-for 0.01 :nodisp) ;; <============================
  (tramp-accept-process-output proc 0.1)
  (cond ((and (memq (process-status proc) '(stop exit))
              (zerop (process-exit-status proc)))
         (tramp-message vec 3 "Process has finished.")


reply via email to

[Prev in Thread] Current Thread [Next in Thread]