| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This reverts commit 7c1b9d0b91295323b5ed5ec3e09b46566288bc75.
The 'big hammer' isn't good enough. The recent changes view seems to
need state on the stack across invocations of the editor.
|
|
|
|
|
| |
..even if at the expense of leaking on the heap. Because the Lua stack
has very limited space (~20 slots). When it overflows, we segfault.
|
| |
|
|
|
|
|
| |
Not my aesthetic choice, but essential at the moment for quickly
interpreting Lua errors.
|
|
|
|
| |
Introduced Nov 28. Let's see if my intermittent segfaults stop now.
|
| |
|
|
|
|
| |
Still sucks, though..
|
| |
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
^/ 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.
|
| |
|
|
|
|
|
| |
Kilo likely never ran into this because it's only been tested on C,
which uses semi-colons at the end of each statement.
|
| |
|
|
|
|
| |
It was printing a phantom null at end of line on screen.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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 going to give up on hiding teliva_editor_buffer from kilo. It was
taking too much knowledge of extern function prototypes on both sides.
|
|
|
|
|
| |
We still need a proper story for file system side effects. But it's not
time yet for sandboxing considerations. Soon, but not yet.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're not using this yet.
I agonized over this decision for several weeks. Is Teliva's need to
restart with execve an utter hack or a good thing? I'm leaning towards
the latter. Constantly exercising the initial flow makes Teliva more
crash-only. We can build Steve Yegge's idea of immortality (http://steve-yegge.blogspot.com/2007/01/pinocchio-problem.html)
out of crash-only primitives, just by making reboots instantaneous. But
focusing directly on immortality tends to compromise crash-only by
exercising it more rarely.
One other issue this brings up: loading these Lua tables from disk is a
vector for arbitrary code execution. I need to fix these when I get to
sandboxing.
|
|
|
|
|
| |
I'm deliberately restricting this incompatibility to the editor
environment for now.
|
|
|
|
|
| |
I'm growing attached to ^e, so mildly breaking with convention there.
Perhaps this is a bad idea.
|
| |
|
| |
|
|
|
|
|
|
| |
Many thanks to dirkf for https://github.com/antirez/kilo/pull/73!
However, teliva is still not ASan-clean.
|
|
|
|
|
|
|
|
|
|
| |
I'd like to enable -Wextra as well, but that creates some false
positives.
I've at least made my changes clean w.r.t. -Wextra.
Now we have 4 remaining warnings with gcc 9.3 that seem genuine. Need to
fix those.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|