In TM1, this command:
mate path/to/dir1 path/to/dir2
used to open both dir1 and dir2 within the same TM main window
In TM2, this command:
mate path/to/dir1 path/to/dir2
opens two distinct windows, one for dir1, one for dir2
How to restore the behaviour from TM1?
Thanks.
Another unrelated question:
What is the rationale that defines where the textmate configuration is
set? For example, the antialias font settings is defined system-wide
with the user "defaults" command, while the font family is defined
within a .tm_properties file. From a very high level, this seems quite
weird - although I'm sure there is a good reason to do so, it does not
seem easy to remember where each setting should be set.
Cheers,
Manu
_______________________________________________
textmate mailing list
text...@lists.macromates.com
http://lists.macromates.com/listinfo/textmate
> […] open both dir1 and dir2 within the same TM main window […] How to restore the behaviour from TM1?
TM2 can’t show multiple folders in the same window.
> What is the rationale that defines where the textmate configuration is
> set? For example, the antialias font settings is defined system-wide
> with the user "defaults" command, while the font family is defined
> within a .tm_properties file.
You can change font via View → Show Fonts and it is stored in user defaults.
Generally things should be set in the GUI and .tm_properties is a way to *make exceptions* (generally for specific file types or folders) — though with the UI being incomplete, some stuff is presently only available via .tm_properties. Ideally even the exceptions should be setable via the GUI, but the flexibility of .tm_properties is hard to express with a GUI (that doesn’t resemble Apple’s property list editor) and .tm_properties will also evolve slightly in the future, which isn’t easy if one has to maintain a parallel GUI.
Is this a temporary limitation, or is it a final design choice?
I'm not sure how to work with TM2:
For example when working on a subset of a very large project,
searching for and editing some specific part of code in a library and
a unit test, what would be the way to address this kind of editing - I
mean without getting hundreds of useless files in the way?
Is it not possible anymore, or is there another way to search (and
work with) two sub directory trees at once?
Thanks,
Emmanuel.
>> TM2 can’t show multiple folders in the same window.
> Is this a temporary limitation, or is it a final design choice?
Nothing is final, but I don’t plan to add support for multiple folders in same browser.
Others might add it later when/if I open up the custom data source API, though Find in Folder, Go to File, commands running on a project (TODO bundle, SCM bundles, Make bundle, etc.) will all be ignorant about such custom data source.
Ok, understood.
So what is the recommended way - if there's any - to work on something
as simple as a small project that references system header files? For
example, how to look for a function declaration from the source code?
If I understand it right, the proper browser window should be selected
first before performing a search. This does not seem usable with more
than a couple of windows, so I guess that I missed something obvious,
didn't I?
Thanks,
Emmanuel.
> So what is the recommended way - if there's any - to work on something
> as simple as a small project that references system header files?
That is a very open-ended question.
I use ⇧⌘D on an #include/import statement to open the relevant header (used on another line, it pops up a dialog). This is for C/Objective-C/C++. The same key equivalent works in several other languages though.
> For example, how to look for a function declaration from the source code?
I am unsure how having multiple folders in the file browser solves this. I tend to use ⌘E followed by ⇧⌘F + ↩ to find functions. My convention is to always declare functions with a space after the name, and invoke functions without such space, making it real easy to find one or the other type via search — a tip here for ⇧⌘F is that you can hit ⌘1-n for the n’th result.
But I got a feeling I’m talking about something completely different than you’re asking about.
> If I understand it right, the proper browser window should be selected
> first before performing a search. This does not seem usable with more
> than a couple of windows, so I guess that I missed something obvious,
> didn't I?
Again, I’m not following you 100% here, but two things:
1. Define your project root, this is what ⇧⌘F defaults to. I sort of get the feeling you _are_ doing search in folder as I described above, but your issue is the wrong starting folder.
2. After hitting ⇧⌘F you can use ⌘⇡ to search “parent” of the currently selected folder. But defining the project directory of course is generally preferred.
> I am unsure how having multiple folders in the file browser solves this. I tend to use ⌘E followed by ⇧⌘F + ↩ to find functions. My convention is to always declare functions with a space after the name, and invoke functions without such space, making it real easy to find one or the other type via search — a tip here for ⇧⌘F is that you can hit ⌘1-n for the n’th result.
Maybe a quick example could give you a better idea of what I'm referring to.
A typical project I work with looks like the following:
sdk/
subdirA/
comp1/
src/
include/
comp2/
...
...
subdirB/
…
sdktests/
subdirA/
comp1_test/
src/
comp2_test/
…
…
I get use to launch TM1 this way:
mate sdk*/subdirA/comp1*
to edit both the component and its unit test at once, easily
navigating from the component to the unit test, etc. Using this kind
of partial subtrees was really efficient to only work with symbols for
a given component. Let's say I wanted to find all occurences of a
common function such as "fprintf" for example, I would be sure to find
the occurences only in my component and tied unit test, fully ignoring
any other components or unit tests not related to my work.
Editing from the root directory (the parent of sdk and sdktests) would
have included thousand of files, making any search a nightmare,
filtering out all but two subdirectories for a given work.
This example is about a component and its unit tests, but I also need
to work on a complete stack, which include a couple of libraries,
drivers, and application, out of a large directory tree. What I'm
seeking is a way to work with a subset of an existing, large tree of
source files.
This does not seem possible with TM2 anymore, so I'm looking for any
other way to restrict the edition to those 2 directories, ignoring all
other ones for a editing session.
I'm not sure how to do that with TM2.
Thanks,
Manu
I was about to suggest you to symlink these folders into some other one, and then edit the latter, but TM2 does treat folder symlinks as files, not folders unfortunately.
--
Adam Strzelecki
I submit that TextMate should adapt the BBEdit multi-file search or just copy it wholesale.
--mkb
On Dec 23, 2011, at 8:07 AM, Emmanuel Blot wrote:
> Editing from the root directory (the parent of sdk and sdktests) would
> have included thousand of files, making any search a nightmare,
> filtering out all but two subdirectories for a given work.
Even though, it would not be practical: we are creating one sandbox
(SVN branch) for every single task to fix/code, it would require to
create and remove symlinks many times a day. Moreover, symlinks would
get in the way when committing the work back to the SVN server, and I
would not want to plague SVN properties (such as svn:ignore) with
Textmate-specific workarounds :-)
Cheers,
Manu
One thing I really like with TM1 is its capability to deal with
several folders coming from different directory trees: there no need
to create a "project" document to quickly edit files that are
semantically related but that do not share the same tree.
It's not just about searching: it's also about having a project drawer
that only contains the file I need to deal with, not the gazillion of
files from a complete kernel, for example. It's far easier to navigate
around 100 files than around dozens of thousands of files.
I'm not sure how to work with TM2 without this feature, I guess there
is another, maybe better way for this feature. I just don't know which
one.
Manu