I tried having a TYPE_ENUM field but that requires typing some part of one entry (with the field performing autocompletion after that). I then thought about perhaps having a TYPE_ALNUM field that has each of the alternative values set in their respective buffers which I first set with set_field_buffer. But how do you switch between buffers then? Or maybe I should have overlapping fields and switch between them in the app? That seems nasty. Any help?
Related
While using form fields I stumbled upon the following behavior of dynamically-sized fields. AFAICT, passing a right arrow key event to the form driver leads to appending of spaces to the field buffer. I.e., this:
case KEY_RIGHT:
form_driver(f, REQ_NEXT_CHAR);
break;
when the cursor is at the end of the field string will append spaces to the field buffer. I am baffled as to how this is the default behavior. IMHO, hard stopping at the end of the field buffer string would be the correct, intuitive behavior, and spaces should be appended only when the user explicitly does so.
Reading the source code I see this is tied to a compatibility macro(?) called GROW_IF_NAVIGATE? I see this as a prime example of a simple enhancement that allows the user to opt out of this behavior. In the meantime what are my options? Just trim?
EDIT: the behavior controlled by this macro is more bizarre than I originally thought. It only limits growth when moving after the end of the field as specified in the field creation. IOW, when the macro is disabled (0), after filling some part of the field the growth is still allowed until the cursor reaches the end of the field where the growth indeed stops. Trimming is perhaps the only recourse here.
From a cursory reading of the latest source code field navigation is not taking into the account the content of the field. The field buffer can be grown by either navigating to the right or typing in characters (or a combination of both). Navigation adds padding characters which are replaced with blanks when the field buffer is eventually evaluated. The macro GROW_IF_NAVIGATE allows/controls the growth of fields when the end of the field window has been reached.
It seems that the recourse is to either not issue the request to navigate to the form driver, and this requires keeping track of every and all field input, or simply discard all padding, but this invalidates input with trailing spaces.
It seems like it's simply more straightforward to hard-code the text values. In an event that these values should be changed it seems like it would be more logical to search for the relevant UI element in each activity's xml layout file rather than look through the entire strings.xml. Of course if you have certain UI elements across multiple activities that all share the same text then this might be an exception (like a back button for instance), but generally there doesn't seem to be much advantage to storing these in the strings.xml. Am I missing something?
I will give you two reasons;
1 - Avoid duplication: all of your strings in one place. also, you can use string value many times. when you want to change it, there is one place to do the change. that makes it easier to maintain.
2 - Multi-language support: if you want to translate your strings to another language you must have all the strings in Strings.xml
let me know if you need more clarifications.
As a bit of context, I am considering making a plugin for vim that would inline specific debugging and/or profiling information on along the left margin (ideally left of the numbers column) which would need to be 4-5 characters wide. However, I cannot find any means to accomplish this. I've searched around, and the closest thing I can find is vimscript code for inserting signs in the sign column, but the sign column is fixed at 2 characters wide.
I've considered the possibility of making my own makeshift column (to the right of the numbers column, in the normally editable text area) and somehow marking it as readonly, but that doesn't seem possible either- from what I've read, the entire buffer must be readonly or not; you can't have just a portion as readonly.
For completeness here's an example. I would like to programmatically insert a 4-5 character column before some text (with numbers set)
1 Text buffer
2 with some
3 text
to make
My 1 Text buffer
own 2 with some
text 3 text
Is there any way to accomplish this task?
The built-in feature for this is the sign column, but yes it is limited to two characters.
Depending on your use cases, it might be okay to enhance the signs with a tooltip popup (:help balloon-eval explicitly mentions This feature allows a debugger, or other external tool, to display dynamic information based on where the mouse is pointing.), or maybe place the additional information in the quickfix or location list.
Modification of the actual buffer has many downsides (as it effectively prevents editing, and Vim's main purpose is just that). What some plugins do is showing a scratch (that is: unpersisted, unmodifiable) buffer in a vertical split, and setting the 'scrollbind' option so that its contents follow the original buffer. For an example, have a look at the VCSCommand plugin, which uses this for annotating a buffer with commit information.
So basically I am trying to rewrite a bash script which uses dialog --radiolist for choosing locale,keyboard,time. At the moment the tag is a number that corresponds to a local (I created a hashtable for it). But because I have, and want to keep it that way for now, around 100 locales it gets messy at the end.
What I wanna achieve is to make it more compact without having to add or add an artificial, non visible item that might easily translate to its tag. (as a tag I would put the locale name)
What I have tried:
1. Noobish thing but I though that there might be some way to include empty like NULL in ASCII or 0, blank space etc, but dialog would always make it visible.
2. Exclude the item at all and finish on on/off but instead on/off takes place of item (not surprisingly if options are as follow --radiolist text height width list-height [ tag item status ])
3. Instead of letting the dialog on exit write to the output the name of the chosen locale I created an output statement myself.
I had red a lot about dialog and whiptail(http://linux.die.net/man/1/dialog, http://linuxcommand.org/lc3_adv_dialog.php) but always end up with having to add tag and an item. Would appreciate any suggestions and maybe some info if there is easily plug-gable dialog/whiptail compatible libs.
Thank You in advance
Perhaps you overlooked the --no-tags option (see manpage):
--no-tags
Some widgets (checklist, inputmenu, radiolist, menu) display a
list with two columns (a "tag" and "description"). The tag is
useful for scripting, but may not help the user. The --no-tags
option (from Xdialog) may be used to suppress the column of tags
from the display. Unlike the --no-items option, this does not
affect the data which is read from the script.
The question mentions whiptail and consistency, which could refer to consistency across dialog and whiptail. There is none, since
whiptail provides fewer options than dialog (inevitably, there will be differences, since there is no one-one mapping possible)
consistency as such between the two is done in dialog occasionally to help with compatibility (the reverse is not true).
In ncurses:
1.What does the A_PROTECT attribute do? Everywhere on the net, the docs just say: Protected mode. What is that?
2.Also I would like to mark the area where the user inputs characters with an underscore, but I would like when the user deletes or backspaces to have the underscore reappear. Is there an attribute that does that, or I have to manually do that?
Protected mode may refer to a little-used feature of some DEC terminals (notably the VT220 and related), called selective erase.
The general idea is that some text can be internally marked as protected. This doesn't change the way it is rendered on the screen, but character cells so marked are not erased by the DECSEL and DECSED (Selective Erase in Line and Selective Erase Data) commands.
This would typically be used to implement something like a data entry form. Field headings and markup would be protected text, and data entered into the fields would be unprotected. You can erase the contents of the form to reset it by performing Selective Erase; thus erasing the data fields but not the headings.
Protect mode is defined by the terminal I'm not sure if it does anything on modern terminals.
There is an attribute "A_UNDERLINE" that underlines a character if your terminal supports it.
For handling input you may want to look at the form library (distributed with ncurses) or cdk (http://invisible-island.net/cdk/)