yed: Your Editor

Vim, with its modal editing style and quick, ergonomic key commands, brings extremely efficient text editing to the masses even today. However, extensibility and customization rely on custom languages, hacky installation methods, and decades of soykaff'd cruft. Emacs, with its infinite customization and configuration, brings powerful advanced features to the table. However, it too has disadvantages: decades of cruft, to be sure, but feature creep has taken its toll with storage size (easily into the hundreds of megabytes for a "lightweight" emacs installation) and speed. It is time to install a new editor: *your* editor. https://your-editor.org/ in;b4 >Why yet another editor? Don't we have enough of those? This one, written in C to be lightweight and performant, includes infinite customizability as a first-class feature. That's why it's *yours*-- you make the editor do what you want it to. With a growing number of plugins, a tiny easy-to-understand core, and a simple C API for creating your own custom plugins, `yed` features all you could ever want in an editor: 1. Per-directory configuration files. 2. Compiled, easy-to-write plugins. 3. Easy style configuration. 4. Powerful, advanced features, but *only* if you want them. 5. Multiple, layer-able frames (e.g. pulling up a `man` page in a frame above the primary one) 6. Dynamic key bindings (including sequences). 7. Crazy-fast startup times: tens of milliseconds, even with 50+ plugins (depends on filesize, of course). 8. Ability to have entire user interfaces built atop buffers and frames. 9. Easy integration with standard UNIX tools. 10. No dependencies. All you need is a C compiler. If you want to chat about `yed`, join our Discord server: you can join it via a link in the User Guide.

This seems really interesting. Have there been any projects built using this yet? I might try doing something with it in Lua. I use awesomewm which has a C core with Lua extensions. Its a really good system. Very easy to work with plus high performance and portability.

>>27560 There are no Lua bindings yet, but you're certainly welcome to write some! Basically, you just need to write a normal C plugin which calls Lua.

>>27559 >Discord server Good that you placed that at the end of your post, as I stopped reading after that. Why Discord, the bloat, the privacy and security nightmare? I'm not sure how XMPP or even IRC wouldn't fit the position of "chat for text editor users". Also, where can I see a full list of all yed plugins without installing the editor and using the YPM thingy?

>>27559 >Join our Discord Wow. Why even spend the time posting here?

>>27570 We use Discord for our work (research in a university lab), so created a server to talk about yed development. You don’t have to join if you don’t want to.

>>27566 Seems silly to discount an entire project just because they’ve decided to chat about it using a service you don’t like. I get it, Discord isn’t great for privacy. I get it, the Electron app is the worst pile to spread its ooze on this planet. I’ve even gotten suspended tons of times on Discord for using a third-party client, so I’m salty about that too. I personally use IRC on a daily basis, but some of our coworkers do not, so we did the easiest thing: created a Discord server. However, the quality of the text editor, lo and behold, does not depend on the chat service that is used by its developers.

>>27559 Good luck. At least you're trying to improve the world. Vim is complete for me, so I'm good thanks.

>>27573 It cuts out the ability to communicate with the project without submitting oneself to a malicious service. That's not a good look.

>>27573 Why go to the trouble of dismissing someone's arguments, and misrepresenting them as simply claiming not to like something, if next up you're going to address and concede those same arguments? The quality of a piece of software depends on the quality of the people writing it. People with a tendency to make poor decisions when choosing software (like picking based on peer pressure rather than practical benefits, or disregarding ethical implications) often display the same tendency when writing software - there is a statistical correlation here, and we have all observed it before. And this isn't the only reason to dismiss a project in this case: if you're going to be excluded from discussion, you'll always be a second-class user/contributor, so you may reasonably prefer not to be a user/contributor at all. It sucks that you had to do the wrong thing for work. I've been there, too, so I can relate. But I don't think that rationalizing it, and switching over to support what you yourself know to be wrong, will do you any good. It certainly won't do others any good, either.

