h.g. muller wrote:
There might still be a problem with the plain arrows that were added as
accelerator keys for <<, <, > and >> in the non-JAWS version.
I obviously put them in the wrong place, but I wanted to send a new
winboard.rc for commit that would have them moved to the NO_ICS
section. But I see that Eric in the mean time had moved them to the
NO_ALT
section.
I am not sure what the function of the NO_ALT section is. From the code
it is not obvious to me that there is any difference at all. The
reason for
moving was to make sure the arrow keys remain usable in the ICS window
for line editing.
I only chose that section because that's where 4.2.7 had those
accelerators. I checked the 4.2.7 source since the goal was pretty much
to get the 4.2.7 behavior back. 4.2.7 has no NO_ICS table, and I don't
know what it's for w/out examining the code.
For the joining problem: perhaps we should indeed add a command-line
option
to control this. In WinBoard I prefer joining, as the ICS window wraps
lines
in a very sensible way. (Tim's efforts in this area definitely were
very worthwile!).
In XBoard people might prefer the ICS to wrap for them. So we could
give the
option in XBoard and WinBoard simply an opposite default. How about
-keepLineBreaksICS true/false
where true would be default for XBoard and false for WinBoard?
We could add it as an undocumented option, as WB people are unlikely to
complain that lines are joined, and XBoard users will only complain when
they recall stored wild games on obscure servers.
Undocumented options? I know you want to make things easy for people,
but I must disagree with intentionally leaving options undocumented.
People who require ease of use never read the documents anyway. That's
why forums are always cluttered with threads that are essentially "how
to X" and replies essentially saying RTFM. But I see no harm whatsoever
in documenting all the arguments.
Related, but for another purpose: Is there a way to obtain the console
width?
I still think always joining lines, and let XBoard insert line breaks
by itself
when it writes to the console would be a fundamentally better solution
then
having an option to eradicate the ICS breaks or not.
Yeah, performing our own splitting sounds good if we can get the
character width of the console. Even so, having an option to disable
joining is good. Some people may like the server side breaking and the
included continuation sequence. I can say I like the look of it when
the server's width variable is set properly. With joining and then
client-side breaking, wrapped lines just continue at the start of the
next line instead of being indented (because of the continuation
sequence) which has the effect of lining things up nicely when there are
several breaks of one line. It does look good that way, at least IMO.
