I wonder whether it's achievable to have a plugin system similar to how web extensions work where you could write a plugin and have it work across different editors. I see how getting people to move to this editor might depend on people moving over once a sufficient amount of their current editor's features are supported, some of which might be contributed by extensions.
Perhaps using WASM via something like https://extism.org/. That would also open it up to building plugins in multiple languages.
Tangential to this I've wondered if it's possible or advisable to have a utility to port VS Code plugins to a plugin that's compatible with the JetBrains IDEs.
So an interface like LSP but for plugins… very interesting idea!
Text manipulation operations are fairly simple to define and can probably be abstracted away into some generic API. Then writing generic text manipulation plugins should be very doable.
The complexity comes with project management, multiple files, build actions, etc. But you could define language specific sub-interfaces and the plugins would implement them. So a C++ plugin would understand CMake files for example.
The complexity comes with interaction in general. Writing plugins on their own is simple. And defining a good API for most common use cases is also not hard today, as we have enough experience now. But the hard part will be defining an independent Interface which will work everywhere on a satisfying level.
I mean that's basically the biggest selling-point of plugin-systems today. Not that you can write your own functions to do something, but how well you can integrate it into the interface and deliver your own interface to enhance the app. And another part would be safe interaction with other plugins, and necessary package-managment.
There seems to be some trend, to outsource plugins into their separate processes, so you can write them in your preferred language. So APIs are already being established here and there. All we probably need is someone carving out a standard from them, with room for editor-specific enhancement, and then convince the projects to support this.
Maybe the neovim-people could get together with other projects, start some group, project, whatever to discuss this further? Of maybe something like this already exists?
Maybe we could invent a standard technology for defining interfaces between software pieces. We could call it Interface Definition Language (IDL for short). And then we could have something that brokers requests to those objects to facilitate intercommunication. We could call that an ORB! Finally a good idea!
I have an even simpler idea. We can have some kind of protocol header that specifies the size and shape of the structures and functions that can be called using a binary-level interface. Then we can just provide the implementation as machine code where the header maps each callable function to its respective code block. To "return" values, the callables can just push their results onto a "stack" at a known location and return control to the caller.
The bonus is this should be really fast and it doesn't even require any codec or message copying.
Awesome, this looks like an editor I've wanted to have for a while. I'll definitely be trying it out.
Basically it seems to take the good parts from a few other editors and combines them:
It's like VSCode, but without the bloat of electron or Microsoft's telemetry.
It's like sublime text, but it's open source and has first class LSP support.
It's like Neovim, but it doesn't require downloading and configuring a bunch of mystery meat plugins just to get what have been table stakes editor features for decades.
> It's like VSCode, but without the bloat of electron or Microsoft's telemetry.
But isn't the bloat of electron which enables the greatest benefit of VS Code? By which I mean the plugins with their wide range of abilities and UI-integrations.
> It's like sublime text, but it's open source and has first class LSP support.
> But isn't the bloat of electron which enables the greatest benefit of VS Code? By which I mean the plugins with their wide range of abilities and UI-integrations.
Maybe for some users. I'm sparing with extensions because I find them hard to vet; I checked and I'm only using clangd and prettier right now. But I don't think Electron is required in order to have rich extensions - just see Vim/Neovim, Emacs, or any IDE.
> Sublime has LSP since a while now.
My bad then. I thought sublime's LSP support came from a third party package.
> But I don't think Electron is required in order to have rich extensions - just see Vim/Neovim, Emacs, or any IDE.
I don't know about IDEs, but I wouldn't put vim & Emacs on the same level as VS Code in terms of interfaces. They go much further than your average text-editor and also grow over time, but at the end they are still text-based interfaces with some fluff. Though, It of course depends strongly on your requirements. For most developers, text with fluff is more than enough.
I see the limitations of vim an advantage not a disadvantage. Because everything is a buffer and the layout is just windows, the usual keys just work.
It's one of the things I have about "real" IDEs with a vim mode. The one in vscode is pretty good, it's pretty rare I break it when just editing code (mostly '.' not doing what I expect). But everything else doesn't fit the vim model. I have the file manager or something open in the left and I can't reach it with ctrl+h, because it's own weird UI thing not just a split (like it would be in vim).
Every plugin in nvim required to learn some new different bs shortcut to have basic features.
Plus, I ran into plenty of crashes and weird error in some plugins - and performance wasn't always great.
The editing is fine, you can get used to buffer editing - it's everything else which is not polished and feels like a pile of half implemented features.
I don't really keep up with the state of the art of vim, so I don't know what the community has shifted to doing in plugins, but in vim you have to go out of your way to override the base keys in your plugin buffer. I guess that might be more popular now, I don't know.
But the principle I'm talking about applies without any plugins at all. If just do :terminal it'll make a split, you can now switch between whatever you were doing and that terminal the same way you would switch between a regular split.
None of the proper IDEs do that. I can't just look at what's on my screen and do "move focus to the thing below where I am". You need to memorize shortcuts for each bloody tab rather than them being context aware, and I hate it.
This is exactly what has always kept me bouncing off of these things.
As a vim user I can reach a sort of uncanny valley where the core editing loop feels "right," but I end up having to fight against all that muscle memory when it comes to using features outside of it.
> I mean, aren't there whole web browsers and email clients written inside of Emacs?
Depends on your definition of "whole". Those modes work by removing features from the webstack, or by borrowing from external GUIs. Emacs browser w3m for example, is AFAIK unable to handle JavaScript. Electron-apps on the other side offer you whole webstack, including all available components, widgets, libs, frameworks, or whatever. So it's very easy to take some webapp or component and integrate into your workflows. Apps like Emacs are unable of doing this, and thus constantly on a game of fetching up on popular features and services.
> I don't think Electron is required in order to have rich extensions - just see Vim/Neovim, Emacs, or any IDE
At the cost of difficulty. Recently I wrote a VSCode extension myself with zero prior knowledge (shameless plug: https://github.com/CrendKing/universal-format-on-type/), in probably one day. All I needed to study is their extension API that I cared about. No need for learning a whole new language or DSL. Also easy to debug since there is no compilation and little environment setup.
There is a good reason even though everyone acknowledge about Electron's performance cost, everyone is still using it.
I haven't made a vscode extension, but I don't agree that neovim extensions are created with any great difficulty. The lua API is easy to use and well documented. There is a huge ecosystem of neovim extensions precisely because it is so easy to get started.
> Vscode got where its now mostly because of how extendable it is imo.
Every IDE or "code" editor has had some sort of extensions since decades. _Not_ being extensible is a reason to not being successful.
What made VS Code was the LSP and that you can use JS (that "everybody" already knows) to write extensions.
The need of Lapce to use a language with manual memory management (to compile to (non GC) WASM) is a problem for general adoption.
That is absolutely right. I downloaded it to try it but luckily I saw this comment and I deleted the install file. I think if someone makes a text editor, they should have the courtesy to say "note: there is no line wrapping in this editor". It's actually a basic expectation that most people have with regard to editors.
Technically, like the person said in the thread "What prevents you from doing it yourself?"
I feel like not having line wrapping is like not having a save function. Yeah technically it's open source but it's a little irritating not to have "NO WRAPPING" in big letters.
The ticket seems to be describing virtual wrapping. Interesting that this is a strict requirement for you. I’ve personally never used this feature in any editor. I disable it when I can.
Personally, I just find such “long” lines too difficult to navigate.
I’ve really liked Lapce for the past 3/4 months I’ve used it, but there’s been a persistent issue that keeps me going back to Lite XL. Pasting huge blocks of text, think 80,000 characters long, breaks it to the point of not being able to open the same file again in the editor. Lite XL doesn’t care and it’s wicked fast with edge cases like that. If Lapce could manage that better, it would be my go to.
Just had a look at this. It's one of the few that doesn't use jsx-like macros, an major anti-feature in my opinion. The jsx stuff looks fancy, but it completely breaks Rust Analyzer. You might not care about code completion, but good luck resolving the complex type+lifetime issues (that UIs in Rust often have) without hover type.
Kudos for showing scope discipline, that's one I will be keeping an eye on.
> The jsx stuff looks fancy, but it completely breaks Rust Analyzer
That's not inherent of macros, but how the parser of the macro body is written. Ideally, the jsx code would be transformed to correct Rust code even on broken input, then Rust Analyzer would map the tokens from the expansion to the tokens from the source code to have context for IDE features (rename, autocompletion, go to definition, etc).
I wrote some stuff [1]. It's a bit all over the place since I'm very bad at writing. Here's also a thread with Rust Analyzer's developers [2]
The problem is that you also sometimes need to inspect output tokens that occur between (or that don't logically map to tokens between) the input tokens. I ran into this with Leptos. It's just a bad idea. Floem shows that you can have something that looks awfully similar to HTML, without the unnecessary complexity (and compile times) of JSX macros.
I've been using this the last year for navigating larger code bases where my usual terminal editor falls a bit short because this looks clean and minimal but has all the IDE navigation features like file system trees and LSP functionality. It's a cool project, and it might be getting to the point where it can be used as the main code editor for a project.
I first thought “Another editor, we don’t need that…” but this one actually gets everything even more right than neovim! Plugins on WASM, written entirely in Rust, renders via wgpu, built in Remote Development. Only thing missing is an official built-in package manager, to avoid the mistake neovim did. A non-barebones VSCode like out-of-the-box configuration would be the cherry on top.
I've been keeping an eye on this one. This holds the most promise of replacing vscode for me. Right now, Kate is more mature and stable at the moment. But I think once it gets further along it'll definitely kick the pants off of the other options.
I've tried Lite XL and CudeText and they are both hard to set up and fall far short of Kate and Lapce in terms of UI.
I'm curious, why not Sublime Text? It is better, faster, and more mature than Lapce, LiteXL, Kate, CudaText, and VSCode (although VSCode might have more extensions).
Is it just because it's not free? I bought it, and it has been my most used piece of software by far.
I've heard about Sublime Text but never considered getting it.
The first code editor I ever got any real use out of was vscode. Which until recently was perfect (some feature regressions and issues with crashing.) At this point the last thing I want to do is depend on a proprietary editor.
Would it be feasible to implement a TUI/ncurses mode over the same editor backend and feature set? Think something like the FreePascal TUI IDE, or the Oberon TUI that made HN a couple days ago: https://news.ycombinator.com/item?id=38240333
The preview image shows intellisense covering up 80% of the code with irrelevant suggestions and a compiler error verbosely complaining about code in progress. That much distraction should have a very small visual indicator at the point of focus, just enough to hint the action required to expand if it is actually relevant.
Tried it. Not bad actually, can't see the type annotations from the Rust lsp though. I see one warning so I imagine annotations are at least partially supported.
Also I can't jump to my jumped-from point when pressing "go to definition" via Ctrl+T when using vim bindings.
Oh, does it means that it's moving back to wgpu after its earlier switch to OpenGL? Does it means that the problems that were encountered earlier with wgpu has been resolved?
> Lapce (IPA: /læps/) is written in pure Rust with a UI in Floem. It is designed with Rope Science from the Xi-Editor which makes for lightning-fast computation, and leverages Wgpu for rendering.
So I think it's reasonable to conclude that they did move back.
It feels extremely fast if you compare with vscode, also it looks like it is already usable for some projects, need more time to see if there's some deal breaker for an early adoption.
This is kind of a problem in that it reduces the number of potential early users, testers and ultimately contributors. Sure it is still early in its development process, but it is important work to do in order to gain traction.
As a non-native English speaker who speaks 4 languages, I have almost never found myself using any other language than English in a code editor or IDE. And I never seen anyone who did, except for very occasional editing of localisation data files.
I have seen used (mainly in comments): Japanese, French, German, Dutch, Chinese (don't know if it was TC or SC; if those are even different unicode ranges or whether they are differentiated by font), and, if I remember correctly, Afrikaans. It's also kinda funny and a little off-putting to see English keywords side-by-side with, like, Dutch variable names.
Indeed, navigating keyboard internationalization is a rabbit hole within a time-sink. Luckily, in most cases, you can just plop in a library, and it works, but it's probably not that simple here. All the wtf edge cases, plus the quirks of different operating systems and hardware manufacturers—it's the stuff of nightmares.
An alternative way of looking at this: a text editor's main job is to turn keys pressed into characters to be inserted in the document and commands to be executed.
Keyboard handling is so fundamental that a text editor must deal with it, perfectly, from the beginning.
The cited issues aren't merely a severe and high impact bug cluster, but also an inexcusable design defect that disqualifies the whole project; I suppose someone decided to use Rust despite the lack of sufficiently mature input handling libraries.
> Keyboard handling is so fundamental that a text editor must deal with it, perfectly, from the beginning.
That would be nice but in reality it's such a tricky and subtle problem that nobody does it perfectly. All the operating systems and browsers are buggy in different ways, nevermind anything with smaller budgets. The deeper you get into proper text handling, the more you will realize that nobody has solved it.
Handling dead keys and displaying national characters is solved problem and has been since MS-DOS times. It's really not that "tricky and subtle problem" in 2023. Unless one is inventing keyboard handling from scratch again.
Dead keys are a drop in the ocean of what goes into international keyboard handling, and even that functions differently in every browser and OS. Which browser or OS do you think has it solved, or do you think that all of them are solved despite giving different results for the same sequence of presses?
Displaying text is an even deeper issue and also broken, the further you go from latin alphabets.
Referencing MS-DOS really takes the cake though. The Unicode standard wasn't even released until late 1991. They're still updating it even today, because it's a lot of work to handle international languages.
Perfection is unlikely, but serious developers should aim to be less buggy than the competition and/or limited by operating system and hardware shortcomings.
That's a very strong opinion about a project that is at 0.3 and is attending to many simultaneous problems, including building their own UI solution.
It's certainly an issue, especially for non-English users, but it doesn't "disqualify the whole project"; it just means that's not what they're prioritising at this time.
Prioritising glamorous and interesting aspects like plugins and "their own UI solution" over boring correctness is not the way to deliver a good text editor.
I want an "I'm adult" switch, which will stop bombing me with popups until I press Tab (for completion) or F1 (for help).
It's unusable, because it distracts on almost every keypress with popups, type hints, and additional characters inserted. Sometimes, these popups even block the CODE I working on. It similar to browsing without an ad-blocker.
I want a helpful and predictable editor, not a kaleidoscope. I don't want to think "hey, what happened?" after a key press.
I can't speak for this particular editor, but Visual Studio once shipped with a mode for C# I think it was, that was like a neon light show. It was unbearable. Also SSMS it has full-on intellisense or nothing at all, and having it on; it just gets in the way. It's like MS only know "my way or the highway".
I realise this is tangential to the subject but I think it bears repeating: respect the user.
Does it try to help you type "if" once you press 'i' ? I find it really weird that (some) code editors do that. Also adding )}] after I type ({ or [, and even worse a second " or ' after I type one " or '. I realise there are ways of turning this sort of thing off (usually), but I miss the days when such things never ever happened.
Edit: I just looked at the project's main website and the auto help provided half way through typing "self" which they are obviously very proud of looks like my worst nightmare. A few weekends back I did some "unplugged" C programming just with Notepad++ rather than Visual Studio and honestly I felt it was a key step to overcoming the migraine issues I've been having lately.
I like autopairs (as those are called) but I really hate it when I type the terminator and the editor inserts another terminator. That's why I gave up on VS Codium after giving it a second try.
No, that would be crazy. Ofc I want syntax highlighting. There's a bug in the newest version which removes syntax highlighting. I thought it's more common, so I understand that probably most are not understanding my comment.
https://github.com/lapce/lapce/issues/2747
