| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Also start using 256 colors, under the assumption most people will have
them.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
It turns out Lua has been providing us this information all along! I'd
just not created the space on screen to show it. Make it persist better.
Kilo now no longer tracks its own status messages, which is a regression
in a rare condition.
|
|
|
|
|
| |
I'd assumed that assume_default_colors updates fg/bg -1, but it doesn't.
Looks like I can't ever use -1 colors.
|
|
|
|
|
| |
Thanks to Mariano Guerra for the Nix command, and to Konrad Hinsen for
the Guix command.
|
|
|
|
|
|
|
| |
^/ works on Linux but not on Mac
^- emits the same character code on Mac
^_ seems to be the underlying character code, and works on both
ctrl-7 also emits the same character code
|
|
|
|
|
| |
Doesn't make sense to use '/' as a delimiter when we have hotkeys
involving '/'.
|
|
|
|
|
| |
For a variety of historical reasons, terminals pause every time you
press `Esc`. Let's get rid of that lag.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On a Thinkpad X13, the `delete` key emits `^[[3~` outside of Teliva.
Within Teliva, ncurses converts it to character code 330 (0x14a), which
it fails to recognize as KEY_BACKSPACE. Why?
My backspace is converted to character code 263, which ncurses does
recognize as KEY_BACKSPACE.
ctrl-h is character code 8.
Both 330 and 263 are valid Unicode code points, which feels really ugly
and ambiguous.
|
| |
|
| |
|
|
|
|
|
|
|
| |
I still don't understand the entire state space here, so I'm trying to
err on the side of improving discoverability of the `ctrl-h` escape
hatch. Without requiring too wide a window to show all hotkeys on the
menu.
|
|
|
|
| |
Also strip out a bunch of Lua's commandline parsing.
|
| |
|
|
|
|
| |
https://github.com/akkartik/teliva/issues/1
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far I've been trying to make Teliva follow the default colorscheme of
the terminal, but that easily ends up with illegible color combinations.
New plan: always start with a light background within Teliva. People who
want a dark background will currently need to mess with C sources.
This should somewhat fix https://github.com/akkartik/teliva/issues/1.
It's still not clear whether the default should be a dark or light
background. While dark background is more common in terminals, I believe
newcomers to terminals will prefer a light background. Then again, I'm
biased since I use a light background in my terminals.
|
|
|
|
| |
This is essential when debugging.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
When installing using NixOS[1], the screen looks wrong. It looks like
attrset(A_NORMAL) does not undo color changes with some versions of
dependencies.
[1] https://github.com/marianoguerra/marianoguerra.github.io/blob/master/advent-of-future-of-code/days/day-02.md
|
| |
|
|
|
|
| |
Thanks sejo.
|
|
|
|
| |
https://archive.org/details/akkartik-teliva-2021-11-30
|
|
|
|
|
|
|
|
| |
I wish I could just hide KEY_BACKSPACE and prevent myself from using it
by accident.
Then again, I'm not making this smarts available in Teliva programs
themselves. Just for the Teliva environment.
|
|
|
|
|
| |
Kilo likely never ran into this because it's only been tested on C,
which uses semi-colons at the end of each statement.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Short of syntax errors that keep us from parsing the teliva_program
table, we should now be able to recover gracefully from everything.
Yesterday I started to try to add this to load_definitions before
realizing most errors are only noticed while running `main`. But I
didn't think of recovering from the docall of `main` until this morning.
|
|
|
|
| |
It was printing a phantom null at end of line on screen.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
It makes me very nervous now that there's save_editor_state within
editor event loop, when the editor could be editing notes. Things are
slightly better than this morning, but this prototype still suxxors.
|
|
|
|
|
|
| |
I think I've gotten rid of all the segfaults, but it's still pretty
messed up: if you hit ctrl-g and go edit some definition, it doesn't get
saved. You're just storing the edit in the note.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm mindful of the way abstractions can create duplicate effort:
https://flak.tedunangst.com/post/browser-ktrace-browsing
== Kartik's SAD theorem
As programs grow complex, you will be repeatedly forced to either:
- maintain some State,
- perform some computations Again,
- or Duplicate some code.
Here a small amount of duplication seems like the best alternative.
Particularly since no syscalls are involved.
|