On Fri, May 02, 2014 at 11:37:57PM +0200, [email protected] wrote:
> patch that scale the size of the fields of the index to fill the whole
> terminal width, while keeping their respective size.
All the additional complexity lies in "keeping their respective size".
You'll find attached my suggestion with aims to help in one case
(related to the initial report).
> If we have space available and that index_format ends with a field,
> then expand the field up to COLS - 1.
... but does not try anything about "respective size": the Bonus space
goes to the last field.
Note 1: I didn't found mvwaddnstr(..., -1) to obey its man page:
> If n is -1, then the entire string will be added, up to the
> maximum number of characters that will fit on the line, or until a
> terminating null is reached.
(don't know how to interpret "line" then)
Note 2: using COLS (rather than COLS - 1), a superfluous newline is
added after the last entry.
Long-run solutions about reduced width seem way more around
horizontal-scrolling and/or live column hiding.
There's also another thing to consider.
Contrary to a table where width could be expressed in %, abook uses an
index format with fixed width only.
We set a number of characters for an email or for a phone number, but
*not* to one proportionally to the other
Eg: "{name:20} {phone:10} {nick:10}" is in no way the same (semantically) than
"{name:50%} {phone:25%} {nick:25%}"
Moreover many fields are useless without their last characters.
If {phone}, for example, is striped down to 9 characters, we get into
troubles. Better for us to get the nickname stripped.
I think that any complexity added by trying to preserve a ratio among
column' widths isn't relevant since this ratio isn't relevant in the
first place.
I even think that respecting ratio gives more chance to strip more fields
introducing potential errors in more fields. Striping the last seems by
far a preferable behavior.
I talked here about ratio preservation in case of restricted width while
OP is about extra width available, but I doubt we should or could
easily have two distinct way to compute column width according to the
way the terminal dimensions changed (width increase or decrease).
diff --git a/list.c b/list.c
index 1f0af79..1130407 100644
--- a/list.c
+++ b/list.c
@@ -185,6 +185,13 @@ print_list_field(int item, int line, int *x_pos, struct index_elem *e)
if(width + x_start >= COLS)
width = bytes2width(s, COLS - x_start);
+ // if this is the last field and nothing follows (neither fields or fixed text)
+ // then override any fixed width for this field and use right-most space
+ if(width + x_start < COLS && ! e->next) {
+ // width = -1; // this would normally make mvwaddnstr() to write up to EOL or \0
+ width = COLS - x_start - 1; // without -1, newlines are introduced
+ }
+
if(width)
mvwaddnstr(list, line, x_start, s, width);
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Abook-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/abook-devel
