You've all seen html tables.
They are formatted somewhat like this.

English|Spanish|Esperanto
Dog|Perro|Hundo
Man|Hombre|Viro
Window|Ventana|Fenestro

This is fine for modest rows, but some rows have a hundred columns or more.
Not html tables perhaps, but database tables.
Possibly none of you have used edbrowse as a database client, but I have, in fact my job depended on it for several years,
and database tables can be very wide, and this format can be awkward.
What is the 35th column in this row? I don't want to count it out as I cursor over all those fields.
A friend suggested I add a command like col35 to find out; but how do I even know it is 35?
I guess 36, oops, guess 31, oops, all over the place.
Slow and awkward.

At this point let me pause and talk about something that has been in my head for many years.
edbrowse reads and renders an excel spreadsheet.
Once again a row in an excel sheet can have 100 columns.
The sighted person moves his eye across and finds quickly what he needs.
He can even go over to column 72 and look down the page to see what happens to that column.
We can't approach that in edbrowse.
Again, it's the long row problem.

Now staying with excel for a moment:
The best way, I think, is to read excel, which means we have to learn the binary format of excel, which doesn't sound like fun, but ok say somebody does that,
and translate it into html, and let edbrowse render that.
It's an html table, no problem, but excel has computational cells.
Like the total of a row, or column, or the average,
or any formula you like.
So we turn that cell into javascript code.
The related sells have onchange code so whenever you change them it feeds into the formula and the computed cell also changes.
We are generating the javascript, so we know edbrowse will run it properly.
I don't have to panic about es6 or whatever.
Admit it; that would be really cool!
Then finally, after you have changed the excel sheet in some way, you type w and it writes back out, converting back to excel format of course.
Cool!

But to be practical, we need some better line oriented commands for those long rows.

As I say, something like col35 to query cell 35 was suggested,
but I don't know if that gives us the power we really need.
Another possibility is ur, for unfold row.
Type this on the man row and it reformats to

English: Man
Spanish: Hombre
Esperanto: Viro

Now you have the power of edbrowse.
You don't know if it's column 35 and you don't care.
Search for Spanish and find the value in the Spanish column.

Type ,ur to unfold all the rows in the table.
Now you can search for Spanish and then type / / / / / to travel down the Spanish column.
That makes no sense in this example but in a business example you are traveling down a column that might make sense,
how a business factor changes over time.
And then the last row is the total or average or maximum or whatever the computed cell is.

Each tr entry would have a new boolean flag, unfold, and if true,
the render() routine in html.c would format that row in this manner, unfolded.
If false it would render the row as it does today, on one line, with pipes.
Sounds doable, but here's the problem.

In the database world, you make a substitute, and it does an update.
It needs the whole row, and gets it from the current line.
It gloms onto the key and puts that into the where clause.
And it sets each field by sql.
set foo = 7, bar = 8, bas = "hello world" where key = 3891;
Sure, but if it's not on one line,
we have to back up to the tr flag, refold the line internally, find the key, and then do the update.
Similarly for delete, insert, etc.
So there's a lot of side effects if we want to retain support for odbc and edbrowse as a database client, which I'd like to do.

excel I think is not a problem.
If you update a field by substitute, even if the row is unfolded,
the onchange code fires, another field is updated, the page rerenders,
the unfolded rows format as they did before, and it all works out.

Another awkwardness to ,ur, a large sheet, 1000 rows and each row 100 columns, now the file has 100 thousand rows.
Hitting return over and over to step through a row, then the next row, etc.
I like that edbrowse can handle large files, and even large web pages, wherein the result is as compact as it can reasonably be.
Not millions of lines.

The odbc complications don't arise if I stay with the col35 style commands, and leave each row per line as it is today.
But I don't know if we can easily find what we want that way.
Maybe col Spanish to print the value of the spanish column, and also tell me its index is 35, then I can type col35 in the future.
,col35 to show the entire Spanish column.
Course I need the names of the columns.
This is just the first row in html or excel.
In a database table there is shc for show columns.

I waffle between these two approaches.
column commands or an unfolded row format.
We need to think carefully, and perhaps discuss, before we write a single line of code.

Karl Dahlke