I've now spent a couple of weekends writing code with TextMate, which is I think enough time to understand its way of working. Some of the things I like most about it come from the language syntax bundles, which are really powerful and flexible. That's a great feature and a real selling point. Typing close characters for me: nice. Auto-completion: nice. C++ class templates: nice. I like the spare look, no stinkin' toolbars cluttering stuff up and distracting from my all-important data.
Love the new tab look in b7. (Maybe a tad darker to set them off more from their background? Eh, maybe not.) Also love the sharp new approach to drawing the selection. Much more readable!
Inevitably, I have suggestions. Users, they're so annoying that way! Most of my suggestions have to do with searching. TextMate doesn't feel quite right, yet.
(I've scanned a bunch of the previous messages to the list, but not enough to be sure these weren't discussed already. Apologies if I'm repeating the past.)
- Keyboard accelerator for "replace and find next". For the love of god, Montresor!
- "Find the selection" action, with keyboard accelerator. (Yes, it can be macroed, but why should I have to macro such an important action?)
- Scroll the text to keep the cursor in the "hot zone" when possible. E.g., if you have to scroll to make the result of a search visible, scroll enough to put the new selection in the middle of the screen. Repeated find-nexts though large files always seem to end up for me with the selection on the bottom-most line, with no context visible. Yuck!
- For extra points, place the selection where it won't be hidden by the Find dialog, which is often covering up the text. (But you're going to add a replace-and-find-next accelerator, so the Find dialog won't be shown so often and this won't matter as much. Right?)
- Bigger fields in the find/replace dialog, please! Try copying some text that spans multiple lines and pasting that into the find field. Hard to deal with, yes?
- Whole word matching option, please, controlled by a checkbox on the find dialog. I often want this without wanting the bother of writing a regular expression every time.
- Multi-file search outside of project groups, please! Minimal implementation searches all the files in a particular directory with optional descent into subdirectories. This is a switch-blocker for me, and I bet it would make lots of other people happy.
More controversially:
You're probably sick of hearing this, but please reconsider adding an app preferences dialog. It will do two things for you:
- It will clear out rarely-changed items that are currently cluttering your menus. - It will make clear which preferences are app-wide, and which ones are settings for the current document. - Bonus: your app will feel more Mac-like than it does now.
Remember, it does me no good to have easy access to stuff I set once, then never ever change again.
As I think about that suggestion and fiddle with things, I begin to realize that TextMate doesn't have per-document settings, and that the appearance of having them is a bug. For instance, open two documents. Turn on text wrapping in one. Note that only the selected document at the time you change the setting is affected. This leads you to believe that wrapping is a document setting. But if you quit TextMate and restart, suddenly all documents are getting text-wrapped. Whoops.
I would suggest that some choices should be saved with the document, as part of its state (cursor position, selection, wrap, font choice, etc). Those settings belong in menus. Consider making anything you expect the user to change often part of the document state. Any setting that affects all documents probably belongs in a preference dialog, tucked out of the way.
I can argue this the other way, that adding document state is more trouble than it's worth. BBEdit does it, and I like it. Soft line wrap in particular is something that I definitely want on some documents and definitely don't want on others. Worth thinking about, anyway.
Boy, I got longwinded. Hope at least some of this is helpful.
Thanks for making such a solid editor, and hope you enjoy that new G5!
--ceej
On Oct 17, 2004, at 8:53 PM, C J Silverio wrote:
- Multi-file search outside of project groups, please! Minimal
implementation searches all the files in a particular directory with optional descent into subdirectories. This is a switch-blocker for me, and I bet it would make lots of other people happy.
On Oct 17, 2004, at 8:53 PM, C J Silverio wrote:
- Multi-file search outside of project groups, please! Minimal implementation searches all the files in a particular directory with optional descent into subdirectories. This is a switch-blocker for me, and I bet it would make lots of other people happy.
The best implementation I've seen of multi-file search was the (old) CodeWarrior IDE search window. You could add arbitrary files to the list of files to be searched by dragging icons from the Finder directly into the list field. The file list was in the main search window, but could be hidden when it wasn't in use. Having everything in one combined search dialog was very handy. Hey, Google found a screenshot:
<http://www.engin.umich.edu/labs/cpc/doc/CodeWarrior/Manuals/ IDE_User_Guide_html/images/IDE060_Find.fm.anc4.gif>
Chris
Since we are taking the find & replace dialog apart :
- If the current selection is only a single line the "search in selection" default doesn't make much sense. Instead it would be nice if it could prefill the search field with the current selection.
On Sun, 17 Oct 2004 21:31:35 -0700, Chris Thomas chris@m-audio.com wrote:
On Oct 17, 2004, at 8:53 PM, C J Silverio wrote:
- Multi-file search outside of project groups, please! Minimal implementation searches all the files in a particular directory with optional descent into subdirectories. This is a switch-blocker for
me, and I bet it would make lots of other people happy.
On Oct 17, 2004, at 8:53 PM, C J Silverio wrote:
- Multi-file search outside of project groups, please! Minimal implementation searches all the files in a particular directory with optional descent into subdirectories. This is a switch-blocker for me, and I bet it would make lots of other people happy.
The best implementation I've seen of multi-file search was the (old) CodeWarrior IDE search window. You could add arbitrary files to the list of files to be searched by dragging icons from the Finder directly into the list field. The file list was in the main search window, but could be hidden when it wasn't in use. Having everything in one combined search dialog was very handy. Hey, Google found a screenshot:
Chris
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/mailman/listinfo/textmate
On 18. Oct 2004, at 6:49, Tobias Luetke wrote:
- If the current selection is only a single line the "search in
selection" default doesn't make much sense.
It's _replace_ in selection (Replace All Scope), so it does *not* affect normal searches. And to me it _does_ make sense. For example when I want to (un)escape stuff in a string.
Instead it would be nice if it could prefill the search field with the current selection.
I get that a lot, but to me that would be rather destructive, and Apple has cmd-e as part of the AHIG to do exactly this thing! It's Edit -> Find -> Use Selection for Find in the menus, and it works in _all_ Cocoa applications (probably also most Carbon), so get used to using it! :) It also works across applications, so you can e.g. press cmd-e in your browser, and then cmd-g in TextMate to find what you'd selected in the browser.
Kind regards Allan
On 18. Oct 2004, at 5:53, C J Silverio wrote:
- Keyboard accelerator for "replace and find next". For the love of god, Montresor!
What is the “standard” key for this? If there is none, I'll probably use cmd-option-f.
- "Find the selection" action, with keyboard accelerator. (Yes, it can be macroed, but why should I have to macro such an important action?)
Seeing how several has expected to find this on cmd-h (which is Hide according to AHIG), it really should be done as a macro!
It's really only grouping cmd-e and cmd-g into one key.
- Scroll the text to keep the cursor in the "hot zone" when possible. E.g., if you have to scroll to make the result of a search visible, scroll enough to put the new selection in the middle of the screen. Repeated find-nexts though large files always seem to end up for me with the selection on the bottom-most line, with no context visible. Yuck!
I choose bottom deliberately, seeing how it's easier to locate, and it always work (i.e. when finding something in the last 20-40 lines, it wouldn't be able to center it.
But I may change it -- visually highlighting the current line may help in that decision.
You're probably sick of hearing this, but please reconsider adding an app preferences dialog. It will do two things for you:
Yes, check the archive if you want a reply.
[...] Soft line wrap in particular is something that I definitely want on some documents and definitely don't want on others. Worth thinking about, anyway.
But generally wouldn't it be better just to have the soft wrap setting stick to the file extension instead of every individual document?
Kind regards Allan
-
Allan Odgaard -
C J Silverio -
Chris Thomas -
jeremy*pinnix -
Tobias Luetke