Yes, even though you are not a REPL Window user, @seancorfield. 😃

As an example of how I am trying to approach this, generally, here is a PR which include a setting that will change of the path of the .calva-repl files to reflect that they are now about the REPL and not primarily about output. • https://github.com/BetterThanTomorrow/calva/pull/2457 • https://output.circle-artifacts.com/output/job/d82cecc2-fa8a-4de5-b6ac-71deae523773/artifacts/0/tmp/artifacts/calva-2.0.430-rename-results-doc-2fee8cb4.vsix to download and install to test this We can’t litter Calva with a lot of settings like this of course. But as an example. We want to both remove the confusion, while not cause too much of a mess for Calva users.

Already confused! Does this mean, if I punch 42 into the REPL, I won't get a 42 back in the REPL, but it will rather go to some other place which I've probably hidden? I hope there will at least be a button ("Show The Stuff That I Am Not Seeing") paired with the REPL to expose the exotic new other place that I'm going to have to keep visible along with the REPL?

@U0HG4EHMH this has already happened. It’s opt in. Or rather the repl window is the current default output destination. The difference is that there are now more options for this.

My advice would be: • Introduce a single setting that acts as a feature flag for all the changes you plan to make in this area (with some caveats, see below). Not a specific one like calva.useLegacyReplWindowPath but a general one like calva.useLegacyRepl. • If you make a series of changes across multiple releases, ensure that the "legacy" behavior is retained for all those changes under this one flag. • In a final change release, make all the breaking API changes and document them all clearly in the release notes (as well as a section in the docs and/or change log doc). I suggest this because Calva tends to have a lot of small releases which means a lot of churn (since auto-update is the default) and it can be really hard to keep track of what changed when. Sometimes, you make multiple releases in a day so people might do one Calva update in a day but skip ahead multiple versions. That one setting would allow people to effectively ignore this whole stream of changes until after you're "done" and they can then decide how they want things setup just once: whether to keep the existing REPL/output behavior or customize it, and to make just one round of configuration changes. The same logic applies to the API changes: if the API changes across multiple releases, it's going to be almost impossible for users who publish scripts to keep track of what to change when and how to communicate that to their end users. Keep the API compatible across all of these releases until you get to the end and then make one sweeping set of API changes and clearly communicate that out to all users. An alternative would be to stop making so many releases -- do all of the work on this (new settings, new API, etc) and make a single big update (`v3.0.x` perhaps) that everyone would know is a breaking change.

The caveats on the "all changes" feature flag would be where you need to introduce new API functions (without changing any existing ones if possible), so that folks who decide to switch early on for testing can try out the new API (with the "feature flag" set to "new behavior" instead of "legacy behavior").

For me, personally, I'll pretty much ignore this round of changes because I don't care about the Calva REPL/output window -- I just don't use it and pretty much always have it completely hidden. I will care about API changes if you break my Joyride scripts or hot keys tho' and I will complain loudly if either a) a breaking change is not clearly documented in any release or b) multiple releases contain breaking changes and I find myself having to update all my Joyride scripts / hot key configs repeatedly!

Thanks, @seancorfield. A limitation we have is that the command name changes can’t be feature flagged. They belong to the extension manifest and are not a run-time thing.

And while I think the one-legacy-setting-to-rule-them-all would be a sound approach, I don’t think we have that situation. We have added output destination settings which changes the role of the repl window. If someone choses to direct output somewhere else than the repl window, that will be their exodus from the legacy behaviour. In a sense, that’s your useLegacyRepl option. Changing the path of where that file is written to is, I think, the only setting of this nature we will see for this adventure. But I will have a think about if that will hold true for something I should foresee.

Your particular hotkeys and scripts are safe, but I take your input about that as that you agree with me that breaking hotkeys should be avoided up to a certain high cost, and beyond that cost it needs to be well planned and communicated and atomic.

FWIW, I've just gone through the process of switching all output to the new (pseudo) output terminal and ensuring neither calva says nor output-window appear at jack-in. I suspect folks might want an option to have the new (pseudo) output terminal open at jack-in?

(mind you, ctrl+` opens and closes the terminal as needed so it's no big deal)

> the command name changes can’t be feature flagged My suggestion was intended to mean: don't change these across multiple releases -- keep the legacy names until the very end and then do one big release that renames them to "better" names. > And while I think the one-legacy-setting-to-rule-them-all would be a sound approach, I don’t think we have that situation. Well, that's because you've already started making those changes without a feature flag 🙂 I suspect the number of people who've changed those settings already is small and you could still introduce the feature flag and put that output redirection logic behind it -- so that would revert the changes I just made, essentially, but I could then opt back into the new behavior by changing that feature flag.

I think the destination setting is the feature flag. I considered a feature flag to prevent the change that affects you even if you don’t opt in, but decided against it because I needed feedback on that particular change. Which I got, and which helped me decide the next move (the terminal output option).

We are at the very end, btw. 😀

As far as there is an end to it.

> I suspect folks might want an option to have the new (pseudo) output terminal open at jack-in? Yes, I should add that option. Something like autoOpenReplEvaluationOutputDestination, crazy as it sounds. 😃 To go with the existing autoOpenREPLWindow .

FWIW, there are two commands to reveal the output terminal, if you have configured it as the destination for results: • calva.showResultOutputDestination, ctrl+alt+o o • calva.showOutputTerminal, ctrl+alt+o t

> don’t change these across multiple releases Gotcha. I’ll postpone changing the command names for now, but when I get there I’ll make it one atomic thing. And probably keep both command names working, although the legacy ones will complain a bit or something.

> We are at the very end, btw. Then I like our destination 🙂

@karol.wojcik, I think I heard you about some support for adding a dependency om clj-commons.pretty? I worry that that could start to conflict with if someone is using some other library for output and error prettifying. So let’s try with this passthrough solution a while and see where that takes us.

I've updated and switched that setting off. Jacked in and got the new file location, so that works. Updating git ignores now:grin:

That println above produces the following for me:

Thanks for testing, @seancorfield !

Thank you so much @U0ETXRFEW! Awesome work!