How do I submit a patch? Needs a couple of tiny mods to compile on OSX.
Author here, both by email or by using the aforementioned github repository is fine.
Design of a Vim-like text editor
41–50 of 92 posts
Re: Design of a Vim-like text editor
#42How about an embedded Lisp interpreter?
That's probably not in line with the suckless way.
I curious their philosophy (less is more?). I used dwm for a bit and still use a personally hacked inspired from dwm console derived dvtm, also by Marc iirc. If their going towards UNIX philosophy concepts it will be nice to hack a post config to extend it with personal my schemes and nda|dfa regex engines. This looks like a nice project. Looking forward to watching it.
Re: Design of a Vim-like text editor
#43Most of the "main goals" are supported by ... Eclipse!
yep, at the expense of all your RAM.
Re: Design of a Vim-like text editor
#44Right now, using vim is better than using this new editor (vis), although vis is close to being substantially better than vim.
I use the suckless window manager (dwm) and terminal (st), so gave vis a try for a couple days. Three vim plugins made me return: git-gutters, you-complete-me (ycm), and clang-format.
It is hard to extend vim's functionality. Its plugin interface has issues. Because of that, ycm and git-gutters can not be used at the same time, and something that ought to be straightforward like exposing clang's autocomplete information requires a considerable engineering effort (ycm) spanning three languages and about as much code as vis is total.
Giving vis good extensibility would be easier than fixed vim's plugin interface (sorry neovim). My personal preference for doing this would be a patch to vis that adds vim like gutters and dropdowns, and then patches that require this one and add specific things like ycm and git-gutters. A reasonable programmer could disagree and prefer out-of-process plugins. Either approach being implemented well would be very exciting.
Re: Design of a Vim-like text editor
#45That was a very interesting read. I might want to implement some of those things in my text editing component. I have one question. How would they implement "go to line number" functionality? How fast would it be?
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 structure such as a balanced binary search tree.
Re: Design of a Vim-like text editor
#46Re: Design of a Vim-like text editor
#47That was a very interesting read. I might want to implement some of those things in my text editing component. I have one question. How would they implement "go to line number" functionality? How fast would it be?
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 structure such as a balanced binary search tree.
What about uncached? Imagine the user opens a file and immediately issues a command "go to line 12345". Or is go to line not implemented at this time?
Re: Design of a Vim-like text editor
#48You don't have to use posix to suck less you know, or do you?
Re: Design of a Vim-like text editor
#49Earlier quoted context omitted.
That's probably not in line with the suckless way.
I curious their philosophy (less is more?). I used dwm for a bit and still use a personally hacked inspired from dwm console derived dvtm, also by Marc iirc. If their going towards UNIX philosophy concepts it will be nice to hack a post config to extend it with personal my schemes and nda|dfa regex engines. This looks like a nice project. Looking forward to watching it.
They actually have a philosophy page which explains it: http://suckless.org/philosophy
It basically boils down to minimalism (in general) with an emphasis on minimalist code instead of minimalist UX/UI (whenever the two conflict).
Re: Design of a Vim-like text editor
#50Earlier quoted context omitted.
yep, at the expense of all your RAM.
And cpu, and battery.
And sanity. ;)
Honestly IDEs in general are the most complex pieces of software that I frequently encounter. Most of that complexity comes in the form of features that I either never intend on using or don't intend on using at the time, which makes that complexity really frustrating. Complexity where it is necessary is fine of course, but I feel like IDEs like Eclipse frequently cross that line.