I presented several approaches, which one you do not like? Or you just like a 85% command palette default?
It is correct, and can be solved by precaching the new size, so instead of just increase the size 1 char, increase it 20 or 100, until it get to the maximum of 85%.
Worth notice size increase would only be required a few cases as when using the Arithmetic command, therefore it is not required a world wide width 85% for all use cases of the command palette.
I have problem with vintage command on Windows build 3154. Whenever i press : in command mode it open command palette with : selected so i need to press : again to use vintage commands.
This is a vanilla install:
Good call, almost forgot reporting this. Also happens with custom binding to open the palette with E. G. āSet Syntax:ā or āBuild with:ā.
On the subject of overlay width, I find the over-wide width of the new Command Palette to be a serious distraction especially, and ironically, in distraction free mode. The other overlays are all positioned centrally while the new Command Palette appears way off on the far left of my monitor.
In September 2016 I made a suggestion, in the API Suggestions thread, which included the addition of flags to control the APIās show_quick_panel() overlayās width. It seems to me that might be a possible solution. Users could set different key bindings to open the Command Palette (and the other overlays) depending on how they want it/them to appear. [e.g. extra width for Show Files to reduce the minor annoyance of path truncation.]
My API suggestion requested that all of the various styles of ST overlays be made available in the API. In particular Iād very much like the Quick Switch Project (prompt_select_workspace) style of overlay be made available - it pops-up and keeps the focus until a user selects something or cancels it, this would be highly appropriate for some tasks. Perhaps, since SHQ are dealing with overlays at the moment, this might be considered. IMO a desirable API addition - all of the various overlay styles being made available in the API would be the holy grail.
I can confirm this behavior, it is quite annoying and ran on this few times a day.
@deathaxe, I also manage to make Sublime Text crash. It just crashed after I attempted to open the command palette. I am not sure on how to reproduce it.
@wbond this is the dump file, I hope it help it to get fixed:
https://github.com/SublimeTextIssues/Core/files/1508173/crash_build_3154_2017_11_27.zip
Dump Summary
------------
Dump File: d1af34d7-6213-4a30-9384-276f96426f01.dmp : D:\SublimeText\d1af34d7-6213-4a30-9384-276f96426f01.dmp
Last Write Time: 27-Nov-17 22:49:15
Process Name: sublime_text.exe : D:\SublimeText\sublime_text.exe
Process Architecture: x86
Exception Code: 0xC0000005
Exception Information: The thread tried to read from or write to a virtual address for which it does not have the appropriate access.
Heap Information: Not Present
System Information
------------------
OS Version: 10.0.15063
CLR Version(s):
Have any of you experienced problems with loading a color scheme in ST 3154 (the build-in Monokai at that)?
Iām on Mac OS High Sierra 10.13.1 (newest) and encounter the problem when using the GitSavvy plugin; see my related Github Issue. It would be nice to confirm whether the problem is confined to me, or if itās a more widespread issue.
####TL;DR of the Github Issue:
~/Library/Application Support/ Sublime Text 3)>>> scheme = view.settings().get("color_scheme")
>>> sublime.load_resource(scheme)
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Applications/Sublime Text.app/Contents/MacOS/sublime.py", line 192, in load_resource
raise IOError("resource not found")
OSError: resource not found
>>> scheme
'Monokai.sublime-color-scheme'
EDIT: grammar.
pretty sure itās not a bug - color schemes IIRC used to have to be referenced by their full path (.tmTheme files), but now with .sublime-color-scheme files, it doesnāt make sense to do so, nor is there generally any need for a plugin to try to directly open a .sublime-color-scheme. If it is absolutely necessary, GitSavvy should probably use sublime.find_resources first to get a full path to the file.
Does anybody else have an issue with this build freezing constantly and using up a lot of system resources? Itās been freezing on and off at least 30-40 times today in only a few hours for me. Itās driving up a damn wall.
Perhaps it is related to these other threads issues:
Which one is your Operating System and version?
Win7 Pro, SP1
Build: 3154
For now I reverted back a build so I could get some work done today.
I do see that the indexing is taking a long time to finish but it is moving steady on the previous build. So far the previous build hasnāt been crashing on me so thatās good.