| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
There is no need to treat the currently focused window specially.
|
|
Use pull instead of push based model for display code. Previously view.c
was calling into the ui frontend code, with the new scheme this switches
around: the necessary data is fetched by the ui as necessary.
The UI independent display code is moved out of view.c/ui-curses.c into
vis.c. The cell styles are now directly embedded into the Cell struct.
New UI styles are introduced for:
- status bar (focused / non-focused)
- info message
- window separator
- EOF symbol
You will have to update your color themes.
The terminal output code is further abstracted into a generic ui-terminal.c
part which keeps track of the whole in-memory cell matrix and #includes
ui-terminal-curses.c for the actual terminal output. This architecture
currently assumes that there are no overlapping windows. It will also
allow non-curses based terminal user interfaces.
|
|
|
|
|
|
Only extend end of range when the motion did so too.
As an example this prevents motions like `$dg_` from deleting the newline
which was the starting position.
|
|
|
|
The macro replay code has since been refactored, making this
obsolete. There is only ever one input queue from which keys
are interpreted.
|
|
$ ./configure --disable-help
shrinks the binary by about 20K on a x86_64 system.
|
|
Previously the window content would not be scrolled down when
inserting a newline exactly at the start of the display area
as in the case when a file starts with an empty line and the
following is performed:
<PageDown><PageUp><PageUp>o
|
|
Some motions should fail (i.e. keep the initial position) when
the specified count can not be satisfied exactly.
Examples include t, f, T, and F.
Fix #497
|
|
|
|
Fix `gN` and delimited inner variants when given a count.
|
|
|
|
|
|
|
|
|
|
Rather than inserting a newline and then looking for leading white space
of the previous line we now gather the white space before newline insertion.
Also we no longer indent empty lines.
Close #472
|
|
Make sure the selection setting code (used to restore selections)
does not move the cursor.
Fix #479
|
|
Terminal.app sets $TERM=xterm-256color and ships a corresponding
terminfo description advocating that it is capable of color changes
to the 256 color palette when in fact it can not.
We introduce a new boolean option "change-256colors" which is
true by default but can be used to disable color changes. It is
automatically set if Terminal.app is detected using $TERM_PROGRAM.
This should fix display artifacts as described in #456.
|
|
Currently the key handling functions do not know through which mapping
they were invoked. As an example the `count` handler exploits the
implementation detail that the input queue is stored in contiguous
memory, meaning `keys[-1]` gives access to the digit being pressed.
This adds infrastructure to keep track of the two most recently processed
keys of the input queue.
The information is guaranteed to be accurate for the initial invocation
of the key handler but will be overwritten in case new keys are pushed
to the input queue (e.g. through vis_keys_feed).
|
|
|
|
<Enter> at the end of the file now inserts two newlines, unless there is
already one in place. This ensures that in 'normal' operation the file
is always new line terminated (as mandated by POSIX). It also means that
there is no problem displaying the right amount of ~ symbols at the end
of the file.
Unlike in vim the cell beyond the end of the file remains adressable
even in normal mode. This means something like the following (starting
from an empty file) might be a little confusing:
o<Escape><Left>dd
Because the starting position is beyond the last newline of the file,
nothing will be deleted.
For now we prefer to avoid the additional complexity, and difference
in behavior between normal and insert mode, needed to fix this slight
inconsistency.
Fix #294
|
|
|
|
Fix #371
|
|
Fix #372
|
|
Fix #448
|
|
The vis_keys_feed function is currently unaffected by this change.
It still creates individual undo points. While this is probably
undesirable from an API point of view, it keeps the lua based tests
that use undo points working.
|
|
Previously if you had a mapping for both `a` and `ab` the latter would
in effect be unreachable because the greedy search would always match
and then execute the former. With the new behavior we keep reading keys
until we have a non ambigious sequence. That is after pressing `a` nothing
will happen, if the next key is a `b` we will execute the `ab` mapping
otherwise we will perform `a` and whatever the action is for the next key.
Close #386
|
|
|
|
These are currently only updated for `x` and `y` sam commands,
whether they should be updated for other search related activities
(`/`, `?`, `n`, `N`, `*`, `#` etc.) needs to be investigated.
|
|
|
|
|
|
|
|
|
|
The handling of :unmap needs to be revisited at some point.
|
|
This should avoid undefined pointer comparisons.
|
|
|
|
|
|
When given a mapping like:
:map! insert >> ><>x>
whose end is a prefix of another mapping we should still remove all
already consumed keys from the input queue.
Fixes #436
|
|
Fixes #434
|
|
It can happen that the Buffer content used for the input queue becomes
<\000> where the NUL byte is intended to terminate the queue, but termkey
happily parses it and because it is delimited by < and > on both sides
we then interpret it as a key. In input mode this leads to the insertion
of a NUL byte which is displayed as ^@.
Close #432
|
|
The very first thing we do if that check is false, is return from the function.
|
|
|
|
|
|
|
|
Move all signal handling code out of "library" code into user application.
|
|
If the caller of vis_pipe is not interested in the output, redirect it
to /dev/null and close the pipe. Otherwise we would wait for possible
output (which might never arrive) only to throw it away.
As a consequence background processes can now be started with:
:> { plumber <&3 3<&- & } 3<&0 2>&-
whereas before one also had to explicitly close stdout:
:> { plumber <&3 3<&- & } 3<&0 1>&- 2>&-
|
|
The `:!` command did redirect stdout to a pipe which was used by
`vis-menu` to return the selected entry. However, this breaks
other interactive commands such as `:!/bin/sh` where command
output was never displayed. Instead we modified `vis-menu` to
re-open /dev/tty for its user interface which makes it work
as a regular filter `:|`
This patch also obsoletes the interactive flag previously passed
to the vis_pipe function. Interactive mode is instead enabled
by piping an invalid range.
|
|
The first argument is the file object while the second argument denotes
the full path to which it will be written. Path might be `nil` if the
file is going to be written to stdout.
The Lua function is expected to return a boolean value indicating whether
the write operation should proceed or be aborted.
|
