Sublime Forum

Interface Suggestions


Most plugins use the send2trash python library. So, just look in your trash



If the ST devs choose to do this, please make it optional. I love the current way show_input_panel works.



If I am not mistaken, a plugin could do this by modifying view.settings().



As far as I’m aware, there’s no setting related to showing/hiding tabs. I know about the toggle_tabs command which I’ve bound to a key combo of my choice but it’s not a setting I can get from view.settings().



Newer builds of Sublime (currently I think just the latest Dev build although I haven’t investigated, but certainly not the last released version) have window.get_tabs_visible() that you could presumably use to determine if tabs are currently visible or not. With a little bit of code somewhat like this code for turning off the mini-map per view you could probably set up turning tabs off and on when specific views have the focus.



ST needs a way to customize tab names for files with the same name (e.g. index.js). If we have multiple files with the same name open ST displays the file name followed by "– path/to/file". The first few characters in a tab name are very important to figure out what’s under the tab quickly. If these few characters represent a generic file name like index.js it doesn’t help you at all. The situation can be even worse if you have "enable_tab_scrolling": false and those tabs are shrunk like in the screenshot below:

Emacs, for example, has a customization like this:

Uniquify Buffer Name Style:
(*) forward
( ) reverse
( ) post-forward
( ) post-forward-angle-brackets
( ) numeric suffixes

   How to construct unique buffer names for files with the same base name.
   The value can be one of: ‘forward’, ‘reverse’, ‘post-forward’,
   ‘post-forward-angle-brackets’, or nil.

   For example, the files ‘/foo/bar/mumble/name’ and ‘/baz/quux/mumble/name’
   would have the following buffer names in the various styles:

     forward                       bar/mumble/name    quux/mumble/name
     reverse                       name\mumble\bar    name\mumble\quux
     post-forward                  name|bar/mumble    name|quux/mumble
     post-forward-angle-brackets   name<bar/mumble>   name<quux/mumble>
     nil                           name               name<2>

   The "mumble" part may be stripped as well, depending on the
   setting of ‘uniquify-strip-common-suffix’.  For more options that
   you can set, browse the ‘uniquify’ custom group.

It’d be great if ST could have something similar to this or at least have the forward option.

1 Like


window.get_tabs_visible() is working just fine for me (not sure why it’s named get_tabs_visible though; are_tabs_visible would make more sense to me). But your MiniMapToggler is not working for me:

...line 18, in on_deactivated
    self.is_minimap_visible (view) == False):
AttributeError: 'MiniMapToggler' object has no attribute 'is_minimap_visible'


I think he meant view.window().is_minimap_visible() instead of self.is_minimap_visible (view) == False. When we’re throwing code up on the forum, we can be a bit sloppy (I know I am). But generally, you can look at the Sublime API page to see how to do these things: Sometimes it doesn’t have all methods documented, but in general it is a decent reference.



Actually the code as presented there has the method defined after the on_deactivated and on_activated methods are defined; perhaps you didn’t copy enough of the code?

That said, that method is defined to get around how the current release version doesn’t have support for checking if the MiniMap is currently visible or not, so it uses a little hackery to figure it out if you’re running it in such a version; that’s the version I’m running and so I never tested it with the latest dev version, for which it may not work.



My bad, I didn’t even scroll the box to see the rest of the code. So I take it back @OdatNurd doesn’t post sloppy/untested code, but I do :).



Neither did I :slightly_smiling: there’s a con to having hidden scroll bars in OS X. The code is working :thumbsup:
Still it’s not what I’d like to achieve. I would like to turn off tabs for specific views regardless of their focus

1 Like


Even more so, the API has a window.set_tabs_visible(flag).

But as far as I can tell, there is not a way to apply this to a focus group, only to a whole window. And the suggested method, of disabling tabs on focus change, does not work here as, while minimap toggles do not change the location of the editor text area, the tab toggles do so such a plugin would cause a lot of moving the text area back-and-forth. So, +1 to the original idea :slightly_smiling:



Can’t you already do this? It seems I can.



Not on Windows at least - I right click and “Copy File Path” for a non active tab (only one tab group / single layout) and it copies the path of the active tab, not the tab I right clicked on.
Ah, but some actions seem to work, like “Close Tabs to the Right”…

EDIT: nevermind, I worked out how it works: "Reveal in tree view" on tab bar
I will delete this request :smiley:



Importance: major.

In my opinion, keybindings are currently very broken, mostly because package maintainers cannot be trusted not to hijack the default keybindings. Sometimes this is because they don’t use that functionality, sometimes it is because they don’t use that platform. Examples off the top of my head (maybe OS X specific):

  • TextPastry hijacks super+alt+b, which should show the build output panel

  • SublimeManpage hijacks super+alt+w, which should toggle “select word” in the find panel

  • PlainTasks hijacks alt+enter, which should insert a newline after the current line

Many (most?) packages hijack some kind of keybinding. Currently, if is difficult to solve these annoyances:

  • It is very difficult to identify which package has hijacked the keybinding

  • There is no centralised place to look to see what a key is bound to

  • You have to find out what the original keybinding was in order to “override” it back to its default. In example 2 above, this is a complicated context-dependent keybinding. Maybe you just want to reinstate the functionality for the find dialog but leave the package binding elsewhere. It can be hard to figure out what is needed.

Personally (though I think this will be unpopular) I think this is the perfect case for a specialised GUI interface. It could be as simple as a searchable table with the following columns:

Keybinding           Context           Command                 Set by                           Reset to default

super+alt+b          everywhere        what_ever               TextPastry                       [button]
alt+enter            everywhere        mark_completed          PlainTasks                       [button]
super+alt+w          everywhere        search_something        SublimeManpage                   [button]
super+alt+w          find_panel        toggle_word             Default                          [button]
ctrl+alt+super+c     everywhere        copy_basename_and_line  User                             [button]
super+shift+n        everywhere        new_window              Default (OS X).sublime-keymap    [button]
super+shift+x        output_panel      misc_command            SomeRandomFile.sublime-keymap    [button]
  • Clicking on a filename could open that filename to be edited.
  • Clicking on keybinding could directly edit the keybinding, by adding it to the User’s keybindings and marking this change in the table.
  • The “reset to default” button would either remove the keybinding from a file, or add an override back to default to the User’s keybindings file, depending on where it is set.

I think something like this would make the keybinding system so much more easy to use.



Importance: Minor

I’m late to the party, and I don’t know if this counts, but I’d love a fix for this issue.

1 Like





Show lines between parent and child nodes in the sidebar treeview of project files.

can make it optional via a preference picked up in a theme


split this topic #83

4 posts were split to a new topic: Package Control Focus Stealing


Package Control Focus Stealing

minihtml 2.0

minihtml in a view

We already have special views, called sheets I guess, to render images. Maybe those can be merged with minihtml views since minihtml can render images and more. They can be used for changelogs and lots of readonly views used by different packages.

minihtml docked to the left/right/bottom of a view

It could be used to render support information, git status, documentation, second sidebar, etc.
The docked view could be either scrollable with the view or have it’s own separate scrollbar.

minihtml popup positioned based on view/window/screen

Right now we can only show a popup at a text point on the view, but it would be helpful to be able to render a popup notification on the top right or bottom right of the view or window or sometimes even the corner of the screen.