2

Connecting to a remote machine with tramp that may have VC (subversion) related files, I tend to see a large number of repeated messages in the *Messages* buffer. For example:

Type "q" in help window to restore previous buffer.
 [2 times]
Mark saved where search started
 [69 times]
Mark saved where search started

...

Quit
mwheel-scroll: Beginning of buffer [7 times]
 [7 times]
Quit [2 times]

...

Quit
 [14 times]
Mark set [2 times]

Mark set

Mark set

Mark set [3 times]

Debugging this has been a pain and it's been very difficult to even get to understanding that the issue is some interaction with TRAMP and VC.

Namely, I understood that in other emacs sessions, I didn't have repeated messages. Obviously the issue doesn't exist in emacs -Q either. Furthermore, I tried the classic emacs configuration bisection, e.g., comment out all configuration and slowly introduce sections until the error appears. However, I was unable to uncover the issue with any of these methods.

Finally, I discovered some Emacs debugger functionallity for Emacs LISP.

I tried M-x RET trace-function RET message RET. However, all I received was quickly filling buffer of empty calls to message.

======================================================================
1 -> (message nil)
1 <- message: nil
======================================================================
1 -> (message "%s" "")
1 <- message: ""
======================================================================
1 -> (message nil)
1 <- message: nil
======================================================================
1 -> (message "Mark set")
1 <- message: "Mark set"
======================================================================
1 -> (message "Mark set")
1 <- message: "Mark set"
======================================================================
1 -> (message "%s" "")
1 <- message: ""
======================================================================
1 -> (message "%s" "Mark set")
1 <- message: "Mark set"
======================================================================
1 -> (message "%s" "")
1 <- message: ""
======================================================================
1 -> (message "%s" "Mark set")
1 <- message: "Mark set"
======================================================================
1 -> (message "%s" "")
1 <- message: ""
======================================================================
1 -> (message "%s" "Mark set")
1 <- message: "Mark set"
======================================================================
1 -> (message "Mark set")
1 <- message: "Mark set"
======================================================================

Which is the issue as described, but doesn't point to where the issue is coming from.

I knew I needed the function call trace, as that will tell me what function is calling message.

Next, I tried using debug-on-entry on message. Finally, I have something! (Actual file names changed for reasons).

Debugger entered--entering a function:
* message("%s" "")
  tramp-sh-handle-vc-registered(#("/ssh:remote-host:/some/svn/file" 1 4 (helm-ff-file t) 5 24 (helm-ff-file t)))
  apply(tramp-sh-handle-vc-registered #("/ssh:remote-host:/some/svn/file" 1 4 (helm-ff-file t) 5 24 (helm-ff-file t)))
  tramp-sh-file-name-handler(vc-registered #("/ssh:remote-host:/some/svn/file" 1 4 (helm-ff-file t) 5 24 (helm-ff-file t)))
  apply(tramp-sh-file-name-handler vc-registered #("/ssh:remote-host:/some/svn/file" 1 4 (helm-ff-file t) 5 24 (helm-ff-file t)))
  tramp-file-name-handler(vc-registered #("/ssh:remote-host:/some/svn/file" 1 4 (helm-ff-file t) 5 24 (helm-ff-file t)))
  vc-registered(#("/ssh:remote-host:/some/svn/file" 1 4 (helm-ff-file t) 5 24 (helm-ff-file t)))
  vc-backend(#("/ssh:remote-host:/some/svn/file" 1 4 (helm-ff-file t) 5 24 (helm-ff-file t)))
  vc-refresh-state()
  #f(compiled-function () #<bytecode 0x215bf89>)()
  auto-revert-handler@bug21559(#f(compiled-function () #<bytecode 0x215bf89>))
  apply(auto-revert-handler@bug21559 #f(compiled-function () #<bytecode 0x215bf89>) nil)
  auto-revert-handler()
  #f(compiled-function () #<bytecode 0x215bffd>)()
  apply(#f(compiled-function () #<bytecode 0x215bffd>) nil)
  auto-revert-buffers()
  apply(auto-revert-buffers nil)
  timer-event-handler([t 24045 51629 615589 5 auto-revert-buffers nil nil 963000])

But, what is the solution to resolve this?

I have set tramp-verbose to 1. However, this might be hiding the particular behaviour instead of spamming a load of messages about how TRAMP is performing VC refreshing.

For now, since this is issue is being caused by some files under SVN control that I have no interest in interacting with, i.e., it's not my repository and I don't have write access anyways, I'm simply disabling the VC backend[0]:

(setq-default vc-handled-backends '(Git))

However, I would like to have a better solution in case I do ever need to interact with SVN (hopefully not, but this feels very hacky).

This had led to the following commit on my dotfiles, which also has some other variables that may be in the middle of the interplay:

(setq-default auto-revert-check-vc-info nil)
(setq-default auto-revert-remote-files nil)

How might I more "properly" resolve this issue?

1

I don't know a solution yet, but I can explain a little bit. Your back-trace tells us, that the message call happens in tramp-sh-handle-vc-registered. And indeed, its body is wrapped by

(with-temp-message "" ...)

This is done in order to preserve the recent message in the echo area while running tramp-sh-handle-vc-registered, which has an own progress reporter.

Your back-trace tells us also, that this happens during auto-revert-buffers. Well, I agree with you that a progress reporter might not be helpful during auto-revert. This shall be suppressed in either Tramp or auto-revert.

An sx question is not appropriate to discuss possible solutions. I encourage you therefore to write a bug report, using M-x report-emacs-bug.

Edit: I've just committed http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=8aaa92a4b648aef137eb9a7054fdffaed04328ff to the Emacs git repo. This might solve the problem.

  • I have not yet had a chance to try your patch, however, since you have submitted a patch, do you still want a bug report? – kballou Dec 13 '19 at 1:14
  • No bug report needed. The patch will be included in Tramp 2.4.3, scheduled for end of the year. Will be available also via GNU ELPA. – Michael Albinus Dec 13 '19 at 10:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.