Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Design of a Vim-like text editor

lists.suckless.org

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Design of a Vim-like text editor

#81

Post by p0nce »

ridiculous_fish wrote: post #74
marvy wrote: post #72

Earlier quoted context omitted.

Um, how on earth do you deal with the 10GB delete? You can't store it in RAM, since there may not be enough, especially if you want 32 bit support. Store it on disk? You can't store it in the original file, since you have no flexibility over its contents after a save: a hex editor must write the bytes asked for, unlike a word processor which controls the file format. Ok, maybe we store it in some other file, call it…

The short answer is that it preserves the undo stack, if it can do so without using more than 16 MB of additional memory. If it exceeds that threshold it drops the stack. (Hey, I didn't claim to have solved it well!) The longer answer: when a file is going to be saved, HF identifies the ranges of the file that will be modified, and then identifies every other "byte array" (what vis calls a "piece chain") that referen…

Interesting, I've always wondered how hex editors did it.

Re: Design of a Vim-like text editor

#82

Post by JackMorgan »

_b wrote: post #44

Right 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-gutte…

With all sincerity, these plugins are available in Emacs, along with a Vim emulator called Evil. I used to fight with Vim so much, but for several years have been just using it inside Emacs, a decision I've never regretted.

Re: Design of a Vim-like text editor

#83

Post by aidenn0 »

gnuvince wrote: post #66
black_knight wrote: post #35

Earlier quoted context omitted.

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 for…

IIRC neovim exposes it via a socket which allows similar behavior.

Re: Design of a Vim-like text editor

#84

Post by exDM69 »

JackMorgan wrote: post #82
_b wrote: post #44

Right 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-gutte…

With all sincerity, these plugins are available in Emacs, along with a Vim emulator called Evil. I used to fight with Vim so much, but for several years have been just using it inside Emacs, a decision I've never regretted.

evil-mode is not without problems either. In particular, it doesn't work very well outside of "regular" code/text buffers. Using it in GDB/scratch/other buffers is very inconvenient.

So if migrating from Vim to Emacs + evil, you still have to learn how vanilla Emacs works. At least this was my experience when trying it out.

Re: Design of a Vim-like text editor

#85

Post by 101914 »

ridiculous_fish wrote: post #69

This 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…

"... I do want a fast text editor that can operate on arbitrarily sized files."

Ever try radare (now radare2)?

Re: Design of a Vim-like text editor

#86

Post by gnuvince »

exDM69 wrote: post #84
JackMorgan wrote: post #82

Earlier quoted context omitted.

With all sincerity, these plugins are available in Emacs, along with a Vim emulator called Evil. I used to fight with Vim so much, but for several years have been just using it inside Emacs, a decision I've never regretted.

evil-mode is not without problems either. In particular, it doesn't work very well outside of "regular" code/text buffers. Using it in GDB/scratch/other buffers is very inconvenient. So if migrating from Vim to Emacs + evil, you still have to learn how vanilla Emacs works. At least this was my experience when trying it out.

You could add a hook to use evil only in certain modes, for instance:

    (add-hook 'prog-mode-hook 'evil-local-mode)
This activates evil only for modes that derive from prog-mode.

Re: Design of a Vim-like text editor

#87

Post by exDM69 »

gnuvince wrote: post #86
exDM69 wrote: post #84

Earlier quoted context omitted.

evil-mode is not without problems either. In particular, it doesn't work very well outside of "regular" code/text buffers. Using it in GDB/scratch/other buffers is very inconvenient. So if migrating from Vim to Emacs + evil, you still have to learn how vanilla Emacs works. At least this was my experience when trying it out.

You could add a hook to use evil only in certain modes, for instance: (add-hook 'prog-mode-hook 'evil-local-mode) This activates evil only for modes that derive from prog-mode.

Yes, that's the only reasonable way to go.

But you still need to learn how vanilla emacs works.

Re: Design of a Vim-like text editor

#88

Post by _b »

airblade wrote: post #75
_b wrote: post #44

Right 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-gutte…

The reason ycm and vim-gitgutter don't work well together isn't the "plugin interface"; it's the limited nature of the sign column which can only display one sign per line. If both ycm and gitgutter want to display a sign on the same line, only one can succeed. Edit: oops, ycm doesn't use signs...I was thinking of syntastic. As far as I know ycm and vim-gitgutter should work together.

Here is a bug report discussing why they don't work together: https://github.com/Valloric/YouCompleteMe/issues/812

Re: Design of a Vim-like text editor

#89

Post by chriswarbo »

rtpg wrote: post #70
ridiculous_fish wrote: post #69

This 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 throu…

> Serious question : is it bad to assume a 64-bit capable running environment for developer's computers nowadays?

There's at least one counter-example, since all my machines are 32bit.

Is there anything in particular about software developers which makes you think they're more likely to grind on the hardware upgrade treadmill? I would have thought the opposite.

The software I use (linux + xmonad + bash + text editor) has far lower requirements than that my family and friends use (various versions of Windows, online video players, antivirus, games, etc.)

I tend to give my hardware more respect than my friends and family too, who are much more likely to drop machines, drop/spill things on to machines, rotate them with hard disks spinning, put stress on hinges or weak points (eg. carrying a laptop by the screen), insert/remove peripherals in mechanically stressful ways, etc.

I'm also more able to investigate and fix problems, rather than eg. buying a new computer when the hard drive gets full. My current machines all use AMD K7 chips (Athlon/Duron), so I've built up a collection of compatible CPUs, RAM, IDE cables/drives etc. from dead machines to fix any issues I get with the remaining ones.

I'm perfectly happy with my hardware, so I see no reason to "upgrade"; rather, I've seen news feeds full of compatibility wars, eg. amd64/IA64, IDEx/eIDE, SATA/PATA, HDMI/Thunderbolt/DisplayPort/whatever, BluRay/HDDVD, etc. none of which I've had to care about.

Re: Design of a Vim-like text editor

#90

Post by mjcohen »

ridiculous_fish wrote: post #71
rtpg wrote: post #70

Earlier quoted context omitted.

>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 throu…

There's definitely still new Linux systems that are 32 bit (Raspberry Pi, etc) though probably not many as a developer computer. Maybe Crouton on a Chromebook? Anyways you have a point about the simplicity of mmap. Reading up on the suckless philosophy, it does seem to fit.

I think Crouton installs 64-bit Linux.
Post reply on HN