Text Editor General

This is the text editor general, the thread for the discussion of implementing, or implementations of, text editors for programming and general use. Less a thread for vi or Emacs help, more on the fundamental nature of text editors like vi and Emacs. >History - General resources | http://texteditors.org/cgi-bin/wiki.pl?EditorHistory - Colossal Typewriter Program | https://www.computerhistory.org/pdp-1/fc990374851eb7082492c2aa341fb1f4 - The NLS Implementation section might be of interest | http://worrydream.com/Engelbart1968 - A Tale of Five Editors | http://www.catb.org/~esr/writings/taoup/html/ch13s02.html >Acme - A Tour of the Acme Editor | https://www.youtube.com/watch?v=dP1xVpMPn8M - acme/acme2k: A lesson in sane IDE defaults | https://dev.to/tux0r/acmeacme2k-a-lesson-in-sane-ide-defaults-2cb6 >Sam - The Text Editor sam | http://doc.cat-v.org/plan_9/4th_edition/papers/sam >Emacs - EMACS: The Extensible, Customizable Display Editor | https://www.gnu.org/software/emacs/emacs-paper.html >Vi(m) - Overview of Vim history and highlights the important choices that were made | https://www.youtube.com/watch?v=ayc_qpB-93o >Implementing - DesigningTextEditors | http://texteditors.org/cgi-bin/wiki.pl?DesigningTextEditors - A Brief Glance at How Various Text Editors Manage Their Textual Data (2015) | https://ecc-comp.blogspot.com/2015/05/a-brief-glance-at-how-5-text-editors.html (https://news.ycombinator.com/item?id=11244103) - Design & Implementation of a Win32 Text Editor | https://web.archive.org/web/20160324045113/http://www.catch22.net/tuts/neatpad - Text editor implementation as a programming étude | http://fredericgingras.ca/2016/05/text-editor-implementation-as-a-programming-etude - The Craft of Text Editing | http://www.finseth.com/craft/index.html - Rope science | https://xi-editor.io/docs/rope_science_00.html (https://news.ycombinator.com/item?id=14129543) - Data Structures for Text Sequences | https://www.cs.unm.edu/~crowley/papers/sds.pdf - Text Editor: Data Structures | https://www.averylaird.com/programming/the%20text%20editor/2017/09/30/the-piece-table (https://news.ycombinator.com/item?id=15381886) - CodeMirror Internals (Enable JS to filter to #cm-internals tag, or don't) | http://marijnhaverbeke.nl/blog/#cm-internals - Build Your Own Text Editor | https://viewsourcecode.org/snaptoken/kilo (https://news.ycombinator.com/item?id=14046446 https://news.ycombinator.com/item?id=20603567) >Questions/Topics to start discussion: Current text editor? Describe your programming and general editor usage and workflow, e.g features you use heavily, any properties unique to your text environment. Have you wrote your own text editor? What language did you use, what features did you implement, how did you account for efficiency, user design, ability to extend etc What do you think of modal editing like what vi presents? How do you feel about text editors being general computing environments, e.g Emacs? Alternatively, what do you expect from a so-called text editor? Is being presented a screen with source text all we need? Or are there other more involved editing mechanics that we could be exploiting and exploring? Programming languages which sport s-expressions often allow for powerful text editing capabilities (lispy, paredit), how else can a language provide opportunity for powerful tooling involving editing and such?

Which editors have branching undo history (viewable in extensions like Mundo)? The only ones I know of are Vim and Emacs. I'm beginning to feel that a text editor without it is severely hobbled. It's like having micro-level version control. And modal editors are probably the best kind to use with branching undo history, since their edits are neatly chunked.

I'd like to feature the editors from my other post, >>15372 NEdit, Maximum Profit and Tilde. - NEdit https://sourceforge.net/projects/nedit - Maximum Profit https://triptico.com/software/mp.html - Tilde: https://os.ghalkes.nl/tilde/ These are all editors which would be familiar to people coming from Mac and Windows, because they are non-modal and have keyboard shortcuts from that WIMP tradition. I also consider Vi and Vim very different editors. It was always very confusing for me for people to mash them up. History on both vi and vim: http://www.softpanorama.org/Editors/Vimorama/history.shtml not everything but cool Crazy people like vi or emacs users, check out lpe and fte (and e3?), if I have some time I want to play with them. Kilo was featured in >>14991 NEdit history: https://nedit.gmxhome.de/history.html Users of XEDIT/KEDIT from VM/CMS might also be interested in THE (Hessling), I personally never used these.

>>15413 Not tested at all, just a bunch of words (too late): diakonos, skimedit, kpad, AEditor, bless, tigerii minipad, smooth, kankowskiedit, https://en.wikipedia.org/w/index.php?title=Undo&oldid=914637772#cite_note-:0-1 Berlage 1994

>>15413 Ah, posted too quickly. More words: LightPad, PowerPad, AkelPad, Hurricane, AXRScan, NoteTab Pro, ynote classic diakonos is MIT and ynote classic is GPL, I have literally no idea about the rest.

>>15421 >Crazy people like vi or emacs users, check out lpe and fte (and e3?) I use emacs, and I don't get what the editors you mention should be interesting to me. Emacs and Vi have editors with keybindings/concepts for every platform. When playing with fte, I feel like using MS notepad.

>>15408 I think we're overdue for a reevaluation of the very premise of text editors. Fundamentally, a text file is a flat-file database, primitive technology even in the 1980s. And text editors are nothing more than interfaces to flat-file databases, that are still following a design paradigm from the late 60s. We should instead be moving to structured file formats and structure editors. Editors in which it's impossible to make a file formatted incorrectly. Beyond that, I think we should also be looking to modernize the extension interface of our interactive programs. Any interactive program for which a user might reasonably use for 10 minutes or more a day should be extensible using a clean modern scripting language with a syntax and semantics that can be learned easily even by halfwit. Vimscript fails HARD on this count. Elisp is much better, but seems rather dated at this point. I recommend embedding a dialect of scheme, perhaps guile. Lua isn't the worst choice, but is far from great. If your program, be it a modern structure editor, a plain jane text editor, or something completely different, should be scriptable. If it's not, I don't think it's even worth consideration. It should also present an rpc interface listening on localhost or a unix socket, or using some form of system bus, and ideally, extensions to your program should be able to connect to other related programs that themselves present such an interface. Emacs excels here, obviously. Vim doesn't do badly. The mpv media player is decent in this regard; you can control an mpv process over a unix socket. But in mpv is suboptimal because it's difficult to connect to a tcp or unix socket from an mpv lua script. As far as modal editing/etc are concerned, I don't think it should really matter. If you do a good job at making your program extensible, the user should be able to casually design their own personal workflows. For instance, I use evil-mode in emacs, because emacs is sufficiently extensible to to implement something like that. A vi-like experience is my personal preference, and because emacs is extensible nobody needs to have the personal preferences of others imposed on them. In this way, extensible software is ethical software.

>>15427 Thank you for your time and answer. I was a little too excited when writing all those posts (because I have been thinking about making a text editor thread myself). All is meant that anyone having enough determination needed to learn those living families of classics should have no problem learning these, all marked for their simplicity. Later I thought that vim (but not vi) and emacs users should be the wrong audience precisely, since they (among other people) like to extend their editors. I will try to write a better post sometime because I also want to answer the OP questions.

>>15421 Wow, I've been using nedit for a week now and it's better in every way than all that gnome/kde/qt soykaf (and vim). Every single thing is faster: opening menus, scrolling, changing tabs. Even entering text in nedit feels faster than gnome soykaf. Overall, still not the best performance, and full of UNIX braindamage, but I'm still surprised at how good it is. Funny that motif 2.3.8 from 2017 is better looking in every way than corporate "UX enhanced" Gnome which gets updated 5 times per week. The changelog of Motif looks pretty braindamge though: >* Fixed bug #1389 (A middle click on a tab lets nedit segfault) That's the changelog for MOTIF, not nedit.

I believe it was Charles Moore who said every programmer should make his own text editor? Anyway, I need some project to do and this one I find a very interesting subject. I also want to actually make more than just an editor, rather something like what Forth does, which is a runtime as well as a programming language and an editor, rather than just 3 things separately. I guess this overlaps with the topic of user interfaces, and in my case my favorite interface is plain old linear text in a terminal screen. Like ed or ex, but better. I know this all sounds like TECO in a way, and I must admit I'm somewhat inspired by it, I just hope I don't make a monstruosity. I think the major feature of a text editor is.... well, text editing capabilities. My editor would therefore be a sort of a combination between ed, sed, perl... wit sam extended regexes. Some sort of line editor, which features a concatenative language centered in text editing.

>>15421 noticed this annoying soykaf recently while using nedit. only happens with word wrap enabled but annoying as fuarrrk

>>15774 Just use a normal text editor, kid.

>>15780 shut the fuarrrk up. what is "normal"? everything "normal" right now is made by insane morons^W^Wthe capitalist system, and barely functions i tried the following and they all have the same bug mousepad leafpad notepad (windows)

>>15804 vim is normal. What exactly is the bug? Seems pretty unlikely for notepad to have the same bug.

>>15808 how is vim normal? because the web programming community started memeing it? there's nothing normal or non-forced about anything built on a terminal, let alone the terminal itself boxes and crap like in windows 95 is normal and the canonical way one would choose to create a GUI. i know this because when i was 5 years old i used an assembler to create an OS with a GUI rendered by simple VBE (VESA BIOS extensions) calls without ever seeing any existing OS, and it turned out just like windows 95 >What exactly is the bug? nedit (bottom left corner of >>15774) shows multiple spaces as one space

Thoughts on xi? https://github.com/xi-editor/xi-editor

>>15958 it's rather weird that you'd have to leave the terminal and click around at little pictures to edit text if you ask a lot of people. what kind of programming do you do that taught you such strong opinions?

>>15962 how bubblized do you have to be to think not only that vim is the best way to program but the absolute most natural way? why am i clicking around? hmmm lets see to go to the definition of something to view the doc of something to copy some data from somewhere into the shell or into a string or whatever etc

>XI let me guess, it's based on vi/vim >A modern editor with a backend written in Rust. wow what a good description >Goals include: >All editing operations should commit and paint in under 16ms. The editor should never make you wait for anything. wow that's actually surprisingly based. i will try it. i really want something that can do vsync with 0 latency so i can actually read text while scrolling (and scrolling by a fixed amount of pixels/per second as opposed to by one character at a time or some other insane mechanism, to prevent judder, double image artifacts, etc). i already implemented this for image viewing and will maybe do file manager and a text editor next. then again it looks like just a library so the "fontends" probably fuarrrk everything up if the library didn't already >Beauty. The editor should fit well on a modern desktop, and not look like a throwback from the ’80s or ’90s. Text drawing should be done with the best technology available (Core Text on Mac, DirectWrite on Windows, etc.), and support Unicode fully. wow and this is the opposite polarization of the vim retard above. everything's either >hurr durr muh text mode or >hurr durr muh """typesetting""" muh hamburger menus

