Adding tabbed layout support

[lefuturiste]

Hello,

I wanted to know if this project would accept or intend to implements tabbed layout with something close to the behavior in vim with :tabe.

The reason why I ask is I feel like using tabbed layout is a core part of my workflow with Neovim currently.

Prior work

@nrabulinsky nrabulinsky created a feature branch adding tabs in the original Helix editor.
helix-editor/helix#7109
This branch seem to be working fine and seems to meet basics requirements for a tabbed layout system in Helix.

[usagi-flow]

Hi @lefuturiste, sorry for answering just now and thank you for asking this question. It's not easy to give a simple answer, but I'll do my best to explain my reasoning, and I;ll put a tl;dr down below.

---

evil-helix approaches additional functionality differently than upstream Helix, in the sense that additional functionality that is "generally" part of an advanced modal editor is seen as a good thing. In contrast, you may have noticed that upstream Helix approaches new features more carefully, for various good reasons.

However, we should keep in mind evil-helix is a soft fork.
This has important implications: We remain fully compatible with upstream Helix, with the advantage of continuously being able to integrate their improvements.

In order for this to work, it's important that any evil-helix-specific code does not conflict with the upstream code.

For evil-helix core functionality (the Vim keybindings), this has been solved with own commands implemented in an isolated module, with few, minimal changes to the upstream code.

For other/new functionality that changes lots of different files, it's more difficult, and requires a similar approach as with the evil commands.

There's an exception to this strategy, however: "backports"
If a PR has been merged upstream (but not released yet), or is very likely to be merged before the next upstream release, then I tend to accept it, because if it's merged upstream by the time we rebase over the new upstream release, then we can just drop the backported code.

So what does that mean for this feature and the existing PR? I'm rather pessimistic here.
We could merge it right away and call it a day, but:

• It currently doesn't look like the upstream project is going to merge that PR (I think Archseer did a great job explaining why: I think Archseer did a great job explaining why: vim/neovim style tabs helix-editor/helix#7109 (comment)).
• The PR modifies upstream Helix code at various places.

This means that the next time we're rebasing over the latest Helix release, we would most likely get a lot more conflicts.
It could even happen that the feature is no longer compatible with the new upstream code (Helix has no internal API stability guarantee, afaik).
In that case, we would end up in a delicate situation:

• Do we try to change the feature to make it fit somehow? -> It would cause a lot of effort, if realistic at all.
• Do we drop the feature again and proceed with the rebase? -> We would take a feature away from users.
• Do we completely give up on rebasing over upstream Helix? -> evil-helix would become a "hard fork" and would no longer get the upstream improvements.

---

tl;dr: I'm open to any "major feature" that one would expect in a modern, advanced, modal text editor, but its implementation must be non-invasive, or the upstream PR must be very likely to be merged in upstream soon (if not merged already).