Instead of only saving a window's currently displayed font's name to the
dump file, have Acme's Dump command save that window's combined low DPI
and high DPI font names when both are available.
See 9fans/plan9port#630
Previously the vertical bar in tick was always black; fine if you
use the standard black-on-white for everything, but any attempt to
add a dark mode ran into trouble with the tick being half hard-coded
black, half the new text color.
As it is allowed to use spaces in file names set interactively through
the tag since 7b1c85f, do not reject names with spaces in the 'name'
ctl message either.
Fixes#559.
In groff, Heirloom Doctools troff, and neatroff, the `\~` escape
sequence produces an adjustable (paddable) but unbreakable space.
mandoc, which does not perform adjustment or render to typesetters,
supports the escape sequence as a synonym for `\ `, the same as `\0`.
This extension is of long pedigree: groff has supported it for at least
30 years, Heirloom for 17, mandoc for 13, and neatroff for 6.
Do the same as mandoc to prevent mis-rendering of documents using this
escape sequence. Heirloom Doctools troff, a descendant of Documenter's
Workbench troff, would be a good place to look for a compatible
implementation of the adjustable semantics for this sequence.
Certain XkbOptions in X11 would change keysyms for modifier keys
between the key press and key release.
For example, under the XkbOptions "grp:shifts_toggle", though shift
keys remain Shift_L/R when pressed, they become ISO_Group_Next/Prev
when released.
This behavior makes devdraw unable to detect the release event
correctly and as a result mouse button 1 click always interpreted
as button 3 event after a shift key is used.
When the 9P connection is closed, reads on the connection will keep
returning 0. So, fossil ends up looping forever, trying to read a 9P
message, consuming 100% CPU. The fix interprets 0 bytes read as EOF.
Reproduce by killing the 9pserve process serving the fossil service, or
by listening on tcp and using 9p(1).
For fonts with subfiles that go beyond the xffff range, the font file size
calculation is incorrect, since lines beyond that range have additional
characters. This patch pads all of the ranges and subfont names with
leading zeros in order to keep them all lines the same length and fixes the
font file length calculation.
It's sometimes useful to know whether there's been editing activity
in a window. This PR adds that information to the ctl file.
Change-Id: I21a342ac636dd5c7701b3ed560e3526867329c2c
