sublime_text
sublime_text copied to clipboard
sublimehq
Add option to disable preview in goto anything
Problem description
when I cycle through the "goto anything" menu (ctrl+p), ST previews files, while this provides context and may be suitable for many users, I find it distracting, and may slow things down when I accidentally highlight a large file (or otherwise a markdown file)
Preferred solution
add a preview argument to the show_overlay command
{
"keys": ["ctrl+p"],
"command": "show_overlay",
"args": {
"overlay": "goto",
"preview": false
}
}
Alternatives
Additional Information (optional)
related to #1842
screencast:
In my opinion it would probably make more sense to not preview if the file is above a certain size.
The Markdown issue will hopefully be fixed in the next build or two.
I currently don't have an opinion about the idea of allowing users to wholesale disable the functionality.
I think this is something that should be controllable by the user, Although this is suitable for many users, many others would wish to disable it, for instance atom and vscode do not preview files (although may be because they are not performant enough).
That sort of delay is indicative of having a plugin installed that's doing blocking IO from one of its events.
Sublime Text itself doesn't do any IO in the main thread when Goto Anything is showing, and should have no delays for any sort of file.
It'd be good to check and see if you get the same behavior with --safe-mode
yes tried with safe mode it's not blocking, I already know that plugins are slowing the preview (It's probably LSP with vscode-html language server), but anyway that's a part of the game isn't it, plugin overhead is inevitable, that's why one would want to disable preview.
Sorry, apparently I only saw the video after the "pause" had happened. I figured from the description you were seeing a loading bar (hence the comment about large files and Markdown).
You can confirm which plugin is causing the slowdown by using Goto Anything for a bit, and then running Tools/Developer/Profile Plugins
Oh, I guess it was Color Highlighter
This list shows how much time each plugin has taken to respond to each event:
_wrapped_on_load:
PackageDev.plugins_.syntaxtest_dev: 0.000s total, mean: 0.000s, max: 0.000s
on_activated:
BracketHighlighter.bh_core: 0.006s total, mean: 0.000s, max: 0.001s
Default.history_list: 0.006s total, mean: 0.000s, max: 0.001s
Emmet2.abbreviation: 0.001s total, mean: 0.000s, max: 0.001s
FileDiffs.file_diffs: 0.004s total, mean: 0.000s, max: 0.001s
Origami.origami: 0.003s total, mean: 0.000s, max: 0.002s
on_close:
Emmet2.abbreviation: 0.001s total, mean: 0.000s, max: 0.001s
FileManager.FileManager: 0.000s total, mean: 0.000s, max: 0.000s
LSP.plugin.core.documents: 0.002s total, mean: 0.001s, max: 0.002s
MarkdownLivePreview.MarkdownLivePreview: 0.001s total, mean: 0.000s, max: 0.001s
Origami.origami: 0.000s total, mean: 0.000s, max: 0.000s
OverrideAudit.src.events: 0.000s total, mean: 0.000s, max: 0.000s
Terminus.terminus.edit_settings: 0.000s total, mean: 0.000s, max: 0.000s
on_hover:
BracketHighlighter.bh_core: 0.007s total, mean: 0.000s, max: 0.001s
Color Highlighter.main: 0.007s total, mean: 0.000s, max: 0.001s
Default.symbol: 0.146s total, mean: 0.007s, max: 0.075s
OpenUri.plugin.OpenUri: 0.006s total, mean: 0.000s, max: 0.001s
OverrideAudit.src.events: 0.001s total, mean: 0.000s, max: 0.001s
Terminus.terminus.mouse: 0.000s total, mean: 0.000s, max: 0.000s
hover_preview.main: 0.004s total, mean: 0.000s, max: 0.001s
on_load:
BracketHighlighter.bh_core: 0.001s total, mean: 0.000s, max: 0.001s
Color Highlighter.main: 2.473s total, mean: 1.237s, max: 2.473s
Default.detect_indentation: 0.007s total, mean: 0.004s, max: 0.004s
Default.exec: 0.004s total, mean: 0.002s, max: 0.003s
FileManager.FileManager: 0.001s total, mean: 0.000s, max: 0.001s
MarkdownEditing.footnotes: 0.000s total, mean: 0.000s, max: 0.000s
on_modified:
BracketHighlighter.bh_core: 0.003s total, mean: 0.000s, max: 0.001s
Color Highlighter.main: 0.000s total, mean: 0.000s, max: 0.000s
Default.history_list: 0.004s total, mean: 0.000s, max: 0.001s
PackageResourceViewer.package_resource_viewer: 0.002s total, mean: 0.000s, max: 0.001s
Terminus.terminus.core: 0.000s total, mean: 0.000s, max: 0.000s
on_new:
Color Highlighter.main: 0.000s total, mean: 0.000s, max: 0.000s
on_post_save:
FileManager.FileManager: 0.000s total, mean: 0.000s, max: 0.000s
MarkdownPreview.markdown_preview: 0.008s total, mean: 0.003s, max: 0.008s
PackageDev.plugins_.settings: 0.000s total, mean: 0.000s, max: 0.000s
on_post_text_command:
Default.history_list: 0.002s total, mean: 0.000s, max: 0.001s
Default.paste_from_history: 0.001s total, mean: 0.000s, max: 0.001s
Emmet2.abbreviation: 0.000s total, mean: 0.000s, max: 0.000s
Emmet2.select_item: 0.002s total, mean: 0.000s, max: 0.001s
PackageDev.plugins_.settings: 0.000s total, mean: 0.000s, max: 0.000s
Terminus.terminus.clipboard: 0.001s total, mean: 0.000s, max: 0.001s
Terminus.terminus.core: 0.000s total, mean: 0.000s, max: 0.000s
on_post_window_command:
Terminus.terminus.edit_settings: 0.000s total, mean: 0.000s, max: 0.000s
on_pre_close:
Compare Side-By-Side.sbs_compare: 0.003s total, mean: 0.000s, max: 0.001s
Default.history_list: 0.000s total, mean: 0.000s, max: 0.000s
MarkdownLivePreview.MarkdownLivePreview: 0.000s total, mean: 0.000s, max: 0.000s
OpenUri.plugin.OpenUri: 0.000s total, mean: 0.000s, max: 0.000s
Origami.origami: 0.000s total, mean: 0.000s, max: 0.000s
Terminus.terminus.core: 0.000s total, mean: 0.000s, max: 0.000s
Terminus.terminus.edit_settings: 0.000s total, mean: 0.000s, max: 0.000s
on_pre_save:
Color Highlighter.main: 0.001s total, mean: 0.000s, max: 0.001s
PackageResourceViewer.package_resource_viewer: 0.007s total, mean: 0.002s, max: 0.007s
on_query_context:
BracketHighlighter.bh_wrapping: 0.000s total, mean: 0.000s, max: 0.000s
Color Highlighter.main: 0.001s total, mean: 0.000s, max: 0.001s
Default.block: 0.000s total, mean: 0.000s, max: 0.000s
Emmet2.abbreviation: 0.000s total, mean: 0.000s, max: 0.000s
Emmet2.go_to_tag_pair: 0.000s total, mean: 0.000s, max: 0.000s
Julia.unicode: 0.005s total, mean: 0.000s, max: 0.003s
OverrideAudit.src.contexts: 0.000s total, mean: 0.000s, max: 0.000s
Terminus.terminus.query: 0.000s total, mean: 0.000s, max: 0.000s
package_setting_context.all.package_setting_context: 0.002s total, mean: 0.000s, max: 0.001s
on_selection_modified:
BracketHighlighter.bh_core: 0.018s total, mean: 0.000s, max: 0.001s
Color Highlighter.main: 0.007s total, mean: 0.000s, max: 0.001s
Default.history_list: 0.016s total, mean: 0.000s, max: 0.002s
Terminus.terminus.core: 0.000s total, mean: 0.000s, max: 0.000s
on_text_command:
Default.history_list: 0.001s total, mean: 0.000s, max: 0.001s
Emmet2.abbreviation: 0.000s total, mean: 0.000s, max: 0.000s
Emmet2.comment: 0.001s total, mean: 0.000s, max: 0.001s
FileManager.FileManager: 0.000s total, mean: 0.000s, max: 0.000s
LSP.plugin.completion: 0.000s total, mean: 0.000s, max: 0.000s
Terminus.terminus.core: 0.003s total, mean: 0.000s, max: 0.001s
Terminus.terminus.mouse: 0.001s total, mean: 0.000s, max: 0.001s
on_window_command:
Default.history_list: 0.001s total, mean: 0.000s, max: 0.001s
Terminus.terminus.core: 0.000s total, mean: 0.000s, max: 0.000s
wrapper:
Emmet2.abbreviation: 0.010s total, mean: 0.000s, max: 0.001s
ST sometimes blocks shortly if the previed file is of a syntax which needs to be loaded. This happens for some of the more sophisticated syntaxes only.
I wouldn't find disabling the preview a good idea.
Maybe some kind of debouncing would help reducing the CPU load and the number of plugin queries while quickly cycling through files. If a user keeps the down button pressed ST cycles too quickly to see the content of the preview anyway.
What I have in mind is something like the debounced preview in the Default/ui.py.
FWIW blocking on loading syntax definitions will be fixed in the next build - the syntax has always been loaded in a background thread, however there was an issue that caused the main thread to block on that in some circumstances
I developed muscle memory to not hit any large file while searching. Thanks sublime.
This is the most annoying feature. You may hit a result of large file while typing or minified javascript files for example, and it lags when showing preview.
Also reported in here and here.
Please, atleast add an option. That would be so much appreciated. So many people have reported it and you seem to don't do anything. Even if it wasn't default, it would be so much better.
It doesn't take that long, but is a design decision to not add it as preview takes place asynchronously and doesn't / shoudn't therefore impact navigation speed. That's what I understood from comments during the last dev cycle.
oh my god, 2016? honestly, i'm considering vscode because a) it doesn't do this (nor does atom or any other editor) b) it's open source (not like i care about that but it's bonus that you can make your own features)
+1, i need that option, my laptop doesn't like that feature at all..
https://github.com/sublimehq/sublime_text/issues/3500
Does anyone know of a plugin that disables the preview? or a plugin that provides a goto file without preview? I need something, it's painful to use
I just noticed it is a 3 years old issue, have people at Sublime forgot about this issue?
Having an option can't be that hard to implement?
FWIW: I wonder if it would make sense to implement the same kind of debouncing delay as for the UI: Select Theme command. So the file is previewed only if user stops typing (for 200/300ms). This would reduce CPU/storage load as files wouldn't need to be opened/parsed after each key stroke.
A simple option to just disable preview would be great. I personally don't experience this "lag" on larger projects when I'm on PC, but I noticed it on my laptop, which is somewhat old. For me, it's more of a distraction than a performance issue. Since it always changes the context I'm looking at, sometimes I lose my chain of thought.
I recently switched from VS Code so my suggestion could be influenced by that since it doesn't have a preview for Goto anything and it has a separate view for searching with preview.
Hello
What's the status on this?
It is still ignored?
The joy of proprietary software, we end up begging for simple usability fix.. very sad
I wonder where our money is going?
The same reply below applies to your comment on the other issue as well.
If the issue/feature request has an assignee, then the chance of that issue/feature request being worked on is much higher. If there is no assignee, you can be certain that that issue/feature request is not being worked on and there is no point continuously asking on in the issue if this is being considered or not. This is not an official statement from SHQ or something but just my observations from the past 2 years of being involved in the community.
Weekly bump, i can't stand this constant screen flickering, i'm close to uninstallation
Weekly bump, i can't stand this constant screen flickering, i'm close to uninstallation
Yeah, i did switch to vscode and other editors many many months ago just because of this
Notifying the Product Lead @dpjohnst, in case employees ignore it to not do hard work
Dude, stop being demanding, impolite and arrogant.
Even if you paid for ST, you deserve nothing more besides what you paid for at the time of the purchase. If you didn't like what you saw then you didn't have to pay for it.
Being a paid customer doesn't mean that someone will be fixing your pet issues now. You didn't get the right (like everybody else) for that with your purchase.
If you are so smart and could fix things yourself (like you alluded to in other issues) then just pick an open source editor that you can fork and improve yourself. Good luck.
Dude, stop being demanding, impolite and arrogant.
Even if you paid for ST, you deserve nothing more besides what you paid for at the time of the purchase. If you didn't like what you saw then you didn't have to pay for it.
Being a paid customer doesn't mean that someone will be fixing your pet issues now. You didn't get the right (like everybody else) for that with your purchase.
You misunderstood my intentions, all i'm doing is suggest improvements and making sure their team acknowledge it
Their latest comment on it is from 2019, we are year 2023, 4 years later, if they let their issues open for years without activity, then perhaps something is wrong at their company, transparency is all i expect
They sell a product, with it comes support service, that's business
If you are so smart and could fix things yourself (like you alluded to in other issues) then just pick an open source editor that you can fork and improve yourself. Good luck.
I could fix it myself indeed, it's not a hard problem for me
I don't use Sublime Text as my main editor, i use it whenever i need to test compatibility with the language server i'm working on
This issue is assigned to a core dev. This may indicate some progress on this topic. TBH, I'd also expect such core things to be configurable, even though I'd personally probably keep it enabled.