I'm new to Textmate, and like what I see so far. Three things off the bat are frustrating that are really keeping me from using it full time. If I'm missing some simple fixes to any of these, please forgive:
1) The undo behavior. I read an earlier digest that standard OS "chunk" undos were planned, but I don't see this pref anywhere. Is there a plist command that will turn on chunk undos, and if not, will this feature be coming soon? Having to hit cmnd-z 34 times in a row is tiresome...
2) While I can pick the language of a file independent of the filename, some command behaviors appears to be tied to the filename. For example, I have foo.php which is mostly straight html code, but since the filename is .php, unComment give me php comments, not html. Shouldn't it be possible to have the commands tied to the language choice?
3) Slowness. I've read a variety of posts on the subject, and it seems TextMate is buggy (or coded in a non-efficient manner) when dealing with multiple open files and across a network. The slowdowns I experiencing when switching tabs or switching to/from the application itself grow slower the longer I have a set of files open-- this problem really needs to be addressed.
Thanks, Steve
- The undo behavior. I read an earlier digest that standard OS
"chunk" undos were planned, but I don't see this pref anywhere. Is there a plist command that will turn on chunk undos, and if not, will this feature be coming soon? Having to hit cmnd-z 34 times in a row is tiresome...
AFAICT, Allan is not very fond of the way chunk undos behave. I'm not sure I'm all for it either, but a preference would sure be nice. Back in the first release I suggested to Allan that he used timed keypressed to determine the undo chunks, so that it's a bit smarter and doesn't undo too much.
- Slowness. I've read a variety of posts on the subject, and it seems
TextMate is buggy (or coded in a non-efficient manner) when dealing with multiple open files and across a network. The slowdowns I experiencing when switching tabs or switching to/from the application itself grow slower the longer I have a set of files open-- this problem really needs to be addressed.
Being around since 1.0, (reg #70), I can tell you it's got much faster in many aspects, and slower in things that were changed recently. Tab switching is really bugging me with b17. App switching is just fine though.
I can appreciate that's his personal preference, but there's something to be said for being consistent with the OS (particularly when they claim to "bring Apple's approach to operating systems into the world of text editors"). I've never even encountered this type of keystroke-level undo until TextMate, and I find it slows me down considerably. Please make chunks a preference!
Re: slowdown, I read about something involving the caching, and I did flip a defaults write, so app switching does seem a bit better..but tab-to-tab is really sluggish, and I'm on a dual 2 G5. This is just a text editor, I can't imaging what's happing behind the scenes that causes this.
On Sep 4, 2005, at 4:48 PM, Caio Chassot wrote:
- The undo behavior. I read an earlier digest that standard OS
"chunk" undos were planned, but I don't see this pref anywhere. Is there a plist command that will turn on chunk undos, and if not, will this feature be coming soon? Having to hit cmnd-z 34 times in a row is tiresome...
AFAICT, Allan is not very fond of the way chunk undos behave. I'm not sure I'm all for it either, but a preference would sure be nice. Back in the first release I suggested to Allan that he used timed keypressed to determine the undo chunks, so that it's a bit smarter and doesn't undo too much.
- Slowness. I've read a variety of posts on the subject, and it
seems TextMate is buggy (or coded in a non-efficient manner) when dealing with multiple open files and across a network. The slowdowns I experiencing when switching tabs or switching to/from the application itself grow slower the longer I have a set of files open-- this problem really needs to be addressed.
Being around since 1.0, (reg #70), I can tell you it's got much faster in many aspects, and slower in things that were changed recently. Tab switching is really bugging me with b17. App switching is just fine though.
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 04/09/2005, at 23.10, Steve Weintraub wrote:
I've never even encountered this type of keystroke-level undo until TextMate, and I find it slows me down considerably. Please make chunks a preference!
Well it would have to be implemented before it can be made a preference! :-p. It's on TODO I know.
Re: slowdown, I read about something involving the caching, and I did flip a defaults write, so app switching does seem a bit better..but tab-to-tab is really sluggish, and I'm on a dual 2 G5. This is just a text editor, I can't imaging what's happing behind the scenes that causes this.
Well, we are only human. There is a lot of parsing and layout and not to mention text layout (using ATSUI), which is actually quite slow on Mac. TextEdit and NSTextView in general have tons of optimizations in their code to cope with this. TextMate also does a good deal of caching here.
-- Sune.
On Sep 4, 2005, at 6:22 PM, Sune Foldager wrote:
On 04/09/2005, at 23.10, Steve Weintraub wrote:
I've never even encountered this type of keystroke-level undo until TextMate, and I find it slows me down considerably. Please make chunks a preference!
Well it would have to be implemented before it can be made a preference! :-p. It's on TODO I know.
Sorry; I had looked in the archives, and saw first mention of this back in February, so assumed that it had been implemented by now. I hate to belabor this, but from what I've read in the archive, a lot of people are asking for "normal" undo, so I hope its high up on the todo list (if there is an ETA, that would be helpful to share).
Re: slowdown, I read about something involving the caching, and I did flip a defaults write, so app switching does seem a bit better..but tab-to-tab is really sluggish, and I'm on a dual 2 G5. This is just a text editor, I can't imaging what's happing behind the scenes that causes this.
Well, we are only human. There is a lot of parsing and layout and not to mention text layout (using ATSUI), which is actually quite slow on Mac. TextEdit and NSTextView in general have tons of optimizations in their code to cope with this. TextMate also does a good deal of caching here.
HUMAN? How dare you! :) I don't know from ATSUI, but I assume there is a good reason you're using it rather than TextEdit or NSTExtView, given what you indicate are optimization compromises.
As a new user to TextMate (and having been in involved in number of development projects), I can't help but bring the baggage of being used to certain performance, behaviors and expectations from a Mac application, so please forgive if I come off a bit frustrated. It's tough competing in this space, what with the 800 lb. BBedit, and its a testament to the work done thus far that I'm using TextMate a bit more now, if only for the integrated project drawer and code- collapsing features.
btw-- how about making the Language label in the window a drop-down menu to change language on the fly? :)
On 05/09/2005, at 1.37, Steve Weintraub wrote:
Sorry; I had looked in the archives, and saw first mention of this back in February, so assumed that it had been implemented by now. I hate to belabor this, but from what I've read in the archive, a lot of people are asking for "normal" undo, so I hope its high up on the todo list (if there is an ETA, that would be helpful to share).
Just to clarify: I'm not the developer, Allan is... that's why I put "I know" at the end ;-). I'm not sure how high up it is, actually.
Well, we are only human. There is a lot of parsing and layout and not to mention text layout (using ATSUI), which is actually quite slow on Mac. TextEdit and NSTextView in general have tons of optimizations in their code to cope with this. TextMate also does a good deal of caching here.
HUMAN? How dare you! :) I don't know from ATSUI, but I assume there is a good reason you're using it rather than TextEdit or NSTExtView, given what you indicate are optimization compromises.
There are good reasons, I think mainly that NSTextView simply doesn't offer the features TextMate needs (as far as folding and such goes), but again Allan would be better to enumerate the reasons in exact.
As a new user to TextMate (and having been in involved in number of development projects), I can't help but bring the baggage of being used to certain performance, behaviors and expectations from a Mac application, so please forgive if I come off a bit frustrated.
Well, I've been complaining about TM performance from time to time as well, since I have an 'older' 1GHz G4 iMac ;-). It's certainly gotten better, due to more caching and various improvements here and there. I don't know about the rendering, but I think there is room for more peephole tweaks in the syntax system, which was a major slowdown here.
btw-- how about making the Language label in the window a drop-down menu to change language on the fly? :)
This is also on the TODO. General improvements of the status bar with more active elements, I believe :-).
-- Sune.
Ah, the royal "we" :) Thanks for the responses and clarifications.
On Sep 4, 2005, at 7:44 PM, Sune Foldager wrote:
Well, we are only human
Just to clarify: I'm not the developer, Allan is... that's why I put "I know" at the end ;-). I'm not sure how high up it is, actually.
On 05/09/2005, at 1.37, Steve Weintraub wrote:
I don't know from ATSUI, but I assume there is a good reason you're using it rather than TextEdit or NSTExtView, given what you indicate are optimization compromises.
Indeed, there are many. And NSTextView has speed related problems as well, generally much more serious than TM. I did:
% dd 2>/dev/null count=10000 if=/dev/random|xxd|tm
And TM showed the ~20 MB file after ~3 seconds, and I could edit it. TextEdit shows the file instantly, but as soon as I do something, it's busy for ~60s, and resizing the window cause a similar long stall in TextEdit.
As a new user to TextMate (and having been in involved in number of development projects), I can't help but bring the baggage of being used to certain performance, behaviors and expectations from a Mac application, so please forgive if I come off a bit frustrated.
I was pretty frustrated myself when I switched to OS X (over the general sluggishness), and I'm a tad irritated by the many hoops I have to go through, to get decent performance on low-end system (which seems to be most below a 2.5 GHz G5 with AGPx8 ;) ).
But OTOH I've also changed my view on these things, make it work, then make it fast, I think that's what Apple does, and it's a philosophy I've adopted myself -- TM is far more dynamic than any other text editor, and makes much more use of “declarative” rules than code/plugins, and I think that adds tremendous value, despite the overhead these things bring.
As a new user to TextMate (and having been in involved in number of development projects), I can't help but bring the baggage of being used to certain performance, behaviors and expectations from a Mac application, so please forgive if I come off a bit frustrated.
I was pretty frustrated myself when I switched to OS X (over the general sluggishness), and I'm a tad irritated by the many hoops I have to go through, to get decent performance on low-end system (which seems to be most below a 2.5 GHz G5 with AGPx8 ;) ).
But OTOH I've also changed my view on these things, make it work, then make it fast, I think that's what Apple does, and it's a philosophy I've adopted myself -- TM is far more dynamic than any other text editor, and makes much more use of “declarative” rules than code/plugins, and I think that adds tremendous value, despite the overhead these things bring.
Fair enough, but first impressions count for a lot, so I think you want to be careful about *what* you make work first, at the cost of performance :)
In my first post in this thread I asked about command behaviors being tied to languages, not filenames. Could you let me know if my analysis here is accurate, or I'm missing something that would make this work?
Steve
On 05/09/2005, at 13.44, Steve Weintraub wrote:
Fair enough, but first impressions count for a lot, so I think you want to be careful about *what* you make work first, at the cost of performance :)
Ah, I'm past the point in my life where I care about other peoples impressions :)
In my first post in this thread I asked about command behaviors being tied to languages, not filenames. Could you let me know if my analysis here is accurate, or I'm missing something that would make this work?
I'd suggest reading http://macromates.com/blog/archives/2005/07/06/ introduction-to-scopes/
As for comments, the Toggle Comment command in the Source bundle uses two variables (TM_COMMENT_START/END), these variables are set for misc. scopes (in the bundle editor), so even in an HTML file, it will use proper comment markers in the misc. <style>…</style>, <script>…</ script>, <?php … ?>, <% # ruby %> etc. blocks -- and in plain HTML, it'll also work.
This however require that you have the language set to HTML (and not PHP, which would make the scope of the entire file source.php).
I'd suggest reading http://macromates.com/blog/archives/2005/07/06/ introduction-to-scopes/
As for comments, the Toggle Comment command in the Source bundle uses two variables (TM_COMMENT_START/END), these variables are set for misc. scopes (in the bundle editor), so even in an HTML file, it will use proper comment markers in the misc. <style>…</style>,
<script>…</script>, <?php … ?>, <% # ruby %> etc. blocks -- and in
plain HTML, it'll also work.
This however require that you have the language set to HTML (and not PHP, which would make the scope of the entire file source.php).
I've read up on that, thanks. I'm still a bit in the dark here; my file is set to HTML as language, but because the file NAME is ".php", all comments are being made as "#" rather than "<!-- -->", regardless of what the blocks are.
On 05/09/2005, at 16.12, Steve Weintraub wrote:
I've read up on that, thanks. I'm still a bit in the dark here; my file is set to HTML as language, but because the file NAME is ".php", all comments are being made as "#" rather than "<!-- -->", regardless of what the blocks are.
Are you using the Toggle Comment from the Source bundle? or the (deprecated) UnComment bundle from the subversion repository? The latter is tied to filename, which is why the new one exist (and is the one included with TM).
On 5 Sep 2005, at 15:16, Allan Odgaard wrote:
Are you using the Toggle Comment from the Source bundle? or the (deprecated) UnComment bundle from the subversion repository? The latter is tied to filename, which is why the new one exist (and is the one included with TM).
FWIW, that's what I was doing wrong - using M-' to comment stuff out rather than M-/. Thanks. :)
On 05/09/2005, at 16.30, Graeme Mathieson wrote:
Are you using the Toggle Comment from the Source bundle? or the (deprecated) UnComment bundle from the subversion repository? The latter is tied to filename, which is why the new one exist (and is the one included with TM).
FWIW, that's what I was doing wrong - using M-' to comment stuff out rather than M-/. Thanks. :)
I've been wanting to remove the UnComment bundle from svn, but it has more options than the official command, thus my hesitation.
Well Cripes on a cracker, I didn't even know about that command! Thanks!
On Sep 5, 2005, at 10:30 AM, Graeme Mathieson wrote:
On 5 Sep 2005, at 15:16, Allan Odgaard wrote:
Are you using the Toggle Comment from the Source bundle? or the (deprecated) UnComment bundle from the subversion repository? The latter is tied to filename, which is why the new one exist (and is the one included with TM).
FWIW, that's what I was doing wrong - using M-' to comment stuff out rather than M-/. Thanks. :) -- Mail: mathie@woss.name | Web: http://woss.name/ AIM: Math1e | PGP: 1024D/D72F2737
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
I'm using both cmnd-' and cntrl-opt-' and running b17, the "UnComment" command
On Sep 5, 2005, at 10:16 AM, Allan Odgaard wrote:
On 05/09/2005, at 16.12, Steve Weintraub wrote:
I've read up on that, thanks. I'm still a bit in the dark here; my file is set to HTML as language, but because the file NAME is ".php", all comments are being made as "#" rather than "<!-- -->", regardless of what the blocks are.
Are you using the Toggle Comment from the Source bundle? or the (deprecated) UnComment bundle from the subversion repository? The latter is tied to filename, which is why the new one exist (and is the one included with TM).
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 05/09/2005, at 16.12, Steve Weintraub wrote:
I've read up on that, thanks. I'm still a bit in the dark here; my file is set to HTML as language, but because the file NAME is ".php", all comments are being made as "#" rather than "<!-- -->", regardless of what the blocks are.
Weird, it works fine for me; When I am in a HTML file, it uses <!-- --
for comments, and /* */ when under a <? ?> block. With a file
saved as test.php, and I loaded it again fresh to make sure.
-- Sune.
On 05-09-2005 01:37, Steve Weintraub wrote:
btw-- how about making the Language label in the window a drop-down menu to change language on the fly? :)
Most syntaxes are reachable by using a keybaord shortcut: Shift - Ctrl - Option - <first letter of the name>
And if it's not set you can set one of those shortcuts yourself (to any key you like).
Jeroen.
Most syntaxes are reachable by using a keybaord shortcut: Shift - Ctrl - Option - <first letter of the name>
And if it's not set you can set one of those shortcuts yourself (to any key you like).
And isn't it also so that if you assign several things to the same hotkey, it pops up a little menu, so in effect you can create a "syntax selector" menu?
Andreas
All this is true, but a drop-down right in the window is faster (to me anyway) than having to commit to memory YAKS. I was actually surprised it wasn't already under the contextual menu (which seems rather anemic to me). Anyway it's moot, as active elements in the info bar appears to be in the todo pipeline.
On Sep 5, 2005, at 8:02 AM, Andreas Wahlin wrote:
Most syntaxes are reachable by using a keybaord shortcut: Shift - Ctrl - Option - <first letter of the name>
And if it's not set you can set one of those shortcuts yourself (to any key you like).
And isn't it also so that if you assign several things to the same hotkey, it pops up a little menu, so in effect you can create a "syntax selector" menu?
On 04/09/2005, at 23.10, Steve Weintraub wrote:
I can appreciate that's his personal preference, but there's something to be said for being consistent with the OS (particularly when they claim to "bring Apple's approach to operating systems into the world of text editors").
That refers to trying to expose the shell (possibilities) etc. in a GUI editor.
I've never even encountered this type of keystroke-level undo until TextMate, and I find it slows me down considerably. Please make chunks a preference!
It will appear in 1.3 (no exact ETA).
Re: slowdown, I read about something involving the caching, and I did flip a defaults write, so app switching does seem a bit better..but tab-to-tab is really sluggish, and I'm on a dual 2 G5. This is just a text editor, I can't imaging what's happing behind the scenes that causes this.
In b17 tab switching got a lot slower because the scope parser is done using an ANTLR generated parser, and it's used a lot (at least when switching tab, because it needs to match apply styling using the rules set in Fonts & Colors) -- most likely I'll introduce caching for this in b18.
I've never even encountered this type of keystroke-level undo until TextMate, and I find it slows me down considerably. Please make chunks a preference!
It will appear in 1.3 (no exact ETA).
I'm disappointed its two full point releases away, but thanks for being this specific, most devs wouldn't be. In the meanwhile, is there any means of mimicking chunk undo behavior? Perhaps an "undo from history"?
Re: slowdown, I read about something involving the caching, and I did flip a defaults write, so app switching does seem a bit better..but tab-to-tab is really sluggish, and I'm on a dual 2 G5. This is just a text editor, I can't imaging what's happing behind the scenes that causes this.
In b17 tab switching got a lot slower because the scope parser is done using an ANTLR generated parser, and it's used a lot (at least when switching tab, because it needs to match apply styling using the rules set in Fonts & Colors) -- most likely I'll introduce caching for this in b18.
Excellent, thanks.
On 4 Sep 2005, at 21:22, Steve Weintraub wrote:
- The undo behavior. I read an earlier digest that standard OS
"chunk" undos were planned, but I don't see this pref anywhere. Is there a plist command that will turn on chunk undos, and if not, will this feature be coming soon? Having to hit cmnd-z 34 times in a row is tiresome...
FWIW, I'd just like to add a 'me too' for some sort of chunked undo functionality...
- While I can pick the language of a file independent of the
filename, some command behaviors appears to be tied to the filename. For example, I have foo.php which is mostly straight html code, but since the filename is .php, unComment give me php comments, not html. Shouldn't it be possible to have the commands tied to the language choice?
Ah. That might explain why, when editing Zope Page Templates (extension .zpt, which I force to being HTML since they mostly are), trying to comment something out results in it being commented out with '#' at the start of the line, rather than <!-- ... -->, which it does correctly when I'm editing a plain HTML (extension .html) file? Does anybody know of a workaround?
-
Allan Odgaard -
Andreas Wahlin -
Caio Chassot -
Graeme Mathieson -
Jeroen van der Ham -
Steve Weintraub -
Sune Foldager