p4.el causes problems if p4 binary is available, but P4 environment is not set up (was: P4 and TRAMP interact badly)

[seabadger]

When I'm attempting to open a file remotely over TRAMP, the open fails, and I see the following error: p4-maybe-start-update-statuses: Writing to process: Input/output error, P4

• This doesn't happen all the time; possibly when TRAMP is opening a new connection, not exactly sure.
• I usually use ido-find-file to open files; when this fails, repeating the command or using regular find-file works. Not sure if repeating ido-find-file a 2nd time will work as well (will update if I find out).

As far as I can tell, the issue is that p4-update-status is added to find-file-hooks, but does not filter out TRAMP buffers. It really should not look at TRAMP buffers unless #132 is fixed :)

[seabadger]

First stab at a workaround is shown below; seems to work:

  (defun p4-tramp-workaround-find-file-hook ()
    "do not let p4.el process remote TRAMP buffers"
    (when
        (and (fboundp 'tramp-tramp-file-p)
             (not (tramp-tramp-file-p buffer-file-name)))
      (p4-update-status)))

  (remove-hook 'find-file-hook 'p4-update-status)
  (add-hook 'find-file-hooks 'p4-tramp-workaround-find-file-hook)

[seabadger]

Update: I think this issue may only arise in the following circumstances:

• the p4 binary is available
• Perforce is not actually configured, so the p4 command fails to do anything useful.

(I use the same emacs config at work and at home; at work everything works like a charm; at home the Perforce environment is not setup, as I work over TRAMP; but because the binary exists on the machine, p4.el keeps trying to do things like p4-update-status).

While using TRAMP seems to exacerbate matters, it's not really the culprit, despite my initial description. Perhaps a better solution might be for p4.el to detect when the p4 environment is not right, and not load itself?