eproject icon indicating copy to clipboard operation
eproject copied to clipboard

Problem with non-file buffers

Open trollusk opened this issue 15 years ago • 3 comments

There is a bug in eproject--selector. It assumes that every buffer where 'eproject-maybe-turn-on' is invoked, must be a file. I am using SLIME (emacs mode for common lisp programming). I have defined a "common-lisp project" like this:

(define-project-type common-lisp (generic) (look-for "*.asd" :glob) :relevant-files '(".lisp$" ".lsp$" ".asd$")) (add-hook 'lisp-mode-hook 'eproject-maybe-turn-on)

Slime creates non-file buffers that are still 'lisp mode', such as SLIME Macroexpansion. Eproject prevents interactive macroexpansion because of the error raised when it finds the new buffer is not a file.

I think it should just do nothing silently when it tries to 'turn on' and finds the buffer is not a file.

trollusk avatar Mar 11 '10 09:03 trollusk

I'm having the same issue with sunrise-commander

julienfantin avatar Jan 14 '11 17:01 julienfantin

The resolution for this problem wrt sunrise-commander has been included in issue #23

escherdragon avatar Aug 10 '12 10:08 escherdragon

I agree that a silent fail probably would be better at all times. I have used this wrapped version for some time now and haven't experienced any bad consequences at all.

  (defun my-eproject-maybe-turn-on ()
      "Ignores errors"
      (interactive)
      (condition-case msg
          (eproject-maybe-turn-on)
        (error (message "Ignored eproject-maybe-turn-on error: %s" msg))))

thomasf avatar Oct 14 '12 13:10 thomasf