Allow goto_prev_buffer OR goto_previous_function...

[nouritsu]

In https://github.com/helix-editor/helix/blob/master/helix-term/src/commands.rs

I noticed that the goto_previous_buffer command is not named with respect to the other goto_prev_ commands like goto_prev_function, goto_prev_class.

I think goto_previous_buffer should be changed to goto_prev_buffer to be consistent with other commands. For backward's compatibility sake, goto_previous_buffer can be aliased to the newgoto_prev_buffer.

If this is even a valid enhancement, I would like it to be my first contribution to Helix.

[oxcrow]

I think goto_previous_buffer should be changed to goto_prev_buffer to be consistent with other commands.

I think goto_previous_buffer is clear and easy to understand.

The other commands which use short acronyms like prev should be changed to be previous so that everything is consistent and is easy to understand by everyone.

My reasoning is this:

• When someone reads commands like goto_prev_something we will need additional documentation to tell them what does it mean.
• However goto_previous_something is more clear and easy to understand.

Using long descriptive names is better than using short acronyms.

[nouritsu]

Is the aliasing solution viable? And how would the deprecation be handled?

[nik-rev]

Is the aliasing solution viable? And how would the deprecation be handled?

I'm not sure there's a need to make a breaking change just because of naming inconsistency. For example, some themes in Helix use kebab-case like adwaita-dark but others use snake_case such as boo_berry

Despite the inconsistency, it was decided not to rename these themes. It would be a breaking change (breaking change in Helix means people's configs will require editing)

[nouritsu]

Ah, I understand. I would like to start working on this, is there a mentorship system like there is for the Rust project? I'm not too sure where to start, maybe https://github.com/helix-editor/helix/blob/master/helix-term/src/commands.rs ?

Maybe by adding something like -

/* Add it to static commands */

fn move_prev_word_start(cx: &mut Context) {
    move_word_impl(cx, movement::move_prev_word_start)
}

fn move_previous_word_start(cx: &mut Context) {
    move_prev_word_start(cx)
}

[the-mikedavis]

Yeah I agree. IMO the inconsistency is not a big deal. Eventually we can fix it when it's the right time to make a lot of breaking changes (when merging an the plugin system for example) but in the meantime I don't want to make unnecessary breaking changes for this or have duplicate commands / aliases.