martanne

> Long-waited NetBSD support in CI would be awesome to be finished too.

As the maintainer of the linked vis project, I can confirm that the provided SSH access to the CI environment is very convenient and saves a lot of time.

I would also like to see the NetBSD support completed. It turns out that up until last week, we missed a #define to compile out of the box[1].

[1] https://git.sr.ht/~martanne/vis/commit/01eef9f87b72b0c147367...

martanne

10년 전discuss

The Plan 9 manual pages and papers are probably a good starting point:

http://man.cat-v.org/plan_9/

http://doc.cat-v.org/plan_9/4th_edition/papers/

martanne

10년 전discuss

> A terminal app that has terminal features doesn't violate any principles of simplicity.

It still depends how these features are implemented.

For example in dvtm scroll back history is made searchable by piping it to $PAGER. Similarly, copy mode is implemented by using $EDITOR as an interactive filter.

martanne

10년 전discuss

> Adding tmux just to get scrollback goes against Unix philosophy.

There are also simpler tools which can provide scrollback support.

The whole Unix tty subsystem goes against the "Unix philosophy", that is why it was completely scraped in Plan 9.

martanne

10년 전discuss

You can be sure that the Kakoune authors are familiar with vi(m).

Having said that, if you like both vi(m) and the structural regular expression support of sam/acme you might be interested in vis which combines the two:

https://github.com/martanne/vis

martanne

10년 전discuss

These operations are already supported by using structural regular expressions. As an example

    x g/foo

will select all lines containing foo. Similarly

    x v/foo

will select all lines not containing foo. Sorting etc. is taken care of by piping text through external tools.

I was more interested in common editing tasks for huge files which according to this thread a lot of people perform using sublime text.

martanne

10년 전discuss

Thanks for the feedback!

Yes syntax highlighting for large files is a hard issue. I'm not really aware of an accurate an high speed solution supporting editing operations in huge files.

In principle the underlying data structure used by vis supports all modifications with linear complexity in the number of editing operations since file load. This is independent of the file structure (i.e. single line files should be well supported). However the frontend code hasn't yet been optimized so in practice there might be some problems.

Unless one specifies the blackhole register when deleting large parts of a file this will create an in memory copy (to enable later pasting at a different location). Better would be to keep a reference to the existing immutable text region.

martanne

10년 전discuss

A number of people expressed the need to edit large files. For the development of my own editor[0] I would be interested to know what kind of usage patterns most often occur. What are the most important operations? Do you search for some (regex) pattern? Do you go to some specific line n? Do you copy/paste large portions of the file around? Do you often edit binary files? If so what types and what kind of changes do you perform?

[0] https://github.com/martanne/vis

martanne

10년 전discuss

Does somebody know how it compares to radare2?

martanne

10년 전discuss

As the main developer of an editor (vis) using a similar segmented data structure (a piece chain, similar to a rope, but storing the text junks in a double linked list, thus asymptotically worse) I can attest that the performance is generally very good. Some work will be required to adapt/write a regexp library around some kind of iterator interface, but in general I found that persistent data structures are very well suited for editors.

One problem with the gap buffer is that as soon as you have multiple cursors/selections or in my case structural regular expression support, then you have to move the gap around all the time. Also undo/redo support is simply not as elegant as with a persistent data structure.

For syntax highlighting copying the relevant text region into a contiguous memory block is simple and works well. For now I'm trying a completely stateless approach to syntax highlighting i.e. the text coloring is always completely recalculated. This trades highlighting accuracy for simplicity, but in practice the results aren't too bad. Efficient syntax highlighting for huge files is a hard problem.

martanne

10년 전discuss

How do you plan to encode binary data in your JSON-based protocol? Base64? This will only increase the overhead.

While the human readability of JSON is nice, it has some serious flaws when the goal is to handle arbitrary data.

I have yet to decide what kind of protocol to use in my own vis editor[1], hence why I'm asking.

[1] https://github.com/martanne/vis