>>15963 lainon didn't say it was the best, just that a lot of people only leave the terminal to look up online documentation, test, and other things you can't do in the terminal. it's quite normal to have the preference of doing as much as you can in your terminal emulator because it helps some people focus. there are cases where a terminal environment is superior, but that's not every case. the level of aggression you're at belittles your opinions. it's foolish for you, but fun for others to point it out because you are this mad about it

>>15964 indeed, Xi will probably be really nice to use once someone builds a plugin for vim-style commands and modal editing.

>>15433 >If your program, be it a modern structure editor, a plain jane text editor, or something completely different, should be scriptable. If it's not, I don't think it's even worth consideration. Why do you think that? In my opinion, text editors are fine as they are. I don't see any improvements to be made when you are literally just writing text, no format whatsoever. Sure, there can be little things to help you, like keyboard navigation in Vim, but other than that there is no need for more. On the other hand, when writing source code there is a lot you can do to help the programmer out. But even then I still don't understand why everyone would need an easily extensible editor with an easily understandble script language. By far most programmers do not want to write their own code for... well, writing more code. You have to get into all the details of how to communicate with your editor, which is a hassle. That's what plugins online are for. >It should also present an rpc interface listening on localhost or a unix socket, or using some form of system bus, and ideally, extensions to your program should be able to connect to other related programs that themselves present such an interface. I have the same problem here. Why do you think this is necessary? This is a text editor, not a program that needs to fulfill the purpose of connecting programs together.

Have any of you had any experience with Kakoune: https://kakoune.org/ It has a interesting editing style that seems to be a cross between the style of Emacs and Vi, while overall having a very clean design. My understanding is that it has zero programability beyond what can be had through the new-jersey style which is unfortunate, and generally they seem a little too focused on keeping the editor simple. If you see it as a proof of concept for this editing style and command set it's really interesting though.

I'm all on board the make your own text editor camp, or at least plugins for other ones. Unfortunately I am a soykafty programmer. I'm jumping on the web dev band wagon, even though I have no real interest in it. But I can't do physical work forever. So I can't manage to find a text editor that just works the way I think it should, some add ons are good, but its not enough ( I settled on visual code studio). My problem is no editor knows how to position the cursor after quotes/tags/brackets {[]}<>"''" etc. Or how to navigate through them. between them, whatever. Even watching youtube professionals you can hear them take their hands off their keyboards and click, or use ctrl-arrow keys or some equally poor solution to navigation. It's driving me insane. Literally it feels like my only option is to make my own text editor.

>>16104 >knows how to position the cursor after quotes/tags/brackets {[]}<>"''" etc. Or how to navigate through them what about vim find (or I guess it called find-forwared) bind to `f`. and there is a plugin -or build-in not sure- that when ur cursor on the `[` for example and u hit `%` you jump to the `]` that close it, and you know there is no shame to use mouse to click on it, Acme is a mouse-driveded Text editor in the first place, where your mouse is your window-manager, Shell, and search >>16104

>>16104 >My problem is no editor knows how to position the cursor after quotes/tags/brackets {[]}<>"''" etc. Or how to navigate through them. between them, whatever. I'm quite confident that whatever behavior you want could be implemented in Emacs Lisp.

>>15780 There is no such thing called Normal text editor. there is a text editor that works, and don't.

>>16104 look at 4coder 4coder is designed to be modifiable, faster than writing an editor from scratch

>>16105 My problem with vim is you have to Learn it. User interface should be intuitional For editing html there should be multiple navigation modes. <tag> one that edits between tags </tag> Pressing ctrl-enter moves you to the next tag, between them. <tag att="one that edits attributes" > Then for example alt-enter goes to next attribute to edit it. Then a quick add attribute hotkey to current tags, that temporarily moves the cursor, then jumps back. Inb4 vim does all this by default Programming languages also need this, navigation modes that allow you to quickly skip to next variable or values or arguments. But it's less of an issue, because programming for me is slower. I have no problem using a mouse, but not when it becomes tedious. >>16107 Absolutely, but I'm a soykaf programmer.

Here goes my grain of sand. 1) Introduction to Joe's Own text Editor, aka, joe: https://joe-editor.sourceforge.io/ Its main characteristics are: - Simple by design. Run it in a terminal and start editing text. - Familiar. It has an emacs mode, a wordstar mode, pico mode and its own mode. - Aimed at writing and programming. Just enough keybindings and features to easily navigate and edit text - Small. - Configurable, but not "scriptable". If you follow Bisqwit in Youtube, you will know he uses it. His main reason is that it is simple and the number of keybindings/functions is low, so you barely have to learn it (if one can even consider it has a learning curve). Personally, I prefer it over nano, since I find it is just simpler and more powerful. 2) My internal debate between Vis (see https://github.com/martanne/vis) or any Vi based editor and Emacs. I find Vi based editors to be very efficient at writing and editing code/text/etc. While Emacs feels more like: "If the main part of a process is writing text, then we should do everything within Emacs". In emacs you have org-mode, which is one of the greatest things to have ever existed. But also a web browser, a music player controller, magit (which is amazing) an entire frontend to git, debugger interfaces... Heck, even a window manager! I feel overwhelmed with the aproach that emacs users have towards the use of Emacs. I know, I don't have to follow what they do, but... But they are kind of right... If I write an email, I would want to use my normal writing tool, same for commiting in git. I would like to easily switch between my editor and a terminal. If I like the vi style of editing, I can have it (evil-mode), if I want to work from the terminal, just emacs -nw... But I like modularity, one efficient tool for every job. The size of some .emacs goes to show how far the Emacs as OS aproach goes. Anyway, in the end I see myself working with Emacs in evil-mode with some extra extension, nothing crazy. 3) Efficiency with newer text editors (not the small ones) I have used VS Code quite a lot (specially with peaple around). One of the things that I love about it, is PlatformIO ( for embedded development, it is soooo nice). And it is quite nice looking, sleek, customizable and there are tools out there for pretty much everything that is programming. However, one thing that I cannot stand with VS Code, or Atom or similar editors, is their foundation: "Let's do everything with web tech!" They are basically Chromium running hundreds of JS scripts. It has some good parts (easily hackable, interactive, very nice UI...). But really, we just want to edit text!!!! There is no need to bring an F18 fighter to pick your grandma to do the groceries. Look at their binary size (inb4 hdd space is cheap), their cpu usage, their boot time, their constant updates, their difficulty to be built from source, etc! I understand why would a begginer start with them, however, they are far from perfect... With this society that falls rapidly into "It works perfectly" and don't question wether something could be done better; no wonder why everybody is with VS Code and Atom or similar editors/IDEs. Anyway, end of rant. 4) Spread the word! One great way to make this world a better place is to share knowledge with peaple that are willing to learn. So share what you know, what tricks you hide, what issues you have found and their solutions. Disagreeing (with harmony) and preaching what you use can help other. Nice thread OP!

I used ed for an entire year. 100% serious. It's actually completely usable. Used readlinewrap to get readline support. And you can configure rlwrap to save history, do tab completion, vi keybindings, etc. Better than default vim actually which has no tab completion or history by default. Obviously it's a little impractical, but not as much as you would think. You learn the origin of a lot of unix tools. E.g. grep is literally just an ed command, Global/RegularExpression/Print. And its options like -v are as well. And sed literally is ed just not interactive. It's the only true command line editor. Everything else is just a GUI that happens to be rendered in text mode on a terminal. You don't actually type commands to do editing. Everything you do in ed can be piped into it in a script. Which has been very handy. The rlwrap thing is just a start, I hope to hack more features onto it. Like copy the current line into readline so I can edit it visually. Maybe that would defeat the purpose of ed, but it would still be way more minimal than even nano. I tried vi next, progressing along unix history. But it kept giving me segmentation faults.

>>16150 >Used readlinewrap to get readline support. And you can configure rlwrap to save history, do tab completion, vi keybindings, etc. Better than default vim actually which has no tab completion or history by default How did you do that ? could u share resource with us please.

>>16150 I know the basics of working with ed, but I never figured out how to conveniently edit existing text. Like if I want to change the name of a word one, that appears three times in a line (let's say the second instance). Or how to insert/delete some text into/from the middle of a line. I can use the substitution command, but it seems stupid. I can copy the entire line manually, but that seems even worse. Do you have any tips? Also, why are you using the historical vi, not nvi? Afaik, it's mostly just ported, but with the same features. >>16154 Just call "rlwrap" with ed as its argument. Usually something like "rlwrap ed -p%", if you want "%" to be your prompt. To activate vi keybindings, take a look at your ".inputrc" file. Just google "inputrc vi mode".

>>16158 You get good at making regexes. It's usually simple to specify the start and end of a piece of text you want to replace. You dont need to only match the text you want to change.

>>16158 >>16159 You do have to use the substitution command a lot. Hence my desire to just feed the current line into the readline buffer for editing. I switched to vim for now. It's ok but the opposite of minimal. And I find myself jumping around with the navigarion keys instead of just typing line numbers.

>>16159 >>16160 Hmm, it still seems too cumbersome. I don't have issues with regexes, but typos mess me up all the time. Having to type everything twice would just be too annoying.

Is there a way to display word count in the Notepad++ status bar?

>>16149 >- Simple by design. Run it in a terminal and start editing text. a text editor in a text console? sounds horrible, and not simple. >features >UTF-8 support >needs explicit UTF-8 support >it doesn't just work by the console having it enabled pathetic. already broken abstractions after 1 second of reading nedit seems to be the best text editor ever made (which doesn't support Unicode BTW, which is a feature). thanks to the lain here recommended it to me

>>15774 The main problems in nedit I have right now are that it doesn't scroll properly (no vsync[1], and scrolls by 1 character at a time). Also this bug (>>15774) and of course there will probably be tons more of bugs like this, as expected of unreliable UNIX software. 1. inb4 input lag. it can be done with zero input lag, contrary to crap techniques games use

