| Age | Commit message (Collapse) | Author |
|---|
|
I would still like to experiment with a busybox style editor
multiplexer which behaves like vi(m), emacs or nano depending
on argv[0].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Pass editor instance and text to operate on as parameter
instead of using global state.
|
|
|
|
Key bindings in vis are always recursive, hence mapping ~
to ~l will cause an infinite loop.
Instead vis supports special editor "keys" which map to
internal editor functions.
As an example one can thus map ~ to <vis-operator-case-swap>l
or even <vis-operator-case-swap><cursor-char-next>
Furthermore this makes it possible to completely unmap core
editor features such as operators, the corresponding funtionality
is still available via its corresponding special key.
|
|
|
|
This adds another level of indirection by defining keyboard actions
which will likely eventually be used by a :map command.
|
|
|
|
This will eventually be exposed via a :map style command.
|
|
The idea is to work more like a finite state machine. Every
function gets an additional argument keys which holds the
already read keyboard input. The return value of the functions
should point to the first not consumed key. A return value
of NULL indicates that more input is needed. The function will
be called again from the editor core when more input is available.
These changes are mostly mechanical and in many cases not
optimal, they will be cleaned up in further commits.
|
|
Key bindings are now specified as symbolic key strings, this
will eventually allow run time configurable key mappings.
This introduces a bulid time dependency on libtermkey which
can be found at:
http://www.leonerd.org.uk/code/libtermkey/
|
|
Also text objects in visual mode should now work better.
|
|
|
|
This cleans up the existing selection handling code and adds the
necessary bits to eventually support multiple cursors/selections.
The cursor position is kept track of using marks, which means
retrieving the cursor position is no longer a constant time operation.
Furthermore the terminal cursor is no longer used, instead the whole
window is redrawn after every cursor movement.
|
|
By now ui-curses.[hc] are the only files dealing directly with
curses related functions. Integration of a proper mainloop is
still pending.
|
|
If we use the file / virtual memory system as cache (using mmap(2))
and another process truncates the file we are editing, we have a
problem. All we can do is catch the resulting SIGBUS, close the
corresponding window and print a warning message.
To test this use:
$ dd if=/dev/zero of=TEST bs=8M count=1
$ vis TEST
:! echo TRUNCATE > TEST
|
|
Eventually this should probably be rewritten to use an iternal
regex engine, currently it has unacceptable memory usage, it
copies the whole text.
|
|
Closes #60
|
|
|
|
|
|
|
|
Also apply syntax rules every time the file name changes.
|
|
View should only display the file content, but not modify it.
|
|
If no range is given then stdin is passed through which allows
interactive usage as in
:!ls -1 *.c | slmenu
For this to work the command needs to use stderr for its user
interface and write any data for vis to stdout.
|
|
|
|
|
|
|
|
|
|
Win -> View, window_* -> view_*
|
|
|
|
Therefore vis->win->text->data becomes vis->win->file->text.
|
|
|
|
This fixes #45
|
|
|
|
|
|
Once again show mode in window status bar.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This adds yet another layer of indirection and stores vi related
stuff which is associated with a given text but shared among all
windows displaying it (e.g. marks).
This will also help if one wants to keep texts arround which
aren't currently displayed.
|
|
In theory only ui-curses.[hc] should depend on curses, however in
practice keyboard input is still handled in vis.c. Furthermore the
syntax definitions as well as keyboard bindings and selection code
in window.c still depends on some curses constants.
There is also a slight regression in that the window status bar
does not show the current mode name. This and related global state
should be eliminated in the future.
|
|
|