>>27579 I don't want to argue about chat services; my intention was to just admit the issues that Discord has, and move on to a discussion about the quality of the text editor. I did not intend to offend you in any way; only to convince you of the text editor's quality, completely separate from the services that a subset of its developers and users might use.

>>27559 >If you want to chat about `yed`, join our Discord server: you can join it via a link in the User Guide. I'd really like to see a chat room for this project on a more private platform, as I and many others on this board collectively refuse to use such an immoral piece of software.

I'll check it out OP. I hope you're a really careful programmer, it's way too easy to write a bug in C.

>>27586 Great, let me know what you think!

>>27584 >>27577 >>27570 I have created an IRC server for `yed` discussion. Please join #yed on DALNet (us.dal.net) if you are interested in talking to other users, developing a plugin, or want to discuss installation or usage.

hi OP. I do like the idea of this editor. Unfortunately the plugin manager doesn't work, whenever I try to load a plugin it says "could not find plugin file". It looks like it's trying to load from ypm/plugins/<plugin name> but the plugin files are stored in .config/yed/ypm/ypm_plugins/<plugin name> once installed . I tried copying all the obviously-installed plugins from there to the other location but it didn't work. vim-like editing commands are a must before I can really use this editor. Overall though this is a surprisingly comfy editor. I am definitely willing to start trying to write a better vim plugin :)

OP that screenshot looks really aesthetic. Whats the theme? Also you might consider making some gifs of yed being used so we have a better idea of the way it works, and because moving images attract more attention.

>memcpy for structs here we go again...

>starting every single function name withe yed_ why?

>yed_once_upon_the_time(yed_in_the_galaxy_far_far_away()) seriously, rethink your naming convention

>>27597 >>27598 C doesn't have namespaces.

>>27599 No soykaf Sherlock

>>27597 Prefixing the function names ensures that plugin developers have an open namespace to name their own code while still linking with all of the available functions from the core. >>27598 The function names clearly and explicitly describe what the functions do. It leaves no question about what's going on when you read code that calls these functions.

>>27592 Oh, sorry about that. We did some recent breaking changes, and I think you've cloned the repo in the five-minute time period that we were in the middle of pushing them. If you do a fresh clone and install, it should work fine for you now.

>>27594 The style is called 'first-light' (there is a dark variant) -- the first ones made for yed!

>>27603 >Prefixing the function names ensures that plugin developers have an open namespace to name their own code while still linking with all of the available functions from the core. You are looking for problems where there is none. No, it does not ensure anything other than you are wasting your life putting yed_before every function name. You want to separate functions of main code with some plugin mechanism? This is what modularity and "static" keyword is for. You are even using static in few places for yed_ functions. You don't have to start every function with yed_. Plugin authors can as well start their functions with prefixes of their own choice if the plugin means recompiling whole project after applying patches. >The function names clearly and explicitly describe what the functions do. It leaves no question about what's going on when you read code that calls these functions. There is multitude of readable huge C projects that use much shorter names and code is clear without using i_really_can_not_invent_better_naming_convention_for_functions Last time I have seen such dumb convention outside university were some code monkey grade java stuff (and it was not bringing any clarity or improve readability) and FreeRTOS. The later probably because it is a code monkey grade RTOS. Also unless you are targeting yed to run on toasters there is no need for global structures and other variables. Especially if you supposedly care about "clear and explicit" part. Heck, getting rid of them would help you develop more modabble/pluggable/modular code where you can switch themes/configs on the flow and pass them to other modules etc. Best regards someone with well over a decade long experience with C projects who read far too much Rob Pike's essays and code early on his C adventure to STFU about codding convention in yed

>>27606 You clearly don't understand. If the functions were static, then the plugin authors could not call them. Not sure how your decade of C experience is any better than my decade of C experience, but I'm also free to use whatever function names I want. There's also no 'convention'. It's just a name that describes what the function does. >develop more modabble/pluggable/modular code where you can switch themes/configs on the flow and pass them to other modules etc This all already works. Not sure what you're talking about...

