I've kept a brief user's log since switching to TextMate. It contains bugs, suggestions, and hacks. Allen suggested I maintain a wiki page:
http://macromates.com/wiki/Profiles/QuinnComendant
(Allen: this is mostly for you ;-)
Q
Such a comprehensive list and not a singel mention of chunk-undo ˆ_ˆ Although I think it's on the to do list as I've heard/wished.
Andreas
On Jun 5, 2006, at 0:50 , Quinn Comendant wrote:
I've kept a brief user's log since switching to TextMate. It contains bugs, suggestions, and hacks. Allen suggested I maintain a wiki page:
http://macromates.com/wiki/Profiles/QuinnComendant
(Allen: this is mostly for you ;-)
Q
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 7 juin 06, at 09:54, Andreas Wahlin wrote:
Such a comprehensive list and not a singel mention of chunk-undo ˆ_ˆ
Not to mention the braindead block editing zero-column selection. Oh, and the death of that fugly drawer! :)
On Jun 8, 2006, at 3:48 AM, Luc Heinrich wrote:
On 7 juin 06, at 09:54, Andreas Wahlin wrote:
Such a comprehensive list and not a singel mention of chunk-undo ˆ_ˆ
Not to mention the braindead block editing zero-column selection. Oh, and the death of that fugly drawer! :)
I'm with you on the drawer. It's SO two years ago. I want the files thing to look like the one in mail and iTunes.
You lost me with the "braindead block editing zero-column selection" . How should it work?
atm. you have to hold down opt to keep it in column selection mode. this differs from the NSTextView implementation which requires you to hold opt when you start making the selection, but doesn't allow you to change your mind later on.
I like the ability in textedit and friends to keep it in column mode if opt it held down when you start a selection. But i don't like that you can't change your mind.
Do you think the textedit version is better?
thomas Aylott—subtleGradient
atm. you have to hold down opt to keep it in column selection mode. this differs from the NSTextView implementation which requires you to hold opt when you start making the selection, but doesn't allow you to change your mind later on.
I personally always use the cursor keys for this ... hold down shift, hit arrow down, press option and you're in column select. Never use the mouse again :)
Andreas
On 8 juin 06, at 13:35, thomas Aylott wrote:
You lost me with the "braindead block editing zero-column selection" . How should it work?
It's not so much the way it works, it's the way it looks, although I also find some aspects of the way it works questionable. My points on this have already been discussed here [1] and I know Allan doesn't agree with me so I won't go over this again. It's just that I like to poke him on the subject once in a while, just to see if he changed his mind ;)
[1] <http://lists.macromates.com/pipermail/textmate/2005-July/ 004856.html>
On 8 juin 06, at 13:35, thomas Aylott wrote:
I'm with you on the drawer. It's SO two years ago.
(sorry about the double reply, I didn't mean to press the send button, I swear ;))
Until last week, all I had against the drawer was that I really found it ugly. Now I *also* find it inconvenient :)
I was working on my Powerbook and had a fully expanded TextMate project window with its drawer opened (i.e. covering the whole screen, minus the menu bar, you get the idea). And then I had to resize the drawer. In this configuration, you first have to shrink the window size, then resize the drawer and then grow the window size again.
Devil. Is. In. The. Details. :)
On Jun 8, 2006, at 4:35 AM, thomas Aylott wrote:
On Jun 8, 2006, at 3:48 AM, Luc Heinrich wrote:
On 7 juin 06, at 09:54, Andreas Wahlin wrote:
Such a comprehensive list and not a singel mention of chunk-undo ˆ_ˆ
Not to mention the braindead block editing zero-column selection. Oh, and the death of that fugly drawer! :)
I'm with you on the drawer. It's SO two years ago. I want the files thing to look like the one in mail and iTunes.
If this changes I'd really like to see the drawer continue to be an option. NSDrawer is recommended for use when the data contained in them needs to be accessed by not all the time. Of course this concept fails miserably for Mail particularly since mailboxes are something you hop around all the time. Personally I almost never access the drawer once I've setup my tab view, and if I need to access a file I use cmd-T.
FWIW, I don't think this is a aesthetics thing because lacking a drawer increases the amount of horizontal space required out of the editor. Given the way I prefer to layout my workspace (http:// flickr.com/photos/mgrimes/159783736/) being forced out of a drawer would force an editor that normally consumes less screen real estate than documentation to no longer be adequately used side-by-side documentation.
-- Mark Grimes Stateful Labs mark@stateful.net
On Jun 8, 2006, at 11:43 AM, Mark Grimes wrote:
On Jun 8, 2006, at 4:35 AM, thomas Aylott wrote:
On Jun 8, 2006, at 3:48 AM, Luc Heinrich wrote:
On 7 juin 06, at 09:54, Andreas Wahlin wrote:
Such a comprehensive list and not a singel mention of chunk-undo ˆ_ˆ
Not to mention the braindead block editing zero-column selection. Oh, and the death of that fugly drawer! :)
I'm with you on the drawer. It's SO two years ago. I want the files thing to look like the one in mail and iTunes.
If this changes I'd really like to see the drawer continue to be an option. NSDrawer is recommended for use when the data contained in them needs to be accessed by not all the time. Of course this concept fails miserably for Mail particularly since mailboxes are something you hop around all the time. Personally I almost never access the drawer once I've setup my tab view, and if I need to access a file I use cmd-T.
FWIW, I don't think this is a aesthetics thing because lacking a drawer increases the amount of horizontal space required out of the editor. Given the way I prefer to layout my workspace (http:// flickr.com/photos/mgrimes/159783736/) being forced out of a drawer would force an editor that normally consumes less screen real estate than documentation to no longer be adequately used side-by- side documentation.
Ok. There are advantages and disadvantages to both. Personally, the drawer works perfectly well enough for me. I just don't much like the look of it. Even after I hacked the nib files.
Mark Grimes Stateful Labs mark@stateful.net
thomas Aylott—subtleGradient
Ok. There are advantages and disadvantages to both. Personally, the drawer works perfectly well enough for me. I just don't much like the look of it. Even after I hacked the nib files.
I think I speak for most of the "kill the drawer" crowd when I say this: We don't want to just kill the drawer and replace it with nothing -- we want it to be replaced with a very similar pane but with improved usability and slightly better usage of screen real estate. Just as Apple did with Mail.app. There should still be an option to hide the pane altogether just as there is now with the drawer. But the most significant difference is that when made visible, the pane would grow *inward* reducing the size of your code view rather than the way the current way the drawer opens *outward* whether there's enough space available or not.
I'm frankly at a complete loss to understand how anyone could think current drawer functionality is better for usability in this regard. Anyone care to enlighten me? ;-)
Sean
:::: DataFly.Net :::: Complete Web Services http://www.datafly.net
Am 9. Jun 2006 um 04:07 schrieb Sean Schertell:
But the most significant difference is that when made visible, the pane would grow *inward* reducing the size of your code view rather than the way the current way the drawer opens *outward* whether there's enough space available or not.
I believe I have seen stuff like this in some Cocoa apps over the last years (can't remember when and where): * When you had a fully maximized window the window would shrink in order to open your drawer. * When you closed the drawer, the window would grow again (if you were working at a maximized state, else not)
Am I dreaming? <g>
Dan
On 9/6/2006, at 4:07, Sean Schertell wrote:
[...] I'm frankly at a complete loss to understand how anyone could think current drawer functionality is better for usability in this regard. Anyone care to enlighten me? ;-)
Then search the archive rather than invite to another pointless thread about drawer pro’s and cons!
FYI your argument is only valid for those who have their window mazimized, not all have that, those who do not, can then resize the drawer without affecting the size of the text editing area.
On Jun 8, 2006, at 10:07 PM, Sean Schertell wrote:
We don't want to just kill the drawer and replace it with nothing -- we want it to be replaced with a very similar pane but with improved usability
well duh. :D I thought everyone knew that that was exactly what i was talking about.
Allan has already told us that we're getting something new and cool.[1] I just forget whether it was a drawer or a mail.app/itunes style inside drawer column thing.
[1] http://macromates.com/blog/archives/2006/02/15/future-directions/
thomas Aylott—subtleGradient
You lost me with the "braindead block editing zero-column selection" . How should it work?
The model here should be sub-etha-edit
Here you option drag across a group of lines and they are all highlighted showing they are in group edit mode, then, where ever you insert the selection point or make a selection, that region is group edited (vertically through the lines).
The benefits are massive: no need for pixel-perfect (pixel-perfect!) dragging of a selection across numerous lines (often several vertical cm). Just a single crude drag-as-you-like option select. Followed by a normal "click here to edit" selection.
It is far more reliable and far more usable.
On 9/6/2006, at 4:14, Timothy Bates wrote:
You lost me with the "braindead block editing zero-column selection" . How should it work?
The model here should be sub-etha-edit [...] The benefits are massive [...] It is far more reliable and far more usable.
For starters I can’t use it from the keyboard, I can’t copy’n’paste the columns selected, I can’t run a transformation on a column, I can’t move the selection around, etc.
The SEE block-edit is something DIFFERENT! That TextMate’s overtyping of column selections can be used for the same, is the only thing they have in common.
The only thing braindead here is the advocating of removing one feature because some clueless person wants ANOTHER feature.
On 9 juin 06, at 13:43, Allan Odgaard wrote:
The only thing braindead here is the advocating of removing one feature because some clueless person wants ANOTHER feature.
Yeah, I love you too Allan :>
guys, keep the cosyness off the list - I might be getting envious ;) and jealous.
scnr
On Jun 8, 2006, at 10:14 PM, Timothy Bates wrote:
You lost me with the "braindead block editing zero-column selection". How shouldit work?
The model here should be sub-etha-edit
Here you option drag across a group of lines and they are all highlighted showing they are in group edit mode, then, where ever you insert the selection point or make a selection, that region is group edited (vertically through the lines).
When I select something then click (not hold, but click) somewhere else, I expect the selection to go away and the cursor to move to where I clicked. This is the behavior of pretty much every application on pretty much every OS. To change the behavior in a single app would screw productivity in my opinion.
The benefits are massive: no need for pixel-perfect (pixel- perfect!) dragging of a selection across numerous lines (often several vertical cm). Just a single crude drag-as-you-like option select. Followed by a normal "click here to edit" selection.
Pixel-perfect? Unless I'm missing something, it seems to require merely character-perfect mousing, which is 1) not that difficult, and 2) something you have to do all the time anyway. There are ways to make these selections even easier (using the keyboard has been mentioned). I also find that (using the mouse) a lot of times it's easier to do a regular style selection, let go of the mouse, then tap the option key to toggle column-mode on.
"I like the way it is" I guess… would be the… main bullet point of this… presentation.
Rob
On Jun 9, 2006, at 10:49 AM, Rob McBroom wrote:
On Jun 8, 2006, at 10:14 PM, Timothy Bates wrote:
The benefits are massive: no need for pixel-perfect (pixel- perfect!) dragging of a selection across numerous lines (often several vertical cm). Just a single crude drag-as-you-like option select. Followed by a normal "click here to edit" selection.
Pixel-perfect? Unless I'm missing something, it seems to require merely character-perfect mousing, which is 1) not that difficult, and 2) something you have to do all the time anyway. There are ways to make these selections even easier (using the keyboard has been mentioned). I also find that (using the mouse) a lot of times it's easier to do a regular style selection, let go of the mouse, then tap the option key to toggle column-mode on.
I am with Tim on this. Character-perfect mousing is inefficient from an HCI point of view if you can accomplish the same thing with gross (read: sweeping) movements, both with the mouse and the keyboard. And selections with the keyboard as you suggest are incredibly frustrating, but with an intelligent block-edit mode (like Tim mentioned, in SubEthaEdit), you could navigate using the keyboard navigation commands you are used to, or with your character-perfect mousing, and not lose your selection-mode. Currently, we have to select into column edit mode, edit, move the cursor, select back into column edit mode, edit, etc. The change Tim mentioned reduces this process dramatically.
Jeff.
On Jun 9, 2006, at 11:11 AM, Jeffrey Robert Spies wrote:
I am with Tim on this. Character-perfect mousing is inefficient from an HCI point of view if you can accomplish the same thing with gross (read: sweeping) movements, both with the mouse and the keyboard.
Well, good or bad, selecting from one specific character to another is a large, unavoidable part of modern computing. I guess I don't see avoiding 3 such selections per day, when I'll probably be making hundreds over all, as that big of a gain.
And selections with the keyboard as you suggest are incredibly frustrating, but with an intelligent block-edit mode (like Tim mentioned, in SubEthaEdit), you could navigate using the keyboard navigation commands you are used to, or with your character-perfect mousing, and not lose your selection-mode.
I maintain that you're *supposed* to lose the selection when you navigate. If for no other reason, it's the fastest and most intuitive way to um… not have that stuff selected any more. :)
Currently, we have to select into column edit mode, edit, move the cursor, select back into column edit mode, edit, etc. The change Tim mentioned reduces this process dramatically.
OK, it's starting to make a little more sense. I hadn't considered wanting to edit multiple different columns within the same range of lines in one sitting. I still think there must be a better way though. Perhaps an easy way to move a multi-line "cursor" a.k.a. an in-between-columns selection left and right (assuming there isn't already a way). This would actually change what's selected, which makes more sense to me than preserving the selection while navigating.
Rob
On Jun 9, 2006, at 1:20 PM, Rob McBroom wrote:
On Jun 9, 2006, at 11:11 AM, Jeffrey Robert Spies wrote:
I am with Tim on this. Character-perfect mousing is inefficient from an HCI point of view if you can accomplish the same thing with gross (read: sweeping) movements, both with the mouse and the keyboard.
Well, good or bad, selecting from one specific character to another is a large, unavoidable part of modern computing. I guess I don't see avoiding 3 such selections per day, when I'll probably be making hundreds over all, as that big of a gain.
Try SubEtha's version of this. Allan has mentioned some problems with this, that he sees, and I'm not arguing anything else other than it is very nice to get in and out of, which prepares for the multi- line cursor (read on). Yes it isn't accessible from the keyboard, but just think if it was. It would be magical.
And selections with the keyboard as you suggest are incredibly frustrating, but with an intelligent block-edit mode (like Tim mentioned, in SubEthaEdit), you could navigate using the keyboard navigation commands you are used to, or with your character- perfect mousing, and not lose your selection-mode.
I maintain that you're *supposed* to lose the selection when you navigate. If for no other reason, it's the fastest and most intuitive way to um… not have that stuff selected any more. :)
Well, if you hit option to get in, why not hit option to get out (or some other keyboard command). :)
Currently, we have to select into column edit mode, edit, move the cursor, select back into column edit mode, edit, etc. The change Tim mentioned reduces this process dramatically.
OK, it's starting to make a little more sense. I hadn't considered wanting to edit multiple different columns within the same range of lines in one sitting. I still think there must be a better way though. Perhaps an easy way to move a multi-line "cursor" a.k.a. an in-between-columns selection left and right (assuming there isn't already a way). This would actually change what's selected, which makes more sense to me than preserving the selection while navigating.
Multi-line cursor: yes, exactly! If you have a multi-line cursor, there's really no reason NOT to select a whole block--it allows a greater range of movement in your initial selection. And why not just select a whole block, keeping the cursor at the point you originally selected? That would merge the character-perfect selection we have and block-mode very nicely.
Jeff.
-
Allan Odgaard -
Andreas Wahlin -
Daniel Käsmayr -
Domenico Carbotta -
Jeffrey Robert Spies -
Luc Heinrich -
Mark Grimes -
Quinn Comendant -
Rob McBroom -
Sean Schertell -
thomas Aylott -
Timothy Bates