-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Customizable/configurable status line #2434
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great! I apologize it took me a while to review.
Thanks for working on this, I just started using these changes and I'm loving the customizability already! Not sure whether I should bring this up now, or wait until this is merged (or if this is even the right place for this discussion...), but I've written a "scope" element here that uses the language server's Is that something we'd be interested in supporting? And if so, should I hold on until after this is merged then create a separate PR, or is there another way I should go about things? |
@mtoohey31 I would recommend a separate PR that adds it as a new component; also we would want to avoid using nerd fonts by default (see #2211). |
Sounds good, I'll wait until this is merged then create one. And yep, I'll make sure to default to symbols that standard fonts will support. Thanks! |
For the file type, could you make it configurable? I like seeing file type info but I don't want to take up multiple characters to show it. Having a config option that could override this default would allow me to use a glyph/icon without making assumptions about anyone else's font. |
Hmm, without introducing a dependency to devicons (or similar) in Helix, you would basically have to map filetypes to alternative labels (these can be single devicons) in your config; something like this: [editor.status-line.file-type]
rust = "<devicon-here>"
javascript = "js" It'd definitely be easy, but I think I'd first gather some extra input. Either way, I believe it's worth opening a separate issue/discussion for this. |
Could you add a section to the docs at https://github.com/helix-editor/helix/blob/master/book/src/configuration.md#editor ? |
Thank you for the review, @sudormrfbin ! I extended the book a bit to include some configuration documentation (000a742 & 6699c05). I'll soon rebase my commits because while this PR was open, #2676 was opened and merged, and conflicts with this PR's changes. |
Avoid very small helper functions for the diagnositcs and inline them instead. Rename the config field `status_line` to `statusline` to remain consistent with `bufferline`.
5621494
to
28fa36f
Compare
Because none of the functions need `Self` and all of them are in an own file, there is no explicit need for the struct.
As a friendly side note: I don't mind refactoring more of this after the PR was merged, even if it's just cosmetic code changes! :) Not that I mind doing so now, but we're starting to block some other features which build upon this, and there's always the risk that we have to rebase onto more changes like #2676. |
The configuration was ignored after reintegrating the changes of #2676 in 8d28f95.
// Left side of the status line. | ||
|
||
let element_ids = &context.editor.config().statusline.left; | ||
element_ids | ||
.iter() | ||
.map(|element_id| get_render_function(*element_id)) | ||
.for_each(|render| render(context, write_left)); | ||
|
||
surface.set_spans( | ||
viewport.x, | ||
viewport.y, | ||
&context.parts.left, | ||
context.parts.left.width() as u16, | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These parts seemed to be duplicated a bit. Is it better to refactor it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, do you mean something like introducing a function like the following and calling it in render()
?
fn render_area(element_ids: &Vec<StatusLineElement>, write: F, x: u16, y: y16)
where F: Fn(&mut RenderContext, String, Option<Style>) + Copy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested and looks fine, I just have one nit about the styling not matching current master
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested, works great! Thanks for working on this :)
* feat(statusline): add the file type (language id) to the status line * refactor(statusline): move the statusline implementation into an own struct * refactor(statusline): split the statusline implementation into different functions * refactor(statusline): Append elements using a consistent API This is a preparation for the configurability which is about to be implemented. * refactor(statusline): implement render_diagnostics() This avoid cluttering the render() function and will simplify configurability. * feat(statusline): make the status line configurable * refactor(statusline): make clippy happy * refactor(statusline): avoid intermediate StatusLineObject Use a more functional approach to obtain render functions and write to the buffers, and avoid an intermediate StatusLineElement object. * fix(statusline): avoid rendering the left elements twice * refactor(statusline): make clippy happy again * refactor(statusline): rename `buffer` into `parts` * refactor(statusline): ensure the match is exhaustive * fix(statusline): avoid an overflow when calculating the maximal center width * chore(statusline): Describe the statusline configurability in the book * chore(statusline): Correct and add documentation * refactor(statusline): refactor some code following the code review Avoid very small helper functions for the diagnositcs and inline them instead. Rename the config field `status_line` to `statusline` to remain consistent with `bufferline`. * chore(statusline): adjust documentation following the config field refactoring * revert(statusline): revert regression introduced by c0a1870 * chore(statusline): slight adjustment in the configuration documentation * feat(statusline): integrate changes from helix-editor#2676 after rebasing * refactor(statusline): remove the StatusLine struct Because none of the functions need `Self` and all of them are in an own file, there is no explicit need for the struct. * fix(statusline): restore the configurability of color modes The configuration was ignored after reintegrating the changes of helix-editor#2676 in 8d28f95. * fix(statusline): remove the spinner padding * refactor(statusline): remove unnecessary format!()
* feat(statusline): add the file type (language id) to the status line * refactor(statusline): move the statusline implementation into an own struct * refactor(statusline): split the statusline implementation into different functions * refactor(statusline): Append elements using a consistent API This is a preparation for the configurability which is about to be implemented. * refactor(statusline): implement render_diagnostics() This avoid cluttering the render() function and will simplify configurability. * feat(statusline): make the status line configurable * refactor(statusline): make clippy happy * refactor(statusline): avoid intermediate StatusLineObject Use a more functional approach to obtain render functions and write to the buffers, and avoid an intermediate StatusLineElement object. * fix(statusline): avoid rendering the left elements twice * refactor(statusline): make clippy happy again * refactor(statusline): rename `buffer` into `parts` * refactor(statusline): ensure the match is exhaustive * fix(statusline): avoid an overflow when calculating the maximal center width * chore(statusline): Describe the statusline configurability in the book * chore(statusline): Correct and add documentation * refactor(statusline): refactor some code following the code review Avoid very small helper functions for the diagnositcs and inline them instead. Rename the config field `status_line` to `statusline` to remain consistent with `bufferline`. * chore(statusline): adjust documentation following the config field refactoring * revert(statusline): revert regression introduced by c0a1870 * chore(statusline): slight adjustment in the configuration documentation * feat(statusline): integrate changes from helix-editor#2676 after rebasing * refactor(statusline): remove the StatusLine struct Because none of the functions need `Self` and all of them are in an own file, there is no explicit need for the struct. * fix(statusline): restore the configurability of color modes The configuration was ignored after reintegrating the changes of helix-editor#2676 in 8d28f95. * fix(statusline): remove the spinner padding * refactor(statusline): remove unnecessary format!()
* feat(statusline): add the file type (language id) to the status line * refactor(statusline): move the statusline implementation into an own struct * refactor(statusline): split the statusline implementation into different functions * refactor(statusline): Append elements using a consistent API This is a preparation for the configurability which is about to be implemented. * refactor(statusline): implement render_diagnostics() This avoid cluttering the render() function and will simplify configurability. * feat(statusline): make the status line configurable * refactor(statusline): make clippy happy * refactor(statusline): avoid intermediate StatusLineObject Use a more functional approach to obtain render functions and write to the buffers, and avoid an intermediate StatusLineElement object. * fix(statusline): avoid rendering the left elements twice * refactor(statusline): make clippy happy again * refactor(statusline): rename `buffer` into `parts` * refactor(statusline): ensure the match is exhaustive * fix(statusline): avoid an overflow when calculating the maximal center width * chore(statusline): Describe the statusline configurability in the book * chore(statusline): Correct and add documentation * refactor(statusline): refactor some code following the code review Avoid very small helper functions for the diagnositcs and inline them instead. Rename the config field `status_line` to `statusline` to remain consistent with `bufferline`. * chore(statusline): adjust documentation following the config field refactoring * revert(statusline): revert regression introduced by c0a1870 * chore(statusline): slight adjustment in the configuration documentation * feat(statusline): integrate changes from helix-editor#2676 after rebasing * refactor(statusline): remove the StatusLine struct Because none of the functions need `Self` and all of them are in an own file, there is no explicit need for the struct. * fix(statusline): restore the configurability of color modes The configuration was ignored after reintegrating the changes of helix-editor#2676 in 8d28f95. * fix(statusline): remove the spinner padding * refactor(statusline): remove unnecessary format!()
Summary
Building upon the feedback of #2420 and the discussion in #708, I refactored the status line implementation and made it configurable.
The configuration happens in the user's configuration file and distinguishes between three areas of the status line: left, center and right.
Within each area, status line elements can be defined. There are no particular restrictions regarding the order, and elements can occur multiple times or be removed completely.
The following elements can currently be configured (see
helix_view::editor::StatusLineElement
):Example
This would move the file name to the center, and add a file type indicated to the far right):
Additional info
The default configuration keeps the same status line layout with the same elements as before. While I do see room for improvement here, I assume it'd better be done in another PR.
On top of the elements which were already present, I added the implementation for one additional element: the file type (disabled by default).