Re: [dev] Is there a text editor following the UNIX philosophy?

From: Kyryl Melekhin <k.melekhin_AT_gmail.com>
Date: Fri, 11 Feb 2022 12:35:40 +0000

Daniel Littlewood <danielittlewood_AT_gmail.com> wrote:

> Hi all,
>
> There was a recent chat about cat -v & single-purpose programs which
> has been rattling around my head for the last few weeks. There are
> *many* bloated code editors (atom, vscode, etc.), but most people
> usually present either emacs or vim as an alternative. I can't see
> these as any less bloated - there are very old jokes about emacs being
> a great OS which is just missing a text editor. And vim implements a
> lot of features that feel like they could (hence should) be provided
> by other utilities. Examples include syntax highlighting, text
> completion, search and replace, pane management (!), and others.
>
> It seems to me like the obvious alternative workflow would be, rather
> than to have a single monolithic program for the general job of
> "editing text" (which is really lots of jobs pretending to be one),
> one might have a program for syntax highlighting, a program for
> completion, a facility for dispatching text to shell commands, and so
> on. On the more extreme end one could even imagine separating the jobs
> of navigating through a buffer (i.e. a pager) from the editing of
> text. Obviously that's not a complete idea by itself, or I wouldn't be
> asking for suggestions.

This is not viable from the technical perspective. It's like trying to
separate each program having it's own command line argument parsing into one
utility somehow. It just does not work that way and there are no benefits to
such separation. What you will end up doing is writing specific code just to
fit that ecosystem, so no other program will be able to make use of this
unless they implement support for such ecosystem themselves. The same way if
you write a separate program for syntax highlighting no other program will be
able to make use of that unless they change and adapt their code. Not to
mention all the limitations that come from all this unnecessary separation.
The problem is that you can't effectively communicate state between programs
in a way that does not suck. Overall you end up with more specific
infrastructure which is, you guess - bloat. Not to say that separation is bad,
for simple text stream tools it's fine but for a TUI text editor definitely
not. Take a look at busybox, they combine all standard unix programs into 1
executable and still have the same separation for each program (via symlinks).
They are able to keep code bloat to a minimum with reuse; talk about real
measurable gains. It comes down to just writing simple small self contained
programs and not overengineer; blindly falling into this unix philosophy trap
where you write so much code trying to make things work together rather than
just focusing on the program doing useful things is a mistake. The only reason
you desire such separation is because you are too used to using bloated
programs, which you cannot understand in a sensible timeframe. So you think
that the solution would be to separate the tasks, but that's not the right
answer. The solution is to strip down the bloat. For example, in nextvi
syntax highlighting feature is basically free, it's implemented in 100 lines
of C. Obviously if something is so small, you start to see that such a problem
does not need any separation at all and it makes no sense. Another example you
mentioned completion, the problem is worth around 200 lines of C, again no
need for separation. And even if you separate it, what other program could make
use of such completion without having to adapt themselves?

Cheers,
Kyryl.
Received on Fri Feb 11 2022 - 13:35:40 CET