Re: Forms highlighting
Dnia sobota, 7 października 2006 09:23, napisałeś: There is a new version at: http://haridara.googlepages.com/forms.vim Significant changes being: - Support for disabling fields. This may be question of gusto but IMO disabled field should be visible but greyed out, not completely hidden. I know some usability studies favor hiding it but it is usually in GUI when disabled element is completely removed, empty lines in Vim form look strange. Rest feels very nice. Thanks for fixing multiple same-hotkeys problem. I modified the demo to include both enabling/disabling fields as well as validation (zip field). When inserting non-valid data it is almost impossible to leave zip field. At least some warning message would be appropriate. This is not for forms stuff but demoform should set good standards for interaction :) On Thu, 5 Oct 2006 at 1:19pm, Mikolaj Machowski wrote: C-N, C-P? It should work everywhere and is quite natural for Vim users (IMO). Now C-N and C-P also work like Tab and S-Tab. Thanks. It has problems when leaving combobox backward but so far it is the best way to navigate in Linux terminal. I would expect some simplifying in use. For example why explicitly declare them? Create listeners automatically. I am not still clear. How can you create listeners automatically? Can you give some example? Maybe by comparison. Now creation of form is: 1. Create listener 2. Define listener functions 3. Create form (g:forms#form.new) 4. Add fields and in buttons declare listener explicitly 5. Add loop to add listener to all other fields 6. Add listener events functions Steps 1. 5. and second half of 4. IMO are not really necessary. Make it: 1. Create form (g:forms#form.new) 2. Define listener functions 3. Add fields 4. Add listener events functions Creation of listener could be done in form.new depending on argument of call. - Validators. Local validation (onBlur event) can be already done. Problem is when doing after pressing OK. Hmm, in fact it can be also done but is boring ;) to do. Some API for that would be good. How was onBlur event possible? Previously you could do validation in the valueChanged() callback, but you couldn't constrain the focus, but the new isValid() callback allows that. My mistake, looked like valueChanged works in way of onBlur. Title may be declared. Make it support for non showing it, like:: What is the use of declaring it when not showing? Are you thinking of it as an identifier, like a name for fields? Yes. One change which would be good to introduce before official beta: obligatory fields. As I wrote earlier - full validation if possible but laborious. And declaring it in API should allow for some emphasis (highlighting?). Does the new isValid() callback meet your expectations? Sorry, don't have time to test it but I suspect this is exactly what I want. m.
Re: Forms highlighting
There is a new version at:
http://haridara.googlepages.com/forms.vim
Significant changes being:
- Support for disabling fields.
- Validator support.
- Cursor monitoring to prevent accidental editing of readonly parts of
the form.
- Several bug fixes.
- F2 to start edit mode.
- Implemented several TODO items.
- Added some new TODO items :)
Combobox functionality is now less flaky, but I have some ideas to make
it better, especially with the readonly version. I have put in several
guards to make sure editing can be done only in the areas where it is
supposed to be done. Please feel free to break this and let me know so
that I can plug any more holes.
I modified the demo to include both enabling/disabling fields as well as
validation (zip field). The demo could be something useful, e.g., a find
dialog like in MS Word, but that could be a lot of work and I would
rather spend that time in improving the script.
See below for my comments.
On Thu, 5 Oct 2006 at 1:19pm, Mikolaj Machowski wrote:
C-N, C-P? It should work everywhere and is quite natural for Vim
users (IMO).
Now C-N and C-P also work like Tab and S-Tab.
I would expect some simplifying in use. For example why explicitly
declare them? Create listeners automatically.
I am not still clear. How can you create listeners automatically? Can
you give some example?
Check example I send earlier. Core stuff is quite simple, big part of it
is overhead dealing with listeners.
Part of it is due to the workarounds you had to put in (which is no
longer needed, I fixed the problem) and the rest is expected if you want
any dynamic nature. If you want to simplify, all that you need is one
listener for the OK button and you are done.
In any case, I have added checks to make callbacks only when the
dict function is defined (with no errors), so there is more flexibility.
You can have all the three callbacks in one dict and use the same dict
for all fields, or split them into different dicts.
- Validators.
Local validation (onBlur event) can be already done. Problem is when
doing after pressing OK. Hmm, in fact it can be also done but is boring
;) to do. Some API for that would be good.
How was onBlur event possible? Previously you could do validation in the
valueChanged() callback, but you couldn't constrain the focus, but the
new isValid() callback allows that.
- When the focus is moved in, explicitly set the value again, to make
sure any fouled up entries are fixed.
Don't understand that. Maybe you were thinking about moving out of
field (onBlur JavaScript event)? It is already possible.
I was just referring to accidentally removing too much (e.g., the {}
bounds of a combobox). Now I am reasonably confident that this is not
possible, so I removed this TODO item.
- Recognize no/empty title.
Title may be declared. Make it support for non showing it, like::
let demoform = g:forms#form.new('Address Entry Form', 1)
To show it and 0 for non showing it.
What is the use of declaring it when not showing? Are you thinking of it
as an identifier, like a name for fields?
One change which would be good to introduce before official beta:
obligatory fields. As I wrote earlier - full validation if possible but
laborious. And declaring it in API should allow for some emphasis
(highlighting?).
Does the new isValid() callback meet your expectations?
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
RE: Forms highlighting
On Thu, 5 Oct 2006 at 9:35am, David Fishburn wrote: I gave the demo a whirl. When you enter the State field the omni completion pops up. You cannot hit escape to get out of this. In fact you must choose something, even if you didn't want to. You can press C-E to close the popup, just like for the normal completion popup. Escape restores the old value, but doesn't close the popup. There is a lot of scope for improvements with the combobox, but using the Vim native popup features, it is very hard to do this. I am thinking of using a recursive expr map in combination of getchar() to make this better, but I don't know if it will work. It is right now usable, though a bit flaky. Entering the Country field. If you cursor is on U, press C. I wanted to just type Canada, but of course C in normal mode changes to end of line. So this wiped out the rest of the line. It seems when the is gone, things get messed up. You can't actually type anything. I plugged a lot of such holes in the latest release. I encourage to break it in other ways and let me know how you did it. There is no reward for breaking though :) (well, you could consider a more robust form.vim as a reward). So I restarted the form. When to USA hit cw, typed in Canaada. Realized my mistake, but my cursor on the a and hit x. Since I was in visual mode this left me with xada. Now use the left and right keys to reposition yourself. Very funky behaviour ending up with the existing characters being repeated many times. Actually it does this with h,l as well. This is an issue with complete(), you can only specify the start column, and end column is restricted to the current column, so you can't complete an item when the cursor is in the middle of it. I faced this same issue with LookupFile also, and the solution was to just hide the popup if the cursor is not at the end. I did the same thing here, so you shouldn't see this anymore. That is all I had a chance to try this morning. Thanks for trying, I was actually counting on you :) -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Forms highlighting
Dnia czwartek, 5 października 2006 01:16, Hari Krishna Dara napisał:
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.
C-N, C-P? It should work everywhere and is quite natural for Vim
users (IMO).
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?
Former.
- 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).
I would expect some simplifying in use. For example why explicitly
declare them? Create listeners automatically.
Check example I send earlier. Core stuff is quite simple, big part of it
is overhead dealing with listeners.
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).
- Pressing Esc in textfield doesn't let you BS into the existing
value
(need to set backspace=start, but this is global).
- Support for radio buttons.
- Optional user completion for textfields and comboboxes (no preset
data).
- Support for disabling fields (greyed out and no editing or focusing).
- Validators.
Local validation (onBlur event) can be already done. Problem is when
doing after pressing OK. Hmm, in fact it can be also done but is boring
;) to do. Some API for that would be good.
- For non-editable comboboxes, don't accept a value that is not in the
data.
- C-N/P in select mode should cancel selection and bring up popup (or
do
nothing by setting 'keymodel' to empty value, but this is global).
- When the focus is moved in, explicitly set the value again, to make
sure any fouled up entries are fixed.
Don't understand that. Maybe you were thinking about moving out of
field (onBlur JavaScript event)? It is already possible.
- Detect cusor movements beyond the fields and disable modifiable. This
will
reduce the chance of accidentally mucking up the form.
- Avoid first empty line (in an empty buffer).
- Recognize no/empty title.
Title may be declared. Make it support for non showing it, like::
let demoform = g:forms#form.new('Address Entry Form', 1)
To show it and 0 for non showing it.
- Encode the field boundaries (like [], ) in the field itself. This
will
make some of the logic more generic and will make it more flexible to
change them.
One change which would be good to introduce before official beta:
obligatory fields. As I wrote earlier - full validation if possible but
laborious. And declaring it in API should allow for some emphasis
(highlighting?).
m.
RE: Forms highlighting
I gave the demo a whirl. When you enter the State field the omni completion pops up. You cannot hit escape to get out of this. In fact you must choose something, even if you didn't want to. Entering the Country field. If you cursor is on U, press C. I wanted to just type Canada, but of course C in normal mode changes to end of line. So this wiped out the rest of the line. It seems when the is gone, things get messed up. You can't actually type anything. So I restarted the form. When to USA hit cw, typed in Canaada. Realized my mistake, but my cursor on the a and hit x. Since I was in visual mode this left me with xada. Now use the left and right keys to reposition yourself. Very funky behaviour ending up with the existing characters being repeated many times. Actually it does this with h,l as well. That is all I had a chance to try this morning. Dave
Re: Forms highlighting
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. 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? 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 don't know if this is more intuitive, but I know Java Swing/AWT framework (the only GUI framework that I am familiar with) doesn't have separate widgets. OK. We have to be careful in doing this. E.g., if you change the height while there is only one window, Vim will behave strangely. Yes. I don't know if there is any similar side effect of changing the width when there is only one window. No. 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. Unfortunately it goes wild when form will be opened in vertical window... What do you mean? Status lines goes up. 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. 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? m.
Re: Forms highlighting
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
Re: Forms highlighting
I have updated it again. The main difference is some syntax highlighting rules and some tweaks. I also changed the hotkey to link to Underlined, which has both a color as well as underscore by default (and I doubt any colorscheme change this). I also added a few extra rules/conditions to highlight the right hotkey as well as the boundaries of fields and button labels. -- Thanks, Hari On Mon, 2 Oct 2006 at 5:33pm, Hari Krishna Dara wrote: My comments below. If anyone is still interested to try, here is how you do it: - Download the below file and put it in your autoload directory: http://haridara.googlepages.com/forms.vim - Start a fresh Vim session and execute: :call forms#demo() - Optionally, remove the downloaded file after you are done trying. It is very easy and safe to try it (I hope I haven't scared away folks with the warning in my previous email :) On Tue, 3 Oct 2006 at 1:31am, Mikolaj Machowski wrote: Hello, Below patch to yesterday version of forms.vim . Rather proof of concept than full solution but looks much nicer: Features: - highlight header of form in Comment - highlight labels of fields as Questions - hightlight hotkeys as Statements I applied your patch and it looks very nice, thanks for taking the time. One minor problem is that if the hotkey repeats multiple times in the label, it is highlighted multiple times. Limitations: - Buttons are not supported We can also highlight checkboxes and comboboxes differently. 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. - when there is more than one the same character as hotkey repeating hotkey doesn't cycle between them. It stucks with last entry with that hotkey I noted this down as a limitation for now. We can look at it later. I am creating a map of hotkey-field which will obviously not work if the same hotkey is used multiple times. On Mon, 2 Oct 2006 at 10:28am, Mikolaj Machowski wrote: Maybe not all. You should catch only switching between major modes and vertical movement. The rest isn't so important. When you Tab into the fields, the values are first selected so that the user can easily overwrite it (like most GUIs do). However, the user can press Esc once to get into the normal insert mode and change the values (there is currently a known issue with this that you can't change the value, unless 'backspace' has start). If you want, you can press Esc again to get into the normal mode to move around, but this will put the buffer in a 'readonly' state, so when you find the field that you want to edit, you can press Space on the field to get back into edit mode. Let me know if you have ideas on how this can be improved. 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. 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. 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 wish more people will come forward to try and give feedback, especially that it is so easy to try it. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Forms highlighting
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.
Re: Forms highlighting
A new version is available, to try:
- Download the below file and put it in your autoload directory:
http://haridara.googlepages.com/forms.vim
- Start a fresh Vim session and execute:
:call forms#demo()
The new version has support for listening to changes in the field
values. The demo can now automatically lookup city and state when you
fill in your zipcode using a webservice (you need wget in the path and
need Internet connection).
On Tue, 3 Oct 2006 at 11:59am, Mikolaj Machowski wrote:
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
Doesn't that just mean your term is not properly setup? I tried it on
win32 console vim and it worked just fine.
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.
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 :)
Wish: different highlighting of in drop-down menu (State) and
combobox (Country). Maybe use {} somewhere?
Makes sense, I took a note in the TODO.
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).
I don't know if this is more intuitive, but I know Java Swing/AWT
framework (the only GUI framework that I am familiar with) doesn't have
separate widgets.
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|
We have to be careful in doing this. E.g., if you change the height
while there is only one window, Vim will behave strangely. I don't know
if there is any similar side effect of changing the width when there is
only one window. 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.
Unfortunately it goes wild when form will be opened in vertical
window...
What do you mean?
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 ;)
I get several such urges and try to control myself. :)
E.g., I created a softtabstop plugin to allow setting tabs at arbitrary
locations (just like a word processor), just for the fun of it and
because I needed it once. However, after I finished it a few weeks back,
I didn't need to use it even once. :))
--
Thanks,
Hari
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Forms highlighting
My comments below. If anyone is still interested to try, here is how you do it: - Download the below file and put it in your autoload directory: http://haridara.googlepages.com/forms.vim - Start a fresh Vim session and execute: :call forms#demo() - Optionally, remove the downloaded file after you are done trying. It is very easy and safe to try it (I hope I haven't scared away folks with the warning in my previous email :) On Tue, 3 Oct 2006 at 1:31am, Mikolaj Machowski wrote: Hello, Below patch to yesterday version of forms.vim . Rather proof of concept than full solution but looks much nicer: Features: - highlight header of form in Comment - highlight labels of fields as Questions - hightlight hotkeys as Statements I applied your patch and it looks very nice, thanks for taking the time. One minor problem is that if the hotkey repeats multiple times in the label, it is highlighted multiple times. Limitations: - Buttons are not supported We can also highlight checkboxes and comboboxes differently. 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. - when there is more than one the same character as hotkey repeating hotkey doesn't cycle between them. It stucks with last entry with that hotkey I noted this down as a limitation for now. We can look at it later. I am creating a map of hotkey-field which will obviously not work if the same hotkey is used multiple times. On Mon, 2 Oct 2006 at 10:28am, Mikolaj Machowski wrote: Maybe not all. You should catch only switching between major modes and vertical movement. The rest isn't so important. When you Tab into the fields, the values are first selected so that the user can easily overwrite it (like most GUIs do). However, the user can press Esc once to get into the normal insert mode and change the values (there is currently a known issue with this that you can't change the value, unless 'backspace' has start). If you want, you can press Esc again to get into the normal mode to move around, but this will put the buffer in a 'readonly' state, so when you find the field that you want to edit, you can press Space on the field to get back into edit mode. Let me know if you have ideas on how this can be improved. 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. 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. 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 wish more people will come forward to try and give feedback, especially that it is so easy to try it. -- Thanks, Hari __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
