unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Albinus <michael.albinus@gmx.de>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: Daniel Pittman <slippycheeze@google.com>, emacs-devel@gnu.org
Subject: Re: TRAMP VC optimization: also breaks process filters -_-
Date: Tue, 07 May 2019 17:51:37 +0200	[thread overview]
Message-ID: <875zqm2rg6.fsf@gmx.de> (raw)
In-Reply-To: jwvo94ee0up.fsf-monnier+emacs@gnu.org

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Daniel's reports have been covered always
>> vc-registered. And indeed, the related `tramp-vc-file-name-handler'
>> seems to expect always a Tramp file name, which is not true for filters
>> and sentinels which run for non-Tramp processes.
>
> I don't understand what filers and sentinels have to do with it.

The last Tramp action as expected was process-send-string (called from
tramp-send-string). According to the Elisp manual, filters or sentinels
from *other* processes can be called during process-send-string:

--8<---------------cut here---------------start------------->8---
   Sometimes the system is unable to accept input for that process,
because the input buffer is full.  When this happens, the send functions
wait a short while, accepting output from subprocesses, and then try
again.  This gives the subprocess a chance to read more of its pending
input and make space in the buffer.  It also allows filters, sentinels
and timers to run—so take account of that in writing your code.
--8<---------------cut here---------------end--------------->8---

This happens here, as Daniel has shown.

The problem is, that expand-file-name has been forwarded to
tramp-vc-file-name-handler due to the remote DIR argument. This isn't
relevant, because FILENAME is absolute, but in the next line FILENAME is
tried to be dissected without any further check. This I have changed.

In the native tramp-file-name-handler, this situation can also happen,
but it is handled already. So we have only to fix tramp-vc-file-name-handler.

>         Stefan

Best regards, Michael.



  reply	other threads:[~2019-05-07 15:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-01 18:13 TRAMP VC optimization: also breaks process filters -_- Daniel Pittman
2019-05-06 17:54 ` Stefan Monnier
2019-05-07 15:24   ` Michael Albinus
2019-05-07 15:42     ` Stefan Monnier
2019-05-07 15:51       ` Michael Albinus [this message]
2019-05-07 16:19         ` Stefan Monnier
2019-05-08  6:35           ` 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=875zqm2rg6.fsf@gmx.de \
    --to=michael.albinus@gmx.de \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    --cc=slippycheeze@google.com \
    /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).