When I've got a lot of tabs open, I sometimes want to go from the file whose contents I'm editing to the listing of that file in the file browser. Didn't there used to be a way to do this? I can't find it. What I want is that the outline in the file browser should open the triangles as necessary to reveal the file listing and select it and scroll to it.
Xcode does this with Navigate > Reveal in Project Navigator.
If TM doesn't do this, could this be a feature request? If it already does, could you remind me how?
Thx - m.
--
matt neuburg, phd = http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 9! http://shop.oreilly.com/product/0636920044352.do
iOS 9 Fundamentals! http://shop.oreilly.com/product/0636920044345.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
I have two displays. If I have two TextMate projects open, one in each
display. When opening a file from the Terminal using the "mate" command
in the project located in the secondary display TextMate will correctly
open that file but set the focus on the project in the first display.
I'm not sure if this is a problem with TextMate or the OS X window
management but it can be quite annoying.
--
/Jacob Carlborg
I am working in a Rails project, and one of the files in the project tree is a catalog of books, exported from another system as a 1MB single-line file. When I engage multi-file search, I will end up in spinning-pizza-of-death until I force-quit the app. As a work-around, I have had to keep search from looking inside it by declaring it to be one of the non-text files (right after jpeg) in the preferences in order to be able to search for anything at all across files.
Is there a better way that I can handle this? It's non-ideal to never be able to look in a JSON file within TM. I can use BBEdit, which does not have any issue at all opening this file, but I'd like to keep it all together.
How else could I globally keep multi-file search from trying to read this file?
Thanks,
Walter
The new feature: mate --project $(uuidgen|tr -C $'\n-' 0) file.txt
is broken as it echoes:
$ mate --project 00000000-0000-0000-0000-0000000000000 xcrash.C
uuid_t: error parsing ‘00000000-0000-0000-0000-0000000000000’
and does not open in a new window. Also the alternative:
$ TM_PROJECT_UUID=00000000-0000-0000-0000-000000000000 mate xcrash.C
uuid_t: error parsing ‘00000000-0000-0000-0000-0000000000000’
does not work anymore.
In addition the —-project option is not documented in mate --help, where it still
is documented as —uuid.
Please fix as my workflow pretty much depends on it.
Cheers, Fons.
--------------------------------------------------------------------------
Dr. Fons Rademakers CERN - European Organization for Nuclear Research
Chief Research Officer 1211 Geneve 23, Switzerland
CERN openlab Tel: +41227679248 Mobile: +41754113742
--------------------------------------------------------------------------
Thanks. The recommendations worked. Adding L:(…) around all the injections selector does the trick. I don’t know why it didn’t work for me then, but probably because of the second problem. Simplifying the other selectors and not trying to follow the ERB syntax makes everything a little bit easier to understand (and correctly syntax highlight both languages in the same file).
Thanks a lot for the help!
El lunes, 30 de mayo de 2016 a las 14:36, textmate-request(a)lists.macromates.com (mailto:textmate-request@lists.macromates.com) escribió:
> On 16 May 2016, at 17:29, Daniel Rodr?guez Troiti?o wrote:
>
> > A simple version of my grammar looks like this:
> > [?]
> > 'source.swift.gyb - (meta.embedded.block.gyb)' = {
> The injection scope selector should use L:(?) so your injected rules
> go before Swift?s (as you also write yourself).
>
> > { begin = '(^|\s*)(?=%\{(?![^\}]*\}%))';
> This seems to be the problem, this rule doesn?t actually match
> anything as it?s a ?begin of line? assertion and then a ?look
> ahead? assertion.
>
> So while the rule ?matches? when you have `%{` at the beginning of a
> line, no characters are consumed, so we descend into the rule?s
> patterns, but here we also have the Swift rules, and the L:(?) only
> affects the priority of the root rules injected (not their children), so
> the Swift rule will consume the `%` character because it was not
> consumed by the parent rule?s begin pattern.
>
> A minimal version of your grammar that works would be this:
>
> { injections = {
> 'L:(source.swift.gyb - meta.embedded.block.gyb)' = {
> patterns = (
> { name = 'meta.embedded.block.gyb';
> begin = '%\{';
> end = '\}%';
> contentName = 'source.python';
> patterns = ( { include = 'source.python'; } );
> },
> );
> };
> };
> patterns = ( { include = 'source.swift'; } );
> }
>
> I understand you wanted to scope the leading/trailing whitespace and
> then re-use the actual matching of %{ and %}, but I don?t think this
> is possible, though I think it will be simpler to add optional matches
> like this:
>
> begin = '(^\s*)?%\{';
> end = '\}%(\s*$)?';
>
> Then name these captures for
> `punctuation.whitespace.embedded.[leading|trailing].gyb`.
