But what it's missing is the even more subtle 50 column marker that I expect for the first line. The commit message UI sprouts a subtle 72 column marker when I put text in it, which is nice. I just opened this on my repo and there's 3 immediate things I noticed:ġ. Is there any official channel for feedback? I've used it almost every day for work for the last 5 years and it's definitely made my life much easier! IMO there aren't very many good diff tools, so a lightweight one that works cross-platform could be a good market to target. There are plugins for Sublime Text that try to do this with two text panes, but they don't work especially well. if two files are selected in the sidebar, you could right-click > diff files, and perhaps an action on an open file could be "diff file with.").
Merge tool integration for file merging/diffing (e.g. Not sure I have any specific suggestions for improvements, but that welcome screen in Sublime Merge sure looks nice.Ģ. I've resorted to opening sublime from the terminal with `cd /path/to/project/ subl. I have tendency to move directories around which makes managing projects a bit awkward. That would be useful.Īside: IMO managing workspaces/projects is a weakness of Sublime Text atm. Note: I notice that there is no "Stage All" button. I currently commit using the terminal (+ Micro Editor), but this could be even better. I imagine Sublime Merge launches pretty quickly, so this would be pretty nice as I wouldn't have to keep it open: I could just let Sublime Text manage my "workspace".
A create commit action accessible from the Command-Shift-P dialog. The ability to configure this to use another git client would make sense, although personally Sublime Merge looks fantastic.Ģ. If Sublime Text could detect when a directory is a git root directory, and present a button to "open in sublime merge" (my sublime projects often span multiple git repos, so detection on a folder by folder basis would be key). It would be cool to have some integration going the other way. (Also God help you if you want to work with remote IMAP servers. Neither of those approaches are great, for obvious reasons. You either have to force an "indexing" step - like notmuch does - or scan the filesystem tree. Using a database to store your state is a cheap alternative, but risks issues getting outdated if you ever interact with the mail outside your program. More important is to design how you're going to work - Originally I allowed something similar to google's tagging, so you could "open a folder" which contained mail from multiple Maildir collections. Partly due to the sheer amount of bogus mails you'll get, and partly due to people having very firm beliefs about what they want. (Think "scriptable mutt".) Writing a mail-client is hard. I wrote a mail client, two actual, focussed upon the console. I'm going to assume you meant you could start in a month, rather than be completed in a month, because otherwise I'd like to save you some pain!
0 kommentar(er)
