[sesman] Link a newly opened file with the current buffer's session

[alexander-yakushev]

Found an annoying bug today. When I M-. to a function definition that is defined in a dependency and I have multiple REPLs running, I'm at the mercy of sesman-use-friendly-sessions to assign the correct session to a newly opened buffer. If I disable the friendly sessions, the opened buffer will have no connection and must be established manually – again, suboptimal experience.

This change explicitly links the newly created buffer with the session of the current buffer. I'm not sure if this is the best way to do it, so I'm open to suggestions.

• You've added tests (if possible) to cover your change(s)
• You've updated the changelog

[vemv]

I'm at the mercy of sesman-use-friendly-sessions to assign the correct session to a newly opened buffer.

Do you use it or not? If not, why?

There's the cider-debug-sesman-friendly-session-p function to help you diagnose those. It would be most helpful to make stuff work as intended, instead of working around a possible bug.

Ultimately, a fix like the current one would surely be only performed conditionally if nothing was found (and there was only one candidate) - else it's a side-effect that can make other functionality harder to understand.

[alexander-yakushev]

I have sesman-use-friendly-sessions enabled since it's the default. But if there is more than one REPL active, it appears as if it decides which REPL is "friendly" randomly. If sort t is passed to the sesman machinery, then it seems to be picking the correct one, but from what I can tell, the sorting is not enabled by default.

I don't mind how this issue is solved but it's been haunting me for quite a while (and other people on Slack, too, you see these threads pop up occasionally). Ultimately, it's the right thing to somehow tell sesman which REPL the request comes from. If it can be achieved by hinting the friendly sessions thing instead, I'm OK with that.

[vemv]

Thanks!

So yes, it would seem best to keep improving the 'friendly' functionality - it's the design Sesman has always had, I merely added some fixes at some point.

cider--sesman-friendly-session-p is a function that can reasonably be understood and further maintained.

Ultimately, it's the right thing to somehow tell sesman which REPL the request comes from.

I'd be ok with that if it was side-effect free.

[alexander-yakushev]

What's wrong with the side effects here? The user action of jumping into a dependency is ultimately an effect. For example, sesman seems to be using the information about how recent the session is, and that is information that comes from side effects.

[vemv]

I'm of course not against side-effects as an entire concept.

But this particular side-effect can affect future computations, shortcircuiting our own logic. It's simpler to start from a clean slate every time.

[alexander-yakushev]

Do I miss some particular usage scenario? In my mind, if I jump to a definition using the runtime REPL facilities (the location which I discovered within the context of the current REPL), I want the destination buffer to also have the context of the source REPL. Do you see some scenario where you codevelop two related projects, and you jump from project A to a function that is project B, and then you want the REPL to have the context of another REPL?

Perhaps, it is possible in some mixed CLJ/CLJS projects if you jump to some cljc function from a CLJS buffer and you want the CLJ REPL being active at the destination.

[vemv]

In my mind, if I jump to a definition using the runtime REPL facilities (the location which I discovered within the context of the current REPL), I want the destination buffer to also have the context of the source REPL.

Yes, that's a fine thing to want, but it can also be achieved with the 'friendly' approach, or with a side-effect-free approach (e.g. pass a context as parameters).

@bbatsov has write access to https://github.com/vspinu/sesman so any sound PR can make it in.

Personally I'd prefer the 'friendly' approach because it would mean we are fixing bugs instead of working around them.

Do I miss some particular usage scenario?

In my view, imagining contrived scenarios that might confirm or deny a hypothesis isn't sound because often, reality is even wilder than one's imagination :)

So it's simpler to me to stick to some nearly universal principles (like understanding what was wrong and then fixing it).

Cheers - V

[bbatsov]

This change explicitly links the newly created buffer with the session of the current buffer. I'm not sure if this is the best way to do it, so I'm open to suggestions.

I was under the impression that sesman was supposed to handle this properly in your use-case. (I recall this is how friendly-sessions were introduced), so it sounds to me like some bug there. I'll look into the issues and the docs, as I rarely work on multiple projects and might have forgotten how this was supposed to work.

And yeah - I can merge PRs for sesman if needed.

[bbatsov]

Here's also one older similar issue with some notes how to debug this #3250

[bbatsov]

One more thing - CIDER is the only project using Sesman, so I'm also contemplating simply inlining it in CIDER and dropping all of the stuff that are more generic. (e.g. it supports session types per projects)

I still think it sorely misses a way to just force a default session that would be used when a session can't be determined (or just use the last session as suggested in this PR) - friendly-sessions were aiming to solve this, but a few years later people still report problems with them, so I'm thinking that probably the simpler solution would also be more reliable.

[vspinu]

The friendleness definition is entirely on the cider's side. Years back it was a very quick hack to make stuff work and I am not sure if the logic has changed since then. It's up to the maintainers of the sesman's client to decide what "friendly" mean and implement that.

BTW< I am back to emacs world after several years of inactivity for personal reasons (but not yet to clojure/cider unfortunately). So I could look into improving sesman, if so required, but the OP doesn't seem to be an issue with sesman proper.

[bbatsov]

@vspinu I'd appreciate some way to set a default session in Sesman - e.g. when a session is selected as default it's always used when a more fitting session can't be found.

[bbatsov]

I'll get back to this and our options for Sesman the Christmas holidays. I hope I'll have a bit more time to tackle some CIDER items then.

See also vspinu/sesman#30