martanne

8 ms·

31.
by martanne 11y ago
Of course all data structures have different trade-offs. I just think the piece chain has some of the most favorable ones. The fragmentation issue you mention is true. Its effects can be mitigated by: 1) storing the pieces in a balanced sea
32.
by martanne 11y ago
In the same vein as the article, the code for insertion can be found at[0]. The interesting thing about the piece chain is indeed that it is a persistent data structure. This makes it relatively easy to implement non chronological undo&#x2F
33.
by martanne 11y ago
"Writing a standard C library from scratch is crazy. Its one of the most commoditized pieces of software. Its almost impossible to do it significantly better than existing implementations [...]" As the musl developers have shown,
34.
by martanne 11y ago
I'm all for experimenting with new ideas, however this seems to duplicate all the conceptual shortcomings I see in tmux. First of all, session support and terminal multiplexing are two distinct features which shouldn't be intermin
35.
by martanne 11y ago
I too find kakoune interesting and have recently begun to add multiple cursor/selection support to my vim like editor. https://github.com/martanne/vis
36.
by martanne 11y ago
I had the chance to take a Oberon related lecture and its simplicity is really nice. Some things found in Oberon, like tiling window management, I use everyday. The book describes the whole system including the RISC CPU design. As part of t
37.
by martanne 11y ago
A piece table[0] solves this rather elegantly. Since it is a persistent data structure, a mark can be represented as a pointer into an underlying buffer. If the corresponding text is deleted, marks are updated automatically, since the point
38.
by martanne 11y ago
Did you consider contributing to libfirm[0]/cparser[1] 0: http://pp.ipd.kit.edu/firm/ 1: https://github.com/MatzeB/cparser
39.
Show HN: Abduco+dvtm a lightweight alternative to tmux and screen(github.com)
1 points by martanne 12y ago|0 comments
40.
by martanne 12y ago
Since I've recently implemented a text editor based on a piece table myself, I spent some time researching where the concept was first used. One of the first references (1974) I found was to the Bravo text editor for the Alto from Xero
41.
by martanne 12y ago
If your window manager is not able to manage your windows to your liking, you might want to fix it? Arguably creating a new window per tab is the correct thing to do. This allows your window manager to do its job. It is also more flexible,
42.
by martanne 12y ago
No. They are not the same and shouldn't be. Rather they should communicate with each other. That is vim shouldn't have its own window functionality but instead detect that it runs within a terminal multiplexer and instruct it to c
43.
by martanne 12y ago
For some reason I share the feeling about emacs. However I personally prefer dwm in X11 environments and have thus written a "clone" for terminal/ssh sessions called dvtm. http://www.brain-dump.org/projects&#
44.
by martanne 12y ago
Then the underlying file is scanned. The performance of this depends on the number of non contiguous changes made to the document. At load time i.e. with no changes this will be relatively fast since it is a single memory mapped piece/
45.
by martanne 12y ago
At the moment only the line number corresponding to the start of the viewable area is cached. Further requests are served based on that. Since the underlying pieces/buffers remain unchanged, one could also maintain a more complex data
46.
by martanne 12y ago
Author here, both by email or by using the aforementioned github repository is fine.
47.
by martanne 12y ago
In my opinion starting out from the mess that vim's code base has become over the years, can't result in something good. That is why I started from scratch: https://github.com/martanne/vis