[TxMt] Re: The overhead of 'Pipe text through' ...
oblivious at subtlegradient.com
Mon Jan 8 16:14:34 UTC 2007
On Jan 8, 2007, at 3:59 AM, Jacob Rus wrote:
> Torsten Grust wrote:
>> Dear all,
>> I'm hacking on a little project that is somewhat abusing the 'Pipe
>> text through' feature of TextMate's Web Preview window
>> (''abusing'' in the sense that I do not want to preview HTML
>> text). If you open the Web Preview and uncheck the 'Pipe text
>> through' option you can observe how rapidly TextMate can update
>> the preview (set the 'Refresh after change delay' to 0.00s and
>> type away in some plain text -- the update seems almost immediate
>> and you'll have immediate typing response in the editor window).
>> Enabling 'Pipe text through' makes TextMate pipe the current
>> editor window contents into the specified command. Even if you
>> only specify 'cat >/dev/null' as that command, you will notice
>> that text editing will become sluggish. I assume that this delay
>> is all due to the overhead of *forking* the specified
>> command -- executing 'cat >/dev/null' itself takes no noticable
>> time on files of size <100k on my Powerbook G4.
>> I've got two questions here:
>> (1) Is there a smarter way to receive live updates of the current
>> editor window contents? Maybe via the plugin API?
>> (2) How about a comptabile change in 'Pipe text through's
>> behavior? If the file specified in 'Pipe text through' is a named
>> pipe (mkfifo(1)) do not fork any command but simply write the
>> editor window contents into that named pipe. Otherwise, behave as
>> Item (2) sounds like a moderate change that could get us rid of
>> the forking overhead for at least some applications that need live
>> update. What are the chances that Allan has open ears for such
>> Thanks and all the best for the New Year,
> I'm not exactly sure what Allan's plans are, but as far as I know,
> all of the architecture for that part of the app (as well as just
> about everything else) is being rewritten for TM 2.0, so your best
> bet is probably to wait for that, and then give feedback. I know
> that Allan wants to do some unification of the regular html preview
> and the commands' html view, etc.
I've been lobbying for an 'update on refresh' option in html output
commands for a LONG time.
I have a little command that I use in the pipe text through thing.
It looks at the scope and guesstimates what you want to be previewing.
If you're writing HTML, textile or markdown, it'll show a live
preview of the rendering.
If you're writing a Rails View, it's supposed to render out the
actual url on your test server but I broke that somehow.
If you're writing CSS, it'll show you any url (including local
file:// urls) with that css applied to it.
The rendering slowdown of using the preview window used to be an
absolute blocker, but recently Allan has made sure that the text
you're typing will make it to the buffer even if it's a wee bit jumpy.
thomas Aylott — design42 — subtleGradient — CrazyEgg
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the textmate