Discord is like this generation's AOL or something?

>>27607 >if the functions were static, then the plugin authors could not call them. That's the point.

>>27609 Is this a joke? Your plugin won't be very useful if it can't interact with the core.

>>27608 It's like the IRC but with images and invigilation out of the box

>>27610 >Is this a joke? Your plugin won't be very useful if it can't interact with the core. The only joke I suspect is that you pretend that you donot get the point I am making.

>>27612 You're misunderstanding what the developer is saying. Here, there are two types of functions: 1. Functions which are intended to be called by plugins. 2. Functions which are NOT intended to be called by plugins. What you're saying is that functions of type #2 should be `static`. They are. He's already doing what you're complaining about. You even mentioned it in an earlier post: >You are even using static in few places for yed_ functions. What he's saying is that, if he made functions of type #1 `static`, plugins would not be able to call them. That's true; he cannot take your advice any more than he already is, because doing so would require modifying `yed_` functions to be `static`, despite their purpose being an interface for plugins to call into the core. >develop more modabble/pluggable/modular code where you can switch themes/configs on the flow and pass them to other modules etc. His point about this is that you can *already* do that, too. You can load plugins and styles on the fly. You can write a `yed` plugin, compile it, and load it dynamically into a running `yed` instance at any point in time. I'm only a user, but I've done this many times.

>>27573 FREEZE. What do you mean you've been suspended for using a third-party client? What are you up to that gets you caught? I rely heavily on a third party client to manage my communities and also for interface customization. I was under the impression that third party clients were unspokenly allowed as long as you aren't spamming or something.

>>27606 >Also unless you are targeting yed to run on toasters I'm pretty sure that is one of the points of this program, yes. Anyway I think you're whining about a really tiny non-issue. >>27614 it's one of those "we won't try to catch you but if we do we will ban you for it" rules.

>>27614 Yeah, just for using the third-party client. Let me clarify: First off, "suspending" is what Discord chooses to call it. It entails being logged out of all devices and getting an email which tells you that you have to reset your password in order to log in again. If you've got 2FA enabled, you have to authenticate with that: under normal circumstances, you would be able to authenticate with your email, a phone number, or scanning the QR code from your phone; but in this case, you *have* to use a 2FA code. The client is Ripcord. I use it on a daily basis on two computers. A couple of weeks ago, Discord started suspending most users (some were unaffected) at 24-hour intervals, so I just stuck with it and reset my password each time. Eventually, after 5 or 6 days, it stopped happening. It wasn't quite as big of a deal as "suspension" makes it sound, and it could have possibly been caused accidentally (by flagging Ripcord-specific activity as "suspicious").

>>27613 You almost get the point but you get it reverse who don't understand whom.

>>27617 That's OK; sometimes I'm wrong. You should try `yed` out: you might like it! If you're interested in stylistic concerns, that's fine; you might want to modify your fork of `yed`, or use your own programming style in any plugins that you write.

>>27599 Don't worry OP, I do the same in my projects, prefixing functions with a word as a way to do namespaces in C. I think it is a good practice, it will prevent headaches in the long run for you and for plug-in programmers.

>>27619 If for some strange reason you constantly run into namespace issues maybe for new projects consider grouping functions into arrays of function pointers or structs of pointers to functions representing interface or create function that returns function pointers. This of course makes sense mostly if your code is modular and functions can be grouped together and share common arguments list model. You can find plenty of inspirations in numerous UNIX shell implementations or UNIX like kernels.

>>27631 >consider grouping functions into arrays of function pointers or structs of pointers to functions This is a horrible idea. Function pointers are way too easy to mishandle and cause massive vulnerabilities.

>>27642 >This is a horrible idea. Function pointers are way too easy to mishandle and cause massive vulnerabilities. a bad workman always blames his tools keep sculpting with blunt chisel if you are so afraid of hurting your fingers with sharp one

