| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Without also saving and restoring the editor mode when the
selections were added to the cache almost no useful actions can be
performed.
While we are at it the 3 jumplist functions can just be combined
into one.
|
|
As far as I could tell from the code this was supposed to be a
fixed size LRU cache of sets of selection regions. The structure
had a maximum size member but it was never set or used.
Furthermore there was some very complicated management of 2
parallel sets of regions. Instead of that mess just treat the
cache as a circular buffer.
Note that this is really not that useful at the moment. While the
selection regions are saved and restored the editor mode is not.
Therefore the selection is visible but not in any way usable. That
will be fixed in the next commit.
|
|
|
|
|
|
|
|
|
|
if vis actually wants to be a library exported symbols may need
mark up depending on the platform (eg. __declspec(dllexport)).
This needs to be hidden behind a macro because the way you export
is not the same on every platform.
I did this based on the assumption that vis.h was supposed to be
the only interface to the "vis" library. Since nobody actually
uses vis as a library I have no idea if this is actually correct.
Anyway marking up all prototypes like this allows for one to
convert all functions to static if a single translation unit is
used by inserting at the start:
#define VIS_INTERNAL static
#define VIS_EXPORT static
|
|
This might be controversial to some but for the purposes of the
editor there will never be more than one instance of vis. This
allows the compiler to use more efficient rip relative addressing
in the places where it knows the code is referring to the global
instance.
Once the code is compiling in a single translation unit with all
functions declared static this will allow for much better
optimization.
From the perspective that vis is meant to be a library, which is
what Marc clearly intended, changing vis_new() to vis_init() and
vis_free() to vis_cleanup() is still better design. The library
user should be allowed to place the vis instance wherever they
want in memory.
|
|
|
|
|
|
same as buffer commit Array is completely visible
|
|
Buffer is fully exposed to the program, no need to rely on the
linker to optimize useless code.
|
|
lets not make the code harder to read for no reason
|
|
There are a couple times when we want to set a style without an
active window. In those cases we just want to use base UI_STYLE_*s
and (Win *) is not needed.
This fixes a crash when trying to do a vis:info() from lua during
an initial file open event.
Note that this code is due for a serious refactor, ui styles
should be stored in Ui and window specific styles should be stored
in Win. Then we won't need any of this difficult to follow
indexing into the styles array based on window id and we will
never have to realloc when a new window opens. Just another thing
to add to my list.
|
|
When you take a pointer to a function in C that function is going
to appear in full in the final binary. This means that there were
3 sections of the final binary with the exact same code.
You could argue that in very high performance programs having that
function closer to the current instruction when it is needed will
give a performance boost but there are so many other places to
gain more significant speed ups in vis before that would be
remotely relevant.
In fact, removing these allows the buffer_append call to inlined
so that buffer_insert can be hopped to directly instead of
including a useless hop in the middle.
|
|
Currently there is now way for long running subprocesses like language
servers to gracefully shutdown.
When reacting to the QUIT event and invalidating the process handle
the subprocess will never be killed and destroyed because the
subprocesses are only checked during vis_run.
Collecting and killing subprocesses with invalid handles after the
QUIT event allows graceful shutdown.
|
|
Currently only Text objects can be piped to external commands.
This is tedious if data not available in any file should be passed
to an external process (e.g. building options and passing them to
vis-menu).
This adds the option to pass a buffer to _vis_pipe and provides wrapper
functions for the original behavior and the new one.
|
|
I already fixed the reason that this even existed (vis_event_emit
getting called at random times when the editor wasn't ready).
The option checking in main() was moved up because I noticed it
was in the wrong place while thinking about where to emit the INIT
event. There is no reason to do a bunch of useless work just to
print the version.
|
|
These are not seperate things and keeping them this way makes
gives this convoluted mess where both Wins and UiWins must have
linked lists to the other Wins and UiWins in the program despite
the fact that neither of them can exist in isolation.
This, like my previous cleanup commits, is part of a larger goal
of properly isolating the various subsystems in vis. Doing so is
required if we ever want to be able to have a vis-server and a
vis-client.
|
|
There is no reason why this isn't just a char *.
|
|
Same as previous commit each window only has a single View. No
need for it to be stored elsewhere in memory.
|
|
There only exists a single Ui so there is no need to force a
pointer redirection for accessing it.
The Ui member was moved down in vis-core.h to punt around an issue
with the way lua checks for existing objects. It may show up again
as I flatten more structs.
|
|
|
|
|
|
|
|
|
|
|
|
This removes the function pointer interface which was adding
needless complexity and making it difficult to add new events. Now
if new events are only meant for lua they only need to be added to
the lua interface. This will also have a minor reduction in
runtime memory usage and produce a smaller binary.
The only runtime difference is that QUIT happens after all windows
have been closed and their files freed.
|
|
|
|
Change the file displayed in a window by writing the new file name
to the window's file member.
This is useful to change the displayed file during events.
Using the edit command during an event caused by a pervious edit
command causes a double free.
|
|
This allows better control over styling, as well as potential for
entirely new UI elements implemented entirely using the Lua API.
|
|
The old style handling had a lot edge cases where one of the
colours or the attribute wouldn't get applied correctly. This
commit adds a new style_set() method to the Ui which should be
called instead of manually touching a cell's style. This also
means that the Cell struct can be made opaque since all the
handling is now done inside the ui-terminal files.
With this it is now viable to combine the light and dark 16 colour
themes into a single base-16 theme. This theme works very well
with the Linux virtual console and will now be the default theme
regardless of if the terminal supports 256 colours or not. This
should address the common complaints about vis not respecting the
users default terminal colours.
fixes #1151: Theming is sometimes partially applied or ignored
see #1103: terminal no longer has transparency/opacity
see #1040: Transparent background and setting options by default
|
|
Silencing compiler's -Wparentheses warning.
|
|
fixes #1151 (part 2): Set foreground color for matching pair
|
|
fixes #1151: Set foreground color for visual selection
|
|
according to POSIX wait(3p) the return status needs to be checked
and the macro WEXITSTATUS(stat_val) should be used to get the actual
return value on a normal exit. POSIX doesn't specify the value of
stat_val on abnormal exit and thus vis_pipe() should just return
-1 as it does for other errors
closes #1130: vis:pipe returns wrong exit status (when non-zero)
Thanks @pippi1otta for the report and suggestion.
|
|
|
|
|
|
Rationale
A modern text editor usually includes tools for helping user
to avoid mistakes in texts. Those tools include spell checkers and
programming language integrations. Though vis explicitly states
that the full featured IDE is not a goal, implementing some of
the tools might be achieved using its Lua API. Unfortunatelly
the API misses the ability to start a process and to perform
a communication with it without completely blocking the editor UI,
which is crucial for any tool that performs background tracking of
the inserted text (e. g. language servers).
Implementation details
New feature introduces new API method: communicate. The method
start a new process and returns a handle to communicate with
the process instantly. The patch inserts stderr and stdout
file descriptors of the process to the pselect call of the main loop
used for reading user input to track the process state without
blocking the main loop until the process is finished.
Any changes in the process state cause the iteration of the main loop
and are being exposed to the Lua API as new event: PROCESS_RESPONSE.
|
|
Reading from curs_refresh(3X) from curses, calling doupdate() repeatedly
will cause 'several bursts of output to the screen'. wnoutrefresh() has
the smarts to only copy the changed lines to the copied virtual screen,
but doupdate() does not.
There have been several bug reports related to flickering but all seems
to be inconsistenly reproducible due to different terminal buffering
behavior. See #1032, #327
Unfortunately, when I am using a slow display, I still notice
flickering, so this commit changes the routines for opening new windows
and splitting windows to wait until the last change is finished before
calling doupdate().
|
|
This enables restoring the terminal from a fullscreen command like
curses based program. Use cases are e.g. a file picker based on some
external program like nnn (https://github.com/jarun/nnn).
|
|
|
|
|
|
|
|
|
|
|
|
Once we have written all data we should properly close the (correct)
pipe. Before we wrongly closed the pipe connected to the standard output
stream.
More generally, we currently do not listen for child process termination,
but instead wait until all the connected pipes are closed. This might
be problematic in case the external process keeps hold of the standard
I/O file descriptors. One particular example of this is wl-copy(1).
See #929
|
|
|
|
There are two main ways how the input queue is managed in vis:
- vis_keys_feed(..) appends new input to the queue and immediately
starts processing it. Starting from the position before the call
i.e. ignoring any previously queued input.
This is typically used in key binding handlers where the input
queue still contains the mapping leading to the invocation of the
handler. In that case new input should be interpreted immediately,
before the handler eventually returns and its mapping is consumed.
- vis_keys_push(..) with pos=0, appends new input to the end of the
queue and starts processing it from the start of the queue, taking
the full content into consideration.
This is used by the main loop when new input becomes available.
This patch switches the handling of <C-c> after a SIGINT from the former
to the latter mechanism and fixes mappings using <C-c> in a non-leading
position.
|
|
|
