Build 2032 on Mac OS X.
* Choose vertical two pane layout.
* Open a file in group 1.
* Switch to group 2. Open the same file there using Goto Anything. The same buffer now appears in two tabs, one in each group.
* Make some changes to the buffer. A "file dirty" marker asterisk appears in both tabs.
* Save the buffer. The asterisk disappears in the tab that was active when the save command was issued, but it remains in the other tab.
When you have multiple cursors/selections which are not in the current view (i.e. you scrolled away from them) it might easily happen that you type away without noticing, that you actually modify multiple places at once. It would be nice to have a clear warning when an additional cursor is not currently visible. For example by showing one or two of these cursors (in their respective scope; i.e. the line they are in) at the top or bottom (depending on where they are in relation to your current view) of the editing window.
- Easier to switch/focus attention (especially for people with bad eyesight).
- More height for the project view.
I'd prefer to click a "Reset" button in the "Find dialog" in cases where the text for which i'm looking isn't highlighted, than focus the document, copy, paste to "Find What" before I can search
Problems arise from the following set of steps:
- Open a locked document
- Make edits to the document
- Save -> Get Error about document being locked
The issue is getting the file unlocked painlessly so the user can save the edits made up to this point. I realize there are plugins that exist to auto-checkout files in source control, but this is an orthogonal issue. For example, if the checkout/unlock operation fails, the user is stranded with edits that cannot be saved.
Possible resolutions include:
- Let the user drag the document icon (in OSX) in the window bar to another application to copy the file path. As of step 2 above it is greyed out and cannot be dragged without undoing the edits.
- Prevent the user from making edits in step 2 until the file has been unlocked. This is how other editors like BBEdit and Xcode behave. This would also be the point at which version control plugins would want to attempt to check out the file.
- The ability to overwrite the locked file during step 3. Some kind of dialog to either cancel the edit or unlock the document. This would be a fallback option in the event a plugin failed to checkout/unlock the document, so the user could still save the edits (they would, of course, be on the hook for checking out the file manually.)
- The ability to get the full path of the frontmost document quickly copied to the clipboard so it can be pasted in another application to checkout/unlock the locked file, making step 3 succeed.
Customer support service by UserEcho