Disable colored title bars and your issue will be fixed. Sublime Text for some reason doesn’t like them in custom themes.
Details:
Dev Build 3154
greg_hoch
#74
Support for multiple rows per entry in sublime_plugin.ListInputHandler
show_quick_panel supports multiple rows for each entry in the quick panel. From the API documentation: "items may be a list of strings, or a list of string lists. In the latter case, each entry in the quick panel will show multiple rows". It would be great to have the same support in sublime_plugin.ListInputHandler. I know that list_items function uses [(str,value)] for the command argument. Still I think it would be great if the two API were consistent. With the current implementation, I sometimes have to pick between a chain of inputs vs multiple rows.
0 Likes
wbond
#75
My plan is to look into this over the next day or two to figure out what is going on.
1 Like
deathaxe
#76
You are on the dev channel. I guess the new command pallet is brand new and a kind of initial implementation. So it’s quite normal not to have it fully functional for all use/edge cases. Maybe feedback like this is exactly the goal of publishing it in such an early state. Furthermore each command needs to support the new command pallet by returning an ImputHandler. Might be the second or third step after command pallet works well enough?
The ability to automatically open the command pallet to query for all missing arguments automatically, would be really great.
0 Likes
deathaxe
#77
You mean multiple lines in the listbox?
I also thought about it. Maybe the preview area can be used to show detailed information about the selected item in the list? This way the listbox itself keeps quite compact. One disadvantage of multi-line items is the list getting very long with only very few items being displayed at a time.
With GitSavvy or GitGutter in mind, I think displaying the branch/tag/commit names only in the list with details about author/date/email, … being displayed for the selected list item in the preview area only, might even be a bit cleaner and avoid overloading the quick panel with too much detailed information.
0 Likes
deathaxe
#78
Your proposal would result in exactly what @jps and @wbond tried to avoid. In the worst case each input would cause the command pallet to resize and “jump around”. Not sure, whether it is really a better solution.
0 Likes
jahazaib
#80
how to turn on auto complete commands that means if i write <htm then full command appear please help
0 Likes
greg_hoch
#81
Yes, like the screenshot. In this case, it shows all previous or current jobs running on a high performance computational cluster. I find the two rows pretty useful…
0 Likes
addons_zz
#82
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.
0 Likes
mehrad1
#83
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:
0 Likes
FichteFoll
#84
Good call, almost forgot reporting this. Also happens with custom binding to open the palette with E. G. “Set Syntax:” or “Build with:”.
0 Likes
mattst
#85
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.
3 Likes
addons_zz
#86
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):
0 Likes
AllanLRH
#87
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:
- Problem persists when I reverted to a freshly installed state (deleted
~/Library/Application Support/ Sublime Text 3) - Persisted when I reinstalled ST 3154, were fixed by installing ST 3153 instead.
- From the console of a fresh ST 3154 install, except for installing Package Control and using it to install GitSavvy:
>>> 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.
1 Like
kingkeith
#88
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.
4 Likes
mikenytola
#89
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.
0 Likes
addons_zz
#90
Perhaps it is related to these other threads issues:
Which one is your Operating System and version?
1 Like
mikenytola
#91
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.
1 Like