low-level api to pause redrawing or combine a lot of addRegion calls into one bulk update operation (asking to make my plugin work better github.com/vprimachenko/Sublime-Colorcoder)
file tree api to add classes to files so it is possible to change and tint the icon, alter file name color, background color of the line eg to show SCM status or server sync status or whatever
nested editors like the “Quick Edit” in Brackets or “Peek Definition” in Visual Studio
low-level api to pause redrawing or combine a lot of addRegion calls into one bulk update operation (asking to make my plugin work better github.com/vprimachenko/Sublime-Colorcoder)
if the scope added with addRegion does not have a background color its foreground is used to fill the background and font color stays
please change it to expected behaviour
file tree api to add classes to files so it is possible to change and tint the icon, alter file name color, background color of the line eg to show SCM status or server sync status or whatever
nested editors like the “Quick Edit” in Brackets or “Peek Definition” in Visual Studio
powered with plugins like the code complete suggestions api[/quote]
+1
I wanted to second every single feature request he made.
Extending the API to allow truly interactive plugins to be developed, as discussed briefly in this forum post. Sublime is already fairly stable, performant, and featureful. Extending the API would allow plugin devs and users to drive more user-facing development and ease the burden on your end.
Fixing bugs already reported on unofficial Github tracker
I thought about another one: add the scope (or a custom information that would need to be added in the syntax file) to the index symbol, this would simplify a lot things in plugin working with symbols and even for the classic goto to definition, when there is multiple deifnition for a same symbol, having the scope would help choose the right file.
There are a few bugs related to the key bindings and different keybaord layouts. I know it will be a boring work because there are a lot of keyboard layouts, but maybe one issue will will fix most of them.
I got around some by changing the shortcut, but that only works 50% of the time.
The first is a local forum topic discussing how some users have setup an account on GitHub to track issues: github.com/SublimeTextIssues. That seems a promising option but no very useful the author of Sublime Text uses it.
The second is linked from the Sublime Text support page but has quite a bad spam problem. The list style with users being able to vote for requests seems like a great fit for feature requests.
I really hope that things can turn around, I’ve been trying out Sublime Text 3 and I really like it. There are still things missing that I use other apps for but this has some great features they don’t have.
But for the love of god, fix some bugs before embarking on new features. There’s a huge amount of them on the github tracker and quite a few unanswered forums posts (thousands, actually).
I realize bug fixing is boring, but it needs to be done.
I personally use Sublime on mac only now because rendering on 4K displays on Windows is slow. Finally, please disable atomic save by default, it has a number of issues on all OS’s and isn’t worth it.
Much appreciated, thanks for this. Here things I consider important:
Give more apis, let the community build/work into the rest. Specially APIs about necessary 'events
’
Allow to turn off things… for example the “double click” in the “find and replace” view/tab, I should trick my mind to not do double click there, and that is very difficult. Another thing I would love to turn off is the restoring of the scroll. Instead of helping is making my life more complicated.
Move as much as possible of sublime behaviour to packages, Open Source the packages and let the community fix/work into these things.
Invest time into Core things, give priority to things that improve/fix extending the editor. For example, I appreciate the new “Open URL”, but that can be done with a package.
Include package control by default.
Centralize the bug tracking, for example in our effort. If you think it can be improved, we are open to suggestions… Just open a new issue
Here things I can live with it
Annoying: impossible to exclude files from “find” results, results include a lot of noise if you don’t skip special files and folders for every search.
Annoying: the sidebar selection is lost with every change of focus, this behavior is disturbing, you cannot work with a set of files, the selection is always lost. If a user wants to locate the current file on sidebar they can just hook on_activated and call “reveal_in_side_bar”
Welcome back, Jon. I’m excited for the future of ST and this thread made me really happy already.
I’ve compiled a few lists with (too many) issues of varying effort.
Bugfixes that I’d like to see:
Invoking window.show_quick_panel with “selected_index” does select the item but does not actually scroll to it (#222
) (annoying)
“atomic_save” should be disabled by default. Atomic saving in itself is not a bad idea, but it must be handled at an OS level because the hack-ish implementation currently messes with how conventional file operation works and renders many file watchers useless. Most users need a pointer to this setting when they experience such issues since it’s not something they are used to. Furthermore, it also doesn’t work sometimes for very odd reasons. (this should be an easy fix) (#379
)
Transient views are sometimes messing with me when they don’t close correctly, as they are not displayed in the “open files” sidebar and I have tabs hidden. Sometimes I close a file and get
There is a very annoying issue regarding syntax def development, which is the file watcher stopping to watch a syntax defition file after a syntax error was detected. (#418
)
Also, the error messages could use some improvement in general as they are hard to debug. (#417)
Ability to edit the recent projects, or more precisely those that get displayed in the project switcher. I use it regularly, but if I happen to move a folder, rename a project or just delete it completely it’s really hard to get rid of the entry there and it will keep being annoying when you accidentally select it. (#88
)
As mentioned before, completion list navigation could use some improvement as it’s very clunky currently. While it probably makes sense to not eat key inputs when there is only one or two completion to display, a huge list is very painful to browse, especially since it doesn’t even support mouse wheel scrolling. (#20
)
Same for quick panels. (#21)
A few features that I have interest in, API-wise and in no particular order:
More application events, especially on_application_close (#10
, #181)
More flexibility in the status bar. Create your own static status bar sections since the “set_status” gets messy quickly, custom menus for these sections or maybe click events (overall low priority) (#15
)
Some sort of Sidebar API. Some ideas: Colorize files, change file/folder icon, create your own sidebar section (below or above the project’s files) with a custom tree view or just some text
Tooltip API. The ability to define regions (buttons) or links that generate an event when clicked would probably be a nice addition to what was mentioned already. (lower priority personally) (#25
)
Better classification of view types. It’s sometimes rather hard to determine what kind of view you got handed in an event callback since technically everything text-related in ST is a view and probably each of them triggers on_modified and the like. While I don’t think that’s bad per se, since you get to do a lot of things with it, you have to commit to a few workarounds currently (#70
)
The current implementation of show_quick_panel is very naive and breaks easily when the lenghts of sublists differ. It should be possible to have differently sized list entries and possible to display them with the same height, if desired. (#384
)
In general, more options to interact with the user GUI-wise. The sidebar and tooltip API are directed at this, but there are likely more options that I just don’t think of right now. Lower priority than the others.
General things:
As you have probably noticed, I try to keep the issue list on github very clean and nicely tagged. I heard from kari that you are looking at it occasionally and if there is anything that we could do with it to make it easier for you to work it, I’d love to hear it.
Better or clearer communication as to where feedback should go, and which kind. Forum, the github issue tracker, userecho etc. I’m very satisfied with how our issue tracker is going so far (except for a few duplicates and issues posted to the wrong repo, but that’s better than on the forum where you can’t even close/tag them). The main issue here is that while the forum is nice for discussions of all kinds, it’s not an issue tracker and the lack of notifications surely doesn’t help. The userecho site hasn’t seen any love in years it seems and it also generally very messy by itself, but it supports voting. If only its stylesheet wasn’t broken in FireFox since an enternity.
Discourse. Yes, I love it.
And the “open source Default packages” thing of course. However, I don’t feel ready yet to make any suggestions right now since this still needs some discussion, imo. If you’re interested in the latest discussion, head over to here: github.com/SublimeTextIssues/Core/issues/621
Package Control integration would be neat but not a necessity since it’s easily installed with just one line from the console. I would normally also mention the docs, but since you supported our campaign for the unofficial docs update (many thanks for that!), we are the ones at charge here.
There are of course more things, but those have way less priority or are just too much to ask right now.
It was, kind of, but not from a mouse event. I (and I think you too) were hoping for the addition of APIs that could translate x and y positions to text extends in the past, which is certainly a welcome addition.
open recent project command: Prompt list of recently opened projects. A preferences option to specify how many recently opened projects ST should remember
sidebar api
close sidebar command
is sidebar open command
get file under-cursor/selection command
colour support e.g. ability to color file tree for git status
Tree view : this will help in building a lot of useful plugins : (debug plugin, class hierarchy, database viewer …)
Multiple gutter icons at the same line.
Tooltip (could be used for : showing errors, function signature, suggestions …)
Window widget : a floating window with ability to add buttons to it so it can be used as a confirmation box …
Extend the api to give more control to developpers.
Outside of sublime text :
No communication blackout, i think i’m speaking for everyone if i say that for a while we thought that sublime text was dead. (a post on the blog or on twitter isn’t such a bad thing after all)
Official bug tracker is a must.
Maybe hire someone, he can fix the bugs, while you make sublime more awesome then it is.
An alternative to the previous suggestion is export as much as possible functionalities into plugins and let the community fix the bugs.
I want to thank you again for your hard work to make this amazing software available and make our life easier.
Hi,
New to this blog, but as a happy ST user for few years now I’d like to contribute with my opinion at least For me the top annoyances/bugs in order
]Platform specific settings, Preferences (Platform).sublime-settings, in User folder, it breaks the ability to share the folder among platforms./] ]Ability to edit which projects are displayed in the project switcher (at least ability to delete one by one; it easily gets filled with garbage projects that no longer exist, clearing all for just get rid of few is very annoying)./] ]An actual block cursor for vintage mode, right now uses same color as the selection, very inconvenient in some themes./] ]Fixing the quick panel so it doesn’t close on Windows when ST loses focus; seems easy to solve and and many people complain about it./]
Open sourcing default packages sounds essential, in my case specially annoyed by the default C++ package; it’s very limited while you have a great improvements in the C++11 package but the only way to use it is ignoring the default one. Seems to me a bit hacky for just supporting stuff in the c++ standard, it’d be great if those kind of fixes can be shipped directly with ST.
And for the API, I’d give priority to
]Tooltip support./] ]More flexibility in the status bar./]
)
For me the top annoyances/bugs in order