Hi all,
I was wondering if anyone might be interested in putting together a simple textile bundle? I'm completely snowed under myself or else I'd endeavor to learn this syntax bundling thing myself!
Thanks.
Chris
I made one for myself, but it's really basic: Lots of Textile tags are not closed by an end tag but by two newlines, and I don't think it's possible for now. So, I thought it will be much more easier with the new syntax engine and didn't improved and tested it much.
Still, if some are interested, I can put it in the repository. What I have for now: I made it super-set of html (as Textile), so -highlight of html tags -highlight of all textile tags, plus special colors for headers, links, images, table.
I use redcloth to: pipe thru it to have html preview. make a "replace selected text with html" command. make a "output to html" command.
(You'd have to install RedCloth or another textile script for that.)
And in my "handle every text jobs with TM" crusade, I made a BBCode bundle and, as I couldn't find one, a BBCode parsing script (BabyCloth? ;), to have html preview, etc.
If it's ok for Allan, I'll add them to the repository.
(BTW, Allan, could you add a way to "remember" a few 'pipe through' script in the html preview, I'd like to avoid retyping the full path every time I change the script..)
-- FredB
On 16 mars 05, at 23:00, Chris Messina wrote:
Hi all,
I was wondering if anyone might be interested in putting together a simple textile bundle? I'm completely snowed under myself or else I'd endeavor to learn this syntax bundling thing myself!
Thanks.
Chris
--
Do the evolution. Get Firefox! http://spreadfirefox.com/community/?q=affiliates&id=5&t=4
Quote of the moment: /"Simplicity is in taking the elegant path. It is also a conscious choice— to achieve simplicity one must eschew complexity. Simple things must be simple."/ -- author unknown
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 Mar 16, 2005, at 23:37, Fred B. wrote:
Lots of Textile tags are not closed by an end tag but by two newlines, and I don't think it's possible for now.
Would this be equivalent to having them closed by a blank line? Ideally this should be doable by setting the end-pattern to “^$”, but because of ignoring zero-width matches, it won't work for 1.1b5 though.
[...] If it's ok for Allan, I'll add them to the repository.
Certainly!
(BTW, Allan, could you add a way to "remember" a few 'pipe through' script in the html preview, I'd like to avoid retyping the full path every time I change the script..)
I'll add it to the to-do.
On 17 mars 05, at 01:58, Allan Odgaard wrote:
On Mar 16, 2005, at 23:37, Fred B. wrote:
Lots of Textile tags are not closed by an end tag but by two newlines, and I don't think it's possible for now.
Would this be equivalent to having them closed by a blank line? Ideally this should be doable by setting the end-pattern to “^$”, but because of ignoring zero-width matches, it won't work for 1.1b5 though.
In fact, they are closed by a blank line. Ex: a paragraph starts with "p.", continue on multiple lines and end on a blank line. I tried a lot of things when I made it, then asked you, and you told me it won't work until the new syntax engine, so I forgot about it. I don't write very complex things in Textile anyway and, it's already much easier to write with the bundle as it is now. It's just that a common error in Textile is to forget a newline, and I wanted the highlight to help avoid that. Ex: h1. This is a header p{color:red}. This is still the header, not a paragraph as there is no blank line before. The tag won't even be parsed.
But the html preview came in the meantime and it helps a lot...
[...] If it's ok for Allan, I'll add them to the repository.
Certainly!
Ok, i'll check them first and commit them in a couple of days.
(BTW, Allan, could you add a way to "remember" a few 'pipe through' script in the html preview, I'd like to avoid retyping the full path every time I change the script..)
I'll add it to the to-do.
Sorry to add something on your to-do. It must already be scary as it is. ;) It's just one of the minor things, I notice every time I use it. I have a little list of minor things, tell me when your to-do looks a bit skinny. ;D
-- Fred
OT: Talking about to-do, I asked the VoodooPad dev, August 'Gus' Mueller, to include TM in the available editors, he answered me: "It's on my todo list. Thanks for reporting it though, I'll move it up a notch :)"
On Mar 17, 2005, at 3:18, Fred B. wrote:
[...] a common error in Textile is to forget a newline, and I wanted the highlight to help avoid that. Ex: h1. This is a header p{color:red}. This is still the header, not a paragraph as there is no blank line before. The tag won't even be parsed.
Yes, I can see how that'd be useful. Well, in 1.1b6 you should be able to match it as: begin = "^h1."; end = "^$";
I'll add it to the to-do.
Sorry to add something on your to-do. It must already be scary as it is. ;) It's just one of the minor things, I notice every time I use it. I have a little list of minor things, tell me when your to-do looks a bit skinny. ;D
Yes :) I think 1.2 will be mostly a “polish” release where I focus on details and documentation (and do code re-factoring). Then 1.3 can be where I introduce scripting and plugin interfaces... but this is just what I currently think ;)
Fred B. wrote:
Sorry to add something on your to-do. It must already be scary as it is. ;) It's just one of the minor things, I notice every time I use it. I have a little list of minor things, tell me when your to-do looks a bit skinny. ;D
Speaking of your To Do list... Could this be made into a public Tada List so that you might get fewer repeat requests since we'd all be able to see what's already on your list?
Chris
On Mar 17, 2005, at 3:39, Chris Messina wrote:
Sorry to add something on your to-do. It must already be scary as it is. ;) It's just one of the minor things, I notice every time I use it. I have a little list of minor things, tell me when your to-do looks a bit skinny. ;D
Speaking of your To Do list... Could this be made into a public Tada List so that you might get fewer repeat requests since we'd all be able to see what's already on your list?
I'd need to spend hours converting the document to something that'd work with ta-da lists, and I'd further more have to spend time maintaining a ta-da list in parallel with my own structured document.
So this is not really something I'm motivated to do, and I also doubt it'd cut down on the duplicate requests -- most personal letters I get (with requests) are from people who downloaded TM 10 minutes prior to sending me their feedback ;)
As Mats correctly hinted, if the feature is in most other editors, there's 99% chance it's on my to-do, or at least something that would render the feature redundant.
If Allan wanted to, and it's a text file, he could just cron it to be posted to the web as a text file daily ..
But then he may not, and it may not be.
D
-----Original Message----- From: Allan Odgaard [mailto:allan@macromates.com] Sent: Thursday, 17 March 2005 1:58 PM To: TM Users Subject: [TxMt] Public to-do list for TM (was: Textile Bundle?)
On Mar 17, 2005, at 3:39, Chris Messina wrote:
Sorry to add something on your to-do. It must already be scary as it is. ;) It's just one of the minor things, I notice every time I use it. I have a little list of minor things, tell me when your to-do looks a bit skinny. ;D
Speaking of your To Do list... Could this be made into a public Tada List so that you might get fewer repeat requests since we'd all be able to see what's already on your list?
I'd need to spend hours converting the document to something that'd work with ta-da lists, and I'd further more have to spend time maintaining a ta-da list in parallel with my own structured document.
So this is not really something I'm motivated to do, and I also doubt it'd cut down on the duplicate requests -- most personal letters I get (with requests) are from people who downloaded TM 10 minutes prior to sending me their feedback ;)
As Mats correctly hinted, if the feature is in most other editors, there's 99% chance it's on my to-do, or at least something that would render the feature redundant.
______________________________________________________________________ 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 Mar 17, 2005, at 4:47, David Lee wrote:
If Allan wanted to, and it's a text file, he could just cron it to be posted to the web as a text file daily ..
But then he may not, and it may not be.
It is a text file -- though there is a few sensitive things in it, and also, it's written in “my” language, so I don't know if people would actually understand half of it, which may just lead to having to answer a lot of questions ;)
I work in open source software (CivicSpaceLabs.org and SpreadFirefox.com) so I'm sort of used to working in the open.
So much of TextMate development seem to be helped by the work on contributors that you've struck a very interesting balance of closed development with open-source attributes.
Maintaining a public to do list would be very nice for the rest of us trying to peek over your shoulder, but I understand that practicalities may make it more of a chore than it's worth.
Thought I'd suggest it anyway. :1
Chris
Allan Odgaard wrote:
On Mar 17, 2005, at 4:47, David Lee wrote:
If Allan wanted to, and it's a text file, he could just cron it to be posted to the web as a text file daily ..
But then he may not, and it may not be.
It is a text file -- though there is a few sensitive things in it, and also, it's written in “my” language, so I don't know if people would actually understand half of it, which may just lead to having to answer a lot of questions ;)
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 17 Mar 2005, at 04:00, Chris Messina wrote:
I work in open source software (CivicSpaceLabs.org and SpreadFirefox.com) so I'm sort of used to working in the open. So much of TextMate development seem to be helped by the work on contributors that you've struck a very interesting balance of closed development with open-source attributes.
You make a very valid and interesting point there Chris. Although perhaps not new as such, Allan's working methods and the community around TM, is what has made TM a much improved app, my experience working with the app very pleasant and a faithful user out of me. In many ways, this is the way that all software developers (here's looking at you Apple et al) should work. I wonder if Allan's studies in Psychology has been instrumental to this, or whether it is just something that has grown organically ??
Maintaining a public to do list would be very nice for the rest of us trying to peek over your shoulder, but I understand that practicalities may make it more of a chore than it's worth.
Not sure how much Allan is concerned about the competition, but I guess that's one important practicality too. Why show the competition what you're planning to do ??
On 17 Mar 2005, at 02:58, Allan Odgaard wrote:
As Mats correctly hinted, if the feature is in most other editors, there's 99% chance it's on my to-do, or at least something that would render the feature redundant.
Yippie, I correctly hinted at something. There's obviously a first time for everything in life ;-)
Kind regards,
Mats
---- "TextMate, coding with an incredible sense of joy and ease" - www.macromates.com -
On Mar 17, 2005, at 11:12, Mats Persson wrote:
[...] I wonder if Allan's studies in Psychology has been instrumental to this, or whether it is just something that has grown organically ??
hehe... I might be smart, but I'm definitely not that smart ;)
Maintaining a public to do list would be very nice for the rest of us trying to peek over your shoulder, but I understand that practicalities may make it more of a chore than it's worth.
Not sure how much Allan is concerned about the competition, but I guess that's one important practicality too. Why show the competition what you're planning to do ??
Competition??? oh.. the rock stars over at BareBones ;)
Not too concerned about that ;) there are a few situations where secrecy is required (when you're in direct competition with a product similar to your own, and the developers have plenty of resources) or an advantage (when you want the press to go into wild speculations about what you're creating, because you need media attention).
Neither of this is really my situation, though another concern is that at times you are likely to get ahead of yourself when speaking of planned features, and if you delay or cut (already “announced”) features, you're likely to disappoint some -- and the picture users paint of you is rarely objective, and disappointment is never an advantage!
But for me currently, I only see being as open as possible as a competitive advantage, and I guess it's just in my nature ;)
When I said sensitive information with regard to the to-do I was thinking of personal info, like email addresses (which I do often keep for suggestions) or when I have pasted text verbatim (I do mostly consider private mails private).
Though my main concerns are still 1) the time spent maintaining a public to-do and 2) receiving questions about the items on (or missing from) the to-do (I just removed the two public to-dos from macromates.com because these alone generated too many questions).
And then there is the fact that this to-do is really not very interesting ;) I don't write detailed descriptions of what I plan, only brief reminders for the things I may otherwise forget. E.g. redoing the project drawer doesn't appear on the list, even though I have a lot of cool ideas for that ;)
On 18 Mar 2005, at 03:12, Allan Odgaard wrote:
[...] I wonder if Allan's studies in Psychology has been instrumental to this, or whether it is just something that has grown organically ??
hehe... I might be smart, but I'm definitely not that smart ;)
hmm... If your followers believe that you can walk on water, I think the general idea is to NOT dispel those beliefs. Seemed to work quite well for JC ;-) (not intending to offend anyone's religious beliefs here, so peace be with you all)
Competition??? oh.. the rock stars over at BareBones ;)
Yeah, I heard about them once. They were pretty big around the time of The Beatles weren't they ?? Not seen much good come out of them lately ;-)
Kind regards,
Mats
---- "TextMate, coding with an incredible sense of joy and ease" - www.macromates.com -
Mats Persson wrote:
Competition??? oh.. the rock stars over at BareBones ;)
Yeah, I heard about them once. They were pretty big around the time of The Beatles weren't they ?? Not seen much good come out of them lately
OK. I've declined to respond to a few of these already. So what follows is not intended as a specific response to Mats' levity above...
There is a great deal to praise about TextMate, Allan and the community, but do we need to sour it with continual jibes at Bare Bones ? Despite licensing TextMate and enjoying using it, I'm still a BBEdit fan and user and a Mailsmith fan and user and I can't be bothered with this moronicity.
Bare Bones Software is a dedicated Mac software developer with a very well earned standing in the community. As a long standing user of BBEdit and Mailsmith and a long standing subscriber to all of Bare Bones mailing lists, I can say that many of the policy jibes I've read here about Bare Bones are not true. That they are far less open than Allan and co is true. That they don't listen to users, don't ever announce planned features and haven't added anything significant to their products in an age is bullshit.
TextMate is the best new mac only editor to arrive since BBEdit. TextMate kicks BBEdits ass in some ways. BBEdit kicks TextMate's ass in others. This will remain the case if we are lucky enough to continue to have two excellent editors on the platform.
Can we drop this now and focus on TextMate ? (That's how it works on the BBEdit lists.)
mark.
On Mar 18, 2005, at 11:59, Mark Smith wrote:
Can we drop this now and focus on TextMate ? (That's how it works on the BBEdit lists.)
In all fairness, they may not make such comments on their lists, but they do make them in public, like: “we have observed the crowding of the landscape with products which don't meet our standards for quality and thoughtfulness” or “these overnight text editors don't reflect well on the genre or the platform” -- this combined with a radio interview I heard is what have made me think of them as spoiled rock stars (hence my reference).
Please take such comments with a grain of salt, like with any other comments sent to this list which doesn't meet your standards for good behavior -- there are hundreds of subscribers from different countries and cultures, not all share the same view of what's appropriate.
Seeing how TextMate is a magnet for disgruntled BBEdit users, I think the occasional reference is unavoidable, similar to how you'll also find an occasional Microsoft bashing on most Apple lists -- but this really isn't what dominates this list, I have 3513 messages stored, only a handful mentions the other company.
Hi Allan,
Well, this is going down precisely the street that I hoped it wouldn't and I'm probably going to get hammered for starting it, so I'll answer this first batch of three (yours first since you are the boss) and then quietly withdraw from the topic.
My point was not to make some counterpoint to TextMate's progress by sticking up for BBEdit and/or Bare Bones.
Rather, I hope that this excellent resource can free itself from continual snide comments about BBEdit and Bare Bones. It doesn't reflect well.
If BBEdit were perfect, TextMate would have no chance. If BBEdit and/or Bare Bones were lousy Bare Bones would have become extinct. I am happy living in the reality that is somewhere in between.
Allan Odgaard wrote:
On Mar 18, 2005, at 11:59, Mark Smith wrote:
Can we drop this now and focus on TextMate ? (That's how it works on the BBEdit lists.)
In all fairness, they may not make such comments on their lists, but they do make them in public, like: “we have observed the crowding of the landscape with products which don't meet our standards for quality and thoughtfulness” or “these overnight text editors don't reflect well on the genre or the platform” -- this combined with a radio interview I heard is what have made me think of them as spoiled rock stars (hence my reference).
Well, TextMate excepted, this comment about mac editors is generally true. The only exceptions I can think of are JEdit (with the usual Java baggage) and Pepper (which fizzled out). You might say that a commercial developer shouldn't be having a go at small independent shareware or freeware efforts, but it happend to be the case that several new editors on the block had started throwing stones at BBEdit even before they get out the starting blocks and ended up festering and forgotten. TextMate's launch included some friendly and subtle anti-BBEdit references too. No problem there, but at the same time, one can't complain if the Ogre then has a go at swatting a fly. In any case, the precise comments you refer to were from Rich Siegel and refer to the rationale for making Text Wrangler free.
Bare Bones as a whole are characterized by a conservative approach to development. Show me a single mature product which is not conservative and remains successful. Allan will inevitably become more conservative with TextMate as it improves and matures. His astronomical progress rate cannot be maintained indefinitely. It is simply ridiculous to compare the current rates of change of the two products.
I do not wish to become the lists BBEdit fan boy. If I were 100% satisfied with Bare Bones and BBEdit, I wouldn't be here. On the other hand, I'm realistic enough to realize that both Allan *and* Bare Bones can count themselves amongst the absolute cream of MacOS X developmers despite the broad differences in approach.
Please take such comments with a grain of salt, like with any other comments sent to this list which doesn't meet your standards for good behavior -- there are hundreds of subscribers from different countries and cultures, not all share the same view of what's appropriate.
Sure. Its not as though I've got unusual standards. A bit of friendly banter is one thing, but I think that disgruntled BBEdit users and Bare Bones hate mail will turn into an albatross for you sooner or later if you let it become a dominant aspect of the community. It will also make it a less interesting and useful place.
Seeing how TextMate is a magnet for disgruntled BBEdit users, I think the occasional reference is unavoidable, similar to how you'll also find an occasional Microsoft bashing on most Apple lists -- but this really isn't what dominates this list, I have 3513 messages stored, only a handful mentions the other company.
Half a dozen already in the last few days and always of the same general form. "Try asking Bare Bones for a feature and see what you get" etc.
It appeared to be on the rise, hence my post. Sorry if it was either unnecessary and/or inappropriate.
mark.
At 5:23 PM +0100 3/18/05, Mark Smith wrote:
Well, TextMate excepted, this comment about mac editors is generally true. The only exceptions I can think of are JEdit (with the usual Java baggage) and Pepper (which fizzled out).
Pepper was great until the developer sort of had a nuclear meltdown. Luckily I got to re-use the Alpha also in its OS9 days was really happening.
And don't forget Subethedit... that's the one other text editor I still use, due to the networking thing. But sometimes I cheat and use TM services to edit in there.
TM has a nice little community around it and a responsive and talented developer. As long as we don't let it go to our heads, we can keep borrowing and improving on the cool things from other editors...
- Eric
On Mar 18, 2005, at 3:59 AM, Mark Smith wrote:
That they don't listen to users, don't ever announce planned features and haven't added anything significant to their products in an age is bullshit.
Really? when was the last time they added anything significant to Mailsmith? I'm not even sure there were any significant additions with the 2.0 release... Have they even hinted that they might even be considering thinking about looking at adding IMAP support yet? I don't really know about the second one, as I stopped reading that mailing list when it became obvious IMAP support wasn't coming anytime soon (and that they weren't planning on dropping that horrible database they use for their mailstore).
Anyway, that's neither here nor there. Suffice it to say that the Bare Bones public interface model has left me with a very bad taste in my mouth, and resulted in them losing me as a customer. At the same time I find Allan's style much more to my liking. Now if he would just get to work on making TextMate fix my code for me as I'm typing it in...
William D. Neumann
"You've got Rita Marlowe in the palm of your hand." "Palm of my hand? You haven't seen Rita Marlowe..."
-- Will Success Spoil Rock Hunter?
William D.Neumann wrote:
Really? when was the last time they added anything significant to Mailsmith? I'm not even sure there were any significant additions with the 2.0 release...
Depends what you consider significant. There has been a steady stream of feature additions whilst admittedly some of the big wished for features have not appeared. I am frustrated by the lack of IMAP support and the lack of the ability to save the otherwise unparalleled searches.
Have they even hinted that they might even be considering thinking about looking at adding IMAP support yet?
Yes, it is officially acknowledged as a planned feature. As are saved queries. My guess (and it is a guess) is that a mahor rewrite of Mailsmith is underway and that the next big release (probably post Tiger) will contain both IMAP support *and* savable queries, possibly in a smart-mailbox analog.
I don't really know about the second one, as I stopped reading that mailing list when it became obvious IMAP support wasn't coming anytime soon (and that they weren't planning on dropping that horrible database they use for their mailstore).
The mailstore aspect is interesting. I'd like to know of a better model. Mbox and maildir have their own issues and on their own don't offer anything like Mailsmith's "metadata" possibilities. Both also start to get troublesome with very large numbers of messages. With the advent of spotlight indexing, it *may* be conceivable for Bare Bones to change the message storage model for Mailsmith, we will see.
Anyway, that's neither here nor there. Suffice it to say that the Bare Bones public interface model has left me with a very bad taste in my mouth, and resulted in them losing me as a customer. At the same time I find Allan's style much more to my liking. Now if he would just get to work on making TextMate fix my code for me as I'm typing it in...
I also like Allan's approach and take my hat off to him for the effort he is putting in. No question. At the same time, I have been treated superbly as a Bare Bones customer. Several support issue have been handled impeccably. All of my mail to support in the areas of feature requests and suggestions have been handled politely and effectively and some have produced results.
It *is* true that on the lists, some Bare Bones staff can be sarcastic or impatient with certain types of post, and I can understand that e.g. Rich's style will rub some folks up the wrong way, but this doesn't seem to me like a reason to publicly whine about the company. They have a veritable army of very satisfied and loyal customers.
OK. Enough from me already. I'm going to focus on TextMate from now on and ignore the Bare Bones jibes.
I may be looking for help with a module for "ConTeXt per XeTeX" soon, hopefully my even-handed treatment of Bare Bones won't preclude me from getting any.
mark.
On 18 Mar 2005, at 10:59, Mark Smith wrote:
OK. I've declined to respond to a few of these already. So what follows is not intended as a specific response to Mats' levity above...
Well, since my levity 'made the cup runneth over' so to speak, I have to respond to Mark's points.
There is a great deal to praise about TextMate, Allan and the community, but do we need to sour it with continual jibes at Bare Bones ?
True praise generally comes from doing the right or good things. Jibes (= negative comments) generally comes from doing bad or the wrong things. Sometimes they are deserved, sometimes they are not.
I can't be bothered with this moronicity.
Hmm, I obviously must have missed some things that you've read Mark, as this "moronicity" has completely passed me by. I'll ignore the "moronicity" 'word' as a badly chosen word, rather than anything else. ;-)
Bare Bones Software is a dedicated Mac software developer with a very well earned standing in the community. As a long standing user of BBEdit and Mailsmith and a long standing subscriber to all of Bare Bones mailing lists, I can say that many of the policy jibes I've read here about Bare Bones are not true.
Yes, BB is (has been??) a respected Mac app developer. I've paid for and used BBEdit since '98/'99 including BBEdit 8.0.x, so I think I have an absolute right to express my views of the company/product.
Perhaps, you can point out just a few of the 'continual' jibes that are unjustified in your mind ??
That they don't listen to users, don't ever announce planned features and haven't added anything significant to their products in an age is bullshit.
Mark, I like the blending of several different aspect in that sentence. But let's address each point:
1. ...don't listen to users: As outsiders we can only hope that they listen to their users, but we can only see/judge their response to our own proposals.
As you can research on this list, I have been proposing a few ideas here and there (I try my best to keep them to a minimum :) ) and as a BBEdit user I have proposed as many or more to BB over the years, to not see a single thing end up in the app. Most of the things I suggested are present in TM, so they can't all have been bad!! (IF I feel bothered, and need to, I can probably trawl old CD's, e-mail backups for the e-mails to prove that !!)
To give you a simple and very telling example please read the following post: [ http://www.listsearch.com/BBEditTalk.lasso?id=17218 ] It's a simple proposal that I made publicly in September last year, and as far as I can see there has not been a single bit of that implemented anywhere in BBEdit. I - and others - have asked for far more from Allan (a single developer vs 4+ dev's) since September, and he has implemented, or is working on most of those requests/features. Most of which seem - in my layman's point-of-view - far more demanding than taking the existing Glossary palette window in BBEdit and adding it to the drawer, which is just one of my points. Please correct me if I'm wrong on that point anyone ??
2. ...don't ever announce planned features = bs Please show me where BB announces their planned features?? I've never seen that part before !!! And while you're at it, please show me where anyone on this list has complained about BB's lack of announcements ???
3. ...added anything significant... I can't recall anyone on this list ever saying that they haven't added anything significant, they obviously must have. However, these additions has never been to the true benefit of my work style and workflow, in contrast to Allan's improvements to TM.
TextMate is the best new mac only editor to arrive since BBEdit. TextMate kicks BBEdits ass in some ways. BBEdit kicks TextMate's ass in others. This will remain the case if we are lucky enough to continue to have two excellent editors on the platform.
Yes, the Mac (=OS X) has more editors than ever before, and most of them kick BBEdit's ass in so many different areas. Something we should be happy and grateful for.
However, the single important point to focus on here though, is this one. (Business 101 coming up)
When you are successful, and/or the market leader in your niche market, it is way too easy to become big headed, complacent and so on. It is a problem that affects every single company/organisation/country eventually. It has affected Apple, M$, many countries/empires in history and countless more examples, so I'm not singling out BareBones here.
Just sit back, and ask yourself this very simple question, IF BBEdit was so damn good, and catered so well to every single need of its users, would there be a market for TM, skEdit, SubEthaEdit ???? Just mentioning three great and small apps that has started up since the release of OS X, all of them produced by much smaller companies/numbers of developers than BBEdit. Now IF all three of those new apps, can implement easy USER changeable syntax highlighting, on top of all the other work required to build a editor, then why the hell can't BB do that ?? Are BB incompetent ?? No, either they have not been bothered, or alternatively, just focused on the wrong type of things !!!
Another point. The next time an app crashes, copy the CrashLog and paste it into new TM & BBEdit doc's and then begin typing some extra text into the top of the doc. TM handles this without problems, BBEdit is barely usable with serious lag time. (Using iMac G5 with 1.25 GB RAM)
There you have just two simple examples. Do I wish for BB to disappear ??? No, I want them to wake up, smell the coffee and start working to keep Allan and other developers on top form. That's what's good for all of us, and that's what is good for OS X as a platform.
Can we drop this now and focus on TextMate ? (That's how it works on the BBEdit lists.)
In my opinion the focus has always and exclusively been on TM, and never ever on any other app. The only times some other app - like BBEdit - has been mentioned, is in a qualified reference/point. If that statement is wrong, I trust that I will be corrected real soon.
Finally, in order to clarify things fully:
On 18 Mar 2005, at 10:29, Mats Persson wrote to Allan's comment:
Competition??? oh.. the rock stars over at BareBones ;)
Yeah, I heard about them once. They were pretty big around the time of The Beatles weren't they ?? Not seen much good come out of them lately ;-)
The above quote(s) was intended as light entertainment - also know as lame jokes (mine at least, not yours Allan). The big clue to that is the smilies at the end of the sentence. ;-)
Peace be with you all, and have a nice weekend away from the computers !
Kind regards,
Mats
---- "TextMate, coding with an incredible sense of joy and ease" - www.macromates.com -
Mats Persson wrote:
Well, since my levity 'made the cup runneth over' so to speak, I have to respond to Mark's points.
Indeed, fair is fair.
Hmm, I obviously must have missed some things that you've read Mark, as this "moronicity" has completely passed me by. I'll ignore the "moronicity" 'word' as a badly chosen word, rather than anything else. ;-)
I would argue that it is somewhat moronic to project the notion that if you ask for a feature from Bare Bones, you won't get it and you might have to take some abuse for asking, whereas here in TextMate land, you can have whatever you want, as soon as you want and that this can be carried on into perpetuity.
However, I will allow that it was not a particularly well chosen word.
Yes, BB is (has been??) a respected Mac app developer. I've paid for and used BBEdit since '98/'99 including BBEdit 8.0.x, so I think I have an absolute right to express my views of the company/product.
As has everybody.
Perhaps, you can point out just a few of the 'continual' jibes that are unjustified in your mind ??
In the last week, I noticed several. Yesterday I had also prepared a reply to a post by William Neumann in the split panes thread, but then thought again and didn't post it, because I thought this will blow over. When two more such posts arrived soon after, it seemed like it was fair enough to go ahead and say my small piece. Might have been a bad call.
That they don't listen to users, don't ever announce planned features and haven't added anything significant to their products in an age is bullshit.
Mark, I like the blending of several different aspect in that sentence. But let's address each point:
...don't listen to users:As outsiders we can only hope that they listen to their users, but we can only see/judge their response to our own proposals.
Which in my experience have been exemplary.
As you can research on this list, I have been proposing a few ideas here and there (I try my best to keep them to a minimum :) ) and as a BBEdit user I have proposed as many or more to BB over the years, to not see a single thing end up in the app. Most of the things I suggested are present in TM, so they can't all have been bad!! (IF I feel bothered, and need to, I can probably trawl old CD's, e-mail backups for the e-mails to prove that !!)
But you will concede I hope that it is normal to have a significant influence in the direction of a fledgling app, but little in the direction of a mature app ? That is the main difference in this case.
To give you a simple and very telling example please read the following post: [ http://www.listsearch.com/BBEditTalk.lasso?id=17218 ] It's a simple proposal that I made publicly in September last year, and as far as I can see there has not been a single bit of that implemented anywhere in BBEdit. I - and others - have asked for far more from Allan (a single developer vs 4+ dev's) since September, and he has implemented, or is working on most of those requests/features. Most of which seem - in my layman's point-of-view - far more demanding than taking the existing Glossary palette window in BBEdit and adding it to the drawer, which is just one of my points. Please correct me if I'm wrong on that point anyone ??
...Ditto.
...don't ever announce planned features = bsPlease show me where BB announces their planned features?? I've never seen that part before !!! And while you're at it, please show me where anyone on this list has complained about BB's lack of announcements ???
I won't resort to searching the archive and naming names unless I must, but I have seen several posts of this nature in the last couple of weeks. Honestly.
Bare Bones have, for example announced that Subversion support is planned as a priority feature addition for BBEdit. A long time back, SFTP was announced as a priority feature addition. IMAP support and savable queries have been announced as planned features for Mailsmith and these are just off the top of my head.
- ...added anything significant...
I can't recall anyone on this list ever saying that they haven't added anything significant, they obviously must have. However, these additions has never been to the true benefit of my work style and workflow, in contrast to Allan's improvements to TM.
Two posts with precisely that allegation in the last two days actually.
TextMate is the best new mac only editor to arrive since BBEdit. TextMate kicks BBEdits ass in some ways. BBEdit kicks TextMate's ass in others. This will remain the case if we are lucky enough to continue to have two excellent editors on the platform.
Yes, the Mac (=OS X) has more editors than ever before, and most of them kick BBEdit's ass in so many different areas. Something we should be happy and grateful for.
However, the single important point to focus on here though, is this one. (Business 101 coming up)
When you are successful, and/or the market leader in your niche market, it is way too easy to become big headed, complacent and so on. It is a problem that affects every single company/organisation/country eventually. It has affected Apple, M$, many countries/empires in history and countless more examples, so I'm not singling out BareBones here.
Just sit back, and ask yourself this very simple question, IF BBEdit was so damn good, and catered so well to every single need of its users, would there be a market for TM, skEdit, SubEthaEdit ???? Just mentioning three great and small apps that has started up since the release of OS X, all of them produced by much smaller companies/numbers of developers than BBEdit. Now IF all three of those new apps, can implement easy USER changeable syntax highlighting, on top of all the other work required to build a editor, then why the hell can't BB do that ?? Are BB incompetent ?? No, either they have not been bothered, or alternatively, just focused on the wrong type of things !!!
Just focussed on things that were not considered important for a subset of their users you mean ? A lot of this has to do with the fact that BBEdit is a mature product and its not so easy and certainly not so clever to just start a bolt-on approach to feature addition. Thats the win32 way and we all know what that leads too. So, its inevitable that a user, or group of users will find a haven in a fledgling editor where they will get a better return on feature requests for two big reasons:
1. They are automatically a more significant proportion of the over all user base
2. Its easier for the developer to influence the direction of their app at an early stage.
To take your example of user editable syntax highlighting, this has been introduced with BBEdit 8 and I imagine that the CLM features will expand until the C-based plugins become obsolete. Sure Allan is currently kicking their ass in this areas. Good on him. Its not though, in my opinion, a robust ground on which to accuse Bare Bones of laziness and arrogance.
Do you suppose that Allan would be so agile if he were working in C with private carbon frameworks on an app as mature, feature rich and with such a complex Apple Events model as BBEdit ?
Another point. The next time an app crashes, copy the CrashLog and paste it into new TM & BBEdit doc's and then begin typing some extra text into the top of the doc. TM handles this without problems, BBEdit is barely usable with serious lag time. (Using iMac G5 with 1.25 GB RAM)
? Yes. Its not really relevant to the (or at least *my*) argument though is it ?
There you have just two simple examples. Do I wish for BB to disappear ??? No, I want them to wake up, smell the coffee and start working to keep Allan and other developers on top form. That's what's good for all of us, and that's what is good for OS X as a platform.
Sure. You can be sure that BBEdit are aware of Allan and TextMate and maybe even concerned for the first time since Pepper got up a head of steam. I hope that this will be a positive catalyst for both. *If* anti-Bare Bones sentiments turn out to be a significant component of the TextMate community in the mid-term though, it may be that the shoe will end up on the other foot. I hope not. I hope we can throw that shoe away altogether.
In my opinion the focus has always and exclusively been on TM, and never ever on any other app. The only times some other app - like BBEdit - has been mentioned, is in a qualified reference/point. If that statement is wrong, I trust that I will be corrected real soon.
Fine. It was probably a mistake for me to comment, but as I mention, there have been a number of posts in the last couple of weeks of this "flavour". Maybe more seasoned community members don't notice them so much or maybe the longer in the tooth TextMate users are those who are least satisfied with TextMate ? If the latter is the case, its guys like me that Allan will need to be recruiting as of now...
In any case, I said I'd answer the first batch. I've done that now, so I withdraw with an apology for straying off topic and an additional one for anybody that I riled with my comments.
mark.
Excuse me for getting the way of ... whatever's bewing here
I'm curious about BBedit (having never really used it), becuase it was the One True Mac Editor. and becuase it costs so much.
What are its best features, all you ex- or bipolar BBedit users? Anything unique that you really miss in Textmate?
Also feel free to mention things about it which TextMate has done better or done away with the need for with a clever design approach etc?
Just curious,
D
On 19/03/2005, at 4:15 AM, Mark Smith wrote:
Mats Persson wrote:
Well, since my levity 'made the cup runneth over' so to speak, I have to respond to Mark's points.
Indeed, fair is fair.
Hmm, I obviously must have missed some things that you've read Mark, as this "moronicity" has completely passed me by. I'll ignore the "moronicity" 'word' as a badly chosen word, rather than anything else. ;-)
I would argue that it is somewhat moronic to project the notion that if you ask for a feature from Bare Bones, you won't get it and you might have to take some abuse for asking, whereas here in TextMate land, you can have whatever you want, as soon as you want and that this can be carried on into perpetuity.
However, I will allow that it was not a particularly well chosen word.
Yes, BB is (has been??) a respected Mac app developer. I've paid for and used BBEdit since '98/'99 including BBEdit 8.0.x, so I think I have an absolute right to express my views of the company/product.
As has everybody.
Perhaps, you can point out just a few of the 'continual' jibes that are unjustified in your mind ??
In the last week, I noticed several. Yesterday I had also prepared a reply to a post by William Neumann in the split panes thread, but then thought again and didn't post it, because I thought this will blow over. When two more such posts arrived soon after, it seemed like it was fair enough to go ahead and say my small piece. Might have been a bad call.
That they don't listen to users, don't ever announce planned features and haven't added anything significant to their products in an age is bullshit.
Mark, I like the blending of several different aspect in that sentence. But let's address each point:
...don't listen to users:As outsiders we can only hope that they listen to their users, but we can only see/judge their response to our own proposals.
Which in my experience have been exemplary.
As you can research on this list, I have been proposing a few ideas here and there (I try my best to keep them to a minimum :) ) and as a BBEdit user I have proposed as many or more to BB over the years, to not see a single thing end up in the app. Most of the things I suggested are present in TM, so they can't all have been bad!! (IF I feel bothered, and need to, I can probably trawl old CD's, e-mail backups for the e-mails to prove that !!)
But you will concede I hope that it is normal to have a significant influence in the direction of a fledgling app, but little in the direction of a mature app ? That is the main difference in this case.
To give you a simple and very telling example please read the following post: [ http://www.listsearch.com/BBEditTalk.lasso?id=17218 ] It's a simple proposal that I made publicly in September last year, and as far as I can see there has not been a single bit of that implemented anywhere in BBEdit. I - and others - have asked for far more from Allan (a single developer vs 4+ dev's) since September, and he has implemented, or is working on most of those requests/features. Most of which seem - in my layman's point-of-view - far more demanding than taking the existing Glossary palette window in BBEdit and adding it to the drawer, which is just one of my points. Please correct me if I'm wrong on that point anyone ??
...Ditto.
...don't ever announce planned features = bsPlease show me where BB announces their planned features?? I've never seen that part before !!! And while you're at it, please show me where anyone on this list has complained about BB's lack of announcements ???
I won't resort to searching the archive and naming names unless I must, but I have seen several posts of this nature in the last couple of weeks. Honestly.
Bare Bones have, for example announced that Subversion support is planned as a priority feature addition for BBEdit. A long time back, SFTP was announced as a priority feature addition. IMAP support and savable queries have been announced as planned features for Mailsmith and these are just off the top of my head.
- ...added anything significant...
I can't recall anyone on this list ever saying that they haven't added anything significant, they obviously must have. However, these additions has never been to the true benefit of my work style and workflow, in contrast to Allan's improvements to TM.
Two posts with precisely that allegation in the last two days actually.
TextMate is the best new mac only editor to arrive since BBEdit. TextMate kicks BBEdits ass in some ways. BBEdit kicks TextMate's ass in others. This will remain the case if we are lucky enough to continue to have two excellent editors on the platform.
Yes, the Mac (=OS X) has more editors than ever before, and most of them kick BBEdit's ass in so many different areas. Something we should be happy and grateful for.
However, the single important point to focus on here though, is this one. (Business 101 coming up)
When you are successful, and/or the market leader in your niche market, it is way too easy to become big headed, complacent and so on. It is a problem that affects every single company/organisation/country eventually. It has affected Apple, M$, many countries/empires in history and countless more examples, so I'm not singling out BareBones here.
Just sit back, and ask yourself this very simple question, IF BBEdit was so damn good, and catered so well to every single need of its users, would there be a market for TM, skEdit, SubEthaEdit ???? Just mentioning three great and small apps that has started up since the release of OS X, all of them produced by much smaller companies/numbers of developers than BBEdit. Now IF all three of those new apps, can implement easy USER changeable syntax highlighting, on top of all the other work required to build a editor, then why the hell can't BB do that ?? Are BB incompetent ?? No, either they have not been bothered, or alternatively, just focused on the wrong type of things !!!
Just focussed on things that were not considered important for a subset of their users you mean ? A lot of this has to do with the fact that BBEdit is a mature product and its not so easy and certainly not so clever to just start a bolt-on approach to feature addition. Thats the win32 way and we all know what that leads too. So, its inevitable that a user, or group of users will find a haven in a fledgling editor where they will get a better return on feature requests for two big reasons:
1. They are automatically a more significant proportion of theover all user base
2. Its easier for the developer to influence the direction oftheir app at an early stage.
To take your example of user editable syntax highlighting, this has been introduced with BBEdit 8 and I imagine that the CLM features will expand until the C-based plugins become obsolete. Sure Allan is currently kicking their ass in this areas. Good on him. Its not though, in my opinion, a robust ground on which to accuse Bare Bones of laziness and arrogance.
Do you suppose that Allan would be so agile if he were working in C with private carbon frameworks on an app as mature, feature rich and with such a complex Apple Events model as BBEdit ?
Another point. The next time an app crashes, copy the CrashLog and paste it into new TM & BBEdit doc's and then begin typing some extra text into the top of the doc. TM handles this without problems, BBEdit is barely usable with serious lag time. (Using iMac G5 with 1.25 GB RAM)
? Yes. Its not really relevant to the (or at least *my*) argument though is it ?
There you have just two simple examples. Do I wish for BB to disappear ??? No, I want them to wake up, smell the coffee and start working to keep Allan and other developers on top form. That's what's good for all of us, and that's what is good for OS X as a platform.
Sure. You can be sure that BBEdit are aware of Allan and TextMate and maybe even concerned for the first time since Pepper got up a head of steam. I hope that this will be a positive catalyst for both. *If* anti-Bare Bones sentiments turn out to be a significant component of the TextMate community in the mid-term though, it may be that the shoe will end up on the other foot. I hope not. I hope we can throw that shoe away altogether.
In my opinion the focus has always and exclusively been on TM, and never ever on any other app. The only times some other app - like BBEdit - has been mentioned, is in a qualified reference/point. If that statement is wrong, I trust that I will be corrected real soon.
Fine. It was probably a mistake for me to comment, but as I mention, there have been a number of posts in the last couple of weeks of this "flavour". Maybe more seasoned community members don't notice them so much or maybe the longer in the tooth TextMate users are those who are least satisfied with TextMate ? If the latter is the case, its guys like me that Allan will need to be recruiting as of now...
In any case, I said I'd answer the first batch. I've done that now, so I withdraw with an apology for straying off topic and an additional one for anybody that I riled with my comments.
mark. ______________________________________________________________________ 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 Mar 18, 2005, at 3:51 PM, David Lee wrote:
I'm curious about BBedit (having never really used it), becuase it was the One True Mac Editor. and becuase it costs so much.
Originally, BBEdit was a simple editor that could handle text files greater than 32 KB in size, with an unambitious plugin architecture. Simplicity aside, I suspect there are several reasons people scrawl 'BBEdit is god' in the pavement:
* It's better than Windows Notepad, TextEdit, etc for editing basic text, by virtue of providing a basic set of very useful manipulations (which you can find in TextMate's Text Utilties and Text > Convert menus) that some people need to perform rather frequently.
* The HTML tools -- originally in the form of a set of third-party plugins. I think it was just after the disappointment of the first generation of graphical web page generators began to sink in that the HTML tools became available. Good timing.
* Support for editing files over FTP (I believe this was originally coordinated with Anarchie, now Interarchy).
* BBEdit's developer never abandoned the application. It's been in more-or-less continuous development since it was first released. Several other text editors -- sometimes unquestionably more advanced than BBEdit at the time -- simply died when their authors decided to move on.
BBEdit has historically been very slow to accumulate new features, and they're almost always seen elsewhere first. The pace has actually quickened in recent years, as the user base has grown larger and more cross-platform.
That's my perspective, anyway; I don't know how well it matches with objective reality. :)
Chris
Chris Thomas wrote:
Originally, BBEdit was a simple editor that could handle text files greater than 32 KB in size, with an unambitious plugin architecture. Simplicity aside, I suspect there are several reasons people scrawl 'BBEdit is god' in the pavement:
- It's better than Windows Notepad, TextEdit, etc for editing basic
text, by virtue of providing a basic set of very useful manipulations (which you can find in TextMate's Text Utilties and Text > Convert menus) that some people need to perform rather frequently.
- The HTML tools -- originally in the form of a set of third-party
plugins. I think it was just after the disappointment of the first generation of graphical web page generators began to sink in that the HTML tools became available. Good timing.
- Support for editing files over FTP (I believe this was originally
coordinated with Anarchie, now Interarchy).
- BBEdit's developer never abandoned the application. It's been in
more-or-less continuous development since it was first released. Several other text editors -- sometimes unquestionably more advanced than BBEdit at the time -- simply died when their authors decided to move on.
BBEdit has historically been very slow to accumulate new features, and they're almost always seen elsewhere first. The pace has actually quickened in recent years, as the user base has grown larger and more cross-platform.
That's my perspective, anyway; I don't know how well it matches with objective reality. :)
Thats fair enough.
I'd add:
superbly organized and granular AppleEvents model / AppleScript dictionary. (Probably doesn't seem important to a lot of developers nowadays, but it remains an important part of some of Apple's markets. Consider that BBEdit is often deployed alongside InDesign, Quark Xpress, MS Word and maybe even in iView MediaPro or Cumulus etc and AppleScripts are used to automate some BBEdit processing of text in these files from these apps. It also integrates well with both ScriptDebugger and Affrus. I seriously doubt that any editor will ever encroach on BBEdit in this space.)
An unrivalled set of intra-app text processing tools. Sure, with the advent of OS X, a lot of what these tools can do is *readily* available via Perl, Python and Shell scripts, but many users will still find BBEdit's easy to use GUI tools preferable.
Although BBEdit only recently got a projects drawer and one which is considerably less able than TextMate's, it has had "File Groups" and "File Browsers" for a long, long time. In fact, I think BBEdit was amongst the first editors on any platform fo have GUI implementations of these features.
Text Factories. This may be considered as "Automator for Editors". Again, a competent unix user will be able to achieve the same with pipes in his/her preferred scripting language, but that's not the point. Text Factories are so easy to set-up that any idiot can do it.
Another aspect for which BBEdit is often praised is its worksheets, especially its MPW implementation and its codewarrior integration. I've never used either so I can't comment.
Completely configurable menu keys. A granular "palette" model Stationery
We've (or at least I've) also got BBEdit to thank for the fact that we have a single GUI email client on the platform in which one can actually edit and process text effectively.
I think Bare Bones could also be credited for the fact that they have two of the best carbon-based apps on the platform. Look around at everything else carbon (exceptions being iView MediaPro and Intaglio). There is always something not correct or missing or jarring. Bare Bones have really gotten this right and I suspect their attention to detail in this department had probably cost them quite a bit in the last 4 years in terms of feature addition. With BBEdit 8, it would seem that a lot of underlying transition work has been completed. So [speculation] once they have done the same with Mailsmith and undertaken the nigh impossible in adding IMAP support to Mailsmith w/o breaking the way it works [take some time to think about this if you are interested, its really a tremendous challenge], we might see the rate of feature addition pick up again.
There is a tremendous support community. The BBEdit-talk and BBEdit-scripting lists are excellent resources with many experts on the app itself and also on Regex, Perl, Python and AppleScript.
Finally, despite what a lot of people say, I like the guys at Bare Bones and though it certainly does not produce rapid feature addition, I like their approach and their attitude. I think its a fairly wise approach all things considered. It will grate with some nowadays with the advent of open source and instant access and the fact that there is so much choice in software and so many users wanting everything yesterday. Bare Bones have not adapated to this at all. It remains to be seen whether they will have to adapt or not.
mark.
On Mar 19, 2005, at 12:25 AM, Mark Smith wrote:
Another aspect for which BBEdit is often praised is its worksheets, especially its MPW implementation and its codewarrior integration. I've never used either so I can't comment.
MPW-style worksheets are basically Terminal in a text window. You can almost get the same effect in any TextMate window by typing command- r. The essential difference is that the environment is maintained (per-window) across command invocations, and you can perform interactive commands. It's very productive for command-line work: it means never having to fire up Terminal, and it also means not having to care whether or not GNU readline is available for things like irb. This would be a great thing to have in TextMate.
I haven't used BBEdit's implementation recently enough to give an opinion on it, however. MPW's implementation was great, although saddled of course with all the unfortunate MPW historical cruft (extremely non-standard variants of Unix tools, regex based on upper 8-bit MacRoman characters, etc).
Chris
On Mar 20, 2005, at 5:06, Chris Thomas wrote:
MPW-style worksheets are basically Terminal in a text window [...] This would be a great thing to have in TextMate.
Agree -- initially I dropped this item because I thought I'd have to do terminal emulation, which I still wait for some knight in shining armor to write for me. But I guess in majority of cases, this isn't necessary!?!
On Mar 20, 2005, at 12:36 AM, Allan Odgaard wrote:
On Mar 20, 2005, at 5:06, Chris Thomas wrote:
MPW-style worksheets are basically Terminal in a text window [...] This would be a great thing to have in TextMate.
Agree -- initially I dropped this item because I thought I'd have to do terminal emulation, which I still wait for some knight in shining armor to write for me. But I guess in majority of cases, this isn't necessary!?!
On reflection, there are different issues bundled up in the concept of 'worksheets'.
(*) MPW-style worksheet capability is sort of separate from the question of terminal emulation. The salient features of MPW as far as I can remember are these:
- Per-window autosave-on-close (window always saves itself on close). MPW had one 'Worksheet' window that was always open, but you could create essentially any number of them by setting the autosave-on- close per-window variable.
- Bind the execute-command-in-shell key to Enter (no modifiers) and Command-Return.
- Redirection to a specific window. If I specify a pathname while piping ("echo something | tm /path/to/file"), open a window for that file and direct the output of the pipe to it. Probably want both append and replace command-line options. If the file is already open in TM, just bring the window to front. [In MPW, because the shell language was intimately bound into the application, you'd actually just redirect to the path of an open file using standard shell append and replace redirection, and the output would appear in the file's window, no intermediate tool required.]
(*) Full terminal emulation, sufficient to -- say -- run emacs, doesn't make sense to me; Terminal and iTerm are fine. Others may disagree (vehemently :). The question is what value TM can add to the experience. Really basic interactivity -- sufficient to run language interpreters -- is probably more interesting. irb with syntax highlight and other features of TM's editor. I _think_ what you'd do is allocate a psuedotty and do line-buffered input, i.e. do not send each character, instead send a full line to the input pipe when the user presses return. This does not handle all possible command-line interactivity, but it ought to work for all the cases that are interesting for a text editor/IDE, and also for some standard tools like gdb and ssh. [I wonder what happens in the cases where it doesn't work, though.]
My thoughts, Chris
In article d445fadae2748cfc4022220a44fccfe6@davelee.com.au, David Lee david@davelee.com.au wrote:
Excuse me for getting the way of ... whatever's bewing here
I'm curious about BBedit (having never really used it), becuase it was the One True Mac Editor. and becuase it costs so much.
What are its best features, all you ex- or bipolar BBedit users? Anything unique that you really miss in Textmate?
Also feel free to mention things about it which TextMate has done better or done away with the need for with a clever design approach etc?
You really should give it a look. TextWrangler (the simpler version of BBEdit) is free and is very good.
Some things BBEdit does right (many other editors have most of this, but few have all of it: - Can find and replace in multiple files (e.g. all open documents, search a directory). - Can "find all" and find with regular expressions. - Multiple undo (though they were very late to implement it). - Robust. - Well supported - Very polished.
The main thing that keeps me from using it is there is no easy and safe way to do a one-off find or replace "in selection". Because: 1) To check the "In Selection" box, you first must uncheck "Start at Top" or "Wrap", if checked. Then reverse the process when you are finished. 2) If you forget to re-check "Start at Top" or "Wrap" checked, then "Replace All" only replaces from the cursor to the end of the file!!! I corrupted a few files due to that and stopped using BBEdit to write code.
My other main gripes are: - Modal find/replace dialog box. But this is a matter of taste; I know some BBEdit users consider it a feature. - You cannot edit the text displayed in the found results window. This is one of several instances where BBEdit lacks sophistication and seems to get between the user and the data. Still..I'd rather have a developer err on the side of simplicity.
Basically if the find/replace dialog box were cleaned up a bit I'd be using BBEdit. But I'm still hoping TextMate turns into a nice polished editor. Once the python text coloring is reasonable I look forward to giving it another look.
-- Russell
Also, BBEdit's side-by-side graphical diff (Find Differences...) is really quite nice. The 'Fast Find' feature is also quite nice, and something like that (or like Firefox's find-in-place) would be really cool to have in TextMate.
On Mar 22, 2005, at 6:03 PM, Russell E. Owen wrote:
You really should give it a look. TextWrangler (the simpler version of BBEdit) is free and is very good.
Some things BBEdit does right (many other editors have most of this, but few have all of it:
- Can find and replace in multiple files (e.g. all open documents,
search a directory).
- Can "find all" and find with regular expressions.
- Multiple undo (though they were very late to implement it).
- Robust.
- Well supported
- Very polished.
Noah M. Daniels wrote:
Also, BBEdit's side-by-side graphical diff (Find Differences...) is really quite nice. The 'Fast Find' feature is also quite nice, and something like that (or like Firefox's find-in-place) would be really cool to have in TextMate.
I don't know bbedit's feature, but I know FF's FAYT, and ^S in TM does pretty much the same thing.
Find as you type is indispensible, in everything. Wish Safari would do this ..
Some things which would be great in TM (one of these years) would be - a good full cocoa FTP client built in(HAHA! I hear you laugh)
I think there's plenty of room for a nice simple working good cocoa FTP client. Transmit almost gets it right except they use retardo views instead of an expandable tree view (with graphical indication of which folders have 'known' contents).
- side by side graphical diff which can operate over ftp, a la the windows program BeyondCompare. It's Really Really Useful.
See http://www.scootersoftware.com/moreinfo.php ; http://www.scootersoftware.com/en/shot7w.png
Now - I think in discussing these I bring up a more interesting question than "will you do x", and that is "What is your long term plan for extending TextMate into the space of other applications ( ftp | graphical diff | regexp wizard | etc)".
Is the intention to A) keep TM a pure editor with a few extra features like edit-over-ftp B) allow it to integrate with a few existing apps (standalone FTP clients) C) write your own fantastic complementary programs which integrate really well with TM D) extend TM into something approaching an IDE by adding these to TM itself E) ??
I'm quite curious. .. Scuse me if I should know / be able to infer this by now.
Cheers
D
-----Original Message----- From: Caio Chassot [mailto:k@v2studio.com] Sent: Wednesday, 23 March 2005 12:32 PM To: TM Users Subject: Re: [TxMt] Re: Bare Bones [was: Public to-do list for TM (was: TextileBundle?)
Noah M. Daniels wrote:
Also, BBEdit's side-by-side graphical diff (Find Differences...) is really quite nice. The 'Fast Find' feature is also quite nice, and something like that (or like Firefox's find-in-place) would be really cool to have in TextMate.
I don't know bbedit's feature, but I know FF's FAYT, and ^S in TM does pretty much the same thing. ______________________________________________________________________ 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 23 mars 2005, at 03:18, David Lee wrote:
Is the intention to A) keep TM a pure editor with a few extra features like edit-over-ftp B) allow it to integrate with a few existing apps (standalone FTP clients) C) write your own fantastic complementary programs which integrate really well with TM D) extend TM into something approaching an IDE by adding these to TM itself E) ??
E) Provide a comprehensive TM plugin Cocoa API for third parties developers, à-la JEdit.
On Mar 23, 2005, at 8:01, Luc Heinrich wrote:
Is the intention to A) keep TM a pure editor with a few extra features like edit-over-ftp B) allow it to integrate with a few existing apps (standalone FTP clients) C) write your own fantastic complementary programs which integrate really well with TM D) extend TM into something approaching an IDE by adding these to TM itself E) ??
E) Provide a comprehensive TM plugin Cocoa API for third parties developers, à-la JEdit.
Yes, definitely A and E.
There are IMO many good reasons why I should only focus on the actual text editing part of TextMate, but this naturally begs for good 3rd party extensibility of the editor.
It does bother me tremendously that I have to spend my time writing ftp support since a) this should be made available to all applications through e.g. a decent Finder implementation instead of having each app re-invent the wheel, b) this is probably unused by the majority of TextMate users and c) it has nothing to do with a text editor.
But seeing how Finder doesn't have useful ftp support and the minority that needs this in TM is a large minority (which are all unfamiliar or unwilling to use Interachy!?! ;) ), I'm letting this one slip -- also because I'll anyway need to make the project drawer support arbitrary sources with callbacks (like svn/cvs), so ftp will just be a plugin that uses this system, most likely based on libcurl and ftpparse.c (except that this doesn't support rename and move operations).
On Mar 23, 2005, at 10:32 AM, Allan Odgaard wrote:
There are IMO many good reasons why I should only focus on the actual text editing part of TextMate, but this naturally begs for good 3rd party extensibility of the editor.
It does bother me tremendously that I have to spend my time writing ftp support since a) this should be made available to all applications through e.g. a decent Finder implementation instead of having each app re-invent the wheel, b) this is probably unused by the majority of TextMate users and c) it has nothing to do with a text editor.
Amen! I can't believe the number of people who find it objectionable that they should have to buy an (s)ftp client, of which there are several that are very good available (I prefer the latest Transmit). I hope that you keep the (s)ftp feature set sharply limited to the basics and focus on the text editing portions of TextMate.
At 10:45 AM -0600 3/23/05, Jason Perkins wrote:
Amen! I can't believe the number of people who find it objectionable that they should have to buy an (s)ftp client, of which there are several that are very good available (I prefer the latest Transmit). I hope that you keep the (s)ftp feature set sharply limited to the basics and focus on the text editing portions of TextMate.
Could some of the (S)FTP boosters spell out how an ideal editor would behave with respect to FTP? I don't get it myself... I always want a local copy as well, so I rarely every edit directly at the FTP site.
It's possible we could all chip in and write a bundle that gets 75% of the way there...
- Eric
On 23-mars-05, at 18:04, Eric Hsu wrote:
Could some of the (S)FTP boosters spell out how an ideal editor would behave with respect to FTP? I don't get it myself... I always want a local copy as well, so I rarely every edit directly at the FTP site.
First, I'm not an (S)FTP booster at all, a good (S)FTP client is a must have for me anyway (Transmit 3 for me). I'm not even sure what an integrated FTP client could bring us, except if it could give me the possibility to open remote files as a Project...
But on "why edit files remotely", it's simply much more easy and fast! Ex: When I'm tweaking some CSS, I can't see how it could be easier than Cmd+S, Cmd+R, switch to browser...
At 6:27 PM +0100 3/23/05, Fred B. wrote:
Ex: When I'm tweaking some CSS, I can't see how it could be easier than Cmd+S, Cmd+R, switch to browser...
What is the Cmd-R for?
I agree that it's faster to the server; I guess you back it up after you've uploaded a final copy?
- Eric
On 23 mars 05, at 18:42, Eric Hsu wrote:
At 6:27 PM +0100 3/23/05, Fred B. wrote:
Ex: When I'm tweaking some CSS, I can't see how it could be easier than Cmd+S, Cmd+R, switch to browser...
What is the Cmd-R for?
It's the "Refresh Browser" command in the html bundle. In fact it would be the same to do: Cmd+S, switch to browser, Cmd+R, as it's "Reload page" in Safari too.
I agree that it's faster to the server; I guess you back it up after you've uploaded a final copy?
Yes I have a mirror folder that I update every now and then. At the end of the day at least.
On Mar 23, 2005, at 11:27 AM, Fred B. wrote:
On 23-mars-05, at 18:04, Eric Hsu wrote:
Could some of the (S)FTP boosters spell out how an ideal editor would behave with respect to FTP? I don't get it myself... I always want a local copy as well, so I rarely every edit directly at the FTP site.
First, I'm not an (S)FTP booster at all, a good (S)FTP client is a must have for me anyway (Transmit 3 for me). I'm not even sure what an integrated FTP client could bring us, except if it could give me the possibility to open remote files as a Project...
I'm curious to see how Projects are going to evolve, specifically if you're using a third party (s)ftp client. Allan, do you have any plans for this?
On Mar 23, 2005, at 19:35, Jason Perkins wrote:
I'm curious to see how Projects are going to evolve, specifically if you're using a third party (s)ftp client. Allan, do you have any plans for this?
The plan is to have the project drawer act as a file system browser with a) additional sources provided by plugins (one being ftp sites), and b) the ability to show the contents of multiple sources at once (i.e. using split views).
I want to move away from the monolithic *.tmproj file and the need to explicitly create projects. So whether you're working with a project or not is just a matter of having the drawer open or closed.
There will be a few issues with project meta-data, but for meta-data relating to folder views, I'll keep this in the filesystem (as a hidden file per folder, only when needed of course), and with regard to which files are open in a window (i.e. the tabs) and which sources are shown in the drawer, I intend to introduce workspaces.
A workspace is a snapshot of all windows currently open and their state. By default it will just remember how you left it all when you restart, but if you work on multiple projects you may want to explicitly create new workspaces (for new projects) and switch workspaces (when you need to switch to another project).
The downside with workspaces is that if you want to have two “projects” open at the same time, you'd need to merge the two workspaces representing the two projects. So I'm not fully settled on workspaces, but I think it's the way to go!
I think workspaces are a great idea.
I like Omniweb's workspaces, particularly the f1, f2 etc fast workspace switching; it's like application-local virtual desktops.
I just recently noticed command-T opens a list of files (recently opened?). I think with very minor modifications this interface would make a **great** buffer list.
I'd like to see it showing files in open tabs separately at the top of this list, and with appropriate keybindings & icons to: - close[for open tabs] or - open [for recent files])
Cheers
D
-----Original Message----- From: Allan Odgaard [mailto:allan@macromates.com] Sent: Thursday, 24 March 2005 6:09 AM To: TM Users Subject: Re: FTP client (was .. RE: [TxMt] Re: Bare Bones [was: Public to-dolist for TM (was: TextileBundle?)
On Mar 23, 2005, at 19:35, Jason Perkins wrote:
I'm curious to see how Projects are going to evolve, specifically if you're using a third party (s)ftp client. Allan, do you have any plans for this?
The plan is to have the project drawer act as a file system browser with a) additional sources provided by plugins (one being ftp sites), and b) the ability to show the contents of multiple sources at once (i.e. using split views).
I want to move away from the monolithic *.tmproj file and the need to explicitly create projects. So whether you're working with a project or not is just a matter of having the drawer open or closed.
There will be a few issues with project meta-data, but for meta-data relating to folder views, I'll keep this in the filesystem (as a hidden file per folder, only when needed of course), and with regard to which files are open in a window (i.e. the tabs) and which sources are shown in the drawer, I intend to introduce workspaces.
A workspace is a snapshot of all windows currently open and their state. By default it will just remember how you left it all when you restart, but if you work on multiple projects you may want to explicitly create new workspaces (for new projects) and switch workspaces (when you need to switch to another project).
The downside with workspaces is that if you want to have two "projects" open at the same time, you'd need to merge the two workspaces representing the two projects. So I'm not fully settled on workspaces, but I think it's the way to go!
______________________________________________________________________ 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 23.03.2005, at 18:27, Fred B. wrote:
I'm not even sure what an integrated FTP client could bring us, except if it could give me the possibility to open remote files as a Project...
amen!
of course, oth with what allan has got lined up with workspaces, we might not need that ability after all.
But on "why edit files remotely", it's simply much more easy and fast!
i use it all the time now. it's *so* much nicer to edit config files in TM rather than in shell!
t.
-- tom lazar tom@tomster.org http://tomster.org
I really like TextMate because its is not overly boated with features. For instance, the discussion on adding an SFTP client to it, is baffling -- I don't like TextWrangler because the program is trying to do everything for everybody -- even its preferences are too complicated for most users. For my work I use Fugu to do my SFTP stuff, because it does a good job, it supports tunneling, which is something that an SFTP program should do. Leave the text editing work for TextMate, and let the focus stay there.
-Howard
On Mar 23, 2005, at 22:00, H H wrote:
I really like TextMate because its is not overly boated with features. For instance, the discussion on adding an SFTP client to it, is baffling -- I don't like TextWrangler because the program is trying to do everything for everybody -- even its preferences are too complicated for most users.
It's definitely a priority for me to keep the GUI of TextMate as simple as possible -- I don't like adding settings/options unless they really do make sense, and I don't like features that may get in the way for people who do not use these features.
I do see some concerned about bloat (outside this ML also), but although I doubt any software author would declare bloat his goal, I definitely have the opposite goal. Finding the features/infrastructure that give optimal end-user flexibility is certainly what I try to pursue with TextMate.
On Mar 23, 2005, at 02:32 PM, Tom Lazar wrote:
But on "why edit files remotely", it's simply much more easy and fast!
i use it all the time now. it's *so* much nicer to edit config files in TM rather than in shell!
Fair one, but you can do that with and of the sftp clients that have been mentioned.
-- Jason N Perkins http://sneer.org/
I'm not an FTP booster either - but if FTP's going in it may as well be SFTP.
To be honest whenever I need to edit something directly on a server I find it much easier to use ssh & vim or emacs; otherwise I work on localhost & upload via Transmit / etc
I'd much rather see Allan spend time on the editor itself. I think most of us would prefer to have One Good Specialised Tool for each job
Cheers
D
-----Original Message----- From: Fred B. [mailto:fredb7@starflam.com] Sent: Thursday, 24 March 2005 4:27 AM To: TM Users Subject: Re: FTP client (was .. RE: [TxMt] Re: Bare Bones [was: Public to-dolist for TM (was: TextileBundle?)
On 23-mars-05, at 18:04, Eric Hsu wrote:
Could some of the (S)FTP boosters spell out how an ideal editor would behave with respect to FTP? I don't get it myself... I always want a local copy as well, so I rarely every edit directly at the FTP site.
First, I'm not an (S)FTP booster at all, a good (S)FTP client is a must have for me anyway (Transmit 3 for me). I'm not even sure what an integrated FTP client could bring us, except if it could give me the possibility to open remote files as a Project...
But on "why edit files remotely", it's simply much more easy and fast! Ex: When I'm tweaking some CSS, I can't see how it could be easier than Cmd+S, Cmd+R, switch to browser...
______________________________________________________________________ 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
Op 23-mrt-05 om 17:45 heeft Jason Perkins het volgende geschreven:
Amen! I can't believe the number of people who find it objectionable that they should have to buy an (s)ftp client, of which there are several that are very good available (I prefer the latest Transmit). I hope that you keep the (s)ftp feature set sharply limited to the basics and focus on the text editing portions of TextMate.
Agreed. It's just that you sometimes want to edit a remote file. Need sftp? Use a tunnel. For synching there's rsync.
The thing that's not clear to me is what functionality people want that you don't get from, say, Fugu or Cyberduck using TM as an external editor. That handles editing on other sites just fine.
It sounds like some people want to mount an entire external folder as a project? That is clearly out of reach of bundle writing.
Are there any other features one could want within TM involving SFTP? - Eric
Eric Hsu wrote:
The thing that's not clear to me is what functionality people want that you don't get from, say, Fugu or Cyberduck using TM as an external editor. That handles editing on other sites just fine.
It sounds like some people want to mount an entire external folder as a project? That is clearly out of reach of bundle writing.
My guess is also that its not so much remote editing of files per se that folks are seeking here. (Since there are a variety of adequate means for doing that already), but analogous to Eric's notion, its "site editing" that people are looking for and this would indeed be along the lines of having a remote mount available as a project. Right ?
Even so, it appears to me that using Transmit, Fugu, RBrowser or Interarchy with TextMate as external editor can provide this already.
Can somebody provide a detailed scenario of how this should work better/differently if it was all done within TextMate ? (genuine interest)
mark.
On 24 mars 05, at 10:46, Mark Smith wrote:
Eric Hsu wrote:
The thing that's not clear to me is what functionality people want that you don't get from, say, Fugu or Cyberduck using TM as an external editor. That handles editing on other sites just fine.
It sounds like some people want to mount an entire external folder as a project? That is clearly out of reach of bundle writing.
My guess is also that its not so much remote editing of files per se that folks are seeking here. (Since there are a variety of adequate means for doing that already), but analogous to Eric's notion, its "site editing" that people are looking for and this would indeed be along the lines of having a remote mount available as a project. Right ?
Even so, it appears to me that using Transmit, Fugu, RBrowser or Interarchy with TextMate as external editor can provide this already.
Can somebody provide a detailed scenario of how this should work better/differently if it was all done within TextMate ? (genuine interest)
mark.
Again, to make it clear, if I'd have to vote on an (S)FTP integration, I'd vote against it, Transmit, Fugu, Interarchy, etc. are ok for me. But I'd love to be able to make a "remote project", or even better: to include remote and local files in a project. Why? Because: It's easier to have a drawer opened than 7 windows. I could use diff on those files. I could use "find in project". Because of all the other project's niceties: Tabs, etc. Etc, etc.
Now, I don't know if this would implies an (S)FTP integration or not. I think it's better to keep things separated...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ok, my time to chime in here.
I agree here with Fred (and others). I like TextMate as an integrated text editor which I pull up from transmit. I have used SFTP integrated text editors too, my choice is Skedit http://www.skti.org/skEdit.php, though SEEdit works well too (includes textmate and CSSEdit integration) http://www.xhtmlsoft.com/ but find that I only use the (s)ftp functionality when I have a very quick edit to do. Generally, I am uploading pages, etc. so transmit works much better.
Of course, when that "White knight" brings terminal integration to textMate, this will all be moot.
On Mar 24, 2005, at 5:59 AM, Fred B. wrote:
Again, to make it clear, if I'd have to vote on an (S)FTP integration, I'd vote against it, Transmit, Fugu, Interarchy, etc. are ok for me.
well put fred,
that sums it up quite nicely for me, especially the last point!
since a lot of my work revolves around editing textfiles on remote machines i'd really like to do as much of that as possible in my editor of choice, i.e. TextMate.
cyberduck and textmate make a nice team but in the sense of getting things done still leave a lot to be desired. when using emacs or zile from the commandline, remote and local editing are seemless - but if that were enough for me, I wouldn't have bought TextMate, would I? ;-)
some other posters here have started using the term 'remote mountpoint' or somesuch - that's beginning to nail the idea for me.
anyone interested in such a functionality might also want to take a look at sshfs [1] - I know a linux developer who's quite happy with that solution...
and yes, allan is quite right, that handling such stuff is actually the responsibilty of the OS, not the app.
anyone know, if Tiger can mount (s)ftp writeable?
just my $0.02,
tom
[1] http://shfs.sourceforge.net/
On 24.03.2005, at 14:59, Fred B. wrote:
But I'd love to be able to make a "remote project", or even better: to include remote and local files in a project. Why? Because: It's easier to have a drawer opened than 7 windows. I could use diff on those files. I could use "find in project". Because of all the other project's niceties: Tabs, etc. Etc, etc.
Now, I don't know if this would implies an (S)FTP integration or not.
-- tom lazar tom@tomster.org http://tomster.org
On Mar 24, 2005, at 20:18, Tom Lazar wrote:
some other posters here have started using the term 'remote mountpoint' or somesuch - that's beginning to nail the idea for me.
Interarchy simulates this and I think FTPeel has something they call magic mirrors, which in name does sound like the functionality, although more a mirror of the remote site with automatic synchronizing, and not really just mounting the remote site (but I haven't tried the program, I just saw it at their web-page).
On 25.03.2005, at 18:29, Allan Odgaard wrote:
Interarchy simulates this and I think FTPeel has something they call magic mirrors, which in name does sound like the functionality, although more a mirror of the remote site with automatic synchronizing, and not really just mounting the remote site (but I haven't tried the program, I just saw it at their web-page).
thanks for the hint, I checked it out. But just like the other oh-so-great professional-ftp-client-for-money (transmit) interarchy, too, doesn't support authentication via public/private key pair and thus useless for me in 90% of cases :-(
so it's still cyberduck for me. free and great (alas without 'remote mounting' or 'magick mirrors' - so still no project-wide search-and-replace for me, *sniff*)
t. -- tom lazar tom@tomster.org http://tomster.org
On 30 mars 05, at 15:32, Tom Lazar wrote:
thanks for the hint, I checked it out. But just like the other oh-so-great professional-ftp-client-for-money (transmit) interarchy, too, doesn't support authentication via public/private key pair and thus useless for me in 90% of cases :-(
I don't know for Interarchy, but what makes you think Transmit doesn't support publickey authentication?
Transmit 3.0.2 Session Transcript (...) Next authentication method: publickey Trying private key: /Users/fredb/.ssh/id_rsa Offering public key: /Users/fredb/.ssh/id_dsa Server accepts key: (...) read PEM private key done: type DSA Authentication succeeded (publickey). (...)
Maybe you should check the facts before firing your oh-so-great-sarcasm? ;)
-- Fred
On 30.03.2005, at 19:01, Fred B. wrote:
Next authentication method: publickey Trying private key: /Users/fredb/.ssh/id_rsa Offering public key: /Users/fredb/.ssh/id_dsa Server accepts key: (...) read PEM private key done: type DSA Authentication succeeded (publickey). (...)
thanks for clearing that up! does it silently check for '~/.ssh.id_dsa' or is there a way to specify a particular key?
Maybe you should check the facts before firing your oh-so-great-sarcasm? ;)
but seriously, it was the first thing I checked, when Transmit3 came out recently - I've obviously missed that option.
I'll definitely give Transmit another try now.
I do think, that the sheer fact that ftp clients are discussed so much here on the list shows that remote editing seems to be an important aspect of a text editor (especially one geared towards developers and admins).
So unless nobody intervenes I say, keep those ftp-related postings coming, I - for one - find them rather useful.
best regards,
tom -- tom lazar tom@tomster.org http://tomster.org
On 30 mars 05, at 19:11, Tom Lazar wrote:
thanks for clearing that up! does it silently check for '~/.ssh.id_dsa' or is there a way to specify a particular key?
I think Transmit basically uses OpenSSh like the shell. I never read anything about publickey in Transmit doc., I just had ssh to my server working in bash and tried Transmit...Bingo. Check Transmit's transcript for more details.
but seriously, it was the first thing I checked, when Transmit3 came out recently - I've obviously missed that option.
You're right it's not obvious at all, but It just works. ;) Maybe they think it's obvious that an SFTP client uses key pairs, so they don't mention it...?
I'll definitely give Transmit another try now.
Ok ;)
Op 23-mrt-05 om 3:18 heeft David Lee het volgende geschreven:
Find as you type is indispensible, in everything. Wish Safari would do this
Look for SAFT.
Ahh, another wonderful yet undocumented (I looked before I sent that email!) feature in TM :) I'm glad to see it there, though.
On Mar 22, 2005, at 8:31 PM, Caio Chassot wrote:
Noah M. Daniels wrote:
Also, BBEdit's side-by-side graphical diff (Find Differences...) is really quite nice. The 'Fast Find' feature is also quite nice, and something like that (or like Firefox's find-in-place) would be really cool to have in TextMate.
I don't know bbedit's feature, but I know FF's FAYT, and ^S in TM does pretty much the same thing. ______________________________________________________________________ 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
Noah M. Daniels wrote:
Caio Chassot wrote:
Noah M. Daniels wrote:
Also, BBEdit's side-by-side graphical diff (Find Differences...) is really quite nice. The 'Fast Find' feature is also quite nice, and something like that (or like Firefox's find-in-place) would be really cool to have in TextMate.
I don't know bbedit's feature, but I know FF's FAYT, and ^S in TM does pretty much the same thing.
Ahh, another wonderful yet undocumented (I looked before I sent that email!) feature in TM :) I'm glad to see it there, though.
I have taken to randomly pressing key combinations and seeing what happens. Has anyone compiled a master list of which features are invoked by which keys? Normally the menus provide such a reference, but there seem to be a lot of these hidden gems that aren't in the menus.
On Mar 23, 2005, at 9:18 AM, Jonathan Chaffer wrote:
I have taken to randomly pressing key combinations and seeing what happens. Has anyone compiled a master list of which features are invoked by which keys? Normally the menus provide such a reference, but there seem to be a lot of these hidden gems that aren't in the menus.
Since TextMate is Cocoa underneath, it supports most of expected Mac interface behavior: http://developer.apple.com/documentation/UserExperience/Conceptual/ OSXHIGuidelines/XHIGUserInput/chapter_2_section_3.html maybe more to the point (keyboard behavior): http://developer.apple.com/documentation/UserExperience/Conceptual/ OSXHIGuidelines/XHIGKeyboardShortcuts/chapter_12_section_1.html To my knowledge, custom key commands are in the Navigation menu.
However, TextMate also extends NSTextView, the default Cocoa framework for text applications. Maybe there should be some more documentation of its extended features? The one that comes to mind that I use a lot is ctl+opt+left/right arrow which moves not to the next/previous semantic word (like opt+left/right arrow) but to the next/previous word, separated by underscores. Like: a_big_lowercase_variable could be navigated with ctl+opt+left/right arrow. ctl+opt+delete is also implemented in addition to opt+delete.
k
On Mar 23, 2005, at 16:18, Jonathan Chaffer wrote:
Ahh, another wonderful yet undocumented (I looked before I sent that email!) feature in TM :) I'm glad to see it there, though.
I have taken to randomly pressing key combinations and seeing what happens. Has anyone compiled a master list of which features are invoked by which keys? Normally the menus provide such a reference, but there seem to be a lot of these hidden gems that aren't in the menus.
Ah, I don't think it's actually that many ;)
The key bindings augmenting the menus are in the KeyBindings.dict you'll find in TextMate.app (Show Package Contents) Contents / Resources.
The main reason incremental search is not in the menu is that it's still “experimental”.
On Wed, 23 Mar 09:37 (-0500), Noah M. Daniels wrote:
Ahh, another wonderful yet undocumented (I looked before I sent that email!) feature in TM :) I'm glad to see it there, though.
Actually it is documented in the Release Notes (Help > Release Notes) for v1.0.2b8 (2004-12-01), looking there when you search 'undocumented' things is always a good idea and this is where I usually look first to see whats new. :)
On Thu, 24 Mar 2005 13:31:52 +0100, Torsten Becker torsten.becker@gmail.com wrote:
Actually it is documented in the Release Notes (Help > Release Notes) for v1.0.2b8 (2004-12-01), looking there when you search 'undocumented' things is always a good idea and this is where I usually look first to see whats new. :)
Oohhh yeeaahhh!! This is wonderful, immediate and simple. Tell me more features of TM like this, please!
-
Allan Odgaard -
Caio Chassot -
Charles M.Gerungan -
Chris Messina -
Chris Thomas -
David Lee -
Eric Hsu -
Fred B. -
H H -
Jason Perkins -
Jason Perkins -
Jonathan Chaffer -
kumar mcmillan -
Luc Heinrich -
Mark Smith -
Mats Persson -
Nick Hristov -
Noah M. Daniels -
Robert Ullrey -
Russell E. Owen -
Tom Lazar -
Tommaso Passi -
Torsten Becker -
William D.Neumann