On Wed, 4 Oct 2006 at 10:37pm, Mikolaj Machowski wrote: > Dnia ¶roda, 4 pa¼dziernika 2006 05:06, Hari Krishna Dara napisa³: > > > > > > No. They are inserting some version of keycode: OA, OB, OC, OD. In gui > > > everything works well. In menus enabled > > > > Doesn't that just mean your term is not properly setup? I tried it on > > win32 console vim and it worked just fine. > > It is normal setup. > Arrows doesn't work in xterm, konsole, rxvt.
I have 6.3 version of cygwin and arrows work fine in rxvt. I stil think your term settings are not right. But this is not really concern forms plugin, though it means we might have to support some other maps that will reliably work in all the terms. > > > Bug: When completely remove value, leave field and later return > > > to it default value is forgotten, Esc is going to Normal mode. > > > > This is not a bug. When you leave the field, the value is immediately > > saved, which means the new empty value overwrote the old value. When you > > return back to the field, this empty value becomes your new default > > value. > > Hmm. Not sure if this is expected behavior, maybe other users could tell > more? Who? No one seems to be interested, it is just us :) > > > Bug: Form is creating swap file which makes hard to use simultaneously > > > the same form in various Vims when editing files in the same > > > directory. Solution: Add 'setl noswapfile' after 'setl nomodified' in > > > SetupBuf function (this is local option and but it is easier to read > > > when explicitly declaring as local). > > > > This is really not a bug. Since the user is creating the buffer, it is > > his responsibility to set noswapfile if he is intending to open the same > > form multiple times. We could set noswapfile in forms, but then if the > > Vim crashes in the middle of the form entry, the user could loose some > > important data :) > > OK. At least for demo use just "new" instead of "new Form". I intended that as a clue on the usage (suggesting a nice name for the buffer). Setting 'noswapfile' is not sufficient if you create multiple buffers with the same name (Vim will essentially open the same buffer in new windows). If we have to demo the ability to create multiple forms then some buffer management will need to be done there (creating unique buffers, tracking which form is shown in which buffer etc.). > > Again, since user is creating the window for now I > > think we should leave this to the user. When buffer management is > > implemented in forms, we can set these parameters. > > Problem with current implementation is that user cannot influence > dimensions of buffer. Before calling ShowForm he don't know them later > it doesn't work. Don't know why, when placing above lines after ShowForm > call formwidth is computed but it only places _ in first field. I don't know why it wouldn't work later, but I can certainly add functions to determine the widthPreference and heightPreference of the form. > One bug: > > On X11 @* (you are using to store form in clipboard) is > selection, which means that it will be overwritten by [OK] (visually > selected with normal navigation). At least on Unix systems you should > use @+ clipboard (don't know how it works on Windows). BTW - you don't > have to play with if/endif:: > > let @* = address > let @+ = address > > will do. I will make this change. > > Another thing. Until now I was only playing with demo. Now I tried to do > my own form and have one thing to say: > > Listener stuff is complicated. Can it be done simpler? Do you mean simplify the listener interface, or completely do away with them? - If you mean the former, then the alternative is to accept a function name (this is what my previous version worked). But a big problem with this is that the function has to be global and I hate defining global functions without intending them to be part of API, and I know several others feel the same. The current scheme of expecting a dict object should be more familiar to many, who worked with the newer GUI frameworks (such as Swing and Flex). While not having to define a global dict variable, it also provides a way to create more "contextual" listeners (you can e.g., put the form that the listener is attached to, without having to modify the listener interface to also expect the form object). - If you mean the later, then I don't know how we can do that. If you have any ideas, you can throw them on me. May be a scriptlet can be passed in as a string instead of a dict object, but I don't know if this can always make it simple. It may however be possible to support both. What do you think are the next priority TODO items before making the first release (or a beta release)? I am thinking if I fix the known issues and implement the items that improve the overall feel of a static form, it will be good enough. Right now, there are too many ways the user can end up in 'modifiable' mode and just remove/change anything, giving the impression that the plugin is not robust). -- Thanks, Hari __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
