| Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
Apparently `labels:` should be an empty list and not an empty string
if you want no default labels; my bad.
|
|
|
|
|
|
This allows to complete file names in latex code (e.g. `\include{foo}`).
|
|
Just a version bump, no changes required.
|
|
This hasn't worked in almost a year and even if it did it makes no
sense. Based on my testing lexing takes a couple milliseconds at
most. If it took 1 second (the default value for this option) vis
would be completely unusable.
If people want support for this it should be submitted upstream
and vis will act based on the outcome of that.
closes #1122: lexer no longer obeys redrawtime
|
|
This obviously draws on the alt_name parameter used in scintillua
but rather then passing it all the way up to the chain to
lexers.load() we will just handle it in set_filetype().
8a420ec accidently readded detection for the removed git-commit
lexer which somehow went unnoticed until we readded caching for
the new lexers. Instead of just removing it we can alias to the
diff filetype and only set the colorcolumn for commit messages.
This fixes the incorrect behaviour of adding a colorcolumn to diff
and patch files and thus completely reverts 0cc684f.
|
|
This adds `[not]dim` to the set of accepted theme keywords
|
|
As defined in https://peps.python.org/pep-0484/#stub-files.
|
|
|
|
When a new subprocess is created during an EXIT event of
another subprocess new_process_in_pool will update the
process_pool pointer. Since we use a pointer to a pointer
for iterating all processes during vis_process_tick its
value will be different before executing the event and after
creating the new subprocess. This causes the updated pointer
to be erroneously destroyed and leaves the Process of the
reaped child behind which causes consecutive waitpid calls
to fail with ECHILD.
This is fixed by destroying the proper current subprocess
and updating the iteration pointer accordingly.
Fixes: 0b015320382e74fcb385a46a81304f588ed27f77
|
|
There are probably more things to simplify but at least this makes
it easier to see what exactly is different between `<C-x><C-f>` and
`<C-x><C-o>`.
Some differences were removed:
* whitespace in range is treated the same for both actions
* empty range will expand to files in CWD for both actions
closes #1146: Complete file name and file path swapped in doc
|
|
fixes #1152: `:2x/foo/<cr>` in a file with only one line makes vis
get stuck in an infinite loop
|
|
fixes #1151 (part 2): Set foreground color for matching pair
|
|
fixes #1151: Set foreground color for visual selection
|
|
The view_style function is used to apply styles to ranges of text in
a view. It approaches the starting position where the style should be
applied by iterating the columns in the appropriate line using
this while loop:
while (pos < start && col < width)
pos += line->cells[col++].len;
The while loop will stop at the last character before the range where
the style should be applied.
This works fine until we encounter "empty" cells between the last
cell containing an actual character and the first cell to be styled.
This can happen if the last character before the range to style is
'\t' which gets expanded with empty cells by vis according to the
tabwidth option. Those empty cells get erroneously styled as well.
This is fixed by skipping all empty cells encountered before the
range to style.
fixes #1147: `win:style` styles more terminal cells than expected
|
|
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.
|
|
Sourcehut recurses into submodules when cloning the repo for building
so unlike github it uses the version of `test` that is checked into
the repo. This is better behaviour but does mean that the submodule
needs to be updated.
|
|
aka:
"check for EOF before unsetting row, col & line cache in view_coord_get"
"fix bug where visual-line selections after view were considered visible"
These commits have created more bugs then they fix. Reverting them
reintroduces #1074: Slave selection strangled by view cliff.
Fixes #1143: Disappearing selection
|
|
same as last commit, `fstab.lua` shouldn't be matched as `fstab`
|
|
The current literal file name detection for GNUmakefile, makefile
or Makefile could match anywhere in the file name.
For example the file type of `makefile.lua` (the name of our makefile lexer)
was detected as makefile.
This is fixed by requiring the literal patterns to start and end with
the string.
|
|
When passing an invalid handler type (i.e., any type that isn't a
string, function, or KeyAction) to Vis:map/Window:map, the editor would
map the key to an empty (zeroed) KeyBinding struct. vis_keys_process()
doesn't take this into account, so the key is never consumed from
the input queue, causing the editor to get stuck in an infinite loop.
|
|
suggested in [0] since it will be help for latex
[0]: https://github.com/martanne/vis/commit/dac6a7e#comments
|
|
|
|
|
|
|
|
{w,}ctype(3) character classes are essentially broken for non-ascii
text. 711447a tried to fix this for words surrounded by blanks but forgot
the use case of completing function and variable names in source code.
Instead of relying on the terrible ctype interface we can hand pick
a set that is good enough for both source code completion and writing
prose. This set is consistent with the old [:alnum:] behaviour for ascii
text but also supports words with single width non-ascii characters.
fixes 711447a: vis-complete: handle non-ascii text
closes #1132: Source code completion are broken
|
|
The temporary directory for vis-single was hard coded to /tmp.
If /tmp happens to be mounted noexec then vis fails as it cannot
run anything placed inside the temporary directory. If the TMPDIR
environment variable is set, respect it for vis-single.
|
|
|
|
|
|
|
|
|
|
fixes #1119: lua: lpeg module isn't actually optional
|
|
`SIZE_MAX` cannot be represented accurately in `lua_Number`. A correct
solution probably doesn't exist but we can silence the warning by
explicitly casting to `lua_Number` and changing the comparison to `<`
instead of `<=`.
checkpos() deals with large numbers for file ranges. For most users we
can assume no one is editing files that are `SIZE_MAX` bytes long (many
petabytes). For obscure systems where `SIZE_MAX` is a small number this
will result in a maximum range (in lua) of 1 byte less than before.
fixes #1120: vis-lua.c:504:21: warning: implicit conversion changes value
|
|
This is in response to a comment left on a35e7ea. Backwards compatibility
is a good idea for at least a release.
|
|
|
|
I thought I fixed these in the applied patch but I guess they slipped by
|
|
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.
|
|
|
|
The first point of this commit is to allow all options to be read from
lua. This has a number of uses for plugin writers. They are grouped into
a couple of tables depending on what they control:
`vis.options`: table with global configuration
`win.options`: table with window specific configuration
The second point is to allow you to set all these options as if they
were simply lua variables. Technically this is already possible by
using `vis:command("set ...")` but personally I think this interface
is cleaner. Note that this already possible for some things like the
current mode (eg. vis.mode = vis.modes.VISUAL). Examples:
`vis.options.ai = true`
`win.options.brk = " !?."`
`win.options = { showeof = true, showtabs = true }
There are a number of related issues and pull requests:
closes #803: Lua API: let plugins read the values of options
closes #812: Window layout property
supersedes/closes #717: Add ability to access tabwidth from Lua
supersedes/closes #1066: expose UI layout and allow it to be set from lua API
|
|
|
|
some users were (rightfully) annoyed by this
|
|
from feature_test_macros(7):
> Defining _XOPEN_SOURCE with a value of 700 or greater produces the
> same effects as defining _POSIX_C_SOURCE with a value of 200809L or
> greater.
Depending on the configuration and system pkg-conf files there can be
redefinition warnings. Rather than patching with a -U_POSIX_C_SOURCE
it can just be dropped instead.
|
|
|
|
The '[:alnum:]' set does not include non-ascii text which results in
the non-ascii text being replaced with newlines. Using the '[:blank:]'
set with no complement flag fixes this issue.
|
|
Before we were not taking non-ascii characters into account properly. With
this patch we still mix byte counts and "grapheme cluster" (i.e. complete
glyphs that are rendered in a terminal cell) counts but the code should
be less broken in the more common case now.
|
|
|
|
The only place where this behaviour was encountered was in
file_lines_iterator() and it was just being worked around.
|
|
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().
|