Are there any recommendations for testing accessibility for TUI applications? The article mentions speakup, but as far as I understand, you need a hardware synthesizer to use that. Is it also possible to use orca?
I am not sure it is helpful to shoehorn terminals into being a second web. The terminal's strength is its simplicity.
For example, I really dislike mouse support in TUIs. 100% of the times I used the mouse on a TUI, I wanted to copy a piece of text. If the TUI hijacks the mouse and does something different with it (e.g. vim switching into visual mode) that is just annoying.
Of course a11y is important. But it barely works on the web and we won't get perfect semantics on the terminal without a lot of work. I say the better option is to strip down the experience to the parts that work well.
I agree that accidental mouse actions in a TTY are horrible, but generally speaking if you hold shift when clicking and dragging, it will work at the terminal emulater layer instead of sending the clicks to the program in the terminal. I have been shift-clicking like this for years. More because I'm generally in tmux than anything else. If I click and drag without shift I think tmux intercepts it usually.
My experience is that often when I think "I wish my email / browser / calendar / … did X" it turns out be a limitation of the underlying protocol. So even if you build all software yourself, you still have to make compromises when you interact with the outside world.
Looks like a helpful honeypot! Any tool that will public announce support for this spec is a tool I know to avoid because it collects telemetry without explicit opt-in in the first place.
DO_NOT_TRACK support doesn't mean tracking is not an explicit opt-in.
Example: the software crashes, and there is a crash handler that asks you if you want to send a crash dump. With DO_NOT_TRACK, the crash handler is disabled entirely, no question, no dump.
If it gets some adoption, that's probably how it will work. Those who have an financial interest in using tracking (ex: ads) probably won't support such an option.
I was working on something similar a while back (https://github.com/xi/spreadsheet) but ended up not using it. I just didn't end up being the first tool that came to mind when I was reaching for a spreadsheet. Not sure why.
I will definitely try out your tool and check if it works better to me.
Two random thoughts:
- In excel I often use the dragging feature, i.e. use a formula like $A2 + B$1 and then drag it in both directions. Does your tool have something similar?
- Another nice feature are visualizations. In my tool I added a bar() function that renders a value between 0 and 1 as a bar in the cell. Not sure how flexible that is, but I did have some fun with it.
Thanks for trying it, and the spreadsheet repo is great prior art — I'll dig through it.
Drag-fill. Not yet, but the parts are mostly there. The formula layer already carries abs_col/abs_row through tokenization → AST → eval, so $A2 + B$1 parses correctly today; what's missing is the editing op that copies a formula across a range and shifts only the relative components. Opened #17 for it. The tricky part isn't the rewrite, it's the keybinding — Vim doesn't have an obvious idiom for "drag," so I'm leaning toward a visual-selection + fill-from-anchor key (Y is a candidate) or a :fill command. Open to suggestions if you have a feel for what works in a modal editor. It also needs to land on top of the bulk-undo work in #8/#9 so a fill is one undo step instead of N.
bar() / inline visualizations. Love it, opened #18. The interesting design call is whether BAR returns a CellValue::Visual { … } that the renderer dispatches on (correct under column resizes, but ripples into CSV export, copy/paste, and how SUM treats a visual cell), or whether it just returns a string of block-drawing chars at eval time (trivial to add, but width gets baked in at compute time which is wrong). The first is the right answer; the second is a tempting MVP. SPARKLINE(range) is the natural follow-up once the abstraction settles.
I am working on https://github.com/xi/xiio, a minimal async runtime for python. It is mostly feature complete with a fraction of the code of asyncio or trio. It is great fun to get into low level stuff and hopefully it helps me to better understand the finer details of async programming.
I am still confused what exactly this tool is doing. I clicked on "examples" in the hope of finding an example of a generated policy. But it only gives examples of the configuration, not the output.
While OP can generate MD, HTML and PDFs we've since moved away from that as the default to an approach in favour of just rendering the outputs as HTML/JSX.
You're 100% right we should make it easy for anyone just checking out the project to see the generated results without running the examples. I will add a CLI example and commit the generated policies to the repo.
Thanks for pointing this out and sorry our docs aren't up to the standard they need to be.
reply