Dnia wtorek, 3 października 2006 02:35, Hari Krishna Dara napisał:
> - Start a fresh Vim session and execute:
> :call forms#demo()
Looks very good (I am using last version).
> > Problems with current version of forms:
> >
> > - arrows doesn't work in terminal. They are completely messing things
> > eg. destroy knowledge about default value.
>
> Do arrows work like j and k outside form? Since I am mapping <Up> and
> <Down> keys, as long as they work outside form, I am assuming they
> shoudl work inside form also.
No. They are inserting some version of keycode: OA, OB, OC, OD. In gui
everything works well. In menus enabled
Bug: When completely remove value, leave field and later return
to it default value is forgotten, Esc is going to Normal mode.
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).
Wish: different highlighting of <> in drop-down menu (State) and
combobox (Country). Maybe use {} somewhere?
I looked in the code: you are making just difference between editable
and non-editable combobox. IMO would be better to split this in two
widgets: combobox and dropdown menu. With that you will be able to make
visual differences between those two items (highlighting, braces).
> > After some consideration <C-K> wasn't best suggestion. I think in such
> > forms is bigger probability of digraphs than somewhere else. Other
> > possibilities; <C-F> (may break behave mswin and/or Cream - obvious
> > client of such script); <C-D/T> no mnemonic value but are covering
> > indenting mappings.
>
> How about using <C-G>? i_CTRL_G is used to move around the buffer, which
> we prevent anyway, and it could be a good mnemonic too.
OK for me.
> > Maybe you are right. I am biased here - I hate buffer management and
> > if someone else can take care about that... ;)
>
> I agree, buffer management is messy, which is why putting the task on
> the user makes it a little easier for the first version to get out :)
>
> I have now uploaded a version with your changes.
>
> http://haridara.googlepages.com/forms.vim
>
> This version also contains an API to create forms. The forms#demo()
>
> function shows you how to use the API. You can invoke it as:
> :call forms#demo()
>
> I will enhance the demo with some buffer management as a suggested
> pattern for the users.
Good thing would be possibility to scale height of buffer to height of
form and width [1]. Usually when filling you want to check context. Also
in space preserving department: header is 3 lines high. First - empty
line should go to /dev/null; second - value of separator is doubtful
when highlighting works.
[1] User may want to split window vertically. Maybe full buffer
management isn't required but some elements for making it easier to user
would be good: eg. length and width of form.
This is complete addition to beginning SetupBuf::
setl noswapfile
let formheight = len(b:curForm.fields) + 3
exe "normal! ".formheight."\<C-W>_"
let formwidth = b:curForm.maxLblSize * 2
exe "normal! ".formwidth."\<C-W>|"
Unfortunately it goes wild when form will be opened in vertical
window...
> Are you interested to use the forms for any of your plugins or are you
> just helping me out? :) (in either case, many thanks).
I have idea where I would like to use it but at the moment it is rather
vague (tag form for HTML/XML editing). At the moment I want to have
something good in tool-box (new screwdriver syndrome ;)
m.
