Re: [dev] Is there a text editor following the UNIX philosophy?
Ismael, > A simple way to deal with the problem is to make an extra commit > (outside the main branch) per release to hold these files and tag it > as the release, that makes it trivial for websites like github to make > proper release tarballs. ah. thanks! cheers, Greg
Re: [dev] Is there a text editor following the UNIX philosophy?
El mar, 15 feb 2022 a la(s) 20:16, Greg Minshall (minsh...@umich.edu) escribió: > > Ismael, > > > These errors mean the named auxiliary build scripts (needed for > > portability) are not present and must be provided... > > thank you for your explanation. i have wondered. > > > Technically, it's wrong to ask users to run autoreconf, projects must > > provide release tarballs with the pregenerated build system at > > releases, this is not just a convenience, first because that step is > > not repeatable and there's no way to fix it except by using the exact > > same autoconf environment, and because other actions might be part of > > the release process which make a snapshot different from a release > > tarball (e.g. bundling submodules, automated editing of some files to > > match the release, etc.). > > but, when "users" (such as many of us, but now a growing number of > others) pick up a "release" via git, my sense is that the authors of the > package have no (convenient?) way of providing the auxiliary scripts. Because that's not a proper release from the point of view of autotools. > so, the "user" must run autoreconf. is that still true? or, is there a > (convenient) way package authors can allow a simple "./configure && make > && make install" to work? The files aren't meant to be part of the development history, but that doesn't mean they shouldn't be tracked. A simple way to deal with the problem is to make an extra commit (outside the main branch) per release to hold these files and tag it as the release, that makes it trivial for websites like github to make proper release tarballs.
Re: [dev] Is there a text editor following the UNIX philosophy?
Ismael, > These errors mean the named auxiliary build scripts (needed for > portability) are not present and must be provided... thank you for your explanation. i have wondered. > Technically, it's wrong to ask users to run autoreconf, projects must > provide release tarballs with the pregenerated build system at > releases, this is not just a convenience, first because that step is > not repeatable and there's no way to fix it except by using the exact > same autoconf environment, and because other actions might be part of > the release process which make a snapshot different from a release > tarball (e.g. bundling submodules, automated editing of some files to > match the release, etc.). but, when "users" (such as many of us, but now a growing number of others) pick up a "release" via git, my sense is that the authors of the package have no (convenient?) way of providing the auxiliary scripts. so, the "user" must run autoreconf. is that still true? or, is there a (convenient) way package authors can allow a simple "./configure && make && make install" to work? cheers, Greg
Re: [dev] Is there a text editor following the UNIX philosophy?
El dom, 13 feb 2022 a la(s) 22:23, Kyryl Melekhin (k.melek...@gmail.com) escribió: > > Michael Hendricks wrote: > > > Agreed. > > > > > If anybody wants to go and fix the build let me know of your fork or > > > patch as I want to try it, out of curiosity. > > > > After cloning the repo[1], I ran `autoreconf -fi` to generate a > > configure script. Then `./configure && make`. Aside from the > > autotools bloat, the build proceeded without trouble for me on > > OpenBSD. > > > > 1: https://github.com/screen-editor/se.git > > Indeed, `autoreconf -fi` worked, thanks. There is an error if one tries to > run just autoconf or autoreconf without arguments. Looks like this: > https://0x0.st/o8-X.txt > > I have no idea what these errors mean, so when I got them I just gave up > initially, as it would of been stupid to waste time trying to figure it > out... Imagine having a bloated build tool, that does not just work, > pathetic. I also find especially frustrating how the INSTALL file tells > the user to run autoconf with no arguments. > These errors mean the named auxiliary build scripts (needed for portability) are not present and must be provided... Technically, it's wrong to ask users to run autoreconf, projects must provide release tarballs with the pregenerated build system at releases, this is not just a convenience, first because that step is not repeatable and there's no way to fix it except by using the exact same autoconf environment, and because other actions might be part of the release process which make a snapshot different from a release tarball (e.g. bundling submodules, automated editing of some files to match the release, etc.).
Re: [dev] Is there a text editor following the UNIX philosophy?
Michael Hendricks wrote: > Agreed. > > > If anybody wants to go and fix the build let me know of your fork or > > patch as I want to try it, out of curiosity. > > After cloning the repo[1], I ran `autoreconf -fi` to generate a > configure script. Then `./configure && make`. Aside from the > autotools bloat, the build proceeded without trouble for me on > OpenBSD. > > 1: https://github.com/screen-editor/se.git Indeed, `autoreconf -fi` worked, thanks. There is an error if one tries to run just autoconf or autoreconf without arguments. Looks like this: https://0x0.st/o8-X.txt I have no idea what these errors mean, so when I got them I just gave up initially, as it would of been stupid to waste time trying to figure it out... Imagine having a bloated build tool, that does not just work, pathetic. I also find especially frustrating how the INSTALL file tells the user to run autoconf with no arguments.
Re: [dev] Is there a text editor following the UNIX philosophy?
> I've heard of se before, however was never able to build it. Such a shame > that a small project like this (5K loc) uses auto* hell configure and make > for no reason. Agreed. > If anybody wants to go and fix the build let me know of your fork or > patch as I want to try it, out of curiosity. After cloning the repo[1], I ran `autoreconf -fi` to generate a configure script. Then `./configure && make`. Aside from the autotools bloat, the build proceeded without trouble for me on OpenBSD. 1: https://github.com/screen-editor/se.git
Re: [dev] Is there a text editor following the UNIX philosophy?
Greg Minshall wrote: > Michael, > > > You might like se[1]. It's a screen-oriented version of ed. It can be > > helpful for certain editing tasks where visual feedback is wanted. > > ... > > 1: https://github.com/screen-editor/se/ > > very nice. thanks for the pointer! > > cheers, Greg I've heard of se before, however was never able to build it. Such a shame that a small project like this (5K loc) uses auto* hell configure and make for no reason. If anybody wants to go and fix the build let me know of your fork or patch as I want to try it, out of curiosity. It's unlikely that it will replace nextvi for me but still, I am open to explore new ideas. Kind Regards, Kyryl
Re: [dev] Is there a text editor following the UNIX philosophy?
Michael, > You might like se[1]. It's a screen-oriented version of ed. It can be > helpful for certain editing tasks where visual feedback is wanted. > ... > 1: https://github.com/screen-editor/se/ very nice. thanks for the pointer! cheers, Greg
Re: [dev] Is there a text editor following the UNIX philosophy?
> I can get away with a less powerful shell as long as it has tab > completion. Tab completion just saves so much time. Directly typing into a shell is a red flag. ie. a shell is just another REPL and should be driven by your editor. This a) documents your work, and b) toggles the developer bit in your brain, so you think about reuse and safety. Literate programming has been a big win in my devops-ish world. Patrick
Re: [dev] Is there a text editor following the UNIX philosophy?
On lut 11 11:47, Daniel Littlewood wrote: > I wonder whether there are any text-editing (particularly > code-editing) workflows people have had success with which combine > many small programs, rather than using a single monolith. I highly recommend vis (https://github.com/martanne/vis). I've been using it successfully for around 2 years now. It is minimal enough to have a small and understandable codebase (around 20k lines C code + some Lua iirc) and it doesn't implement unnecessary features. For example it doesn't implement window/tab management, for which you can use tmux. In its core functionality it's very similar to vim, the main difference being structural regular expressions taken from sam (a very simple and very powerful feature). Vis is also easy to combine with other programs - I've built an "IDE-like" experience by combining it with tmux (to manage buffers), nnn (for a window with the filesystem tree), Python/R interpreters for a read-eval-print loop etc. I don't see the benefit of delegating things like syntax highlighting to an external tool. It's a performance-critical functionality because it's called often and I'm pretty sure that piping large files back and forth would be slow (though I haven't tried). IMO vis strikes the perfect balance of being small and minimalist, but containing all the necessary features to be usable and efficient. Best regards, Maciej
Re: [dev] Is there a text editor following the UNIX philosophy?
> Jonathan Bakke wrote: > Daniel Littlewood wrote: > > From the other end, there is always ed. > > I use ed. Each tool is specialized, though. > > I prefer vi-like editing for fixing typos. Having visual feedback > drastically reduces errors from commands like sed. You might like se[1]. It's a screen-oriented version of ed. It can be helpful for certain editing tasks where visual feedback is wanted. Unrelated to ed, but for those who use emacs, I find mg[2] to be a productive, medium-weight editor (~15k LOC). I use the one that comes with OpenBSD. 1: https://github.com/screen-editor/se/
Re: [dev] Is there a text editor following the UNIX philosophy?
On Fri, Feb 11, 2022 at 3:47 AM, Daniel Littlewood
wrote:
> ...
> From the other end, there is always ed.
> Unfortunately I don't have much experience with it, and it's not often
> discussed, so I can't tell whether it could do the "integration" step.
>
> I wonder whether there are any text-editing (particularly
> code-editing) workflows people have had success with which combine
> many small programs, rather than using a single monolith.
I use ed. Each tool is specialized, though.
I prefer vi-like editing for fixing typos. Having visual feedback drastically
reduces errors from commands like sed.
For multiple changes of the same sort, though, sed is better. I write a draft
of the editing command, verify that it does what I want on standard output,
then repeat the command with it overwriting the file.
awk is nicer than sed at picking out parts of lines -- back references, in
regex-speak. For anything more than a one-line script, though, I prefer to
write something in C, but that just comes down to a question of familiarity.
Use Perl or Python, anything that you're comfortable with... but don't avoid
the right tool only because you haven't yet learned to use it comfortably. I've
tried using shell scripts for direct text manipulation -- that way lies madness
-- but collating utilities with the shell is the indispensable feature that
IDEs try to dispose of. That means learning how to use lots of utilities.
grep is better than any in-editor find tool I've used. Line numbers are the
bridge between grep and your editor of choice... between most utilities,
actually. 'find -exec grep' is better than any in-IDE find tool I've used. And
sed, of course, fills the role of replace.
An alias that runs { grep | tee tempfile } can be useful to automatically save
your searches to review later or iterate over, if repeating your search with {
grep > tempfile } is a bridge too far.
For codebases that use long lines, piping whatever to { cut -c 1 $(tput cols) }
can make all the difference.
For dumping text from my mind, I like ed. All of that chrome in visual editors
that makes it easy to figure out where you are? That's just distraction for
pure input. When done, most languages have language-specific formatting
utilities; or, just open in emacs (lisp/emacs seems better than regex/vim for
handling syntax) to clean up the visual bits, which can be scripted if you're
not looking for the full carpal-tunnel-syndrome experience.
I also like ed for commit messages. Since I perform editing in the terminal,
and since ed doesn't clear the terminal view, I can review what I've recently
done while writing about what I've recently done. Neat and nifty.
I want to use ed for complex document reviews, too: comparing code, checking
multiple sections, etc. For example, create four terminal windows. In three of
them, create a FIFO and cat it. In the fourth, open a file in ed -- and write
relevant sections to your FIFOs. But the hassle of setting them up, then the
mental overhead of tracking which is which has always been too much for me. A
someday/maybe project of mine is to write a front-end for ed that handles all
of this; basically, a macro editor/launcher, or what emacs started out as but
for visual arrangement. Heck, maybe forget the shell and code it into dwm...
hmm. A lightweight version of that is [ grep -> ed -> print given lines ],
which is similar to folding in other editors.
I've tried tags but never found those systems useful. grep is enough.
A common theme here: the way I use lots of utilities is slow, but it forces me
to evaluate similar search results and to remember locations, all of which
helps me understand and navigate a project after a bit of exposure.
For non-coding (e.g., fiction), I use the filesystem as an outliner. Use tree
to get a listing; edit chapters in chunks, then cat together for review;
maintain notes and research documents in another tree then 'ln -s' them where
relevant. Backup early and often; plain text makes this easy.
I don't do syntax highlighting. My brain might be different, but all those
colors are pretty and pleasing without being informative; they make me think I
understand more about the code than I actually do. Coding style is all that's
needed to quickly figure out what highlighting is supposed to convey. Again,
though, your mind might be different. And there is a 'cat'-like replacement
that does syntax highlighting, if slowly ... 'bat', maybe?
But mostly I just use vim, partly because most editing is fixing typos, but
also due to the difficulty of slowing down enough to learn to do things quickly.
Re: [dev] Is there a text editor following the UNIX philosophy?
pt., 11 lut 2022 o 12:56 Daniel Littlewood napisał(a): > > Hi all, > > I wonder whether there are any text-editing (particularly > code-editing) workflows people have had success with which combine > many small programs, rather than using a single monolith. Here you go: https://c9x.me/edit/ Daniel
Re: [dev] Is there a text editor following the UNIX philosophy?
> The dependancy on tree-sitter is specficially what made me uninstall neovim > and switch over to vanilla vim. You can use the same syntax files you use with Vim on Neovim; you don't have to use tree-sitter. There is no dependancy.
Re: [dev] Is there a text editor following the UNIX philosophy?
Hi, AFAIK, neovim is trying to offload some of it's stuff (autocomplete/linting) to a language server via LSP. They're also offloading syntax highlighting to tree-sitter. But I highly doubt that this is what you're looking for when you're talking about a "unix-like" editor. The dependancy on tree-sitter is specficially what made me uninstall neovim and switch over to vanilla vim. - NRK
Re: [dev] Is there a text editor following the UNIX philosophy?
My impression so far with acme is that it fills the "IDE" gap much more than the "text editor" gap. I watched a screencast by Russ Cox (https://www.youtube.com/watch?v=dP1xVpMPn8M) and the appealing features were mostly around co-ordination of windows rather than the contents of the windows themselves. Being able to right-click a file reference (to redirect directly to a failing test, for example) is handy. It's kind of funny that they insist on using a GUI, but all of the windows are designed to render text and nothing else. I wonder whether a similarly designed program, with mouse chording replaced by customisable buttons?, and the acme windows replaced by terminals, would provide many of the gains with less weirdness. On Sat, Feb 12, 2022 at 2:30 PM Ethan Marshall wrote: > > > Acme looks extremely neat. Mouse > > chording is a strange concept (which doesn't play nicely with my > > laptop mouse) > > This is something that I fundamentally disagree with the designers of > acme on, actually. I think that mouse "chording" or mouse-based > shortcuts of any kind are slow and wasteful of precious time. > > When entering text, you keep your hands on the keyboard. I see no reason > why we should introduce yet another input device for simply editing or > transforming the text. This is why so many programs naturally gravitate > toward cursor-addressed, textual editing. vi is designed to keep your > fingers on the home row when moving the cursor, so touch typing is meant > to be easier. Not only is this a stroke of genius (something that I feel > Emacs never succeeded in), it also has wide, practical implications on > your editing of text. Why should I reach for a mouse to cut the previous > section of text when I can keep using the current input device? Rather > than moving my hands over an inch, instead I can not move them at all > and get the same result, the only requirement being that I press escape > first. > > The usual counter-argument for this is that the keyboard is an imperfect > device for this situation, as it was not designed for anything but > inputting characters. So - in theory - the time saved from using a > device meant for this purpose should be better. However, practice again > teaches us that this is not the case. Mice are the bane of most users' > lives when they are forced to use them for editing text. You have to > take your hand off the keyboard, move them to some arbitrary location, > correctly manoeuvre the mouse, move back to the initial position and > finally edit your text. After all this, you may have to repeat the > process to navigate to the end of the text. > > Even if the mouse were, in fact, the perfect time-saver that we are > told, it is not designed for such shortcuts and chording. The mouse has > three buttons. These were intended with three very clear purposes. The > keyboard usually has 104+ keys on it for usage in key shortcuts. The > mouse? Three. If we assume chording, a theoretical maximum of nine > shortcuts. However, to access them, you have to memorize a nonsensical > pattern of M1-M2 (Emacs style). Instead, to delete text in my silly, > inefficient visual editor, I just press d on my keyboard. > > This may just be me being a perfectionist who likes to edit back what he > has just written, or it may just be something that I feel personally > about mice, but I cannot understand why you would build an editor for > programmers which does not use keyboard bindings. > > I have tried acme and sam. Both have their benefits, and I like the some > of their ideas. I tried acme for equal to or greater than the amount of > time which I spent learning vi(m) - and I just cannot like it. > > Ethan >
Re: [dev] Is there a text editor following the UNIX philosophy?
On Fri, 11 Feb 2022 11:47:56 + Daniel Littlewood wrote: > I wonder whether there are any text-editing (particularly > code-editing) workflows people have had success with which combine > many small programs, rather than using a single monolith. On development machines there are two places where I want power, and one where I have no choice. 1) My editor. I spend all day in the editor. I want it to be very flexible. I use Emacs. But I don't use it to read mail or browse the web even though it can. 2) My shell. I use zsh. 3) I have to use chrome or firefox as a browser because of work related web based apps. I have no choice here, well no choice if I want to keep my job ;) I can get away with a less powerful shell as long as it has tab completion. Tab completion just saves so much time. Cheers, Sean
Re: [dev] Is there a text editor following the UNIX philosophy?
> Acme looks extremely neat. Mouse > chording is a strange concept (which doesn't play nicely with my > laptop mouse) This is something that I fundamentally disagree with the designers of acme on, actually. I think that mouse "chording" or mouse-based shortcuts of any kind are slow and wasteful of precious time. When entering text, you keep your hands on the keyboard. I see no reason why we should introduce yet another input device for simply editing or transforming the text. This is why so many programs naturally gravitate toward cursor-addressed, textual editing. vi is designed to keep your fingers on the home row when moving the cursor, so touch typing is meant to be easier. Not only is this a stroke of genius (something that I feel Emacs never succeeded in), it also has wide, practical implications on your editing of text. Why should I reach for a mouse to cut the previous section of text when I can keep using the current input device? Rather than moving my hands over an inch, instead I can not move them at all and get the same result, the only requirement being that I press escape first. The usual counter-argument for this is that the keyboard is an imperfect device for this situation, as it was not designed for anything but inputting characters. So - in theory - the time saved from using a device meant for this purpose should be better. However, practice again teaches us that this is not the case. Mice are the bane of most users' lives when they are forced to use them for editing text. You have to take your hand off the keyboard, move them to some arbitrary location, correctly manoeuvre the mouse, move back to the initial position and finally edit your text. After all this, you may have to repeat the process to navigate to the end of the text. Even if the mouse were, in fact, the perfect time-saver that we are told, it is not designed for such shortcuts and chording. The mouse has three buttons. These were intended with three very clear purposes. The keyboard usually has 104+ keys on it for usage in key shortcuts. The mouse? Three. If we assume chording, a theoretical maximum of nine shortcuts. However, to access them, you have to memorize a nonsensical pattern of M1-M2 (Emacs style). Instead, to delete text in my silly, inefficient visual editor, I just press d on my keyboard. This may just be me being a perfectionist who likes to edit back what he has just written, or it may just be something that I feel personally about mice, but I cannot understand why you would build an editor for programmers which does not use keyboard bindings. I have tried acme and sam. Both have their benefits, and I like the some of their ideas. I tried acme for equal to or greater than the amount of time which I spent learning vi(m) - and I just cannot like it. Ethan
Re: [dev] Is there a text editor following the UNIX philosophy?
On 22/02/11 11:47, Daniel Littlewood wrote: > 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. The question of "Unix philosophy" is more nuanced than that, it should be applied in an sensible manner. It just isn't practical to bring the scope which the "thing" that "programs do well" belongs to, down to such a fundamental level as navigating through a buffer. Those buffers are better manipulated as internal structures inside a single program, rather than some (textual) representation in an input/output stream. What should and can be avoided though, are for example plugins. A text editor doesn't need plugins, it should be sufficient for its purpose. Customization could be instead implemented through patches, as in other suckless programs. A text editor should do "its thing" well, nothing more, nothing less. "Its thing" should be editing of text files. signature.asc Description: PGP signature
Re: [dev] Is there a text editor following the UNIX philosophy?
Thanks for the suggestions everyone. Acme looks extremely neat. Mouse chording is a strange concept (which doesn't play nicely with my laptop mouse), but the idea of building an IDE around customised short shell commands is really appealing. As for text editing specifically, the idea of piping a buffer through sed rather than a custom implemented search-and-replace utility is really interesting. Ditto spell checking. Compared with a vim-like editor, navigating through a buffer seems much more painful - but perhaps I haven't found the right strategy yet. The lack of syntax highlighting, and the ugly GUI (which can't be run in console mode) are unfortunate. About syntax highlighting in particular, my naive suggestion would be to constantly pipe the input file/buffer through a program which decorates it with appropriate ANSI colour codes, which could then be interpreted by your preferred reader. This sounds absurd in terms of performance, but I don't understand how implemented syntax highlighters do anything different - presumably new tokens can make pretty much arbitrary changes to the underlying syntax tree, and yet vim (for example) will re-highlight an entire file quite happily. Regarding "can this be done" - I can't be sure. But for "is this even useful" - surely yes? I happen to have syntax highlighting in my text editor. Why not in my shell/terminal/pager? Why should they implement them differently? I happen to have tab completion in bash, and with a vim plugin. Why are they unconnected? For what it's worth (I know this is not particularly fashionable) - I'm much more interested in separating separable features than implementing the same feature set in less code. You may be right that these are not really separable features, but if they *are* separable, then it's not persuasive to me that they can be implemented in a small number of lines. All the best, Dan
Re: [dev] Is there a text editor following the UNIX philosophy?
Daniel Littlewood 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.
Re: [dev] Is there a text editor following the UNIX philosophy?
craekz wrote: > On Fri, Feb 11, 2022 at 11:47:56AM +, Daniel Littlewood wrote: > > 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. > > > Acme is pretty close to what you describe. > > Some resources can be found here: > https://acme.cat-v.org/ Acme is not minimal. 17K lines of C and legacy crap. Have a look at my own texteditor, you would very much be impressed with the amount of features you get in around 6.6K lines of C. https://github.com/kyx0r/nextvi Recently development has been finished, which means no more bloat will be added. Optional patches available too. And if that's too much for your heart, have a look at original neatvi, that would upset you only to read 5.5K lines of C. Though I would not reccomend it, as the code is written in a worse fashion, therefore it runs much slower. Also you may hit lots of pitfalls trying to customize or add features if you start from there. Based on my research, Nextvi may very well be the best suckless text editor. Don't believe me? Try comparing the number of lines of code of others to the quality of life of features they present. At this point I've seen a lot and went down deep the rabbit hole to make something of quality. Almost every solution either requires you to bear extra bloat, sacrificing the freedom to understand the entire code. And even if this is not enough for you, you at least can learn a proper way of how to write a texteditor from that code. Kind Regards, Kyryl.
Re: [dev] Is there a text editor following the UNIX philosophy?
Are you aware of sam, acme, and vis? https://github.com/martanne/vis
[dev] Is there a text editor following the UNIX philosophy?
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. I found kakoune, which seems essentially like a vim clone with better shell integration. From the other end, there is always ed. Unfortunately I don't have much experience with it, and it's not often discussed, so I can't tell whether it could do the "integration" step. I wonder whether there are any text-editing (particularly code-editing) workflows people have had success with which combine many small programs, rather than using a single monolith.
