On Friday, March 25, 2005, at 12:45PM, Allan Odgaard <allan(a)macromates.com> wrote:
>On Mar 24, 2005, at 16:05, Gregg Thomason wrote:
>> [...] If it's replacing an existing app, it has to replicate workflow
>ehm... I'm pretty sure that all TextMate users did use a text editor
>previous to october 2004, and I doubt it replicate the workflow from
>any of these editors /exactly/! :)
Well, to be fair, you had the good sense to allow me to port BBEdit-style filter scripts with little to no effort (to pick but one of several examples). You *did* replicate everything I needed to get working: emacs keybindings (years of muscle memory), plus mac-ness (same), years of filter scripts and odd bits of code (that are more crucial to me than I let on), etc.
User-level extensibility works.
Just wondering if anyone else has experienced this. When I use the
scroll-line-down feature (Control-Command-DownArrow), it will not
switch the highlighted line with the last line of the text.
I.e. if the text has 10 lines, and line 9 is highlighted,
scroll-line-down has no effect. Can someone confirm this? If so, is it
the expected behavior, or should I file a bug, or is a bug already
Attached is a bundle to implement kill (^k) and yank (^y) as close to
the Cocoa/Emacs implementation as I've been able to get. I hope others
can get some use out of it as well.
Using TextMate, I've had a terrible time trying to overcome years of
muscle memory in using ^k to kill and ^y to yank. The same
functionality is certainly available in TextMate, but I just can't
make my fingers not expect ^k and ^y to work a certain way. Allan has
mentioned that a Cocoa-like kill buffer is on his todo list, but I
thought I'd attempt something to tide myself over until that arrives.
Some high-level things you should know about the bundle:
* It does map ^k and ^y.
* Like Cocoa/Emacs it uses a kill buffer totally separate from the
standard Cocoa clipboard.
* I couldn't figure a good way to implement the kill buffer without
using the filesystem, so that's what it does.
* In order to get the behavior as close as possible to a real Cocoa
kill buffer, it's a great kluge of multiple commands and macros. That
fact plus the fact that it uses the file system makes it sort of slow
(I think certainly usable, though).
I hope folks find some use in it.
I'm a little perplexed by this because I've searched the list and
can't find anyone else having this problem, so I'm starting to wonder
if it's just happening to me for some reason.
In the default W3C Validation command for HTML, which uses "Show as
HTML" for output, the perl filter leaves off the url part of the txmt
URL, which causes the frontmost TextMate window to be used as the
target rather than finding an explicit file. The problem is that
whenever you use that command (or I assume any command with HTML
output), the HTML output window *is* the frontmost window and so a
txmt URL without the file specified can't work.
Isn't anyone else seeing this?
It seems to me that the only way for this to work would be if the
output window wasn't counted when looking for the frontmost window. Is
I've fixed this problem for myself by changing the W3C validation command to:
curl 2>/dev/null -F uploaded_file=@/dev/stdin\;type=text/html
| perl -pe 's#(Line (\d+), column (\d+))#<a
...but I'm intrigued that no one else is reporting this problem. Does
this not happen for others?
I have a project where the .tcl files traditionally uses and
indentation of 4, and the .adp (html) files use indentation of 2.
Is it possible to set TextMate up to set the tab size dependent on the
mode? So far I've either stuck with a tabsize of 2 for everything, and
then hit once more on the TAB key in tcl, or I've been switching back
and forth, both of which are suboptimal.
On Wednesday, March 23, 2005, at 04:17PM, H H <hh(a)keensoft.com> wrote:
>I really like TextMate because its is not overly boated with features.
Be careful with the term "bloat", as it inspires religious fervor. Consider: Emacs includes a Tetris game and psychotherapist (albeit a poor one), among other things. Is Emacs "bloated"? Well it certainly increases the size of the download, but deleting eliza.el isn't likely to 1)radically speed that up or 2)make it perform better.
One man's bloat is another man's must-have feature.
>For instance, the discussion on adding an SFTP client to it, is
>baffling -- I don't like TextWrangler because the program is trying to
>do everything for everybody -- even its preferences are too complicated
>for most users.
On the opposite side of the coin, think about the number of people who demand this feature. Just about every professional programmer's editor on Mac, Linux and Windows has it. This has become a bullet-point you *have* to add, no matter how nonsensical.
> For my work I use Fugu to do my SFTP stuff, because it
>does a good job, it supports tunneling, which is something that an SFTP
>program should do. Leave the text editing work for TextMate, and let
>the focus stay there.
The point I'm trying to make here, is *your* work is not *my* work, and yet TextMate may be 100% applicable to *both* our jobs.
Or, phrased another way, "Software development is hard, let's go shopping."
If you're taking votes, though, my vote would be "no" on built-in S/FTP. Although "yes!" to a user-extensible plugin system for such gee-gaws, if you think the editor part is complete. :)