In another thread Allan Odgaard wrote:
TextMate will not search binary files, granted it knows that the file type is binary. So right-click a file (using the extension you want to exclude) in the project drawer and select to treat it as binary.
That helps, but isn't perfect. For one thing, it can't handle files without an extension, such as executables. If I just open a directory as a project, it's likely to be a mixed bag of source, object, and executable files. It's easy enough to tell TextMate to skip the object (*.o) files, but how do I tell it that the executable named "xyzzy" is binary?
There's another quirk related to filename extensions that drives me nuts. For various reasons, I have a lot of files with the extension "*.txt" which actually contain different types of data. We have, for instance, configuration files, SNMP MIB files, and plain ol' text files sharing that extension. I'd like different syntax highlighting rules to be used for each. So I open "foo.txt" and change the language to "MIB". Then I open "bar.txt" and change to "plain text", and so on. It seems that every time I open a file with the *.txt extension I have to fiddle with the language.
(Yeah, if it were up to me I'd give all these files different extensions. Unfortunately the naming conventions were established long before I was hired here!)
Since the majority of *.txt files I edit actually are plain text, I think it'd be great if I could tell TextMate explicitly, "Treat *.txt as plain text unless I tell you specifically otherwise" instead of having it automatically change the definition of the whole extension whenever I switch. I'd still end up changing types, but at least it'd cut down on how often I'd need to. Bonus points for remembering which full filenames have been manually mapped to something else.
What would be even better would be for TextMate to examine the contents of the file as well as the filename to determine what language it is. If the extension is ambiguous, check the first few bytes for a shell shebang line, or an emacs-style modeline, or some other clue as to the type. And I would absolutely swoon if the language definition itself contained a way to specify what to look for, letting TextMate try each language in turn until it found a match.
On 24 Apr 2008, at 21:46, Steve King wrote:
In another thread Allan Odgaard wrote:
TextMate will not search binary files, granted it knows that the file type is binary. So right-click a file (using the extension you want to exclude) in the project drawer and select to treat it as binary.
That helps, but isn't perfect. For one thing, it can't handle files without an extension, such as executables.
There is nothing there to indicate, that the file is what you refer to as binary. TextMate uses a heuristic where it scans the first 4 KB or similar, and if it looks like text, it is treated as text. But if you do not use extensions, you can’t expect programs to figure out what the type of the file is.
There's another quirk related to filename extensions that drives me nuts. For various reasons, I have a lot of files with the extension "*.txt" [...]
I am sorry, but from my POV using the same extension for different types is wrong, and “supporting” that is not exactly a priority.
You can however use double-extensions, like ‘file.real-type.txt’ and then update the language grammar of real-type to claim the ‘real- type.txt’ extension.
[...] What would be even better would be for TextMate to examine the contents of the file as well as the filename to determine what language it is. If the extension is ambiguous, check the first few bytes for a shell shebang line, or an emacs-style modeline, or some other clue as to the type. And I would absolutely swoon if the language definition itself contained a way to specify what to look for, letting TextMate try each language in turn until it found a match.
The grammars have a ‘firstLineMatch’ regexp to look for shebang and similar.
Allan Odgaard wrote:
There is nothing there to indicate, that the file is what you refer to as binary. TextMate uses a heuristic where it scans the first 4 KB or similar, and if it looks like text, it is treated as text. But if you do not use extensions, you can’t expect programs to figure out what the type of the file is.
I'm not asking the application to determine it, just a way to manually tell the app "this particular file is binary". As opposed to "all files with this extension are binary".
(Although I should note that whatever heuristic Perl uses to determine whether a file is text or binary seems to work in the huge majority of cases, so it's at least possible for the app to make an educated guess.)
You can however use double-extensions, like ‘file.real-type.txt’ and then update the language grammar of real-type to claim the ‘real-type.txt’ extension.
Alas, I can't go back and change years worth of file names. Again, this is where I'd like a feature to say "this PARTICULAR file is such-and-such" without saying "any file with this extension is such-and-such". Or even a way to say "treat this particular file as a different type for the duration of this session, but DON'T change the type associated with the extension". I don't care if the temporary association to an individual file is preserved across sessions.
The grammars have a ‘firstLineMatch’ regexp to look for shebang and similar.
Ah, I didn't know that! Is that a new behavior, or just something I've missed seeing? Is there any way to extend it to a multiline match so it could find something like an emacs modeline or vim config line elsewhere in the file? (The vim guys like to put it at the end of the file.)
On Fri, Apr 25, 2008 at 9:26 AM, Steve King sking@arbor.net wrote:
Ah, I didn't know that! Is that a new behavior, or just something I've missed seeing?
The latter. :-)
Is there any way to extend it to a multiline match so it could find something like an emacs modeline or vim config line elsewhere in the file? (The vim guys like to put it at the end of the file.)
http://konstochvanligasaker.se/tabmate/
j.
Jay Soffian wrote:
Is there any way to extend it to a multiline match so it could find something like an emacs modeline or vim config line elsewhere in the file? (The vim guys like to put it at the end of the file.)
Well, yes, I know about that. I was hoping for something native to the language grammar (such as 'firstLineMatch') that wouldn't require a plugin. From the docs it appears that TabMate still only scans the first line of the file, and the format seems fixed. I'm after something more general like a regex parser. A similar line used for vim rather than emacs looks like:
vim:tw=78:ts=8:ft=help:norl:
(Wrap at 78 columns, tabstops are 8 chars, filetype is "help", do not display as right-to-left) And, just to be different, the vim convention is to place the modeline at the bottom of the file.
-
Allan Odgaard -
Jay Soffian -
Steve King