Just wondering if this is a bug or the expected behavior. I currently have open the theme editor, and bundle editor, and a document. If I press Cmd-` successively, the windows come in front in the following order:
document - bundle - document - theme - document - bundle - ....
I would have expected
document - bundle - theme - document - bundle - .....
If I have two documents open, the sequence of events is:
document1 - bundle - document1 - theme - document1 - document2 - bundle - document 2 - theme - document2 - document1 - ...
This certainly doesn't feel right, and it takes forever to get from document1 to document2.
Haris
On Jun 14, 2005, at 2:41, Charilaos Skiadas wrote:
Just wondering if this is a bug or the expected behavior. I currently have open the theme editor, and bundle editor, and a document. If I press Cmd-` successively, the windows come in front in the following order:
Yeah, that's pretty weird -- the reason seems to be because I've made both the bundle editor and theme editor a panel (instead of a window). Something I generally do for two reasons; 1) before Tiger, only panels would close on 'escape', and 2) by default panels do not get 'main window' status, meaning that important actions are still sent to the window containing the text editor (this is important mostly for things like the find dialog, which “work” on the main window, but both the theme and bundle editor also make use of having a main window e.g. when creating new items and setting a default scope).
Though panels also seem to have several disadvantages, I wasn't aware of this window-cycle chain problem, but I know of two other window- ordering related problems which only happen for panels.
For b13 I've changed both these two panels to be normal windows. This means that new items no longer get the current scope as default scope, but window-cycling works as expected :)
Hi All,
I'm trying to resolve a key conflict (command-b used to wrap the selection in bold. Now it tries to build in Xcode) and I'm wondering if there's a better way to try to resolve this than to 1) go to /Library/Application Support/Textmate and delete bundles I don't use 2) pour through everything in the bundle editor looking for command-b or just give the html command-b snippet better scope.
The language is: HTML (PHP) and the caret is within a php print command.
Outside of the php the command works fine, so of course one fix is to go into the bundle editor and add source.php.embedded.html to that snippet's scope. But this leads me to another point.
I haven't been in the bundle editor lately, so I'm guessing the new xcode key binding is from a bundle update or an install of the latest beta. This strikes me as tricky behavior. Is the bundle editor a straw house that I'll need to fine tune regularly?
TextMate is feeling complicated to me these days, at least for the work that I do (php/css/html/mysql/js). I'm not sure if it's because I'm unused to the new bundle architecture, that I'm using the latest betas, or it really is complicated. But it's gotten to the point that I'd like to bring up the topic. Perhaps TextMate is moving toward more of a higher end development tool -- I see a lot of latex (which I believe is a type of paint...) and other languages that are not so front-end web developer-ish, and if so then that's how it is. I would be sad, however. I can see how it's getting tremendously more powerful...it's just trying to keep up that appears difficult.
One possible solution is to have a (gasp) Setup Wizard that would allow someone to select which languages they use, and to simplify the bundle editor,etc, based on that.
-Ben
On Jun 14, 2005, at 3:52, Ben Parzybok wrote:
I'm trying to resolve a key conflict (command-b used to wrap the selection in bold. Now it tries to build in Xcode) and I'm wondering if there's a better way to try to resolve this than to
Well, for this particular key, it was “decided” that cmd-B should do a build, so cmd-B is used for several different commands (that all do builds for misc. languages), and so, it's not recommended to use that key for custom stuff -- of course, if you don't care about this, go ahead! :)
- go to /Library/Application Support/Textmate
and delete bundles I don't use 2) pour through everything in the bundle editor looking for command-b or 3) just give the html command-b snippet better scope.
As for #2 you can use Show Keybindings from the Language Definition bundle, and as for #1 you can disable bundles via Change Filtering… in the bundle editor.
Giving your own command a better scope would probably be a good solution, seeing how cmd-B is currently overloaded for text.latex, source.java, and source. So you'd have to delete/disable 3 bundles/ commands. And more commands using cmd-B may appear in the future (though for specific scopes, so probably won't clash with your stuff).
Outside of the php the command works fine
It's the “generic” build command that has scope set to source. So anything more specific than just source, or anything not containing source (as e.g. text.html) will win over this build command.
I haven't been in the bundle editor lately, so I'm guessing the new xcode key binding is from a bundle update or an install of the latest beta. This strikes me as tricky behavior. Is the bundle editor a straw house that I'll need to fine tune regularly?
Not exactly sure what a straw house refers to (in the figurative sense).
Hopefully it shouldn't be necessary to care about bundle items for other languages than those you use yourself when bundles are updated, because these items should limit their activation method to the scope of the language. Xcode build of course being the exception ;)
However, if you open the bundle editor, click the Change Filtering… and disable all but the bundles you use, you won't see any updates to all the disabled bundles in the future, and so, these shouldn't interfere with your custom stuff.
TextMate is feeling complicated to me these days, at least for the work that I do (php/css/html/mysql/js). I'm not sure if it's because I'm unused to the new bundle architecture, that I'm using the latest betas, or it really is complicated. But it's gotten to the point that I'd like to bring up the topic. Perhaps TextMate is moving toward more of a higher end development tool -- I see a lot of latex (which I believe is a type of paint...) and other languages that are not so front-end web developer-ish, and if so then that's how it is. I would be sad, however. I can see how it's getting tremendously more powerful...it's just trying to keep up that appears difficult.
I'm not sure if it's the actual UI of the bundle editor you find complicated, or the amount of (default) stuff in the bundle editor? As for the latter, Mats suggested that TM should ship with only a couple of languages enabled by default, and then let the View -> Language have a “More languages…” option that'd take the user directly to the filtering prefernce.
Such an approach might help, although the motivation for pursuing this is mainly that some do not find that TM actually do support their language (because it's disabled by default).
As for the structure of it all, it does bother me slightly that a new user unfamiliar with the bundles concept might find it strange that 90% of the functionality is buried deep down in the Automation submenus, but I'm not sure how to better layout all that stuff.
One possible solution is to have a (gasp) Setup Wizard that would allow someone to select which languages they use, and to simplify the bundle editor,etc, based on that.
Sometime in the future bundles should be selected like e.g. Quicksilver plugins -- but I'm not sure how you'd adjust the bundle editor to the installed bundles. The GUI is currently very minimal. What might help would be if each bundle item had a “second page” with item specific documentation. Although it doesn't sound like this is what you're seeking.
On Jun 13, 2005, at 9:40 PM, Allan Odgaard wrote:
I'm not sure if it's the actual UI of the bundle editor you find complicated, or the amount of (default) stuff in the bundle editor? As for the latter, Mats suggested that TM should ship with only a couple of languages enabled by default, and then let the View -> Language have a “More languages…” option that'd take the user directly to the filtering prefernce.
Maybe slightly related to this, as we are on the topic of UI confusion: In the Language Editor, the button titled "Change filtering...". I have to admit, I personally did not at first understand what it was doing, i.e. that it would change what bundles are viewed. I thought it would mean that maybe it would filter what individual items in each language would show up. In other words, I feel it is not clear at first glance that the languages are in any way "filtered", rather, I am seeing a list of languages and expect that that's it, unless there is a button to tell me otherwise, and that mysterious button called "Change filtering..." somehow doesn't sound like the right thing. Of course it is obvious the moment you press the button, but it is sometimes hard to get to that stage, and it seems some other people have had the same problem as well. I feel something like "Customize Language List" or some such might be a more appropriate choice of name.
Then again, maybe I'm the only one with this problem. :-) Haris
On 14 Jun 2005, at 03:40, Allan Odgaard wrote:
I'm not sure if it's the actual UI of the bundle editor you find complicated, or the amount of (default) stuff in the bundle editor? As for the latter, Mats suggested that TM should ship with only a couple of languages enabled by default, and then let the View -> Language have a “More languages…” option that'd take the user directly to the filtering prefernce.
Although I may be wrong here, but I think I also proposed a Firefox type Extensions system that when a new user activates TM for the first time, it provides a nice GUI for deciding what bundles are needed (beyond a few default ones). ie: in Ben's case he would have a "Web Developer" section where the available bundles would be listed together with a brief info about them and so on. That way he would download/install the required bundles and nothing more. This feature would obviously also support notification of new updates, etc etc. but I'll leave that for another discussion.
Note to Allan: bundles in TM.app should NOT be activated, but once a bundle is activated by user, they are copied to AppSupp/TM/ together with the default's
On 14 Jun 2005, at 02:52, Ben Parzybok wrote:
TextMate is feeling complicated to me these days, at least for the work that I do (php/css/html/mysql/js). I'm not sure if it's because I'm unused to the new bundle architecture, that I'm using the latest betas, or it really is complicated. But it's gotten to the point that I'd like to bring up the topic. Perhaps TextMate is moving toward more of a higher end development tool -- I see a lot of latex (which I believe is a type of paint...) and other languages that are not so front-end web developer-ish, and if so then that's how it is. I would be sad, however. I can see how it's getting tremendously more powerful...it's just trying to keep up that appears difficult.
Ben raises a very good and valid point. However, I would like to counter it with a few important points.
1. TextMate's / Allan's flaw right now is a version handling issue. There should ideally be two versions of TM the official (TM 1.1b5) and the developers (TM 1.1b12) version, and only a small subset of people should be aware of the dev version. Unfortunately Allan has 'lost' a bit of control over this lately partly through a few errors on his behalf, but mainly through the actions of 3rd parties. This has happened even though he tried to control things. As a result of this, more users are using an incomplete, unrefined version of TM than should be.
To put it in context for Ben and others, Allan's clients (we) are using and finding problems with an uncompleted project, and I think Allan has personally handled all of this really well ! I doubt many of us would want our clients to use/'complain' about incomplete projects. I certainly wouldn't like it !!
2. Many of the problems found in using TM today relate back to a lack of documentation/information. If you could find an answer about things easily, reliably and quickly then it would not be a problem in the first place. That is why I (and others ?) are trying to help Allan get a better documentation system going, so please be patient, or even better begin to help us out. (apply within for vacant position )
3. With great extensibility and functionality comes complexity. The challenge is how to handle that complexity and make it easy for end users. The problem we all face (as developers) is that we understand our project deeply, whereas our clients/others don't. That's why constructive comments like Ben's are so valuable to us all. For Allan and us other that have been informed about it, "Change filtering..." makes sense, to newcomers it doesn't.
4. Yes, if you are living on the bleeding edge, then there will be some price to pay for it. Considering the number of changes, improvements, new features etc. etc. that Allan has added into TM since 1.0 it's absolutely amazing from both a speed and numbers perspective. That rapid change is in my book very good, and why I like TM and admire Allan's work style. But if it's not for you, then downgrade or freeze at your current version until the next official version is released and you find the required documentation.
Kind regards,
Mats
---- "TextMate, coding with an incredible sense of joy and ease" - www.macromates.com -
hi ben,
please notice the following footer that comes with each email on this list,
thanks!
best regards,
tom
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
-- Tom Lazar http://tomster.org
On 14-06-2005 11:00, Tom Lazar wrote:
hi ben,
please notice the following footer that comes with each email on this list,
In other words, prepare for the collapse of the universe!
Jeroen.
On 14/06/2005, at 11.00, Tom Lazar wrote:
hi ben, please notice the following footer that comes with each email on this list, thanks!
best regards, tom
Hmm.. the threading worked fine for me on that one..!?
-- Sune.
On 14-06-2005 12:55, Sune Foldager wrote:
Hmm.. the threading worked fine for me on that one..!?
Then there's a problem with Mail.app:
Subject: Re: [TxMt] Cmd-` doesn't really cycle through the windows? Message-Id: 420783A5-920C-444F-AE05-7D632B8B3EB4@macromates.com
Subject: [TxMt] elusive key bindings & UI confusion In-Reply-To: 420783A5-920C-444F-AE05-7D632B8B3EB4@macromates.com
Jeroen.
On Jun 13, 2005, at 8:05 PM, Allan Odgaard wrote:
For b13 I've changed both these two panels to be normal windows. This means that new items no longer get the current scope as default scope, but window-cycling works as expected :)
Excellent, thanks! I didn't even know that new items were getting the current scope as default scope :-) Or that those windows could be closed by a simple esc :-)
Haris
-
Allan Odgaard -
Ben Parzybok -
Charilaos Skiadas -
Jeroen van der Ham -
Mats Persson -
Sune Foldager -
Tom Lazar