I could write an entire essay about this and related topics, so I'll keep this post more brief than that and only even allude to some topics. >>15408 >Current text editor? I've used Emacs for several years now. It holds no special place in my heart, it's merely the best option currently available to me. >Describe your programming and general editor usage and workflow, e.g features you use heavily, any properties unique to your text environment. Emacs is the main interface to my computer. I don't do it nearly enough, but when I'm frustrated enough by something, I dig into the editor to customize it, be that changing a symbol's value or writing and binding my own little function specifically for the problem. I like using keyboard macros more than other facilities, even though they're more brittle. It's my email and IRC client, I run my REPLs from it, and I do almost all of my programming in it, with the exception of programming in my own tools I've designed for myself. >What do you think of modal editing like what vi presents? I think modes have their place, but they should be very clearly delineated, very different, and the fewer the better. Some of this interview is relevant and I've added emphasis: http://xahlee.info/comp/interview_with_bill_joy.html >REVIEW: What would you do differently? >JOY: I wish we hadn't used all the keys on the keyboard. I think one of the interesting things is that vi is really a mode-based editor. I think as mode-based editors go, it pretty good. One of the good things about EMACS, though, is its programmability and the modelessness. Those are two ideas which never occurred to me. I also wasn't very good at optimizing code when I wrote vi. I think the redisplay module of the editor is almost intractable. It does a really good job for what it does, but when you're writing programs as you're learning... That's why I stopped working on it. >How do you feel about text editors being general computing environments, e.g Emacs? Alternatively, what do you expect from a so-called text editor? I believe it would work better if the entire system were truly built around it. I also believe text isn't the best interface for computers, so I'd prefer to see them de-emphasized. I want for a system where my writing and my programming are two very different activities, rather than this midway point where both are underserved and mistreated. >Is being presented a screen with source text all we need? Or are there other more involved editing mechanics that we could be exploiting and exploring? >Programming languages which sport s-expressions often allow for powerful text editing capabilities (lispy, paredit), how else can a language provide opportunity for powerful tooling involving editing and such? I don't believe the end goal should be having ever more complex and even useful text editing facilities. The actual goal is programming, and usually actually what the program accomplishes, and this can be achieved better and simpler by having hyper-specialized environments for different kinds of programming. Some things, such as bracket matching, seem truly universal, but even those aren't fit for quite every language. >>15433 >We should instead be moving to structured file formats and structure editors. Editors in which it's impossible to make a file formatted incorrectly. I agree, but it's also possible to go further and not use text at all to express programs. Then, it can be made infeasible to even write a program which is unacceptable as input to the system, along with ridding ourselves of the idea that writing a program and inputting it are different operations. >Beyond that, I think we should also be looking to modernize the extension interface of our interactive programs. It really needs to be consistent and embedded into the system, which no operating system currently provides, so everyone chooses their own pet language. Look at the Suckless idiots pretending C is their configuration language. >Any interactive program for which a user might reasonably use for 10 minutes or more a day should be extensible using a clean modern scripting language with a syntax and semantics that can be learned easily even by halfwit. I disagree with the last point. There are programs halfwits shouldn't use to start with. >It should also present an rpc interface listening on localhost or a unix socket, or using some form of system bus, and ideally, extensions to your program should be able to connect to other related programs that themselves present such an interface. This is another thing the system should provide. I've read of and agree with the perspective that a program shouldn't even need to worry over this. There should be a more general system which allows programs to be used in this way without even knowing about it. >A vi-like experience is my personal preference, and because emacs is extensible nobody needs to have the personal preferences of others imposed on them. In this way, extensible software is ethical software. I've written my own development tool, the first of several, but I've struggled to provide an extension mechanism that suits me, and I'm the only user. To me, the idea of the tool is more important than being able to customize it, which I'd still like to add, but I've also necessarily customized it to my liking because I'm the sole author. Instead of every software being customizable, there's merit in the idea more people should simply write their own software. My issue is the customization mechanism flavors the tool, and I wouldn't want to force that flavor on anyone else. One option is providing a weaker, non-Turing-complete mechanism for customization, or providing a flavor that no one prefers. >>15718 >I believe it was Charles Moore who said every programmer should make his own text editor? Anyway, I need some project to do and this one I find a very interesting subject. With what I wrote earlier, every programmer should write ever more of his own tools. This begets experimentation. TECO could be considered a text editor toolkit, and Emacs came from that. >>16150 >I used ed for an entire year. 100% serious. It's actually completely usable. Used readlinewrap to get readline support. And you can configure rlwrap to save history, do tab completion, vi keybindings, etc. I used plain ed for a while, before I knew better and when trying to pick my editor. Ed is unpleasant to use and correcting a basic mistake involves retyping the line or determining the replacement expression to use, which may be mostly retyping anyway. It's mostly useless. >Obviously it's a little impractical, but not as much as you would think. You learn the origin of a lot of unix tools. The origin of those tools isn't worth learning. Those tools were rather useless and outdated when they were made, and they've only become less useful since. The best versions of these tools, which actually handle edge cases correctly, are the GNU versions, which GNU explicitly rejects in spirit. >The rlwrap thing is just a start, I hope to hack more features onto it. Like copy the current line into readline so I can edit it visually. Maybe that would defeat the purpose of ed, but it would still be way more minimal than even nano. It's one thing to be minimalist and another thing entirely to be minimalist. It would be one thing if you wrote your own version of ed and used that, because that minimalism would come with learning and improvement, but just piecing together this software isn't minimal. Are you using a minimalist machine as well? You're launching an entire operating system to use ed, instead of running ed directly from the BIOS or UEFI?

I'm doing everything in Vim now, I can't live without

Nano does all I really need. I downloaded a theme which gives it syntax highlighting and I also enabled numbered lines, and finally I swapped the control and capslock keys. With all that enabled, Nano becomes a very comfy text editor!

I use PyCharm and VSCode. Fite me. Really, I’m looking forward to this kind of editing to become more popular https://reasonablypolymorphic.com/blog/towards-tactics/ It would be nice to move away from typing words to describe what I want syntactically to just selecting what I want semantically.

>>21389 Snippets are very commonly used with vim and emacs. Emacs implementations tend to be more polished and easier to extend yourself. I write a soykaf ton of LaTeX and its getting to the point where I rarely actually write markup symbols. For example I just C-c C-e environmentname <enter>, and I get a \begin{environmentname} \end{environmentname} block with my cursor in the middle.

butterflies.

>>21398 C-x M-c M-butterfly

>>15959 Interesting idea, but they didn't manage to deliver.

A lot of people recommends Vim for programming, but never says because is very good, so... why Vim is an excellent test editor?

>>21464 I've always been confused by that, too. Personally I've never seen the appeal of modal editors. But to each their own I guess. For development I prefer VSCodium (vscodium.com) which is basically VSCode with the Microsoft stuff ripped out. I know some people aren't fans of Electron, but as far as Electron apps go, it's actually pretty resource-efficient. I hate to give Microsoft credit but I gotta say they're doing a good job with it. For simple text editing I like joe (joe-editor.sourceforge.io). I started using it with Slackware back in 1998-ish, and I've just stuck with it.

>>21468 >I've never seen the appeal of modal editors Basically it means you don't have to bury things under chorded leaders. There are other benefits but that's the main one worth mentioning. In other words you just hit escape and move around the file however you want rather than having to keep your little finger on the control key. It's better in some situations (like having to restructure a section of code) and worse in others (like fixing a typo or jumping forward a couple characters in insert mode). Essentially, instead of reaching for your mouse you hit escape and use the keyboard. I don't know how common this experience is but I used to be a firm proponent of modal editing when I first started using vim. However I recently switched to emacs evil-mode and found that really I was just a proponent of not using the mouse and modal editing was just the only way I knew to accomplish that. I find myself using more and more conventional emacs shortcuts as I learn them (although I still prefer vi keys for navigation and larger editing actions like moving/deleting/pasting entire lines or blocks).

>>21469 >like fixing a typo or jumping forward a couple characters in insert mode I found operations to be much easier once I remapped Escape. Popular replacements are jk and kk, but the idea is to choose a letter combination that doesn't usually occur. You can also copy emacs/readline if you still prefer staying in Insert mode: inoremap ^F <Right> inoremap ^B <Left> inoremap <M-f> <C-Right> inoremap <M-b> <C-Left> (Use Ctrl-v, Ctrl-f to generate the actual control code instead of just typing the characters ^ and F)

>>21471 >I found operations to be much easier once I remapped Escape Have you tried switching caps and escape?

