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 before.
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 things?
Thanks and all the best for the New Year, --Torsten
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 before.
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 things?
Thanks and all the best for the New Year, --Torsten
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.
-Jacob
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 before. 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 things? Thanks and all the best for the New Year, --Torsten
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.
-Jacob
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 Javascript it'll give you a live update of my 'Basic Javascript Test' window. 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
Jacob Rus and Thomas Aylott wrote (with possible deletions):
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.
-Jacob
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. [...] thomas Aylott — design42 — subtleGradient — CrazyEgg
Dear Jacob and Thomas, many thanks for your replies.
Knowing that all keystrokes are buffered is good. Still, the situation is not quite satisfactory in my eyes since you can actually see at which rates TextMate *could* update and publish the editor window contents if the forking overhead would go away.
(Please correct me if I am mistaken here, but even if I write a TextMate command, there will still be the overhead to fork() the script interpreter, be it perl or ruby or whatnot. That's what I try to get around here.)
Thanks again and best wishes, --Torsten
-
Jacob Rus -
thomas Aylott -
Torsten Grust