Monday, June 11, 2012

Re: Truncate "change" list

On Monday, June 11, 2012 2:34:42 PM UTC-5, Richard wrote:
> Well Ben,
>
> On 06/11/2012 11:36 AM, Ben Fritz wrote:
> >> Without such an ability, a small feature of my script
> >> will give incorrect results. I certainly do not want to
> >> have to go through some massive effort to get this to
> >> work; I was hoping for some already built-in Vim
> >> capability - Vim is really such an open environment.
> >>
> >
> > I'm really curious what this script is that you are making, that you want to make changes which are not part of the undo tree and are not repeatable with '.'. What sort of changes do you think people would want to have these characteristics?
> >
>
> I am not really ready for a general announcement, maybe a couple of
> weeks away, but for console Vim I've got a general forms capability.
>
>
> [...]
>
> So, to my issue with repeat '.' support. The gvim Edit menu has
> the Repeat menu item which executes '.'. For my system to do
> the Repeat operation, any of the menu drawing commands, etc.
> which where used to display the menus must be removed from
> the "remembered command" and the previous "remembered command"
> re-installed as the last command.
>
> Richard
>

Ah, so your plugin draws a UI by modifying the buffer, then removes the UI, again by modifying it.

Except for text areas where the user must actually make changes to the buffer, I think you could accomplish this with the :undojoin command. The idea is:

1. (user makes some changes)
2. undojoin | (draw UI)
3. (user invokes mapping but doesn't make any changes to the buffer)
4. undojoin | (modify UI if needed)
5. undojoin | (remove UI)

Since (2) + (4) + (5) add together to make zero changes, the effect of (1)+(2)+(4)+(5) in the undo tree (and possibly for the sake of repeat), is just (1).

In general though, accounting for user-modifiable text areas, I'm not sure how to handle it. Maybe the UI could provide a button to split a window with a scratch buffer for text entry instead of allowing direct user interaction. Or use an input() call instead of direct interaction.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

No comments: