Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make *compilation* per-project #1517

Closed
sellout opened this issue Apr 21, 2020 · 4 comments · Fixed by #1535 or #1702
Closed

Make *compilation* per-project #1517

sellout opened this issue Apr 21, 2020 · 4 comments · Fixed by #1535 or #1702

Comments

@sellout
Copy link
Contributor

sellout commented Apr 21, 2020

Right now any compilation/test/etc. happens in the single *compilation* buffer, so switching between projects isn't as independent as I would like (if the first project has a long compilation, I can't go work on something else and compile it while I wait for the first project to finish).

Expected behavior

  • C-c p c to compile the current project
  • C-c p p to switch projects
  • C-c p c to compile the second project, both now compiling concurrently, ideally in buffers named something like *compilation*<project1> and *compilation*<project2>

Actual behavior

The second C-c p c says "A compilation process is running` kill it?"

Steps to reproduce the problem

The expected behavior steps should do it, I think. You need two projects that have a compilation time of over a few seconds. Using yes as the compilation command should get it to just run indefinitely.

Environment & Version information

Projectile version information

Projectile 20191216.2105

Emacs version

GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.13)

Operating system

NixOS 20.03

@bbatsov
Copy link
Owner

bbatsov commented Apr 28, 2020

Nice idea! I think that'd be pretty easy to implement.

@sellout
Copy link
Contributor Author

sellout commented May 13, 2020

I started poking at this, but ran into some problems.

;; Run the compilation for each project in a buffer that contains the project name.
;;
;; This works, but I use direnv, and for some reason all the *compilation*
;; buffers seem to share a common direnv environment. I.e., whenever I switch
;; between *compilation* buffers, I have to `M-x direnv-update-environment`
;; before I can compile in it.
(setq compilation-buffer-name-function
      (lambda (compilation-mode)
	(concat "*" (downcase compilation-mode) "*<" (projectile-project-name) ">")))

;; When compiling, only ask to save buffers for the project getting compiled.
;;
;; This doesn't work at all. The problem is that this gets called like
;;
;;     (with-current-buffer <unsaved-file-buffer>
;;       (funcall compilation-save-buffers-predicate))
;;
;; which means that this always returns `t`, since `(projectile-project-root)`
;; is relative to `(current-buffer)`. To complain about Emacs a bit I wish
;; `(current-buffer)` referred to the *compilation* buffer, and the
;; unsaved-file-buffer was passed as a parameter ... this is a thunk for no good
;; reason, AFAICT.
;;
;; Since the *compilation* buffers are now named based on the project, I don't
;; see how I can find the correct projectile-project-root. E.g.,
;;
;;     (let ((root (with-current-buffer "*compilation*" (projectile-project-root)))) ...)
;;
;; could approximate it if I wasn't trying to distinguish the buffers.
(setq compilation-save-buffers-predicate
      (lambda ()
	(let ((root (projectile-project-root)))
	  (or (not root)
	      (projectile-project-buffer-p (current-buffer) root)))))

@sellout
Copy link
Contributor Author

sellout commented May 13, 2020

I think the direnv thing is probably independent (wbolster/emacs-direnv#16). Just probably hadn't noticed before because I wasn't switching between projects as often.

@sellout
Copy link
Contributor Author

sellout commented May 13, 2020

For the second problem, figured out that I can do

(with-current-buffer (window-buffer) (projectile-project-root))

so that problem is solved.

@sellout sellout closed this as completed May 13, 2020
@sellout sellout reopened this May 13, 2020
sellout added a commit to sellout/projectile that referenced this issue May 18, 2020
Currently, this requires that the user explicitly set

    (setq compilation-buffer-name-function #'projectile-compilation-buffer-name)
    (setq compilation-save-buffers-predicate #'projectile-current-project-buffer-p)

both of these degrade properly when not inside a project. Is there a better way
to enable these than telling a user that they should set the variables?

Fixes bbatsov#1517.
sellout added a commit to sellout/projectile that referenced this issue May 18, 2020
Currently, this requires that the user explicitly set

    (setq compilation-buffer-name-function
          #'projectile-compilation-buffer-name)
    (setq compilation-save-buffers-predicate
          #'projectile-current-project-buffer-p)

both of these degrade properly when not inside a project. Is there a
better way to enable these than telling a user that they should set the
variables?

Fixes bbatsov#1517.
bbatsov added a commit that referenced this issue Nov 25, 2020
Currently, this requires that the user explicitly set

    (setq compilation-buffer-name-function
          #'projectile-compilation-buffer-name)
    (setq compilation-save-buffers-predicate
          #'projectile-current-project-buffer-p)

both of these degrade properly when not inside a project. Is there a
better way to enable these than telling a user that they should set the
variables?

Fixes #1517.

Co-authored-by: Bozhidar Batsov <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants