Greetings!
I'm trying to change the background/foreground colors, which only seems to work on documents w/out syntax highlighting. I set my background to black, but when I open a PHP file it has a white background. I set my background to white, but when I open a Ruby file it shows up black. Is this deliberate? Do I have to learn how to rewrite the syntax rules to make this change? Frankly, it seems quite counter-intuitive. Why offer that option if it usually doesn't even work?
If there is a simple answer, can someone direct me to it? I would be ever so grateful.
Also, is there a manual for this software? Between the mailing list, the startup tips, the newsgroup, the wiki, and the blog, I'm near my wit's end. I do like this program, but I assumed that it would come with documentation!!! Frankly, using this feels more like a scavenger hunt, not exactly par for commercial software.
Please don't take me wrong, I'm just a little frustrated.
Regards, Raymond
On Mar 4, 2005, at 19:17, Raymond Brigleb wrote:
I'm trying to change the background/foreground colors, which only seems to work on documents w/out syntax highlighting.
That is correct.
Do I have to learn how to rewrite the syntax rules to make this change?
Currently yes, but I'm working on a style sheet system that should solve this problem. This is currently my main priority, so it should appear shortly (but everything takes longer than I estimate ;) ). Though if you want black background for HTML/PHP then you may instead want to just check out the latest PHP (+ CSS/JS) bundle from the repository [1], since Mats Persson just committed a version with a dark color scheme.
Why offer that option if it usually doesn't even work?
It is the default value for when there is no syntax applied to the current file. In the future there may instead just always be a default syntax.
[...] I do like this program, but I assumed that it would come with documentation!!! Frankly, using this feels more like a scavenger hunt, not exactly par for commercial software.
There will be better documentation, but most likely not before after 1.1 final. The reason is twofold: 1) commercial software (or shareware, as I prefer to call it) does not equal unlimited resources and 2) the program is very much work in progress, and writing documentation now and updating it while the program evolves, would probably consume 3-4 times more time than just writing the documentation when the program is more or less “stable” in basic functionality.
On 4 Mar 2005, at 18:36, Allan Odgaard wrote in response to Raymond Brigleb writings:
Though if you want black background for HTML/PHP then you may instead want to just check out the latest PHP (+ CSS/JS) bundle from the repository [1], since Mats Persson just committed a version with a dark color scheme.
To clarify that point, the HTML, PHP, CSS & JS combined syntax files are stored in the PHP.tmbundle [1] in the repository. If you - or anyone else - don't have Subversion installed which you need to check it out I'll be happy to send you the bundle off-list, just let me know. A better bundle download solution is, I'm sure, under development somewhere. :)
[1] http://anon:anon@macromates.com/svn/Bundles/trunk/PHP.tmbundle/
For those not interested in PHP, but want the other bits, all of them will work fine on their own (without PHP) as well. Might merge the syntax files into the default HTML, CSS & JS syntax's later on if everything is working OK and that's OK with the grand master.
[...] I do like this program, but I assumed that it would come with documentation!!! Frankly, using this feels more like a scavenger hunt, not exactly par for commercial software.
There will be better documentation, but most likely not before after 1.1 final. The reason is twofold: 1) commercial software (or shareware, as I prefer to call it) does not equal unlimited resources and 2) the program is very much work in progress, and writing documentation now and updating it while the program evolves, would probably consume 3-4 times more time than just writing the documentation when the program is more or less “stable” in basic functionality.
As a paid up user since v 1.0, and not paid by Allan :) I must say that there is a basic documentation in the Help Viewer, and if anything is missing from there, please just ping of a question like you did today, and someone - most likely the amazing Allan himself - will answer quickly. The ML has been a bit quiet lately, but that's also a good sign I guess.
However, I must stress the following point: I would rather have Allan be productive in improving the app (as he has done fantastically well since 1.0) than spend his limited time writing documentation. I know there is a balance to be had here, but as things are currently I think that there is a fairly large group of users that are helping out in whatever way they can with answering questions, creating syntax's and commands etc. Perhaps that group could also collaborate on creating a more extensive documentation on the Wiki ??? Sort of a mini TM Wikipedia.org thing.
Note to Allan: Perhaps the Help files could be editable on the wiki so that end users could add/amend the missing/insufficient parts. You could then pull down and include a version for each app release ?? Or something similar.
Working with TM - and the community around it - is the closest I have ever come to the true Mac experience with any commercial (shareware) app. Forget all the old <other editors> stuff and Think different! :)
Kind regards,
Mats
---- "TextMate, coding with an incredible sense of joy and ease" - www.macromates.com -
At 9:14 PM +0000 3/4/05, Mats Persson wrote:
Perhaps that group could also collaborate on creating a more extensive documentation on the Wiki ??? Sort of a mini TM Wikipedia.org thing.
I think this is a very good idea, and probably the best use (in my opinion) for the Wiki. Feature requests and bug reports seem to mostly live on the mailing list and developer talk lives on the SVN mailing list.
However, this will take one energetic person to organize the effort, and that person is not me! However, once a part of the wiki were organized, bundle writers could promise to write some documentation for the WikiManual.
best wishes, Eric
Thanks everyone for the helpful feedback! And that certainly is something that makes TextMate special. Maybe I came off as a complainer... sorry, I was more saying that there's a million great tips and info out there, but lamenting that you have to look in five places to find them all!
I agree with the direction this topic is heading though, in that I feel efforts should maybe be more focused on the Wiki, and that needs to start with a structure more like a user manual / documentation. I don't know if I'm the person to do it because I'm a complete novice, but I'd surely like to help.
I think the changes could start small, maybe a sub-page on the Wiki where the structure begins, then information is filled in. If one person was on top of the structure, checked on it daily, then maybe the rest of the community could aim at putting their tips and tricks and whatnot in there as they arise. Wikis are ideal for that.
With respect to the actual user manual, I just mainly feel that it's missing a beginner's guide / tutorial / philosophy / feature overview kinda thing. With something as unique as TextMate, I feel like one needs to hit the ground with some idea of the philosophy behind the text editor. I'm only slowly grasping the unique tricks and workflow of the software. For example, today I just stumbled across the "column editing" feature by trial-and-error. I probably wouldn't have realized what it was if I hadn't just browsed the feature list.
But I digress. It's a great piece of software, a great community, and I'm grateful to have purchased a copy all my own. Do forgive; my comments stem only from a desire to help a great program get better. By the way, nice to meet you all!!!
Regards, Raymond
On Mar 4, 2005, at 1:26 PM, Eric Hsu wrote:
At 9:14 PM +0000 3/4/05, Mats Persson wrote:
Perhaps that group could also collaborate on creating a more extensive documentation on the Wiki ??? Sort of a mini TM Wikipedia.org thing.
I think this is a very good idea, and probably the best use (in my opinion) for the Wiki. Feature requests and bug reports seem to mostly live on the mailing list and developer talk lives on the SVN mailing list.
However, this will take one energetic person to organize the effort, and that person is not me! However, once a part of the wiki were organized, bundle writers could promise to write some documentation for the WikiManual.
best wishes, Eric
Eric Hsu, Assistant Professor of Mathematics San Francisco State University erichsu@math.sfsu.edu http://math.sfsu.edu/hsu ______________________________________________________________________ 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
Ok. While I'm on a "roll."
Would it be difficult to write, or has anyone seen/written, a script that would go through all your formatting bundles and set the foreground color and background colors to values you enter. Or white/black. Something like that? Now *that* would shut me up. :)
Again I thank you, Raymond
On Mar 4, 2005, at 22:51, Raymond Brigleb wrote:
I agree with the direction this topic is heading though, in that I feel efforts should maybe be more focused on the Wiki, and that needs to start with a structure more like a user manual / documentation.
Yes, Jeroen van der Ham actually suggested that I put the current documentation in the wiki as a starting point.
The current documentation was never intended as a real manual, more like what one couldn't figure out through trial and error -- when I released 1.0 I wasn't sure exactly what people expected from the documentation (and if people actually read that stuff ;) ) -- I do think I have a better understanding of what (those who write me) expect, but how to actually deliver this is very hard.
My approach would be to document the individual features, but I don't think this is really what people want, 90% of these “features” can be seen in the menus, and the behavior of them should be more or less obvious (for the majority of them at least).
The thing people want (as I understand it) is an introduction to how to combine these features to do more than the feature itself. For me that's almost equivalent with having to document e.g. C++ in a way that makes people understand why this is actually an awesome programming language ;)
I did however put down an outline of topics I think would go into a manual: http://macromates.com/wiki/pmwiki?n=Documentation.Main
Hopefully with enough examples this will give the user at least an idea of the flexibility hidden in the program.
I don't know if I'm the person to do it because I'm a complete novice, but I'd surely like to help.
That's actually great, because I've been using computers for so long that I take everything for granted, which makes me rather poor at writing documentation, but good at answering questions :)
With respect to the actual user manual, I just mainly feel that it's missing a beginner's guide / tutorial / philosophy / feature overview kinda thing.
Yes -- I've been trying to write down the philosophy behind it a few times, but there's actually 3 separate goals I've tried to pursue with TextMate, and I always end up making one of these overshadow the other two, which makes me throw it all away ;)
But the next time I venture into this, I'll place it in the wiki!
With something as unique as TextMate, I feel like one needs to hit the ground with some idea of the philosophy behind the text editor. I'm only slowly grasping the unique tricks and workflow of the software.
Although I don't want to hide that the documentation is everything but optimal, one also has to remember that for most new software it just takes time to use the full potential of it :)
Op 5-mrt-05 om 1:02 heeft Allan Odgaard het volgende geschreven:
On Mar 4, 2005, at 22:51, Raymond Brigleb wrote:
I agree with the direction this topic is heading though, in that I feel efforts should maybe be more focused on the Wiki, and that needs to start with a structure more like a user manual / documentation.
I did however put down an outline of topics I think would go into a manual: http://macromates.com/wiki/pmwiki?n=Documentation.Main
Instead of using a wiki, you should check out hieraki.org. Looks like a wiki but goes further and feels way better.
Plus you have its dev as loyal fan if any additional features are needed.
Instead of using a wiki, you should check out hieraki.org. Looks like a wiki but goes further and feels way better.
Op 5-mrt-05 om 1:37 heeft Tobias Luetke het volgende geschreven:
Plus you have its dev as loyal fan if any additional features are needed.
Instead of using a wiki, you should check out hieraki.org. Looks like a wiki but goes further and feels way better.
Oh, here you respond to me :)
Op 5-mrt-05 om 1:37 heeft Tobias Luetke het volgende geschreven:
Plus you have its dev as loyal fan if any additional features are needed.
Instead of using a wiki, you should check out hieraki.org. Looks like a wiki but goes further and feels way better.
Just to clarify: Hieraki invites you to write a document, not a snippet, which is my main gripe with how people tend to use a wiki.
OK, it seems like my comment about the TM users collaborating on the documentation hit some right notes.
On 5 Mar 2005, at 00:02, Allan Odgaard wrote:
I don't know if I'm the person to do it because I'm a complete novice, but I'd surely like to help.
That's actually great, because I've been using computers for so long that I take everything for granted, which makes me rather poor at writing documentation, but good at answering questions :)
In the above snippet we have the two types of people that are crucial to creating a good documentation. -- The novice (new user) that is not yet understanding the app/(whatever) and therefore asks basic questions that other more experienced users have learnt/found ways around etc. --The developer/expert user that knows it all, but would naturally have problems understanding the questions arising in the mind of a new user.
The key issue is now how to retain/contain those two key parts as efficiently as possible. I think the following would go a part of the way towards doing that: (thinking out loud here)
1. The contents of the current Help Docs is put up on the wiki as a starting point, and Allan's documentation outline is implemented.
2. A registered group of user - like the Bundle Dev's - can then add new bits or amend existing bits. Each Doc's Developer could then get an e-mail with the latest changes in it like SVN commit messages, or we could have a page that shows all those changes only on a single page type of thing. Not sure which is best/easiest to do??
3. The bundled TM Help Doc's is a local copy of the existing online docs at the time of release, where on the first page of the Help Doc's there is a clear reference to the online doc's and a description of what to do when your question has not been answered by the existing doc's, i.e. mail your question to the ML or possibly some web form that forwards it to the list to save people from joining the ML if they don't want to.
4. The ML or DocDev's would then get the question and instead of writing the answer in a reply e-mail, they would write it directly into the online docs and then just reply with the link to the answer. That way a single action is retained and there is no duplication of efforts, and the doc's will grow organically according to actual real user needs. Now if Allan or someone else, finds that the answer is incorrect or incomplete they could amend the online doc's and resend the reply. (Needs a bit more figuring out, but you get the basic idea)
I know that part of that might seem like a bit too ideal, but it's really the fastest/best way I can think of. Over to your input ??
As for helping out. Count me in, but due to health reasons I'm not the "energetic person to organize the effort".
I already like to have a go at the RegEx section with some real life examples and regex translations into plain English for us regex challenged individuals ;-)
Yes -- I've been trying to write down the philosophy behind it a few times, but there's actually 3 separate goals I've tried to pursue with TextMate, and I always end up making one of these overshadow the other two, which makes me throw it all away ;)
Hmm, I might have misinterpreted your philosophy Allan, but I always assumed it to be "Enabling users to be as productive as they can be no matter what code/text they are working with"
But hey, now you've got me really intrigued ;-)
On 6 Mar 2005, at 09:17, Charles M.Gerungan wrote in response to Chris Thomas' writings:
I guess this is as good a time as any to say that I don't like PmWiki at all. The site structuring system feels weird; the basic formatting operators are clunky; the style is not attractive. IMHO. :)
Agreed. But it's Allen who has to maintain it. (Or is it the users?) Plus, having Tobi on your site and his wilingness to support it is very nice indeed. I envision a fully loaded Hieraki and Tobi creating a "Publish to PDF" button. There you go, a full-fledged manual to be distributed with the application, chapters and all.
Hieraki wins my vote hands down over the existing PmWiki in every single aspect I've thought of this far. (Really nice work there Tobias, and if you ever get around to implementing Charles' thoughts it will be even sexier !!! )
Not sure how Allan would think of it, but if the users collectively did a good enough job, and Allan was always in control over it in the background, then I guess he would be happy. I would be at least.
I agree with you Chris, but PmWiki was - I guess - a quick replacement for the 'beleaguered' Instiki Wiki. (Sorry, just liked to remind all of us 'beleaguered' Mac users of a word we don't hear that often these days :) No offence intended DHH )
Kind regards,
Mats
---- "TextMate, coding with an incredible sense of joy and ease" - www.macromates.com -
-
Allan Odgaard -
Eric Hsu -
Mats Persson -
Nednieuws -
Raymond Brigleb -
Tobias Luetke