Re: [vile] Using filter-til to replace format-til

[Thomas Dickey]

On Mon, 11 Aug 2008, J?~Anis R??cis wrote:

> On Sun, Aug 10, 2008 at 08:28:26PM -0400, Thomas Dickey wrote:
> > On Sun, Aug 10, 2008 at 03:46:09PM +0300, J??nis R??cis wrote:
> > >     store-procedure my-format-til
> > >         filter-til &gtmotion 'default' 'par -j1 -w70'
> > >     ~end
> > >     bind-key g my-format-til
> >
> > fixing minor typos:
> >
> >         store-procedure my-format-til
> >                 filter-til &gtmotion 'default' 'par -j1 -w70'
> >         ~endm
> >         bind-key my-format-til g
>
> Much appreciated.  :)
>
> > However, the repeat on the procedure will cause a &gtmotion on each
> > occurrence.  You can work around _that_ by adding a variable to record
> > the state (though that's clumsy - for instance, you could set the variable
> > to &stime to record the starting time of the macro, and prompt when it's
> > a new system-time).
>
> Based on this and reading through some documentation once again, I've
> managed to craft a macro that's already pretty close to format-til
> (except for error checking and other basic intelligence):
>
>    store-procedure format-with-external-til \
>        "operator:  format text in the region using par(1)"
>
>        ~if &equal $cmd-count 1
>            write-message 'External format pending...'
>            setv %fmtmotion &gtmotion 'default'
>        ~else
>            ; Undo the previous filter-til to preserve the original
>            ; meaning of the motion.
>            undo-change

I wouldn't have thought of that...

Aside from concerns about the undo-behavior, the rest of making a
store-operator command seems relatively simple (I may add an experimental
one, to see).

>        ~endif
>
>        $cmd-count filter-til %fmtmotion 'par -j1 -w70'
>    ~endm
>    bind-key format-with-external-til ^A-f
>
> It seems to work as expected with '<repeat-count>^A-f<motion>', but
> won't handle '^A-f<repeat-count><motion>'.  This is easy to get used
> to.
>
> While testing this macro, I ran into some weird interaction of the
> undo stack and macro tracing.  I wrapped the macro body in '~trace
> on'/'~trace off' for debugging and ended up crashing the entire
> program after a few undo/redo sequences.

It's not supposed to do this (of course).  I'll check/see what the bug is.


--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net