| Age | Commit message (Collapse) | Author |
|
Executing a vis:command("qall!") or similar from a Lua WIN_OPEN
event handler is a bad idea.
|
|
Since vis.lua now loads a standard set of plugins, we do not need
to include the visrc.lua file which might contain user specific
changes.
|
|
This might fix the tests on systems where /proc/self/exe is not available.
|
|
This loads the default plugins whose functionality can now
also be tested.
|
|
It is not worth the trouble to deal with different escaping rules.
The tests should be relatively small and self contained anyway,
hence comments should not be that important.
|
|
The problem is that :qall in the win open event would immediately
close the window before anyting gets executed.
|
|
This should make sure that vis always terminates and never hangs
waiting for further input. Lua errors in particular cause a new
window/file to be displayed showing a detailed error message.
Previously only this internal file was closed but the original
file remained open and prevented vis from exiting.
|
|
Using cpp(1) to remove comments might not have been the best idea,
some versions of clang leave trailing white space intact whereas
gcc removes them. These trailing spaces were wrongly interpreted
as <Space> input. This hopefully fixes the tests on Mac OS X.
|
|
Instead of using the keys utility to convert the textual key representation
into something a terminal would send and then pipe it to vis' standard input
use the Lua API to directly feed the keys into vis' input queue.
This has a number of advantages:
- it is less fragile: the keys utility is incomplete and only handles the
most common keys
- it is faster because there is no need to artificially delay input
after an <Escape> key to give vis a chance to distinguish between
a single <Escape> and the start of an escape sequence
|