| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Blocking.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Not exercised anywhere except in the shell. I ran into it after running:
(print screen 34)
Introduced in commit d2f96cb0b6c5 on Sep 1. This is the sort of thing I
currently don't know how to write tests for :/
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
In the process we eliminate a whole bunch of duplication and give item
navigation a single source of truth.
Page-up isn't quite _identical_ to how it used to be before. Let's see
if it bothers us.
|
| |
|
|
|
|
|
|
|
| |
new test:
hit enter, go to thread view, hit enter again, go into thread view again. No crash.
Just bite the bullet and make item-index robust to single-thread tabs.
|
|
|
|
|
|
|
|
|
|
| |
Tests to create when I start creating tests:
hide an item. Cursor moves to a new item.
hide an item that's not the bottom-most item, hit down arrow. Cursor moves to a new item.
hide an item that's not the top-most item, hit up arrow. Cursor moves to a new item.
hide top-most item. Cursor on new item. Hit up arrow. No change. Scroll down. New item.
hide bottom-most item. Cursor on new item. Hit down arrow. No change. Scroll up. New item.
open a thread. Hit down arrow. No crash (item-index not called).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To hide all comments from the same thread as the item at cursor, press
ctrl-h.
To later unhide everything, press ctrl-u.
Currently ctrl-u works by creating a whole new tab (that you can back
out of using Esc). That gives a way to undo it.
Still some rough edges:
update number of items in view when hiding a thread
avoid clipping menu in channel view
undo a single hide without giving up previous ones
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
I'm increasingly missing CI.
|
| |
|
| |
|
|
|
|
| |
By definition that function can't support combining characters.
|
|
|
|
| |
Fake screens can't handle them yet.
|
| |
|
| |
|
|
|
|
| |
A more common hindi vowel.
|
|
|
|
|
| |
Inline render-code-point in one of its call-sites before we add support
for combining characters.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
There's a new example app showing this ability.
Still to go: support for combining characters when rendering text and
streams.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately the Unicode database doesn't actually provide obvious
metadata for combining characters. The process I followed is as follows.
I noticed that GNU Unifont provides the following files for download:
- unifont-13.0.06.hex: All Plane 0 glyphs
- unifont_sample-13.0.06.hex: The above .hex file with combining circles added
Downloading and diffing the two yields all code-points with combining
circles. I assume they are exactly the combining characters I care
about.
One mechanical difficulty is cross-correlating the above files that
include the code-point in each line with font.subx which does not. I got
things to work by modifying the above files in place until they have the
same format as font.subx, using the following Vim commands on each file:
:%s|.\{64\}|10/size^M00/is-combine^M&|
:%s|^.\{32\}$|08/size^M00/is-combine^M&00000000000000000000000000000000|
:%s|..|& |g
:%s|10 /s iz e|10/size|
:%s|08 /s iz e|08/size|
:%s|00 /i s- co mb in e|00/is-combine|
Now I can update the metadata with a Vim macro which jumps to the next
hunk and increments /is-combine on the previous line.
|
|
|
|
|
|
|
|
|
|
|
| |
https://en.wikipedia.org/wiki/Combining_character
The plan: just draw the combining character in the same space as the
previous character. This will almost certainly not work for some Unicode
blocks (tibetan?)
This commit only changes the data/memory/disk model to make some space.
As always in Mu, we avoid bit-mask tricks even if that wastes memory.
|
| |
|
|
|
|
|
|
|
|
| |
Yet another gnarly reason to start checking all arg metadata in
linux/pack.subx or something like that. With this bug most of my
programs (including browser-slack!) were working even though the
instruction stream was almost certainly misdecoded halfway through every
attempt to draw glyphs.
|