martanne

10년 전discuss

Thanks for the hacking file, it is a good read for people like myself who are interested in text editor implementations. If time permits I will try delve a bit into the joe code base.

As for the syntax highlighting in vis, yes it currently is stateless and only considers a fixed range of text prior to the start of the window. Having no state at all simplifies some things and allows vis to highlight even extremely large files at the expense of the occasional glitch. In practice it seems to work reasonably well.

This approach also requires that the highlighting is fast, because nothing is cached, it is completely redone after every cursor motion. I'm quite happy with LPeg so far, it is convenient to express grammars in a high level language like Lua. It also supports nested grammars nicely, but due to the completely stateless approach taken by vis this is currently not fully exploited. As an added bonus there were already ~100 lexers (of admittedly varying quality) available for use.

martanne

10년 전discuss

Kakoune is a fine editor.

Regarding vis, Lua is optional (you lose syntax highlighting though). libtermkey is a 3 file library and despite what the author claims it works, is useful and could be maintained in the vis repository if necessary.

If you think anything C++ related is lighter than something C based, then we just have to agree to disagree.

martanne

10년 전discuss

The nice thing about the pointer as mark thingy is that while the offset from the start of the file might change when something is inserted before it, the pointer will remain the same.

Anyway this was just an example. I agree that higher level languages (including functional ones) have their own merit. If I would start again today I might consider Rust. But again the LLVM dependency seems kind of scary.

Again for me an ideal base system is built upon a kernel, libc (musl), C compiler (cparser/libfirm), coreutils (sbase/ubase, toybox, busybox), editor (vis) etc. Writing a C compiler is non-trivial, but doable. Creating a C++ compiler on the other hand ...

A self contained (including terminfo entries etc), statically linked vis binary weights in at around ~800K. This allows usage in resource constrained sytems, I don't think the same would be possible using e.g. Haskell.

martanne

10년 전discuss

Some things are just more convenient/efficient to do in C. As an example the mark handling[1] used to represent cursors/selection relies on pointer arithmetic.

Other things like the syntax highlighting are implemented in Lua which is high level but still has low resource usage.

And yes part of the choice is also philosophical. I consider an editor a core system tool which should have minimal dependencies.

[1] https://github.com/martanne/vis/blob/02c6df7cd4bca89506cf1d0...

martanne

10년 전discuss

Yes the lack of binary packages is a known problem.

The whole project is still somewhat in flux, feel free to contribute by filling a packaging request to your favorite distribution ...

Historically it originates from a community which is comfortable building from source.

martanne

10년 전discuss

I agree there are a lot of interesting ideas in 9term/sam/acme and Oberon (which was the initial inspiration for the project). In the future I would like to experiment with integrating a few more, but unfortunately time is a limiting factor.

martanne

10년 전discuss

> Does it build with LuaJIT?

I'm not sure. I think a few Lua >= 5.2 dependencies have crept in, but it shouldn't be difficult to fix this if desired.

LuaJIT's FFI is indeed very nice, but it is unfortunate that Lua has essentially been forked after the 5.1 release. The current C->Lua interface has been manually written.

martanne

10년 전discuss

Yes from a design philosophy standpoint vis is closer to kakoune than {neo,}vim. The implementation is quite different though (no C++, no boost, no home grown scripting/extension/syntax highlighting language).

martanne

10년 전discuss

Reposting an answer from a related thread.

The main difference is that vis is written from scratch while neovim inherited an old and hard to maintain code base. This allows vis to experiment with various ideas:

- native multiple cursors/selection support

- structural regular expression support

- different core data structure resulting in efficient large file support

- LPeg based syntax highlighting

- Lua as an in process extension language

- client/server design (not yet implemented)

without having to care about backward compatibility and legacy systems. Of course this has also some drawbacks for example there is no existing plugin ecosystem etc

Submissions

Show HN: Abduco+dvtm a lightweight alternative to tmux and screen

comments