[Feature] Register arbitrary term window for TT management

[BlueDrink9]

TT isn't a repl plugin. However, people keep asking for repl functionality because they want to improve their interface to their repl terms.

In my mind, the perfect situation would be to allow a command that registers a given term buffer for TT management, so people could start their repl plugin normally, and from there treat it like a TT while retaining purpose-built repl functionality.

How feasible would this be? Under the hood is much different about a normal TT window?

[BlueDrink9]

As an aside, this would be helpful for saving and reopening sessions with open TT terms; they could be re-registered

[BlueDrink9]

Depending on the estimated complexity, I'd be happy to chip in on this

[BlueDrink9]

Quick look makes it seem plausible.

vim.o.channel contains the channel id if connected to the buffer (which it would be for terminals/repls). So that covers setting self.job_id = jobpid(&channel) in the registered term.

Synchronising the working dir, if it has changed within the repl via cd, doesn't seem very easy. &autoshelldir requires special shell setup to emit the right codes. But having self.cwd out of sync shouldn't be major, right?

Adding the on_stdout etc callbacks might be more challenging, but may just need to be a caveat.

An alternative approach might be figuring out how to completely wrap a repl's open call with TT's instead. That might require sacrificing similar intercommunication to the above. Those comms feels to me more important for repls than for TT, and TT is more the common factor; whereas a user might have multiple repl plugins they would have to handle

[akinsho]

For max context @BlueDrink9 my maintenance of my FOSS plugins is on a critical only background mode right now. I'm not looking to start investigating or building new features only critical blocking bugs. I've tried to emphasise to so many people over the entire lifetime of this plugin that I really do not want any of the faff that comes with REPLs there are so many alternatives to this plugin that do REPLs so I really think there's isn't much need to accommodate some small version because whenever I do things like that that massively comes back to bite me much like my allowing some small amount of REPL-esque commands that was/is a can of worms tbh.

[BlueDrink9]

Yes, sorry I quite understand. I take it this means a PR wouldn't be accepted? In my mind this would reduce the TT burden by offloading feature requests to other plugins.

If you don't want a PR and I fork for this, are you able to think of any reasons that this might be technically difficult?

[akinsho]

No idea, I'd have to really think it through to know so I think only the implementer would have a good sense of how possible this would be but in general I'd rather avoiding this complexity (appreciate the difference of opinion re. this will be that but I strongly believe it will), thanks anyway