3 ms·

If you want to go ultimately minimalist http://ex-vi.sourceforge.net/ http://ex-vi.sourceforge.net/ builds and runs on most modern systems just fine. Having le

by mst 5y ago

If you want to go ultimately minimalist http://ex-vi.sourceforge.net/ http://ex-vi.sourceforge.net/ builds and runs on most modern systems just fine. Having learned vi across eight-ish different unices at once my muscle memory is very minimalist so I tend to use ex-vi preferentially, simply because everything else adds features I don't use that I can accidentally activate with a typo and break myself out of flow figuring out wtf just happened. I can absolutely imagine that for somebody who tends to use OpenBSD on their own machines, being able to have the exact same editor elsewhere could be really quite handy for much the same reasons.

throwawayboise 5y ago
OpenBSD also includes mg, which is a "minimalist emacs" for people who don't want to install the full emacs port but who have emacs muscle memory.
- trn 5y ago
  pEmacs is "even better" for minimalists. https://github.com/hughbarney/pEmacs https://github.com/hughbarney/pEmacs Stripped -Os build using link-time GC on Linux x86_64 glibc: 30 KB pe* Compare to portable mg: 132 KB mg* OpenVi is ... 278 KB bin/vi* An even smaller vi implementation is Xvi. 56 KB src/xvi* This would be an 'ersatz' vi since it is not built on top of a real ex-mode. Even tinier ersatz-vi clones exist (`levee`, `s`, `VIrus`) but these are not complete implementations.
trn 5y ago
Using Carsten Kunze's actively maintained continuation of Gunnar Ritter's (outstanding) traditional ex/vi project is highly recommended. See https://github.com/n-t-roff/heirloom-ex-vi/ https://github.com/n-t-roff/heirloom-ex-vi/. The parent project on SourceForge hasn't had any activity for 15 years, nor a release in 17+ years, and contains various known bugs, all of which are fixed in Carsten Kunze's project.
- mst 5y ago
  That sounds like a better idea for everybody who isn't me. Naturally I've accumulated a few local patches over the years so I'll have to figure out which of them are obsoleted by the improvements in that version and which of them I want to port first ;) (thanks very much for sharing that this exists though, I shall be digging in when I have available tuits)
  - trn 5y ago
    It should be simple, mostly fixes and no major features or refactoring.
    - mst 5y ago
      I also ported it to use malloc instead of treating the heap as a single giant array, though a quick look suggests they did it rather more competently (though admittedly given my C code that's really not a high bar to clear). I suspect that once I untangle my somewhat hacky version of that the remainder of my patches will apply just fine but there'll still be at least a bit of mental effort involved.
      - trn 5y ago
        Do you have a summary of those changes or a repo up anywhere? If they are general-purpose you might consider sending a PR upstream to n-t-roff
        mst 5y ago
        A little late replying here, sorry. Probably nothing that interesting - the malloc stuff was the big change and n-t-roff already did a much better job of it than I did. But if there's anything in the remaining stack once I've backed it out that seems useful I'll be sure to PR it - even if it doesn't make it in to mainline it seems as good a way to memorialise the patch for other people's use as anything else. (the repo is currently private because gritter had politely requested nobody make it work on windows and one of my patches worked around a cygwin bug - given the advent of WSL I doubt anybody would want that one anyway so I expect to let it be lost to time along with the half-arsed malloc code)

by mst 5y ago

throwawayboise 5y ago

OpenBSD also includes mg, which is a "minimalist emacs" for people who don't want to install the full emacs port but who have emacs muscle memory.

trn 5y ago
pEmacs is "even better" for minimalists. https://github.com/hughbarney/pEmacs https://github.com/hughbarney/pEmacs Stripped -Os build using link-time GC on Linux x86_64 glibc: 30 KB pe* Compare to portable mg: 132 KB mg* OpenVi is ... 278 KB bin/vi* An even smaller vi implementation is Xvi. 56 KB src/xvi* This would be an 'ersatz' vi since it is not built on top of a real ex-mode. Even tinier ersatz-vi clones exist (`levee`, `s`, `VIrus`) but these are not complete implementations.

trn 5y ago

Using Carsten Kunze's actively maintained continuation of Gunnar Ritter's (outstanding) traditional ex/vi project is highly recommended. See https://github.com/n-t-roff/heirloom-ex-vi/ https://github.com/n-t-roff/heirloom-ex-vi/. The parent project on SourceForge hasn't had any activity for 15 years, nor a release in 17+ years, and contains various known bugs, all of which are fixed in Carsten Kunze's project.

mst 5y ago
That sounds like a better idea for everybody who isn't me. Naturally I've accumulated a few local patches over the years so I'll have to figure out which of them are obsoleted by the improvements in that version and which of them I want to port first ;) (thanks very much for sharing that this exists though, I shall be digging in when I have available tuits)
- trn 5y ago
  It should be simple, mostly fixes and no major features or refactoring.
  - mst 5y ago
    I also ported it to use malloc instead of treating the heap as a single giant array, though a quick look suggests they did it rather more competently (though admittedly given my C code that's really not a high bar to clear). I suspect that once I untangle my somewhat hacky version of that the remainder of my patches will apply just fine but there'll still be at least a bit of mental effort involved.
    - trn 5y ago
      Do you have a summary of those changes or a repo up anywhere? If they are general-purpose you might consider sending a PR upstream to n-t-roff
      - mst 5y ago
        A little late replying here, sorry. Probably nothing that interesting - the malloc stuff was the big change and n-t-roff already did a much better job of it than I did. But if there's anything in the remaining stack once I've backed it out that seems useful I'll be sure to PR it - even if it doesn't make it in to mainline it seems as good a way to memorialise the patch for other people's use as anything else. (the repo is currently private because gritter had politely requested nobody make it work on windows and one of my patches worked around a cygwin bug - given the advent of WSL I doubt anybody would want that one anyway so I expect to let it be lost to time along with the half-arsed malloc code)