>>27645 Speaking of sharp tools: `yed` is an extremely sharp text editor that allows you to master your own text-editing by fine-tuning your keybindings, plugins, and writing any custom text-editing functionality you want. Try it out!

>>27645 you're more likely to hurt yourself with a blunt chisel, dumbass.

I don't like modal. If I wanted Emacs+Vim I'd just install Doom Emacs. Is there a way to run it with traditional keybinds?

>>27649 Yed is not modal unless you specifically choose to install the “vimish” plugin. You can customize the keybindings to your liking, and vim-like or modal keybindings are not the default (although they can be chosen if desired).

>>27604 just tried it again, problem persists.

>>27653 Could you try removing the ~/.config/yed directory entirely and trying again?

Sorry, but I like using vi hotkeys.

Sorry I'm not a larper and actually use a text editor professionally. The only options out there are mature ones like emacs and (neo)vim. If you want any level of productivity you want to jam as much into your workspace as possible. My normal window contains 6 to 8 terminal buffers, and 4 normal buffers. I don't want any kind of bloat preventing me from seeing as much on the screen as possible et once.

>>27677 The whole point of this editor is that you can make it do whatever you want (including vi-style keybindings). >>27678 >actually use a text editor professionally I use this text editor professionally. >My normal window contains 6 to 8 terminal buffers, and 4 normal buffers What makes you think you can't do this? >I don't want any kind of bloat preventing me from seeing as much on the screen as possible et once. What bloat? You can size/arrange the frames in any way you'd like.

i gave it a try. i like how fast it is and you don't have to mess around with config files for the plugins, you just install them and they load into the editor immediately without a restart. however, i'm already too used to vim at this point, and the "vimish" plugin kinda is like kicking dead whales down the beach. it's missing a lot of keybinds, even basic things like o / O for creating new lines, and i can't use ZZ to save and quit (i suppose it's doing its job though, original vi technically doesn't have these binds as far as i can remember...). i could probably recreate some binds and even use the macros plugin to make more complex binds, but this is the last thing i should be dealing with. i also dislike how hitting page up / down moves the cursor. there's a plugin called "scroll buffer" or something similar which, at least that's what i understand, is supposed to prevent that from happening, but it doesn't seem to work. if this gets better vim-keys support then i think i might ditch vim and start using this.

No one actually uses emacs bareback anymore. Everyone I know uses DOOM Emacs and just configures from there. Problem is that then they don't actually know what the default experience is like, which is kind of bad.

>>27705 lolwut? Speak for yourself. Doom includes a soykafton of unnecessary settings that make modifying your Emacs a pain, it also vastly complicates debugging.

>>27703 Thanks for checking it out! vimish was never intended to be true vim emulation. It’s become more of my own interpretation, but I’m hopeful someone will write a plugin that actually does emulate vim accurately (it’s definitely possible, just needs to be written).

>>27573 If your post had ended in "Heil Hitler" I would have dismissed it too.

>>27713 what does that have to do with anything he said? >>27566 >Also, where can I see a full list of all yed plugins without installing the editor and using the YPM thingy? it seems that the "full list" is any repo that starts with "yed-" over here: https://github.com/kammerdienerb?tab=repositories it'd be nice if there was a wiki in the yed repo with all the plugins and their details. i'd do it myself but i don't know how to use github or git in general.

>>27714 Plugins can come from anywhere (including those you build yourself), so there is no comprehensive list. As far as those plugins that are distributed by the plugin manager, you can view them in yed with the command ypm-menu, or look at https://github.com/mickidymick/ypm_plugins.

>>27706 You've got to be SHITTING ME. You realize that Doom actually improves your startup times by like 70%? Anyways configing it is easy since all you have to do is uncomment a few lines, not do whatever you usually have to do when you config the emac. It Just Works.

>>27716 >You've got to be SHITTING ME. You realize that Doom actually improves your startup times by like 70%? No, that's use-package and its deferred loading, which Doom also uses.

