Anti-purpose?

[tomdl89]

Is it possible to dedicate a window to not display windows of a certain mode/ modes? Right now I have 4 windows. 2 are dedicated to Clojure, 1 is dedicated to Cider REPL and 1 is not dedicated (general). If I follow a link to a Clojure file in the general window, I always want it to open in one of the Clojure-dedicated windows, but instead, it always opens in the general window. Maybe there is another approach to solve this? Thanks!

[bmag]

It is not possible to mark a window to not display buffers of a certain mode/modes.

The desired behavior is the expected behavior. Following a link from the general window should already display Clojure files in a Clojure window. Clearly that isn't the case, so we need to find the cause. The usual suspects for are:

• mis-configuration of Purpose. I'm assuming Clojure buffers get the edit purpose, and the general window holds a buffer with the general purpose.
• underlying code by-passes display-buffer mechanism: "following a link" internally calls some function to display a buffer. Usually it is a function the calls display-buffer down the line, but occasionally I see code that calls lower-level functions directly (e.g. split-window and set-window-buffer).
• underlying code misuses display-buffer mechanism: sometimes the underlying code calls a display function and expects a certain behavior but doesn't pass the correct function arguments to ensure that behavior. Since Purpose adds a new option to reuse windows (i.e. according to purposes), it can behave differently than default display-buffer behavior and break that piece of code.

My answer comes so late that it might not be relevant to you anymore, but a way to debug this is as follows:

• take a "before" and "after" screenshots (before/after following the link) that show the name, major-mode and purpose of each visible buffer (the mode-line normally contains all this data). It doesn't have to be a real screenshot, you can store the window layout to a variable with M-: (setq your-variable (window-state-get)) and look at its value with C-h f your-variable. The visible buffers and their names can be deduced from this information, usually their major-modes can be deduced from their names, and the purposes can be deduced from their names and major-modes (assuming the user's purpose configuration is known).
• via advice mechanism, cause purpose--action-function to throw an error when trying to display the offending buffer. Next time you try display that buffer (presumably in the problematic way) a backtrace will be displayed. From the backtrace you can see what is the underlying code and proceed to analyze if it conflicts with Purpose.

From before/after screenshots, the backtrace above and your purpose configuration, I should be able to figure out what went wrong.