I use Emacs with evil-mode on a small laptop keyboard (don't have space on my desk for a bigger one), what keybindings would you guys recommend? I swapped Esc with Caps but I'm not sure if I should use Caps for Ctrl instead

>>21489 I find CTRL to be fine where it is, I have the exact same setup, ESC to CAPS, it works really well

How would you approach problems when they happen in one file at once on a system with let's say 12MB (yes, twelve) of RAM - huge length of a line (in megabytes) - huge amount of such lines () - file in total exceeds system I choose 12MB as it's relatively easy to test ideas about handling stuff in practice and may have real life applications. What data structures/algorithms/access methods would you choose to implement editor able to work on such files? By work I mean most basic editing like writing text, using backspace and insert when typing, doing copy/paste (would there be limits?). Possibly also search and extra points if doing some form of regexp.

How do you guy feel about notepad++? That's what I use

>>21807 Notepad++ is awesome. Some people may whine about it being made for Windows, but I'd argue that making great GPL software for Windows is a great way to introduce the Free software concept to people still in that world.

>>21503 >loading whole file into memory in order to edit it I think we've passed this stage somewhere in 70's, no?

>>21809 Too bad nothing like Notepad++ exists for Linux. Ever tried to edit a >300KB file in Gedit?

>>21807 What I liked on it was how most non-printable invisible characters are printed with three letter blocks like pic related and this is somewhat useful when looking for strings inside binary files. On linux, it's just not the same. You could even use notepad++ and edit or split/combine files without breaking it while some text editors somehow try to mess with it. It's also quite fast, no truncation, able to view large binaries and even search quickly. >>21503 12MB isn't even that small. Old PDA phones and j2me phones had less than 12MB and surprisingly were able to view and edit files larger than their native memory. I mean that was the time when programmers had less resources and still do best practices to make programs fit into small RAM and small disk (like those phones only had 8MB internal memory).

>>21807 It would be my favorite if a Linux port existed

>>21810 >I think we've passed this stage somewhere in 70's, no? I have no idea when you and your friends passed it. People still edit large files that don't fit into memory, tho. >>21815 Yea, but some abstractions are better in that regards other not so. Also scaling issues.

>>21810 I guess you've never seen a 40GB syslog or debug log? It's not exactly rare.

Has anybody tried ox (https://github.com/curlpipe/ox)? I saw it show up on a few aggregators, but its proposition is insufficiently convincing.

>>21890 >Written in Rust To the trash it goes, not because rust is not a proper language but beacuse being "written in Rust" is apparently its main feature, the other ones beng nondescript.

I used to be a hardcore Emacs user, but ever since I've switched to XFCE I've been using Mousepad more and more Is something wrong with my init.el??

>>21890 I went out of my way and tried it out. Before I start, I'd just like to say that I read some of the source code and it's surprisingly pretty for a Rust project. However... >Hold the up key for a while and then stop holding. Cursor continues scrolling through >How do I exit ox? >Empty file with one empty line. Press backspace -> Line gets deleted. Press backspace again -> Ox panics. >My font doesn't show emojis >The search feature (Ctrl-F) is a little iffy and the cursor always seems to land a line below >The replace feature is as broken as the search feature and because it lands a line below, it can't replace the word It's minimalist but also broken and unoptimized. The author acknowledges it at least: >Bear in mind, this is a personal project and is nowhere near ready to replace your existing tools just yet

>>22059 Idk how does it look like? A lot of people invest too much time and energy into uphill battles, that are either not worth it, create fragile setups or that they are not prepared to take on. It's understandable if people give up, but I think it's just a misunderstanding. Learning the defaults and how people used Emacs before the LSP/Helm/straight.el/Doom-mess can also be useful.

>>22060 Wow, that's worse than I thought, actually. >It's minimalist but also broken and unoptimized. The author acknowledges it at least: And yet this guy added his very WIP project to software repos, and thus reserving its name. Douche move, I must say.

>>22063 Many projects in github repos are WIP and some are even abandoned. It is a text editor and it works, just not as well as others. It's somewhat far from being usable and it's even farther from reaching its goal, that is >an editor that takes features from some of the most popular editors out there, gaining the best of all worlds At the moment, his note on Xi also seems a little ironic >Xi is also written in Rust but is purely a backend at the moment, I decided to make Ox both a frontend and a backend because Xi has many frontends, but most of them are broken and it lacks a lot of features. It seems that he wants to create a minimalist and simple to use (Nano-like) but very extensible (Vim/Emacs-like) editor. However, the minimalism might be a bit Sisyphean because he wants to write a "Prettifier / Automatic code formatter", "Built In linter", "Auto brackets", "Auto complete" and "File tree". If he hardcodes these things instead of writing an extension system for them, minimalism will be gone nearly immediately. In the end, perhaps it will be just another unremarkable editor. And when you look at his github page, if you're skeptical enough, you shouldn't expect magic from him: >Hey! I'm curlpipe, a pro-privacy, anti-telemetry programmer and ArchLinux user. Explicitly stating that he's an Arch Linux user. Hard to say if he's memeing or if he's serious. >(In progress) Ox, an advanced text editor with IDE like features built in. Written in Rust. >Ox is super minimal and aims to use as few dependencies as possible, allowing for rapid compile time and low risk of breakage. "Advanced text editor with IDE like features built in," but also "super minimal" and "low risk of breakage". >(Concept) Resonance, a privacy-respecting online music player for all platforms. Written in JS on desktop and web. JS on desktop ._. >(Concept) Morris, a Mobile development platform written in Rust with simplicity above everything. A mobile development platform ._. >My favorite languages: Rust, Ruby, Python >Technologies I am familiar with: HTML5, CSS3, JavaScript, lots of other less important stuff >Technologies I plan to learn in the future: ReactJS, SvelteJS, TypeScript, other stuff Given the fact that Rust is mentioned next to Ruby and Python, and that he clearly likes webdev, you can assume that he won't use Rust for systems programming. He's ambitious but not a magician. I guess >>21890 got caught into the good ol' Rust cargo cult. It's a shame because there are some Rust projects which are amazing but remain mostly underground, unannounced. I guess that if you're learning Rust and you already want to contribute some code, Ox might be a good idea because its source is simple and bugs are plenty.

>>22088 >[Citation needed] If this is true, Mozilla has drastically failed because now instead of more systems programmers, we have more webdev programmers with webassembly. JavaScript developers are like monkeys. Some monkeys are clever and nice but most of them are just monkeys. And now you have monkeys with jetpacks. That's really bad.

>>22072 It's odd to me that Rust attracted so many webdev people. I would've assumed that most of the people using Rust would be application and systems programmers, since that's what it's designed for.

>>22081 it's actually the perfect programming language for high-performance web servers. There's a ton of rust web frameworks with some pretty impressive performance. there are some other rust web frameworks out there. They also went all in on the WebAssembly cancer.

>>22072 > Explicitly stating that he's an Arch Linux user. Hard to say if he's memeing or if he's serious. Apparently people do do this, and I don't understand it either.

>>22081 Rust was a plot by Mozilla to recycle dedicated webdevs into system programming

Is term "rust" an Old-English word for "I cannot into memory management"?

>>22082 >. There's a ton of rust web frameworks with some pretty impressive performance. So is written in ANSI C and C++

>>22096 >Apparently people do do this, and I don't understand it either. Arch is a sect and only Gentoo user herd is bigger in fanaticism (and masochism).

>>22098 Is term "washing machine" an Old-English word for "I cannot into washboard and river"?

>>22101 no, it's modern English term for that

>>22099 >>There's a ton of rust web frameworks with some pretty impressive performance. >So is written in ANSI C and C++ Theoretically, yes. But I've never been convinced of the wisdom of writing network services in C or C++. Buffer overflows in those two languages have probably caused more security problems than all other classes of code errors combined.

>>22115 Up until recently it's not like you had very many better options than C++. But yeah, it makes sense that people are using rust and go for that kind if thing now. The other thing is that web stacks for big companies are getting more bespoke. Http servers were always usually written in C or C++ but now unless you're just running a relatively small time website you're probably writing your own custom server side software instead of just cobbling something together with apache and CGI. So there's more of a demand for languages that will let you do that more easily.

>>22117 >Up until recently it's not like you had very many better options than C++ Golang is around for over a decade.

>>22126 That's still relatively recent. But yeah, as a big Go fan myself, it's certainly the first language I turn to when building any service exposed to the public internet.

>>22129 >That's still relatively recent. when you are 30+

>>22133 >when you are 30+ Hah, perhaps. I'm actually 40.

>>21503 >How would you approach problems when they happen in one file at once on a system with let's say 12MB (yes, twelve) of RAM The basic idea is, of course, to have a paging mechanism of some sort, since the approach of loading it entirely into memory won't work. > huge length of a line (in megabytes) > huge amount of such lines () I'm fond of the idea of storing text as a list of arrays, perhaps where each line is an array using the gap buffer approach, and this extreme case would certainly harm that. Virtual memory, and either a line length limit or a more complex line data structure would be needed. I could see, say, calculating how much of the first characters of a line would ever be necessary for things such as display, and have a specialized representation that stores those specially, with the rest of the line stored differently. > file in total exceeds system Virtual memory or other paging is reasonably necessary. The problem gets much easier when certain constraints can be added, such as line length limits, file limits, etc. It wouldn't be unreasonable to require files be below a certain size, and simply allow them to be used by the system in spite of this constraint. The best approach is certainly to specialize, so that such a text editor becomes less and less unnecessary. A specialized tool can use less memory, more on its own terms, etc. Now, just viewing a file is entirely different, since that only requires enough memory to fill the screen with information. Now, I make this post to share this, which is relevant to the question: http://leahneukirchen.org/blog/archive/2020/10/efficient-text-editing-on-a-pdp-10.html The basic idea is these systems, for large files, demanded that special conventions be used, and added some constraints on what could be done, but otherwise worked well. >>21810 It's my understanding this is still done, but the virtual memory systems hide it.

>>15408 I feel like Sam/Acme/Willy are lost potential due to their mouse needed to work with them nature

>>22206 it's just an idee fix of mine to think about most wicked corner cases sheer contrast with many modern popular text editors that sometimes were for years not able to open files larger than just 2MB if you know what I am talking about

Micro is pretty based. Like an extended nano

>>22319 I'm waiting for an even more advanced editor called "milli".

What are some interesting/experimental text editors to check out? I'm checking out some kakoune at the moment.

>>22329 It's there alrready an editor called pico? >>22330 Plan9's Acme and Sam are always interesting. TECO is cool if ed is too easy.

>>22487 Nope. When I am dealing with text, I expect to take my hands off the keyboard as little as possible. It's distracting. Now I may be stupid or something, but very often I need to move up a line or two. I never could do this in acme or sam because the up/down arrows do something different. I had to use the mouse to do a trivial displace. I've noticed when someone approaches acme users with this specific argument, they resort to this very strawman. No, nobody said the mouse is bad, but needing the mouse exclusively breaks the flow more often than not.

>>22492 How would you know since you never *actually* used a plan9 utility?

>>22553 I used plan 9 for a few months. It was nice. Plan9 C is way cleaner than regular UNIX C, I also liked the colorscheme, a lot. The fact that GUIs are not full of bells and whistles and are reduced to text areas with different properties was one of my favorite things. I liked the filesystem interface of acme and though I didn't really get to make use of it it sems to make the editor just as powerful as emacs. Plumbing seemed interesting enough, though I didn't use it either. I didn't really miss using the web when I had plan 9 (I did use mothra but it's certainly not the same as firefox, I was able to post in lainchan though). I dropped it for a couple reasons. I wanted to write scheme code, but never actually got around to write a scheme interpreter. And I never got used to programming in there because of the mouse. On the terminal, whenever I wanted to repeat a command, there seemed to be no way outside of retyping the whole thing. Or scrolling up, selecting the command, and then pasting it at the bottom of the screeen. I already talked about having to chase everything with the mouse on acme. Sam looks really powerful, though I never really needed structural regexps. I am sure they come in handy especially in large files, but for someone who's trying to correct those little typing mistakes scattered on a single medium-sized C file I only had the mouse. Had I a different environment, mouse, etc, perhaps it'd have been different. But I personally find it waay easier to keep hands on keyboard while I edit text. That said, you ought to fuarrrk off and die before making assumptions about what other people have or have not used you useless garbage.

>>22557 >filtered by the mouse I can't believe they have you zombies convinced that simple gestures are bad and remembering and using complex multi-metakey combinations is good. ABSOLUTELY pathetic.

>>22557 Other lainon here, I too don't like excessive use of pointer device in Plan9 graphic environment. Even while using a trackball myself, not a mouse.

>>22558 The only good side of mouse is the ease of picking up basics of using it. Trackballs cost user a lot of less energy to use and save from carpal tunnel and also could be much more precise. But mastering it takes time and making it really fast and precise (for example in Quake 3) the same time require mastering pointer acceleration. When you are concentrated on typing on keyboard switching to pointer device takes time, requires refocusing and then you go back to keyboard. It's multitasking. Humans suck at multitasking. Switching context frequently seriously annoys them. Especially when they are touch typists.

>>22558 When typing it is far more comfortable to keep hands on the keyboard. Chasing the mouse around for trivial movements is overkill. One doesn't even need complex keybimdings, that's what the arrows are there for. And the basic movement keys are but a handful, for basic movements. Again, the use of a strawman by calling out on esoteric combinations of keybindings. Also, you seem to like people insulting you, why is that?

https://www.computerworld.com/article/2826902/7-days-using-only-keyboard-shortcuts--no-mouse--no-trackpad--no-problem-.html Turns out the stopwatch doesn't lie, using a mouse is faster

>>22577 This topic often comes up when discussing plan9, but I only find it hypocritical. The same people who ignore research pointing out manual memory management is error prone, hardware having higher functions is better, dynamic linking done properly results in saved resources, or file versioning done right is better, amongst other research, will gleefully point out the mouse is faster than the keyboard, according to a study or few. I'm not trying to start a large argument, but it's very obvious to me the UNIX weenie and plan9 crowd are going to do whatever comes down from their high priests, regardless of the evidence for it. >The mouse is faster than the keyboard, so having an editor dependent on it is fine. >A garbage-collected language like Lisp entirely eliminates memory errors, but programmers should just stop making mistakes. I'm not exaggerating. Interviews with Ken Thompson have shown that's really his opinion on memory management.

>>22577 But for what? Even acme has keys to jump to the beginning or the end of a line, so there's a boundry. I agree that mouse-phoboia is wrong, but a statment like "mouse is faster" seems hard to generalize.

>>22330 Vis is an interesting experiment, but I would like more lainons check efte and xwpe, they are more like IDE replacements with the hotkeys of notepad and the look of borland turbo from the DOS days.

How do I get plan9port's sam to have the same color scheme as on plan9?

>>16452 >which doesn't support Unicode BTW, which is a feature What kind of bizzare world you live in? >>21816 What about notepadqq?

>>22319 >Micro is pretty based. >Like an extended nano Micro is the editor I've waited for, and was literally within about a week of trying to make myself before I discovered it was already done.

>>15408 I'm using vim, sometimes I use vis because I like the structural regular expression of sam. But I get back to vim because I have problems programming in scheme on vis.. Usually I keep two terminal opens: on one side vim with relevant source files and on the other side a shell to compile/man pages/grep/repl/other things.

>>22319 I came here to post about micro as well. It is almost perfect, I just wish it had more users and plugins. Really well written too, you can read the whole source in an hour. This is after using emacs for 2 years, painfully customising each piece of it but never being satisfied. I think I know why: > too much choice is bad for out primate brains > emacs keybinds are terrible, alternatives like ergomacs are not much better > emacs wants you to use it for everything, meaning learning the emacs version of git, web browser, dired, etc. which sux > it's huge and takes too long to boot for quick edits, running as a daemon doesn't work very well because buffers are kept between sessions

>>25589 >> it's huge and takes too long to boot for quick edits, running as a daemon doesn't work very well because buffers are kept between sessions You realize that saving and restoring buffers is optional and by default disabled unless your distro does weird soykaf, right? Anyway, you'll want to customize `desktop-save-mode`.

>>25589 >I came here to post about micro as well. It is almost perfect, I just wish it had more users and plugins. I've been working on learning how to write micro plugins since discovering micro last week. I'm having to dust off my very very rusty Lua skills to do so. But it's been fun to relearn Lua. Ironically the problem I'm having is coming up with interesting ideas for plugins that aren't just learning toys. If you (or anyone else) has any suggestions, I'd be interested in giving them a shot. Email: c@sprawl.city. >Really well written too, you can read the whole source in an hour. That's Go for you. Small keyword count, one looping construct, one enforced bracing style, and a massive standard library combine to make it incredibly easy to read a Go program written by anyone even remotely competent, with the reader having even the most minor experience in the language.

I am absolutely torn between learning neovim and kakoune. I intend to use it for programming. I can only choose one. https://github.com/noctuid/dotfiles/blob/master/emacs/editing.org#why-not-kakoune https://kakoune.org/why-kakoune/why-kakoune.html https://github.com/mawww/kakoune/blob/master/doc/design.asciidoc Kakoune feels /comfy/ when I use it and I don't know why. But I'm also put off by Kakoune because its keybindings are novel; this means if I want to switch to I can't switch easily to nvim or a vi-like plugin for a popular IDE (such as Emacs or IntelliJ). I am not sure if Kakoune is future proof. I am not sure if Kakoune is a gimmick. I am also not sure if Kakoune uses less keystrokes. Kakoune's community is very small. Can someone give me advice?

Is vis a usable text editor? Is it mature enough for daily use? I know that the main difference between vis and vim is structured regex and multiple cursors. https://github.com/martanne/vis/wiki/Differences-from-Vi(m) https://github.com/martanne/vis/wiki/FAQ#what-are-structural-regular-expressions http://doc.cat-v.org/bell_labs/structural_regexps/ I am not a vim user. Can someone explain what structured regular expressions are and what ex-mode is? What type of regex does vim have? Is it just POSIX-compliant regex? I don't what ex-mode is and structured regular expressions after reading the attached links. Can someone explain?

>>25589 >it's huge and takes too long to boot for quick edits, running as a daemon doesn't work very well because buffers are kept between sessions You are only meant to boot it once. But I still use vim when ssh into server and doing a quick edit. Emacs is a great tool, but it is not the only existent tool. Emacs wants nothing. But once you are familiar with it, you might want to use it for everything. Mainly because you can script the soykaf out of your workflow once you are using it for most things. Your other points can easily solved within emacs.

>>25887 If you care about your editor being future-proof, by which I suppose you mean that it will continue to exist for a long time, the only sane choices are vim and emacs. If you pick anything else, you're accepting the chance that it'll be abandoned in a few years. Since you seem to enjoy kakoune so much, I think you should pick it and use it for all your intended editing needs for a few weeks. If you still like it as much afterwards, ask yourself if you'd be willing to maintain it after everyone else has abandoned it. There's nothing wrong with being the fool on a hill who uses a dead editor if you really fuarrrking love said editor.

What is the purpose of LSP? What can LSP do that ctags, search and replace cannot do (apart from code completion)? Does anyone have experience with Kakoune's LSP?

>>25888 Checked. The essential difference with structured regex is that, unlike classical unix regexes, they are not lmited by newline characters. >Unlike other UNIX text editors, including the non-interactive ones such as sed and awk,7 sam is good for manipulating files with multi-line ‘records.’ [1] They also have slightly more general commands to go with that, such as x which is a looping construct[1]: >Sam’s iterator is called x, for extract: >x/expression/ command >finds all matches in dot of the specified expression, and for each such match, sets dot to the text matched and runs the command. It is hard to come up with examples for the need of sre's in everyday use. I am sure with regular use they might prove useful, but I haven;t taken the leap to take the time to learn the editor. > I don't what ex-mode is and structured regular expressions after reading the attached links. Can someone explain? ex-mode is just the command-line version of vi*, it's vi* witjout the visual part, it's ed+, ed with the commands available from vi. Vim uses line-oriented unix regexes. >Is vis a usable text editor? Is it mature enough for daily use? Yes. But it depends on what you need. It doesn't have a GUI-styled editor such as gvim (which you might like better), I don't know if it supports UTF-8/Unicode, and while I think it is lua-extensible, I am not sure it has the enormous plugin ecosystem that some people seem to need. I usually fire the editor, edit text, and leave. [1]: http://doc.cat-v.org/plan_9/4th_edition/papers/sam/

>>25893 >If you still like it as much afterwards, ask yourself if you'd be willing to maintain it after everyone else has abandoned it. This is one of the reasons I've switched over entirely to Micro (https://micro-editor.github.io/). I love the program for its easy extensibility (plugins are just simple Lua programs), and I'd be willing and able to maintain it if necessary.

>>25895 Full semantic analysis using the AST of a given language by LSP servers, in a way that is pluggable with a standardized protocol to represent the various interactions. ctags, search & replace cannot do that unless you basically combine them into a bespoke lexer & parser for the language you want to deal with.

Is anyone aware of a vintage or fork of Hemlock in a functional state? I've tried the latest CMUCL version and the quicklisp fork both of which had many severe errors (some of which make them nearly if not in actuality unusable). I've been reading the manuals, and I expected to need to do some work myself, but it's seeming to be in a worse state than I imagined. If this is no such program is there another Emacs with a standardized lisp implementation/extension language which is available? Preferably one which is fossilized, sane, and well documented. Edwin perhaps?

>>15408 Since this is a text editor general, have there been any studies done on differences between modal and regular text editors that compared their speed? Many people claim modal editors such as Vim or Kakoune are much faster to edit in than stuff like Visual Studio Code but they never show any evidence to support that and they were consistently slower in my experience.

>>25921 On second thought, I think I'll draft a specification of sanity, and attempt to make a minimal viable prototype.

>>25933 Is anyone aware of a way to have an editor with capabilities to operate on generic language ASTs as 'text-objects' (I think I've heard this called semantic editing before)? It seems like you need to couple to the compiler if you want to work in languages with parse-time evaluation like Common Lisp, or OCaml (with camlp). At the same time the language server protocol doesn't provide facilities to do such a thing in a language generic way. Perhaps given coupling to every compiler is not practical a parser should just be written for each language, and when users use parse-time evaluation features they should be encouraged to extend the editor parser as well? Typically these features aren't used very often, so this is reasonable? Further support could be added for the implementation language's parse-time evaluation by coupling to the compiler and other languages could be left with this other implementation. I'm currently reading some about Shütz, but I don't believe this solves the mentioned problem.

>>25942 >Shütz Harmonia seems to be better reading, as an introduction to the subject I'm going to read that first, I think maybe my proposal in the last post is the best option. Also these features are unlikely to appear in my prototype in any case.

>>26071 I watched a video on this; I suspect the author was aware of the research because it's very similar to the core of Harmonia.

>>15435 >Later I thought that vim (but not vi) and emacs users should be the wrong audience precisely, since they (among other people) like to extend their editors. it's interesting to hear people describe vim this way. I like precisely because I don't need to configure anything. the only thing I wish stock vim had was a register stack, but I can get by without it.

>>26086 >>26071 Godspeed lainanons! I think a language-agnostic editor that uses AST inspection and other features like treesitter would provide a lot of cool benefits to programming that language servers don't do (well), some of which would include: - proper syntax highlighting - proper syntax folding - project source awareness (being able to rename an object across the project, being able to jump around in the project, etc) - partial evaluation (what is x in this line of python source?) - realtime syntax checking and style linting - probably more

>>21494 i had it configured in X . as ctrl if you hold it and as esc if you press it once . changed it to super instead of ctrl but mainly its just used as esc

>>15408 >Current text editor? NeoVim >Describe your programming and general editor usage and workflow, e.g features you use heavily, any properties unique to your text environment. I am not a programmer but I am learning webdev. Aside from copy and pasting some scripts for NeoVim and Shell, there is nothing else, for now at least. I do a lot of prose and my personal notes are in asciidoc with neovim as a tool for searching and editing (nothing fancy) >Have you wrote your own text editor? Nope >What do you think of modal editing like what vi presents? It's different and comfortable but it depends if you really want to learn it. I began with Vim (then Emacs and then NeoVim) but I didn't switch because of the bindings but because I liked how "modern" NeoVim is compared to Emacs. Also Vim CoC is easier to install than lsp-mode. >How do you feel about text editors being general computing environments, e.g Emacs? Alternatively, what do you expect from a so-called text editor? Like I said, I am not a programmer so my needs are smaller and simpler than someone who has to build a program for money or hobby. I personally used Vim and Emacs more for prose and modifying some config files and scripts in Linux and for that, they work great. Having modal editing is a plus but for me, not a huge improvement. Being keyboard only, that was the most important "discovery" of using both Vim and Emacs. >Is being presented a screen with source text all we need? Or are there other more involved editing mechanics that we could be exploiting and exploring? I don't know about programming but for prose, only text in front of you it's the best. A few syntax highlighting is ok (I use asciidoc) but anything else is too much noise. I got used to CoC, I was surprised how it helps when writing prose or simple notes. >Programming languages which sport s-expressions often allow for powerful text editing capabilities (lispy, paredit), how else can a language provide opportunity for powerful tooling involving editing and such? Well, editing my Emacs conf was an ok experience. I did basic stuff and most of my configuration was copy paste from the internet, but I guess Lisp is very different but you can get used to it. Is it better? I cannot say, vimscript is very different but easier? Lua looks a little more modern like Python, so I guess when I get better in NeoVim I will try to change to a Lua config. If you like parenthesis, you could try Fennel if you don't want to try Emacs.

>Ctrl-F kate >no matches I am disappoint.

>>27318 I'm delighted. It's a mark of maturity of lainchan userbase.

>>27349 Why would using Kate be "immature"?

> Current text editor? Acme is my daily driver, has been for about a year by now > Describe your programming and general editor usage and workflow, e.g features you use heavily, any properties unique to your text environment. Well acme being acme I find the integration with the OS tools quite useful, I regularly find myself pipeing data from selections to program, grepping all over the place, right clicking on stuff. I've even gotten to the point of writing custom plumber rules to be able to right click on even more stuff like S3 addresses and even EC2 instance ID's. > Have you written your own text editor? No > What do you think of modal editing like what vi presents? I see why people like them, I used vim for like two years, although I can't shake off the feeling it's something invented for a bygone limitation. UIs have moved past the times of only terminals. > How do you feel about text editors being general computing environments, e.g Emacs? Alternatively, what do you expect from a so-called text editor? Your editor should be part of a system, if the editor provides said system that's good by me. Both Emacs and Acme share in that, but Emacs takes it the "let's rewrite everything in e-list" approach. I feel your text editor should in some way work together with what you're working with. Compiling, linting, runnign commands while working is part of the workflow most developers use, so your editor should allow you to run these tools. > Is being presented a screen with source text all we need? Or are there other more involved editing mechanics that we could be exploiting and exploring? In order to get some basic soykaf done? Yeah sure, I've had to use machines that only had `ed` which well was a bit extreme even for me. Now in order to work comfortable without loathing my own existance? fuarrrk no. My system is filled to the brim with binaries and scripts that help make my life easier, I expect to be able to use them. > Programming languages which sport s-expressions often allow for powerful text editing capabilities (lispy, paredit), how else can a language provide opportunity for powerful tooling involving editing and such? [Citation needed] Ok jokes aside, I feel any language can help you work with whatever you're doing, Acme really shines in that it allows you to use anything that uses standard input and output. If you can interface with that, you can write your utilities in whatever language you like, be it C, C++, Brainfuck, Anything-that-isnt-yaml, the sky's the limit.

>>27355 Because it krashes.

>>16150 >I used ed for a year as an ed user myself I have to ask, why'd you quit ? for more comments on my workflow etc, for longer projects I often keep a few files open simultaneously in less to browse around and keep an eye on different parts of the program simultaneously. I've seen emacs users do similar things with just another editor window focused elsewhere on the file. I like the search tools ed has (basically grep), and the persistent buffer whereby you can print out like, all the lines matching a regex (good way to list all functions out without any other cruft for instance). Of course vi/m has all these things, I suppose most editors do, but a continually updated buffer is a bit annoying to me now. >feelings on full computing environments as editors I really don't see the point. you can just have a few windows with shells/less/ed open and this seems basically the same as a full emacs or vim session. Its useful, but having it in or out of the editor is immaterial.

>>15408 >How do you feel about text editors being general computing environments, e.g Emacs? Only worthwhile if you use it as your main computing ecosystem - whether living in a tty full-time or using Emacs as your window manager via EXWM. Otherwise you may as well boot up a VM to edit your text files.

>>30613 The view of emacs as basically an OS is one of the most annoying misconceptions I see. It isn't anywhere close to an OS in terms of complexity or function. It is much closer to a web browser in both aspects. I use Emacs primarily for editing text and it is very good for that.

>>30622 Emacs isn't an OS, it's a desktop environment. You're right that it has a lot in common with modern web browsers; you can live in Emacs as readily as many people live in their web browser today (Chromebooks). A lot of people may not mind using it for single simple tasks, though, and that's fair.

>>30622 It's a very limited OS in terms of modern expectations for an OS, but I would say it's closer to an OS than a web browser. It's a lisp machine emulator with a text-based interface that happens to have a decent text editor built in. In much the same way, Nyxt is a lisp machine emulator which comes with a full-fledged browser engine with support for JS, stylesheets, etc. - but it is a lisp machine nonetheless. Of course, anyone with a semblance of sanity who uses Emacs will use it primarily for editing text and as a git client, *maybe* as an email client if they are involved with free software development over mailing lists. Anyone using Emacs as much else is an enthusiast to be sure but can't be doing too much of value. While all the various modes of Emacs which significantly extends its functionality beyond that of a text editor are cool, they are mostly pointless. eww is pointless, eshell is pointless, dired is a useful in-editor tool if you're too lazy to use your normal file explorer but otherwise useless, gnus and all email clients are neat but impractical for modern email (read: HTML-based email - sorry, it's here to stay), org-mode is cool but you're truly a savant if you use it for anything but the most basic markup. The exceptions to the rule in Emacs are magit (genuinely the best available git client out there) and, if you're developing with languages other than C/C++, lsp-mode/eglot which make the whole experience much closer to a modern text editor/light-IDE like VSCode.

Atom is dead >we’ve decided to retire Atom in order to further our commitment to bringing fast and reliable software development to the cloud via Microsoft Visual Studio Code and GitHub Codespaces. >https://github.blog/2022-06-08-sunsetting-atom/ I think this is a good thing. If you know someone who's still using Atom, tell them to switch to VSCodium (sic.) or Neovim/Emacs.

>>31458 ive never even thought of even trying atom thats how obvious bullshit it is im not glad hes gone, but im glad hes dead

>>15408 3 years late but I just read that acme article (A lesson in sane IDE defaults), what a trainwreck, complete soykaf. >no "syntax highlighting" (which is a good thing) already off to a bad start considering the linked article is one of my most despised relatively popular tech article of all time. >There are no configuration files. >Why would you need them? why? you highlight the main disadvantage of this way of working, and it is already a complete dealbreaker for me: >If you don't like the defaults, Acme is not for you. and why does this have to be the case? I absolutely despise Emacs' defaults, but it is my favorite text editor because it can accomplish anything I want it to do. sure, in the ideal frictionless universe where dev time is infinite and all possible ideas have already been implemented I can just look for a text editor that fits my tastes by default and evolves in the same way I do. I would love for that to be the case, but it just isn't possible in the real world. >FAQ: "Wouldn't that slow you down?" - No, not really. Being a productive developer, you probably spend most of the time writing new code instead of changing existing code. WHAT?! in what universe does this guy live in? reality is the complete opposite of what he says. >Even if you need to do that, clicking directly where you want to type is notably easier than instructing your cursor to go two lines up, five columns to the right and then enter the Insert mode. this shows his lack of experience with modal editors. the most efficient solution for most of these movement problems is searching for the section you want and tabbing to it. I type 150wpm, typing 5-7 letters will never be slower than reaching for my mouse and reacting to a contextual menu, not to mention how unergonomic switching every couple minutes can be. >Your disadvantage: You'll need to open your mind a bit. This is not like "moving from Sublime Text to Atom", this is like "moving from an IBM PC to a PlayStation". good analogy, I love programming on my PlayStation. >I am currently using six text editors on different systems for different tasks. If there was that one perfect editor, everyone would use it everywhere... this is one of his replies in the comment sections. I genuinely wonder how he thinks this is a better situation than having 1-2 editors and spending a negligible amount of time messing around with settings. I personally use Emacs (DOOM) as my daily driver and (barely configured) vim for quick edits. I haven't touched my vim config in years, and my emacs config uses up about an hour a month of my time.

>>21489 As an Emacs and evil user, I mapped Caps to Control and then made Control-Space to exiting insert mode. This lets me use both Emacs and Vim keybindings very comfortably.

>>22206 >storing text as a list of arrays, perhaps where each line is an array using the gap buffer approach Isn't a rope data structure a better idea? The array of lines approach is simple, but it will have problems with extremely long lines.

I can recommend lite or its chubby brother lite-xl. Looks like Sublime text or Atom but performance is a lot higher, ram usage is only 10MB and install size is around 1-2MB depending if you install plugins and stuff. https://github.com/rxi/lite https://lite-xl.com/

https://github.com/pulsar-edit/pulsar https://play.google.com/store/apps/details?id=com.rhmsoft.edit

What do you think of dion ? It is a prototype programming environment that operated off of code that is stored as something closer to an abstract-syntax-tree representation instead of plain text.

>>36407 Looks very nice. I'll be looking at that, lately I've been thinkijljg about this indeed, code editors should deal with ASTs directly, and text ought to just be an interface for the user, which could emphasize or hide different things. Right now we type in our programs character by character, isn't that odd?

reminder vim and neovim use large dependencies to match what Emacs does out of the box I've compiled them all and compared their build options, Emacs is the most minimal

>>36632 My preference for neovim over emacs and vscode mostly boils down to neovim being faster. But I use vscode when I do Unity development. If emacs could start in less than 100ms at it’s slowest AND have all the functionality of a full editor (including lsp, treesitter, motions, other nicities, and not use elisp for configs because fuarrrk elisp). Then I’d probably use emacs.

>>36633 Referring to startup time specifically, emacsclient starts up instantly if you already have an emacs daemon running. I have the following line in an emacsclient.desktop shortcut, so if a daemon is not already running the emacsclient invocation will spawn a daemon for itself and other clients to use (even after this client is destroyed). Exec=/usr/bin/emacsclient --alternate-editor= --create-frame %F Some people also use user services, or scripts that run on login to initialize an emacs daemon. I've never found this necessary though, as emacs starts in under a second for me (and I would consider my init.el to be very bloated and unoptimized). Emacs in general is very fast nowadays when built with jit enabled. It's enabled on gentoo by setting the jit useflag, but I'm not sure if the emacs binaries provided in the repos of larger distributions have this enabled.

>>36634 I know these daemon tricks and startup time for me was never more than 1.3s, but anything slower than 80ms is painful for me, and daemons do not glorify the name of jeesus

I'm sure the novelty will wear off pretty quickly, but the ability to set alpha-background in emacs 29 is pretty cool. It's gimmicky, but I've been using it to have 4k walking tours of cities playing behind my editor. It's pretty comfy and not as distracting as you might think. If anything I feel as if I tab out to a web browser less. When I'm losing focus I can just watch the background video instead of distracting myself on the internet.

I don't know why some people love to debate online about their favorite little text editor. It's childish to me. As a vim user, i don't give a damn if you love emacs, vis, xi, micro, nano, atom, vscodium... Why do you people care so much? It's a piece of software, it's not worth it to put all of your emotions on it, let alone make it a part of your identity. Yes, emacs can do things that vim can't... And? If I needed those things, I would have already switched. I mean, it's great to see emacs do cool things, or any other text editor do cool things, but at the end of the day, vi(m) is my editor, and I never needed anything else. You will not convince me to switch, for that is something only I have control over; If I wanna switch I will. If I don't wanna switch, I won't. So stop fighting. Focus on being productive, being efficient, regardless of what tool you use. Ask for advice from people who use your tools, not from people who want you to use something else. >Describe your programming and general editor usage and workflow, e.g features you use heavily, any properties unique to your text environment. I don't use any plugins. My vimrc file is 57 lines long. I enjoy the simplicity of my setup. So it's pretty much default vim experience, aside from syntax highlighting, some custom theming, and numbered lines. I don't need anything else when I already have the capabilities of vi-like keybindings, ed commands, and being able to pipe the text in my buffer to other scripts or programs. my nvi (not neovim. nvi, the modern vi clone) config is just the vi-compatible options from my vimrc + a few other ones. I use it when I feel like it, honestly. I can't pipe lines of text to wl-copy for some reason (it hangs), so I use vim most of the time. >How do you feel about text editors being general computing environments, e.g Emacs? Unnecessary for me. Even when I was super into programming in C and Rust, vim (and tmux, but this is a text editor thread) was all I ever needed. >Alternatively, what do you expect from a so-called text editor? Uhmmm... That it can create and modify text files? Jokes aside, vi-like keybindings and modal editing, and for it to be fast and simple. I really don't care about anything else.

>>36649 >I don't use any plugins. My vimrc file is 57 lines long. my work setup doesn't use any plugins aside from one i hacked together to help with one of our internal DSPs and has a pretty minimal vimrc. it's cozy and still much better than the alternatives I tried, but i only run it without plugins because my work has a painful approval policy for any 3rd party software and it takes months to get anything approved. my home setup has some language server plugin and some language specific debugger plugins. Those are the only things i miss when using vanilla vim.

Bram Moolenaar, the original author of Vim, has passed away. Original text: https://groups.google.com/g/vim_announce/c/tWahca9zkt4 --- Dear all, It is with a heavy heart that we have to inform you that Bram Moolenaar passed away on 3 August 2023. Bram was suffering from a medical condition that progressed quickly over the last few weeks. Bram dedicated a large part of his life to VIM and he was very proud of the VIM community that you are all part of. We as family are now arranging the funeral service of Bram which will take place in The Netherlands and will be held in the Dutch lanuage. The extact date, time and place are still to be determined. Should you wish to attend his funeral then please send a message to funer...@gmail.com. This email address can also be used to get in contact with the family regarding other matters, bearing in the mind the situation we are in right now as family. With kind regards, The family of Bram Moolenaar

>>36656 F Ive often complained about vim but still a noble project and sad to see this.

>>36656 >rms still alive GNU Emacs - 1 Vim - 0

>>36641 >I've been using it to have 4k walking tours of cities playing behind my editor could you share a source for that?

>>36680 mpv + https://www.youtube.com/search?q=barcelona+walking+tour&duration=long&features=four_k&features=hdr I've archived a couple TB of them before youtube gets WEI-walled.

>>36656 F, RIP. I will keep using Vim.

>>36633 >If emacs could start in less than 100ms at it’s slowest Seems like a larp, if you can tell the difference from UI perspective from 100ms to 125ms, this could be taken seriously. But humans can't. >>36640 > but anything slower than 80ms is painful for me you can just be a troll... this isn't the ping in an online FPS game.

>>36641 Really pisses me off that it doesn't work for images though. I would use it if it didn't look like total soykaf to boot up Emacs and have a random 100% alpha recktangle around the logo. >>36649 >As a vim user Stopped reading here lol. You can't call other people childish for talking about text editors then write this much about your vimrc or whatever. >>36407 This has been a long time coming but it'll never take off. Using treesitter for editing documents structurally is the closest I think most will get (which is fairly good, all things considered, but a downgrade from lisp). I really hate that cursor thing. I get that it helps you keep track of this, but I've always thought the right way to do that is to just keep the cursor centred in the window. Variable names with spaces is something I kinda want, but at the end of the day, I know it will never happen and I'm glad it won't.

>>36682 What is WEI? >>36703 I won’t debate you on that but I can really feel when my vimec takes longer than 40ms, it becomes obvious at 200ms, and it becomes torture at 700+ms. That’s why I optimize its startup so heavily. Bear in mind I’m using a monitor with more than 120hz refresh. > troll Mean! I’ve genuinely used doom and vanilla emacs but I don’t like daemons (the jeebus thing was a joke, I just dislike background processes), and I really hate slow startup times.

>>36711 >What is WEI? Google's recent attempt at DRMing websites. https://en.wikipedia.org/wiki/Web_Environment_Integrity

>>31458 Why do even bother? I started working with programming in /1998/, back then I only had two options at work: emacs or vim. It turned out that I got used to vim but I don't see a reason to recommend that to other people. We have powerful computers nowadays, it's not like performance would be a issue. Yeah, I tried to use VsC*de but I hated it since I was already used to vim and all my configs. Even though I don't think it's a good idea to recommend vim or emacs for newcomers, they'll spend more time trying to figure out the key combo rather than getting the job done, that's why I don't recommend vim or emacs. If the person wants to learn for the sake of curiosity then OK, I will try my best to help, but I will not wage slave things such as code editors. If they want to continue using Atom what's the problem? If they get the job done in a soykafty code editor then it's okay for me.

How should I go about making my own text editor? Is it best to use a GUI framework like GTK or QT (I really don't like these at first glance)? Should I read the X11 documentation? Any direction is appreciated

>>37012 SDL is better, fundamentally you just need to render a grid of characters for a text editor.

Should we make an emacs general? I'll just ask my question here. Anyone know of a good right click context menu plugin? Pic related is like kicking dead whales down the beach, you can't escape it without choosing an option from the menu, which can be annoying. Here's it's git just incase I missed some config option and someone wants to try it (It's also on MELPA) https://github.com/zonuexe/right-click-context

Oh, you guys and your word filters

>>37509 It's easy for me to forget about them.

>>37012 Use either Tk or SDL. I recommend starting out with Tk, unless you have experience with SDL. >Should I read the X11 documentation? Go make your text editor and use a GUI toolkit. You can always later change the GUI to use libx11 (or better XCB) later. >>37508 >Should we make an emacs general? No. Just post everything that's related to text editors here or >>37339 (depending on which is more suitable).

>>37550 >No. Just post everything that's related to text editors here Ok. Is there a good emacs package for remembering your scroll position when you leave the immediate buffer? As for the right click, I realized the C-mouse-3 pretty much does what I want, I'd just like to be able to replace it with mouse-3. I'd like to swap the two commands, if possible (I know it's possible I just don't know how and the documentation is hard to browse sometimes

>>37561 You mean save-place-mode ? Emacs also supports bookmarks: https://www.gnu.org/software/emacs/manual/html_node/emacs/Bookmarks.html

>>37577 No. I mean, maybe it's nitpicky, but when viewing a large document you should be able to scroll past the buffer window and have your cursor stay where it's at without having to remember to manually set a mark. I read a post on reddit from several years ago detailing how people were working on an extension but it was still in the beta phase. I'm wondering if any progress has been made yet. Apparently with the way emacs is written it would be very hard to implement something like that

>>37579 Doesn't eww already block all of that stuff? Maybe not adblocking, but I didn't know it supports javascript in the first place.

Micro is indeed a great editor with good extensibility and excellent mouse support but it's dysfunction during regex searching or text replacing when newline is involved really puts me off sometimes. Kinda solved with "Alt-s": "command-edit:textfilter sed -e \'" "Alt-s": "command-edit:textfilter ssam -e \'" in the config file but it's a bit hacky. There are multiple issues in the github repo regarding this but they've been there for a while now. Maybe a simple Lua plugin would be the cure. Aaaaand the "Replace & Find (next)" functionality of Geany would be great also.

>>37508 Emacs has `context-menu-mode' built in.

>>37012 You can make the core separate from the GUI and then you can implement whatever GUIs you want. That's what Emacs does.

>>30393 >>16150 same, but still using it. i even for fun, added highlighting to it using another command, pygmentize. my version has macros, and scripting and registers and i have couple fast shortcuts in my inputrc for saving and quiting or compiling and for using less when needed, and for clearing the screen. >>19321 the idea of using a lot of tools for one task, is the core idea of unix. >>16158 You learn regex, for example, to do what you're asking; s/one/anon/2p (line-position)[command]/regex/substitution/(commands, args...) this substitutes the second appearance of the word "one" with the word "anon". for the third appearance, that would be just changing the number 2 to 3.

>>36407 Pretty cool, u go the source?

I have tried Neovim and Helix for months and I still could not be productive or comfortable with these editors. They are too reliant on memory for all kinds of keybinds. Editors like Micro are great, very intuitive to me right from the start, and I am very productive with them. Unfortunately, there's not many TUI editors like Micro, most follow the Vim-like trend. As for GUI editors, more than ever the big ones are more bloated than your mother unfortunately, but you still have lightweight ones like Kate, Geany, Notepad++ for Windows users, and I guess some new editors like Lapce. Maybe the GTK text editors in Cinnamon, Gnome, etc are also good enough? Dunno, never tried.

I made a small Bash script that lets you run inline shell commands and execute code blocks inside Helix, like Acme. No plugins, no dependencies—just your editor’s pipe command. It brings more interactivity to Helix (or any modal editor that supports piping), making it feel more alive. I didn’t expect it to be this useful, but now I use it all the time. Thinking of adding per-buffer sessioning, so you can keep variables and imports between executions, making it a lightweight Jupyter alternative. Would love to hear if it works in other editors. Test it, break it, improve it: https://github.com/greek-cheese/akme.sh

>>41137 No reason for being bash, it's almost entirely POSIX sh. Use shellcheck. Use set -eu. `| eval bash` is gibberish, eval does nothing here. Same with `| xargs`. Did you do that with a LLM or what?

>>41138 Hey! Thank you for your feedback and for showing me a shellcheck. Yes, I used LLM, but I should have been more careful about those points (will use my own eyes more and shellcheck as well). Thank you again, I really appreciate someone's alive view on my script, because I have little to no people with whom I can talk about such topics. However, I also wanted to ask: How do you feel about the general idea? Do you think bringing Acme-style execution into Helix using shell is a dumb idea, or do you think it could have some potential? Also, as someone who's still relatively new to shell scripting, do you have any other advice or things I should look into? I recently learned that cat might not always be the best choice, and that instead of a multiplexer for adding context to each new buffer I can use FIFO pipes. What else might be good for me to consider as I continue learning?

Acme is one of the most based programs to have ever exist. It has exactly everything I want, with none of things I don't. >>41139 I'm not the poster you're replying to, but check out the second pic for a good reference to writing bash/sh scripts. It'll say when something is POSIX compliant or exclusive to bash. Shell scripting is super easy to figure out once you realize a shell script just runs each line in a file as though you were typing it into a shell prompt. It makes debugging scripts far easier.

>>41141 Thank you for the book! Dived into it and POSIX specifications. About Acme, I agree, the concept is very powerful, and I simply don't like that Acme is: 1. Mouse driven 2. Requires plan9port to run on Linux And thus, it is possible to implement, at least partially, this idea inside other text editor, I feel that we lack something more UNIX-like on the market with pure shell API, much like sed, but yet stateful, with ability to connect through different front ends, similarly to Kakoune, and scriptable with any sort of shell, cause it is accessible by any other programming language in the world. I know this is a bold idea, however, this is something I will be trying to achieve in the future.

>>15421 only one mention of tilde??? i'm sad not more people know about it :( i would totally use it but for quick edits my brain is already mapped to nano shortcuts; now for longer stuff its excellent as it has an easily accessible undo macro

>>41141 > Bash pocket reference i wonder if there is something similar to this, but for the dash shell closest thing i can think of is printing the man page, and in a sense this could also work for bash flood detected, sanity discarded

>>41151 Everyone gives the mouse a lot of soykaf because nobody else learned how to use it right. All any of you know about using the mouse is clunky IDEs forcing you to navigate through 5e10 menus to get at what you want. So of course memorizing weird Vim motions and learning finger gymnastics with Emacs seems faster. Acme (and Sam to a certain extent) uses the mouse combined with plumbing rules to radically change how you use the mouse. Mouse chords let you do common tasks like copy/paste. You can also run commands withing Acme from the mouse. As far as I can tell, Plan 9 was the only project that properly understood the power of a mouse.

>>41178 ya know last time I tried using acme was on a laptop with a trackpad I should give it another go now that I have a real mouse

>>15408 Never answered OP's questions. Just wanted to talk about Acme lmao. >Current text editor? Acme (shocker). I came to it after trying to make vim work with as few plugins as necessary. >Describe your programming and general editor usage and workflow, e.g features you use heavily, any properties unique to your text environment. I'm on a fresh Arch install so I'm still getting things situated. But right now I'm focusing heavily on using Acme for as much programming work as possible. I'm configuring acme-lsp so I can have some modern programming features. Eventually I'd like to do just about everything reasonable in it. >Have you wrote your own text editor? Nope. >What do you think of modal editing like what vi presents? Modal editing is from a bygone era where mice didn't exist and computing resources were scarce. Don't get me wrong I still have Vim installed for when I need to do something quick, but for any serious work more sophisticated editors are needed. I'm not denying that people can get used to using vi/vim commands and be fast with working. By all means, learn your tool. But don't sit there and pretend that "dap" is more intuitive than selecting the text with your mouse and hitting the delete key. >How do you feel about text editors being general computing environments, e.g Emacs? Acme is what Emacs wishes it could be. OP linked to Russ Cox's video where he goes into more detail on this topic, but Acme is an Integrating Development Environment that doesn't come packaged with its own tools, but instead acts as an interface for tools already on your system. It does Emacs stuff without the need for installing a whole lisp machine onto your computer. Implementing a way to indent blocks of code was as simple as making a sed script. And the plumber can help out with more complex tasks like opening non-text files. I even wrote a gemini ( https://geminiprotocol.net/ ) client that used Acme as an interface. I don't know a damn thing about network programming or encryption, but I was able to cobble something together with netcat and some awk scripts. I had the time of my life hacking that out. >Is being presented a screen with source text all we need? Or are there other more involved editing mechanics that we could be exploiting and exploring? Show me a better way and I'll listen. But I haven't seen anything more efficient than just plain text. >Programming languages which sport s-expressions often allow for powerful text editing capabilities (lispy, paredit), how else can a language provide opportunity for powerful tooling involving editing and such? More like suck-expressions yooooo. No seriously, I've tried to get into lisps a few times and I don't think they ever clicked for me. I've used Racket and Chicken Scheme (really like the latter, btw) and though they're cool, I just haven't seen the power of s-expressions other than I guess being easier for a parser to parse. I just want to code. >>41179 Most mouses have 3-button support so you should be good. Though I still use Acme with my Thinkpad nub and I have a great time with it. If the laptop keys give you a hard time, you can use the control and shift keys in combination with mouse-1 to simulate the 2nd and 3rd buttons.

>>41180 I find using mouse extremely slow. I work with CAD as my day job, and even though it's 99% mouse input, I configured it to have my most used commands or macros as keyboard shortcuts. I can't say that using a mouse to select text and delete it is faster than navigating and deleting it with only keyboard commands that you have memorized. For a layman who only knows the mouse and uses keyboard only for typing, then sure, it's faster, but for someone who works with a computer most of the day? It seems like wasting resources, moving your hand aeay from the keyboard to operate the mouse. But, do whatever feels good for you.

happy emacsunday emacsirs!ヽ( ˙꒳˙ )ﾉ >emac 30.1 released https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-30 https://lists.gnu.org/archive/html/emacs-devel/2025-02/msg00997.html

been working on an editor with a daemon mode, so it should be able to be front-end agnostic. Are there any projects that implement just the drawing / update part of terminal text editors? I'd like to have a terminal version but a terminal text editor presents many unique problems to solve that are unrelated to editing text and my editor environment.

>>41193 >mouse extremly slow Funny you mention it, because Apple tried to test exactly that (https://www.asktog.com/TOI/toi06KeyboardVMouse1.html). In tl;dr they found out that keyboard "feels" more busy, because you are doing clickclackclack stuff, but mouse is faster in raw speed.

Helix is getting very close to merging in the branch that adds Scheme as an extension language. https://github.com/helix-editor/helix/pull/8675#pullrequestreview-3018763923 - https://github.com/mattwparas/helix/blob/steel-event-system/STEEL.md (Build Instructions for Helix+Steel) - https://helix-plugins.com/ (List of Helix Plugins)

>>42621 Does author mention why they choose to use Steel instead of more well known implementation like Guile/Chibi/Chicken/Bigloo?

>>42623 I believe the main motivation was better interop with Rust which Helix is written in. Guile in particular was not great at this nor were any of the others, so Steel ended up being chosen. If you look at the small list of existing Helix plugins, a lot of them are half-Rust/half-Scheme. I think only one of them is pure Scheme. https://github.com/helix-editor/helix/pull/2949#issuecomment-1186159322

>>42626 >I think only one of them is pure Scheme. It's two, now. switcheroo.hx smooth-scroll.hx The other three include some Rust.

>>42626 Understandable, since you don't have to worry about bindings and soykaf.

>>15808 Vim is potentially the least normal thing ever created. It goes head to head with Emacs.

I'm tempted to try writing an experimental CAD-inspired text editor from scratch but it seems like it would just be a gimmicky waste of time. By CAD-inspired I mean very mouse heavy but not quite like Acme, more like a typical CAD program. You'll enter an operator (say X for cut), then select the operands, and finally chose the point(s) for the result. I'm a bit undecided whether this would work better as a modal editor (keyboard inputs commands in normal mode) or a chorded editor (say press middle mouse then input one command) or whether it actually matters as chords are just temporary modes. This stems from a desire of mine to integrate the mouse better into manipulating the structure of the text, instead of treating the value of text as simply letters on the screen as Acme does. I'm also very interested if anyone knows of an existing similar editor.

>>42738 I know that you talk about Acme a lot in the last post, but what you are talking about, the structured regular expressions are heavily implemented inside Acme, in a not-so-hidden command Edit. Other than there, you can also just try standalone Sam editor (http://sam.cat-v.org/), which is basically what Acme uses for that command. As an alternative, you might consider looking at the vis editor (https://sr.ht/~martanne/vis/), it employs a similar concept or structural regular expressions in the modal editing formula. Not sure if these 2 editors are close to the ones you are looking for, but I wish you luck, anon

I had this giga autist idea to try and add markdown/org-mode rendering to ed. Thoughts?

>>42774 Try it, why not. But I cannot get the concept, would love if you can tell more details

>>42774 I'd like to hear about it too. Line editors don't get enough love.

>>42774 >markdown/org-mode rendering What do you mean by this? Syntax highlighting?

>>41193 what soykafty CAD package are you using that is 99% mouse? Some amazing keyboard input interfaces in CAD land, I am especially fond of qcad's. >>42617 Things are very different in CAD, need to draw a line of a specific size and orientation? Doing it with the mouse will only get you close and then you have to pop into the properties editor and type in the coords you wanted. Most CAD packages have a highly developed keyboard driven command interface, so you can just type 'li 0.13 .4 8.13 .4' and have your line exactly where you want it, or type 'la 1 1, 38 10' and have a 38 degree like at x1 y1 that 10 long, and you can have that 38 degrees reference off of anything and the origin be precisely places on another element. When accuracy is important there is little comparison here, keyboard is much faster.

>>42774 Am gonna say it like this, some folks did a modal interpreter in pure ed[1] or implemented Rosetta Code "exercises" in ed, so knock yourself out doing that. [1] https://github.com/aartaka/modal.ed

>>42859 That was more interesting than I expected. https://wryl.tech/projects/modal.html https://wiki.xxiivv.com/site/modal.html

>>42764 Thanks anon, I was really only referencing Acme inasmuch as it is a relatively well-known editor that tries hard to integrate the mouse. I am generally aware of Sam and Vis but your post made me revisit them and I was presently surprised to find >Efficient syntax highlighting is provided using Parsing Expression Grammars, which can be conveniently expressed using Lua in the form of LPeg. Since making that post, I started on my own editor with the goal of creating enough structure and exposing it to the extension language (probably Chez Scheme) that I could test my CAD-inspired editor. My idea for syntax highlighting was some form of parametrized FSM (I'm an EE not CS so idk what I'm doing lol) that would also include other metadata such as indentation level but PEGs is probably a better idea.. Unfortunately since starting the editor I have been spending most of my free time reading books or working on my TeX format so not much progress has been made. Anyway I'm not really sure if this CAD-like editor will actually mean anything after all because when text editing you don't really interact with parametrized objects in the way that CAD programs present drawings. Instead I have been considering a mouse-aided method of creating SREs (primarily prompted by your post): i.e. comparing with the Vis asciinema, instead of writing a SRE you could select the portions of text to match ("static", "cmd_" and "(") and press a couple of keys to select how they should be combined ("and", "or", ".*", etc. ideally the keys will be brief and centered around your resting left hand position) and it will generate the SRE from these visual-based inputs. My issue with SREs and the like is that they usually take too much mental time (for me) to construct them when I really just want to focus on the text.

>>42860 It's fun to implement modal, knock yourself out.

Rob Pike really had a some good ideas creating Acme. I find the concept of a language agnositc extension process rather fascinating so instead of like emacs having to manipulate buffers with elisp it's just external programs writing data in an API endpoint. Where it does fall short though in my opinion: 1. Making all endpoints files raises questions with concurrency aka what if two programs try to write to the file at the same time or what if a program locks the file andd hangs and so on. Fiddly stuff. 2. You can't just bolt anything on the editor if it doesn't support it already. Like for example syntax highlighting.

>>44676 Modern nvim, helix, kakoune, etc, are all about lsp and treesitter, which work exactly like that.

>>44677 afaik those editors have built-in support for these protocols specifically while acme providea a general interface for any program to read/write control and buffer content data externally.

>>44678 > afaik those editors have built-in support for these protocols specifically Only Helix, in Neovim it's all plugins. > a general interface for any program to read/write control and buffer content data externally. That's cool though.

>>44678 also lsp doesn't really work like that. The lsp client in the editor makes requests to lsp server and the server spits json at it, that the editor has to then parse by itself. It doesn't directly tell the editor what to do

>>44680 But that makes more sense? LSP pushes common format for many editors to pull and interpret however they want, if you do it other way round, LSP will have to push control commands into each particular editor in its own particular way. This is a general engineering principle, when a program needs external data, it makes most sense to have it some general format, and it's responsibility of program to interpret that general format, it would be ridiculous to ask external programs to recognize your program and send particular control commands instead.

>>44681 Well, that wasn't the question. You said that lsp works exactly like that and I said that it does not work exactly like that. More in line with acme model would be an external binary client that churned json into acme instructions.

>>44682 Yeah, it makes sense to have something like this as a middleware. It can be programmed in any way compared to plugins. Maybe it's a bit more effort to maintain that protocol vs just having access to all internal APIs like in plugins.

>>44683 I suppose the goals are a bit different. Acme's goal was to make a text editor that is also a "glue" front-end for any cli program that would enable the mouse use for cil programs. A plugin system is just meant to expand the editor. But ultimately both are limited to what APIs are exposed.