tramp-devel
[Top][All Lists]
Advanced

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

Re: weird interaction between tramp-mode and annotate-mode


From: Michael Albinus
Subject: Re: weird interaction between tramp-mode and annotate-mode
Date: Sat, 29 Oct 2022 10:34:03 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

cage <cage-dev@twistfold.it> writes:

> Hi!

Hi,

> Seems  that, for  some  reasons,  tramp is  invoking  a function  from
> annotate-mode  (``annotate--remove-annotation-property'') on  a buffer
> different from the one where annotate  mode is active. Said buffer has
> a name like: ``*tramp/ssh something*''

Tramp doesn't use annotate on its own, anywhere. So I guess you shall
add some house-keeping for annotate, knowing for which buffers annotate
shall run, and where it shall be silent.

> Please check the first message as  it contains both the stacktrace and
> useful information at the end.
>
> I  used   a  workaround  (prevent   the  function  above  to   run  if
> ``annotate-mode'' is bound to nil), but i do not like this solution.

This could be a kind of house-keeping, yes.

> In  brief, i  am asking  for suggestion,  why TRAMP  is visiting  that
> buffer? And why is calling that annotate function (that is supposed to
> be call to fontify the annotated buffer when the latter is modified)?

The buffer *tramp/ssh something* is an internal buffer, which keeps the
connection process to the remote host. Tramp needs to use it frequently.

According to the backtraces in your issue tracker,
annotate--remove-annotation-property is called by
internal-default-process-filter. I guess via a hook.

> Can calling ``annotate--remove-annotation-property''  be prevented?

Not by Tramp. It doesn't know about.

> Am I missing a call to a macro like ``with-current-buffer'' somewhere?

Don't know. But as I said, pls do house-keeping of involved buffers.

> And,  out  of curiosity,  what  the  buffer ``*tramp/ssh  something*''
> contains? Seems like a register for TRAMP.

As said, it is an internal process buffer. Nothing any other package
shall care about.

> Thanks in advance!
> C.

Best regards, Michael.



reply via email to

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