I think that explaining core of the editor to the people is whole point of how to get people to use/extend/modify it. And this post really hit the nail on the head.
Design of a Vim-like text editor
61–70 of 92 posts
Re: Design of a Vim-like text editor
#62Earlier quoted context omitted.
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.
Eclipse isn't really just an IDE, it's almost an OS in its scope and complexity. I agree it's way too complicated and bloated, and worse: the rewards aren't there like they are in IntelliJ or Visual Studio. It's not as polished and not as easy to set up. The whole point of integrated software is to be able to do everything in one place: debug interactive in editor, hover to inspect values, edit the code and have the…
The type of complexity that bothers me is complexity that I have to wade through on a day-to-day basis when trying to find features that I do want to use. For example, lots of menus, each with tons of menu entries and submenus. That sort of complexity won't (or at least shouldn't...) impact performance in a meaningful way, but it exacts a psychological toll on me.
As you say, Vim's complexity is different. It has a lot of nonsense built in, but unless you go looking for it you will probably not become aware of it. It also can be complex to set up correctly like you mention, but that sort of complexity bothers me much less. That's more of a "once and done" thing, which I find much more tolerable.
My tolerance for configuring software is actually very nearly pegged at zero, unless I believe that the configuration I am creating will still be useful for at least 10 years. This rules out configuring just about anything for me, with very few exceptions. My current significant configurations are for vim (the emergence of neovim gives me some concern) and zsh (aliases and basic keybindings only. I am confident that any shell I'll be using in the future will allow aliases). My window manager, browsers, etc all use their default configurations (I got burned by Awesome WM changing their configuration scheme a few years ago).
Configuring Eclipse to be tolerable is probably possible, but I have zero confidence that any such configuration could last even two or three years.
Re: Design of a Vim-like text editor
#63Most of the "main goals" are supported by ... Eclipse!
Consider the following: multi-tools, mess kits, and sporks exist, yet many people prefer using the specialized equivalents.
The analogy breaks very fast, as people who prefer the specialized equivalents don't go sticking tons of smaller pieces together to try to make them resemble a multi-tool functionality, whereas Vim and Emacs users do add tons of plugins to get IDE like behavior.
FWIW, I think the aversion to IDEs is bogus -- unless it comes from people who don't install plugins on their Vim/Emacs. If they do, then their problem is not IDEs per se, but how popular IDEs are implemented.
The gist of an IDE is "having all the functionality in one place": edit, search, refactor, browse code, scm, REPL, build, etc. People loading Vim/Emacs with plugin try to build the same thing essentially.
The problem with IDEs is not their "IDE-ness" but: 1) they lack a decent, fast, editor component. 2) they are slow to load and memory hogs.
Nothing of the two is inevitable. Just an issue with current implementations. For (1) we can image an ide with a full Vim component, for example, as it's editor part. For (2), the problem is that both 2 popular IDEs (Eclipse, Idea) are built with either Java (which is crappy for GUIs), or have a messed up GUI like Visual Studio.
Re: Design of a Vim-like text editor
#64Earlier quoted context omitted.
It looks cool, and I love Rust. A question, which are your frustrations with other text editors? Can it really be the case that you can't find an existing text editor that you like? :)
Another part of it which I didn't mention is that I've always wanted to build a text editor, they've always intrigued me. So this was me scratching the itch if you like. I also used it as an opportunity to learn rust, which I really like, incidentally. To answer your question, I actually hadn't found one that suited me, fully. There are many that I like, but non which did it for me. It sounds a bit weird, but it need…
I was curious if you could describe the specific frustrations, and which of these you can fix.
Re: Design of a Vim-like text editor
#65I'm currently building a similar project in Rust called iota: https://github.com/gchp/iota I don't intend it to be a vim clone, however I'm currently adding some features which I've borrowed from vim. The main one being modal editing. Its much earlier on than this project, though. As a side note, building a text editor is great fun, one of the most interesting projects I've worked on!
I'm gonna need to read that source code; I've been an Emacs user for a long time now (and vim before that), and although I don't feel the need to switch (yet), I'm always on the lookout for new editors. A recent editor that I found is OpenBSD's mg(1), a super lightweight Emacs clone. If it were not for its lack of support for UTF-8 (I write a lot in French), I would use it a lot more than I do now. Let's hope iota can become that editor!
Re: Design of a Vim-like text editor
#66How about an embedded Lisp interpreter?
I have come to favour the Acme[1] approach of having a virtual file system to interact with the editor, so that you can write compatible scripts in any language! [1] http://research.swtch.com/acme
That sounds like a mighty good idea to me. Not a fan of the Acme interface, but the idea of exposing the editor API through the filesystem means that there is no war like Emacs Lisp vs Scheme in the Emacs world (an no people suggesting that we should switch to JavaScript): people will write plugins in any language they damn please, and they can even follow trends (Go this year, Rust next year, and OCaml from 2017 forth).
Re: Design of a Vim-like text editor
#67So weird to see this at #1 since I was researching this exact topic last night. My idea is a fully scriptable (Racket or CL) editor with modern package management system. A tiny C core would handle rendering (curses, etc.). Very cool write up though!
A fully-scriptable editor (not in CL but emacs-lisp is pretty close) with a modern package management system is pretty much just emacs+melpa
Re: Design of a Vim-like text editor
#68The article mentions the Project Oberon book and the piece list algorithm, which goes back to Xerox PARC's Bravo editor. Coincidentally I came across this paper recently about different data structures for text editors, which covers the piece list algorithm but also several others: "Data Structures for Text Sequences" (1998), Charles Crowley (https://www.cs.unm.edu/~crowley/papers/sds.pdf).
Re: Design of a Vim-like text editor
#69This piqued my interest:
> handle arbitrary files (this includes large ones, think >100M SQL-dumps)
My old hex editor Hex Fiend was a serious attempt to handle arbitrary-sized files correctly. It's hard! In particular, operations which are usually instantaneous (e.g. Find) now may take a long time: they need progress reporting and cancellation, and ideally should not be modal.
A text editor makes that even harder, because now simple operations like "go to beginning of line" may take a long time if you have to find the beginning of the line. There's probably some conditions that you could impose (e.g. handles large files but not long lines); it would be interesting to see what those are.
> Loading a file from disk is as simple as mmap
This is a sketchy decision. For one thing, it means you cannot work with files larger than maybe 3 GB, or even 3 1 GB files, in a 32 bit process. I'd also be uncomfortable relying on mmap over NFS.
Hex Fiend handled this by not mapping files, but reading them (via pread) on demand.
> Since the buffers are append only and the spans/pieces are never destroyed undo/redo functionality is implemented by swapping the required spans/pieces back in.
Saving is what makes this tricky. Say I open a 10 GB file, delete it all, and save it. Can I now undo that delete? (Hex Fiend initially could not, and users were unhappy). If so, where does that 10 GB data live?
For that matter, how DO files get saved? Say I append 1 byte to the end of a file: is the entire file rewritten? Say I delete 1 byte from the front of the file: does it require twice the disk space to save it?
How about copy and paste? Say I open a 1 GB file, copy it, and paste it into another. Does that 1 GB of data get copied into memory, or is it just referenced in the original file? If it's referenced, what happens if I now edit that original file - does the data get copied at that point?
Anyways this is really tricky (but fun) stuff, and I hope the author succeeds since I do want a fast text editor that can operate on arbitrarily sized files.
Re: Design of a Vim-like text editor
#70This piqued my interest: > handle arbitrary files (this includes large ones, think >100M SQL-dumps) My old hex editor Hex Fiend was a serious attempt to handle arbitrary-sized files correctly. It's hard! In particular, operations which are usually instantaneous (e.g. Find) now may take a long time: they need progress reporting and cancellation, and ideally should not be modal. A text editor makes that even harder, be…
>For one thing, it means you cannot work with files larger than maybe 3 GB, or even 3 1 GB files, in a 32 bit process.
Serious question : is it bad to assume a 64-bit capable running environment for developer's computers nowadays? I feel like it's better to run with something simple (and way less error prone) if the cost is some 32-bit issues like stated.
Granted, vim is a special case, since we're running this through ssh on servers or whatnot.
Lots of really good cases mentioned in this post, though, bet you make a good debugger