Ah, that will do for now. A long-term fix for this could involve using a custom protocol to communicate between Factor and emacs. This will also clean up issues with parsing Factor output where an unexpected error gets thrown; your protocol could differentiate successful outputs from errors.
Slava On Sun, Jan 11, 2009 at 9:35 AM, Jose A. Ortega Ruiz <[email protected]> wrote: > This is caused by a misinterpretation of Factor's output by Emacs' > comint mode. The latter expects output from the process to end in a > prompt, but in this case the trace from the throw appears after the > prompt. Factor's process is not dead, it's only that comint mode refuses > to take input. As a workaround, i've modified fuel-nuke-listener to > clean up the output. So, when this (or any other) hang up happens > > M-x fuel-nuke-listener > > should fix things. Note that this command does *not* restart Factor. > > A bit ugly, i know :) > > Cheers, > jao > > ------------------------------------------------------------------------------ > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > _______________________________________________ > Factor-talk mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/factor-talk > ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
