Create Some Helix Design Guidelines for Consistency?

[robenkleene]

I've been noticing a pattern in discussions where there are some overarching design guidelines for Helix, but these aren't published anywhere (that I'm aware of). So you only really see them come up in the comments when ideas are proposed that contradict them.

Here's a few example conversations like this:

• Vim `cc` equivalent (replace line content) #4507
• Vim key navigation in file picker #4646, Normal mode in file and buffer picker #2820
• some design quirks of Helix #3388
• ed-style editing? #4143

I think there would be some value in publishing these guidelines somewhere, then we could reference that document when replying.

And for sure the canonical example is tall the discussions about vgld (#863, #1215, #4429, #1511). #1215 especially highlights the importance of a consistent set of design principles, since it seems like the entire vgld conversation is misguided, since it implies that gl (and gh, gs, etc...) should actually be selecting the text first.

A secondary goal of creating the guidelines would also be to clean up some of the inconsistencies like the goto family of movements not selecting. There are a few other cases where Helix itself seems inconsistent to me, and it would be great to fix that (or publish the reasoning for the inconsistencies, e.g., perhaps there's a logic to it I'm missing).

Suggested Guidelines

1. Helix's model is the selection -> action model. This means that nothing should change the existing text in a buffer without selecting it first. This also means by extension, all instances of find and replace should leverage selection.
2. All movements should select. (gl, gh, gs, ge, and gg should be fixed to select by default.)
3. Helix has two text editing modes: Normal and Insert. The same bindings should always be supported in both modes. Pickers should always default to insert mode, since the primary action is starting to insert text. (Right now, there are some inconsistencies in this mode, for example in pickers Ctrl-u/d go up and down a page, but have entirely different meanings in insert mode.)

Do these seem like a good set of guidelines? And more importantly, what do you think about publishing these (or others that are agreed upon) somewhere?

I don't think the specifics themselves are so important, but I think it would be great to just have the guidelines people agree on published somewhere, and implemented consistently in the app.