> Yes. But what happens when you then edit that macro by putting the > register into a buffer, changing it, and yanking it again? This is not > uncommonly done. How should the registers be stored in .viminfo? How do > you write the input to the feedkeys function as a string in vimscript? > Etc.. These are the kinds of issues I was trying to raise.
Well, I don't see what the problem is? Just do it like today, maybe with some expansions e.g "<C-A><S-I><Tab>somechars<U-234>". I mean this is simple key-as-text representation and then text-representation- to-struct creation no? For example, the user records a macro into register q that is then displayed as "ihello<Tab>worlld<Esc><Left><Left>x". He then edits the macro in a buffer, yanks it into register q, and when @q is executed all it does is interpret the string? We'll probably need some escape mechanism to differentiate between the text "<Tab>" and the tab key, but this looks fairly easy to find no? Wether it being a special byte before the <> block or some \ or whatever. Maybe I'm oversimplifying it but it'd help if you were more specific about the "issues" the new design have. To me it looks like we just need to agree on a new set of conventions by describing how the new system would work for all the current (and future) macros/registers/ whatever scenarios. I suggest maybe we make some kind of "new design" draft which would answer all the issues raised (memory size/1970 support/macros concerns) ? Philippe -- You received this message from the "vim_dev" 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
