[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Dickey
Subject: Re: [vile] Using filter-til to replace format-til
Date: Mon, 11 Aug 2008 06:38:12 -0400 (EDT)

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'
    bind-key g my-format-til

fixing minor typos:

        store-procedure my-format-til
                filter-til &gtmotion 'default' 'par -j1 -w70'
        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'
           ; Undo the previous filter-til to preserve the original
           ; meaning of the motion.

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).


       $cmd-count filter-til %fmtmotion 'par -j1 -w70'
   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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]