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

[Dave Abrahams]

on Thu Mar 02 2017, Dave Abrahams <dave-AT-boostpro.com> wrote:

> on Thu Mar 02 2017, Dave Abrahams <dave-AT-boostpro.com> wrote:
>
>> on Wed Feb 08 2017, Michael Albinus <michael.albinus-AT-gmx.de> 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.")

-- 
-Dave