>>27559 Your website's CSS are broken on mobile. Also, why am getting kicked from discord server? >>27631 >>27645 Why add an extra layer of indirection to every function call? That is just slow. You had better use a language with namespaces like C++ or write your own namespace preprocessor.

>>27723 The issue with discord should hopefully be fixed with a new invite link: https://discord.gg/cx3JFJ2gNU

>>27723 >Why add an extra layer of indirection to every function call? That is just slow. lolwut.xml >You had better use a language with namespaces like C++ or write your own namespace preprocessor. rotflmao.wut

>>27729 And here you demonstrate you don't even understand the downsides of the very approach you suggested. Nice job.

>>27731 Wat makes you think it was the one who wrote these proposals? First of the points is a non issue if you actually understands C programming and 2nd is matter of aesthetics and in practice like firing a cannon at a mosquito.

>>27559 the next generation text editor must come with a new mode for terminal emulator: canvas mode - lets draw anything on the alternate screen as fast as you cant imagine without fuarrrking slow n curses

>>27559 this just looks like JOE

>>27559 Looks interesting, OP!!! What's the learning curve like and what's it like from web dev. perspective? Most of the time I use PHP and JS, and edit them with Vim, including a bunch of handy plugins - it's just so comfy.

>>28041 Join the Discord and chat with us about it!

Funny the OP doesn't mention neovim which fixes all of the mentioned vim problems and much more. Weird no one else mentioned it either...

Would be interesting to see a mutli cursors plugin for kakoune-like functionality. Idk if that's possible, but would be cool.

>>27559 >Dependency free how is this a good thing

>>28555 Not OP, but I personally hate having to install dependencies, especially in some projects that I want to compile that have awful documentation and don't list their dependencies fully.

>>28516 Saging because of offtopic, but the same (and more) could be said for Emacs. It has unmatched extensible packages in a language that is just a delight to work with, if you have the megs of storage (which ofcourse any reasonable person has on his main workstation - and is all you need to be infinitely more productive in infinitely less time). He is just promoting this editor because at least it is interesting, not because it'll replace vim or your precious Neovim. Emacs did that already with vim before Neovim and still does with your precious Neovim. There is literally no reason to promote/mention Neovim in this thread except maybe your own dogmatism.

>>28555 how is this NOT a good thing? you can run this editor with nothing but a linux kernel, a TTY and glibc. >>28558 a text editor shouldn't require "megs of storage", and you don't need a bunch of plugins either. just get an IDE at that point.

It simply doesn't work as I expected, I hope OP is happy with it. But if I may I'd like some improvements. (1) A portable build script, not a bash script that doesn't work on most of my machines as I use POSIX compliant shells; Makefile are also fine. (2) Better manuals, guessing commands to do basic tasks is simply dumb. (3) Better code documentation: again guessing why stuff is there and requiring me to read the entire project codebase to understand its structure. I did not dig any deeper than this.

>>28582 >you can run this editor with nothing but a linux kernel, a TTY and glibc. You can run Emacs like that as well; https://www.informatimago.com/linux/emacs-on-user-mode-linux.html I don't see your point..

>>27559 > This one, written in C to be lightweight and performant C does not magically make your programs 'lightweight and performant'. Modern web browsers and graphical toolkits are all written in C, and would you say that they're 'lightweight and performant'? If you want your program to grow and remain lightweight and performant, you need tools for managing complexity. You'll want a language that cannot leak memory and shies away from mutation so that you can build better abstractions that isolate out your programs performance, letting you focus on it much harder. You wouldn't choose a language that moves attention away from the problem onto the irrelevant details. > Feature creep has taken its toll with storage size (easily into the hundreds of megabytes for a "lightweight" emacs installation) and speed. Has it? Base Emacs is 6MB, and +11MB for built-in packages. The 'hundreds of megabytes' you're referring to (it's actually closer to 90M) is source code and documentation kept around for hacking purposes. > 2. Compiled, easy-to-write plugins. What do you mean by easy-to-write? Easier than Elisp packages? Does the system let me hack and replace part of the editor core? If I can't do that, then your customizability is not nearly as 'infinite' as you claim. > 7. Crazy-fast startup times: tens of milliseconds, even with 50+ plugins (depends on filesize, of course). Cool, that's only... $ time ./yed -c quit Thanks for using yed! real 0m0.029s user 0m0.024s sys 0m0.004s $ time emacs -Q -nw --eval '(kill-emacs)' real 0m0.032s user 0m0.024s sys 0m0.008s The same as Emacs? And, just to note, Emacs's boot-time remains constant with the number of packages thanks to it's image based nature; I can always portable-emacs-dump if I feel a 0.21 second boot, for a GUI+132 packages, is a bit slow. > 10. No dependencies. All you need is a C compiler. Is a C compiler, and everything that pulls in, not a considered a dependency? What about GNU Coreutils? The Linux Kernel? I'm not convinced that this is a good for anything more than circle jerk material. All you're doing is making your software more complex for yourself and for your users.

>>28622 Having no dependencies eliminates the need to download and configure extra things. And especially elimates incompatible versions of dependencies breaking the program. No troubles with updates breaking things. No troubles with package managers only providing old incompatible versions of dependencies that won't work with the program. Dependencies only complicate things because your standing on shaky ground that others are constantly rearranging and modified, so of course you'll fall over. Big projects and teams can deal with this, but small things just break rot and die. Unfortunately linux the os is just a mess of unstable dependencies wrangled together so programs are inevitably dependent on specific versions of linux and the binaries break over time. You can reduce this by eliminating as many dependnecies as possible. But fundamentally you have to write a program for an os, and linux just refuses to act like an os, it refuses to provide a stable layer to build software upon. Why bother writing programs for linux when a few years later they won't even work anymore. That's one of the reasons people don't bother. windows really is like kicking dead whales down the beach but at least win32 is mostly stable foundation for programs to sit on.

>>28630 You can't make these arguments anymore when Nix/Guix exists to solve all these issues.

>>28630 > windows really is like kicking dead whales down the beach but at least win32 is mostly stable foundation for programs to sit on. The basic Linux APIs are similarly stable. Libraries are unstable, and it's not any better on Windows, it's worse. Ever had 5 different versions of DX installed at once? >>28642 Also this.

A bit off topic but rxi's lite is quite nice, it's a smaller graphical editor where the bulk of it is writen in lua. I've hacked on it a tiny bit and it works pretty well. I did go back to acme as my main editor though because I don't need to think about it.

Entire thread derailed by Discord. Good job everyone.

>>28664 Not just a derailed thread, but quite possibly a derailed project. No good ever came from having a Discord guild associated with any project.

>>28558 did i say anything about neovim?

>>28418 While the above post focused on comparing yed to other editors (as is necessary), the main purpose of the project is not to create "vim, but better." The primary purpose is to make *your* editor: a completely customizable editor which keeps most things out of the core, but has extremely fast and efficient plugins which can implement any functionality you'd like.

>>28516 We've had a user create a plugin which implements their desired features of kakoune, so you might be interested in it: https://github.com/uniquepointer/yed-drill/tree/87ac6c55d0a4990b68736bccffccb566084b501d

>>28617 >1 You're right that the build system isn't the project's strong suit, but we've tried this on a huge variety of machines (including Linux, MacOS, BSD, Solaris), and it works for all of them. Do you not have a BASH installation available to you? >2 This is definitely something that we're actively working on. Very important, but things needed to settle before we finished up a good guide for plugin authors. >3 There aren't many comments in the code itself, but as someone who's never worked on the core, I'm able to scoot around the codebase just fine. It's split properly into files and functions that have sane and explanatory names, so that I find it extremely easy to understand.

Not sure if I'll get a reply or not, but is it going to be possible to package this program? I found a GitHub issue about this and it seems like no progress has been made on it since October.

>discord server seriously? :/

>>31235 It's a how-to-kill-your-editor 101 move. What kind of Free software project is hosted on Discord, a company that's very hostile to free software?

>>27611 Expect for IRC isn't run by one shady company. Discord has sooooo many users yet what's their business model? Where are they getting the money for the infrastructure? Nitro or whatever is clearly not enough. They're getting money from investors who think because the product is popular it'll make money. Well Discord's gonna have to make some money some time soon to give back to the investors. And when that time comes, Discord will not just morally soykaf but pratically soykaf and everyone will move off.

>>28664 Rightly so. The tool looks great. Pure C no dependencies. I like the simple core + plugins for extra functionality idea. Website looks awesome. Lean and spyware free. But hosted on Microsoft's GitHub and "official" communication platform is... Discord. Doesn't it feel like a spit in the face. Oh and MIT license just in case a big company likes it and can use it because GPL is too viral.

>>31234 >todo.txt obvsly a lot of refactoring needed

>>31284 Are you referencing an actual list of missing features? I can't find it on the site or the GitHub page.

>>31263 Discord is collecting datasets of private data beyond the wildest imaginations of most companies. Their privacy policies are incredibly dystopian but people continue to feed it highly private conversations. The end game is clearly to monetise this.

>>27559 To first note, I'm a NeoVim guy, If you don't got a good vim implementation or don't use NVim, then its not worth while as an editor. This editor fails to matchup to (neo)vim or emacs, appearently that 'cruft' makes them the best. after some light usage, installing the 'Vimish' plugin, editing files, not being able to open more than one file with 'buffer', Bang! shell commands aren't supported, and Vim like behavior completely is like kicking dead whales down the beach (some basic mode stuff and no advanced features). This is your editor, not mine. I don't feel it is worth my time to make it work like NeoVim, or Emacs, when I could just use those, for they are extensible enough to do anything your editor can do, both with massive communities in comparison. There isn't enough advantage to it, and it ignores alot. Vim is fast, really fast, and with some reason, is an editor and solely an editor, it does editing in the best way you could edit. Emacs, has an editor, it is a super multi-tool, you can live in Emacs. YEd can't do either, maybe with a fancy plugin that is just NeoVim, then it might be usable, but it won't ever beat them. Even on it's own, it does have some neat features, such as compiled plugins, but the difference this makes is little to none. I in all my usage of Vim/NVim/Emacs/Doom, have never used more than twenty plugins. But some people like to completely overhaul their interface with hundreds of plugin, which your program does not have those 'hundreds of plugins', thus making it all a m00t point. Without an insane community backing, this will not be worth while for a long time, and with only three years of development can not compare. It WOULD be worth while to take the good of this editor (compiled plugins) and implement it into N/Vim and/or emacs, rather than create (((another editor))). Vimish = shi(t)vim

this single-handedly filtered me. if I can't quit your soykaf with just one shortcut, I hate it t. nano user

>>31234 looks like packaging should be pretty easy, just configure the install options file based on your packaging install prefix. Not the tidyest way but I've seen worse. I don't suppose you've packaged much software have you mate.

>>31406 >looks like Have you actually tried to do this? Say you choose /work/pkg/usr/ as a prefix, the binary will look for its libraries in that directory instead of /usr/. The install script just needs a DESTDIR option / variable, which I tried adding but failed.

>>31408 oh, eww, guess it would take a bigger patch then.

>>28582 >a text editor shouldn't require "megs of storage" I feel like this is emblematic of the very mindset that leads to clone-software like yed and vis and kak and the others. It is technically correct, it is also true that high storage needs can correlate with slow performance that the user actually feels but... People aren't going to notice a difference between a 1MB editor and a 100MB editor without checking the file size. It's all internal. You change all that source code, and you move all those plugins somewhere else, and you make it take less storage, so you assume you must have created new software. But you didn't. You were tricked. It's the same teddybear with different stuffing, so no one on the outside can tell. 90% of it changed, and you can see that from the inside, but the users can't. To everyone else it's just another Buzz Lightyear on that shelf from Toy Story 2.

>>31413 this is an analogy-riddled way of saying "people who don't use your software don't understand it" which is pretty obvious.

>>31417 This is plain disingenuous. My post has one analogy and a joke. But you are correct. People don't understand it, and they can't understand it because to them it is identical to every other editor. No meaningful change has been made to the parts which they use. Even if they did understand the difference, it still would not make them want to use it as the changed parts have no bearing on them. The soul unique user-facing feature of yed is an octopus based UI, need I say more?

>>31417 I mean, it's true, isn't it? Software, even stuff made for people who know how computers work, succeeds based on what it can provide to the user. Being small and efficient used to be a lot more important back when computers were slower and memory more expensive. Don't get me wrong, getting good performance and a small memory footprint is still highly desirable, but it's no longer a selling point. As long as a program runs "well enough", non-technical users won't notice, and most technical users won't really care. The important thing is that your software can offer something of practical value that you can't get elsewhere. You can see this all across the Unix/Linux world; most of the software that catches on is kind of lousy from an implementation and design standpoint, but it's practical so everyone uses it anyway.

>7. Crazy-fast startup times: tens of milliseconds, even with 50+ plugins (depends on filesize, of course). the fact that you think this is a feature as opposed to a default that doesnt need to be mentioned confirms my assumption that this is software for retards. oh yeah that and it is t*rminal LARP garbage. terminals were obsolete before 1990

>>32907 > the fact that you think this is a feature as opposed to a default that doesnt need to be mentioned Not a common thing in most editors nowadays, worth mentioning > terminals were obsolete before 1990 If you don't ever intend to program or generally make your life easier yes. The terminal is a good way to run simple programs with many options and do so in a versatile way, good luck using google chrome to automatically archive the posts here. There is no alternative to bash (no python doesn't count you can't chain programs together efficiently and you still need a terminal to execute it) in terms of chainability and simple composition.

>>32909 >mentions the slowest useless program on earth who the hell said anything about chrome? install nedit >there is no alternative to bash >t. actual fuarrrktard

2/? i actually find it funny when i go into an enterprise shop and see that one senior trying to into the terminal, imagine being an enterprise domo and a terminal autist at the same time

3/? >>32909 >Not a common thing in most editors nowadays, worth mentioning yes because the industry is full of clout chasing soykaf for brains retard cultures. including this yed crap in my larval days i used to just use notepad2 and ontepad++ and i wrote world class programs and exploits in that (that was like 1 year then i moved to UN*X and wanted to kill myself ever since) imagine being that script kiddie flinging a bunch of bash scripts in his vim or IDE or yed or whatever the fuarrrk that break all the time because they dont use simple composable primitives but strings and "just read the code bro" protocols>>32912

>>32909 >you still need a terminal to execute it A terminal isn't the same thing as a shell. You need a terminal to execute Bash as well. Both Python and Bash are just programs that accept commands on stdin, you terminal just happens to execute Bash by default rather than Python. >no python doesn't count you can't chain programs together efficiently This is semi trivial to solve. The real reason you don't use python as a shell is because it doesn't accommodate a lot of the common shell activities. That said, it works better than Bash in a lot of cases. This is a real testament to just how bad Bash (and POSIX Sh in general) is.

>>28708 >a completely customizable editor which keeps most things out of the core, but has extremely fast and efficient plugins which can implement any functionality you'd like So neovim.

FWIW I've managed to crash the base install opening a source code file. How this is even possible is concerning to me, is opening a random text file from the internet going to run me the risk of falling to a RCE? A modern text editor should not crash over parsing or whatever else it was doing.

>>27559 its been more than a year, and you havent updated the plugin page on the website. please do so, im really interested in using this for lisp stuff.

>>33244 Can you post the file or a similar one that caused the crash? I’d be interested in seeing it

>>33244 If it’s written in C, of course that is possible. You could probably fuzz the hell out of it.