| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Except for special cases like gn and gN vis expected that a text object
would be a function mapping a position to a range as follows:
f: pos -> [start, end] with start <= f(pos) <= end
Clearly this condition does not hold for inner text objects when the
initial position i.e. the cursor is on the opening delimiter.
This also obsoletes the need for the SPLIT text object flag which should
be removed in a later commit if the current behavior is found to be
working as expected.
|
|
|
|
This is a not yet successful attempt to reduce terminal flickering
when resizing windows as is for example the case when entering
command mode.
UI related debug output can be enabled with:
$ make CFLAGS=-DDEBUG_UI=1
$ ./vis > log
|
|
Try to display a shorthand version in the status bar, this currently
only works for files below the current working directory of the editor
process.
|
|
This is encouraged by the ISO C99 standard.
|
|
|
|
Make window status bar content configurable via Lua.
|
|
|
|
|
|
|
|
|
|
Previously the interactive mode was implicitly enabled by passing
an invalid range. However for some use cases (e.g. completion) we
need to be able to pipe a given text range to an external process
without also redirecting stderr (which is used to draw the slmenu
interface on top of vis).
|
|
|
|
This caused issues on OpenBSD where it crashed the terminal.
Also on Mac OS X suspend via ^Z (Ctrl-Z) was missing a \r i.e.
the shell prompt was not properly redrawn.
While in principle user interfaces should not have to depend on
libtermkey, in practice this won't be an issue unless we are
adding a non-terminal based UI (which won't happen anytime soon).
This reverts commit 8f92b98848f9366e78c7aa824615bade83971513.
Close #311
|
|
Close #314
|
|
|
|
|
|
A concrete user interface implementation should not have to depend
on libtermkey. Therefore the vis core now uses an independent instance
to parse keys.
|
|
They behave like an inclusive motion, but only if they are also
linewise (which they are by default).
This should make `yjp` and `ykp` yank both the current and
the next/previous line when the cursor is at the start of
a line.
See also 532f52e9e52b98dc5749396f7353295418e0227a and #237
|
|
|
|
|
|
|
|
This is needed to make the vis.event.start Lua callback useful,
setting global options should be possible even if no windows exist
yet.
The :set command options should probably be cleaned up further,
some of them apply only to the currently active window while others
have a global effect.
|
|
Close #271
|
|
|
|
The built in commands should always be available.
|
|
|
|
|
|
This means no event handlers are run for it, hence there is no chance
for recursive errors.
|
|
Should have been part of f50465312dbb7e8fcb2409aa691d1aea7a43c466.
|
|
This reverts part of bd1d849b2033b04a372542c59d458d4f8279c937
just use a literal space within your key mappings.
Close #280
|
|
|
|
This fixes interactive :-commands when the user has configured
to set custom options vis:command(...) via the Lua win_open
event handler.
The problem was that the creation of the window for the command
prompt would itself trigger an execution of a :-command. Upon
successful completion the editor would switch to normal mode.
Therefore the interactively entered command would not be applied
to the correct range.
|
|
One should generally use <Space> in mappings:
:map! normal <Space> h
except for insert/replace mode where a literal space has to be used:
:map! insert " " foo
|
|
This improves responsiveness of {count}j for files with less than count
lines. For huge files this will still be slow because the code tries
to restore cursor position on every line before moving on to the next.
Also moving up will generally be slower than downwards. Use {count}%
(fastest) or or :count (slower) instead.
Close #267
|
|
Close #224
|
|
|
|
|
|
|
|
The following vi commands have been dropped:
- saveas
- xit
- !
The following commands are only recognized in their short form:
- e (edit)
- q (quit)
- s (substitute)
- w (write)
- r (read)
|
|
There exist two typical ways to use an array:
1) to hold pointers to externally allocated memory regions
Use array_init(...) for initialization, an element has the
size of a pointer. Use the functions suffixed with `_ptr'
to manage your pointers. The cleanup function array_release_full
must only be used with this type of array.
2) to hold arbitrary sized objects
Use array_init_sized(...) to specify the size of a single
element. Use the regular (i.e. without the `_ptr' suffix)
functions to manage your objects. array_get will return a
pointer to the object stored within the array.
|
|
|
|
|
|
|
|
This makes @: (and @/) work.
|
|
|
|
|
|
|
|
Also support upper case register to append to an existing macro.
|
|
|
