Skip to content
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

Allow syntax highlighting to be disabled #2053

Closed
wants to merge 7 commits into from

Conversation

Mazurel
Copy link

@Mazurel Mazurel commented Apr 9, 2022

This PR resolves issue #338.

It adds a possibility for syntax highlighting to be disabled for some document.
Such occurrence happens automatically for "big" files and can also be triggered artificially by a command from command palette.
Running the command toggles the syntax highlighting on/off, so it can be easily re-enabled if needed.

I have assumed that "big" file is more than or equal to 128 Megabytes in size. After this size, documents tend to lag, but this number if up for debate.

}
} else {
// If there is some syntax and it should be disabled, disable it.
self.syntax = None;
Copy link
Member

@dead10ck dead10ck Apr 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm understanding this right, this isn't really just disabling highlighting, it's disabling any and all syntax tree parsing. Is the issue of slow speed specifically due to highlight rendering, or is it caused by having such a large syntax tree loaded into memory at once? Disabling the syntax parsing will also disable text objects, auto complete, etc.

If it's specifically caused by highlighting, then we may want to disable highlighting without disabling all of the syntax tree parsing. And if we do want to disable syntax parsing altogether, then I think we should rename the command and struct fields something like enable_tree_sitter or something.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, you are completely right, this is more about disabling syntax parsing then highlighting. Highlighting (or rendering) by itself is not an issue, the parser is. I have experimented with the parser, but I have not found any better solution than disabling it completely.

I will rename commands and struct fields to names that are more accurate, as you have suggested.

helix-view/src/document.rs Outdated Show resolved Hide resolved
@@ -414,7 +414,8 @@ impl MappableCommand {
decrement, "Decrement",
record_macro, "Record macro",
replay_macro, "Replay macro",
command_palette, "Open command palette",
command_palette, "Open command pallete",
toggle_syntax_highlighting, "Toggle syntax highlighting for current document",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need a separate command, it should be the equivalent of setting the language to none/unset via the set language command

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm though yeah this would disable lsp and other integrations too

@@ -101,6 +105,8 @@ pub struct Document {
syntax: Option<Syntax>,
/// Corresponding language scope name. Usually `source.<lang>`.
pub(crate) language: Option<Arc<LanguageConfiguration>>,
/// Sets if syntax highlighting should be used or not
pub highlight_syntax: bool,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be removed and set the language to None

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, it is not an issue, but I think that setting language to None when disabling parser, may cause some confusion to someone in the future. Language by itself is not changing/non-existent, it is just not parsed.

@Mazurel
Copy link
Author

Mazurel commented May 15, 2022

Sorry for leaving this PR with no response for so long, I have unexpectedly had way more personal work to do, than I have expected. I will try to be more active from now on.

@the-mikedavis the-mikedavis added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label May 18, 2022
@the-mikedavis the-mikedavis removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label May 27, 2022
@Mazurel
Copy link
Author

Mazurel commented May 29, 2022

I have implemented prompt when syntax parsing is disabled, as suggested above. This required some code modifications, so I am waiting for responses, as I have probably made some rookie Rust mistakes.

helix-term/src/commands.rs Outdated Show resolved Hide resolved
Comment on lines +136 to +142

pub document_events: (
UnboundedSender<DocumentEvent>,
UnboundedReceiver<DocumentEvent>,
),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this? Not sure if possible but I think it is better to just look at enable_syntax, or just trigger a redraw when user set the syntax option.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way I understand the architecture of this project, the other possibility would be to check some flag in the idle event (in the main tokio loop). This solution however doesn't seem that elegant.

I also think that it is a matter of time, when there will be a need for sending event from document to the rendering loop.

@tgharib
Copy link

tgharib commented Aug 13, 2022

I have assumed that "big" file is more than or equal to 128 Megabytes in size. After this size, documents tend to lag, but this number if up for debate.

I hope this will be configurable in the future. "Big" is dependent on user tolerance for lag, CPU power and the language/treesitter implementation.

Comment on lines +1518 to +1522
fn toggle_syntax(
cx: &mut compositor::Context,
args: &[Cow<str>],
_event: PromptEvent,
) -> anyhow::Result<()> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't handle PromptEvent correctly, it is also toggling on preview, so like :toggle-syntax off<esc> still change the config, it should do syntax toggling correctly and ignore completion event, since preview isn't very useful for toggling syntax.

@@ -431,7 +431,7 @@ impl MappableCommand {
decrement, "Decrement item under cursor",
record_macro, "Record macro",
replay_macro, "Replay macro",
command_palette, "Open command palette",
command_palette, "Open command pallete",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be palette like the command?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -634,6 +654,15 @@ impl Document {
// and error out when document is saved
self.path = path;

if self.text.len_bytes() > BIG_FILE_THRESHOLD {
self.enable_syntax = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be a message saying that syntax is disabled or maybe some signs, or otherwise the user might find it surprising.

@kirawi kirawi added A-helix-term Area: Helix term improvements S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 13, 2022
@kirawi kirawi added S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 24, 2022
@pascalkuthe
Copy link
Member

closing out this PR as its very stale. I also don't see us moving forward in this direction. We have an automatic timeout now for treesitter parsers which covers most related cases. Thank you for contributing!

@neuromagus
Copy link

neuromagus commented Apr 16, 2024

What to do with those programming languages where TS grammars do not support the latest language changes? For example - csharp grammar or tsx/typescript? Or parser errors with a new version?

I want to use Helix by turning off this module while the developers fix bugs or make changes. Or are you involved in supporting grammars?

@the-mikedavis
Copy link
Member

I think it would make sense to respect the use-grammars setting when loading grammars https://docs.helix-editor.com/languages.html#choosing-grammars. Currently it's only used when fetching/building grammars but I think it would be less surprising if setting use-grammars.except = ["c"] stopped the C grammar from loading for example. That should fit your use-case if I understand correctly.

@neuromagus
Copy link

Currently it's only used when fetching/building grammars but I think it would be less surprising if setting use-grammars.except = ["c"] stopped the C grammar from loading for example.

This is solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-helix-term Area: Helix term improvements S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants