[HN Gopher] Lapce Editor 0.3
___________________________________________________________________
Lapce Editor 0.3
Author : philonoist
Score : 195 points
Date : 2023-11-14 13:00 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Alifatisk wrote:
| I could definitely give this a shot, looks clean as hell. Does it
| support Ruby?
| jitl wrote:
| There's a language server for Ruby maintained by Shopify so I
| expect it should support Ruby okay if you have that installed.
| czechdeveloper wrote:
| Looks better than last time I checked. I like the idea and it's
| getting there.
| attende_domine wrote:
| Promising project, but keyboard internationalization is a mess.
| It's unusable for those using non-English keyboard layouts.
|
| https://github.com/lapce/lapce/issues/2244
|
| https://github.com/lapce/lapce/issues/1094
|
| https://github.com/lapce/lapce/issues/1689
|
| https://github.com/lapce/lapce/issues/2731
| petepete wrote:
| It's at 0.3, cut them some slack.
| Iridescent_ wrote:
| 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.
| golergka wrote:
| 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.
| tmtvl wrote:
| 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.
| tom_ wrote:
| 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.
| eyelidlessness wrote:
| So what? It isn't claiming to be ready, for its main job or
| otherwise.
| ReleaseCandidat wrote:
| I do not see any indication of its "not-readiness"
| anywhere in the README https://github.com/lapce/lapce or
| their website: https://lapce.dev/
|
| So while it isn't claiming to be ready, their content
| does not tell otherwise. Yes, the version is 0.3, but
| Neovim is at 0.9.
| nwienert wrote:
| Says pre alpha right at the very top of the website.
| ReleaseCandidat wrote:
| Oh, you're right, it's there right above the title
| "Lightning-fast and Powerful Code Editor". I swear they
| added that after my post ;)
| yjftsjthsd-h wrote:
| > Yes, the version is 0.3, but Neovim is at 0.9.
|
| I would argue that that's a fault on neovim's side; I'm
| sure there's a reason, but I would call it 1.x software.
| ReleaseCandidat wrote:
| Oh, that's to be version-comparable to Emacs, which is at
| version 29. Vim being at 9 is just way too optimistic!
|
| _duck and run_
| artisin wrote:
| 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.
| HelloNurse wrote:
| 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.
| Strom wrote:
| > _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.
| Philpax wrote:
| 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.
| poulpy123 wrote:
| I'm not going to criticize them but being able to type with
| my keyboard is pretty high in my list of requirements for a
| text editor :D
| bfrog wrote:
| I'm sure contributions are welcome to solve the problem
| oneshtein wrote:
| Please, contribute to discussion at least.
| AndreasBackx wrote:
| 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.
| elteto wrote:
| 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.
| PurpleRamen wrote:
| 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.
| akoboldfrying wrote:
| >So a C++ plugin would understand CMake files for example.
|
| No one understands CMake files
| PurpleRamen wrote:
| 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?
| digitalsanctum wrote:
| 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.
| yjftsjthsd-h wrote:
| > Perhaps using WASM via something like https://extism.org/.
| That would also open it up to building plugins in multiple
| languages.
|
| https://github.com/lapce/lapce already says,
|
| > Plugins can be written in programming languages that can
| compile to the WASI format (C, Rust, AssemblyScript)
|
| so it sounds like they did that?
| mring33621 wrote:
| 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!
| PH95VuimJjqBqy wrote:
| oh man, we can then build it into the OS and give it a
| recognizeable name like Component Object Model!
| hoistbypetard wrote:
| Could we define a common specification for how those brokers
| should interact with other objects, and call it CORBA?
| ReleaseCandidat wrote:
| Yes, why not! But I guess that's too complex, we'd need a
| simple object access protocol!
| tmtvl wrote:
| OMG, why are we talking about ancient uncool technology?
|
| Jokes aside, there are so many cool standards for doing
| stuff it's a shame we seem to reinvent the wheel over and
| over again.
| TwentyPosts wrote:
| Still not sure what the "killer feature" here is. Is there even
| one? Or is it just "something like vs code but in Rust and faster
| and slicker"?
|
| I'd give it a try, but I am very happy using Helix, which is
| pretty novel in its own right.
| nicoburns wrote:
| I'd say it's either "VS Code, but with better performance /
| resource usage" or "Sublime Text, but open source"
| agluszak wrote:
| Not everything has to have a killer feature. It's an oper-
| source project, not a for-profit startup
| eviks wrote:
| this is the one
|
| > You can write a plugin for Lapce with any programing language
| that compiles to WASI
|
| though faster and slicker than Electron would also be nice. A
| helix-like as opposed to vim-like mode as well
| zozbot234 wrote:
| > A helix-like as opposed to vim-like mode as well
|
| Discussed here: https://github.com/lapce/lapce/issues/281
| afefers wrote:
| The killer feature for me is not being an Electron app.
| snvzz wrote:
| Neither is kate.
|
| Nor vim nor emacs for that matter.
| afefers wrote:
| Yup. I use Emacs since 2002 and am pretty happy with it.
| Never used an Electron-based app and probably never will.
| whywhywhywhy wrote:
| > Or is it just "something like vs code but in Rust and faster
| and slicker"?
|
| By that logic wasn't the "killer feature" of VSCode just
| "something like Atom but in Typescript and faster and slicker"?
| zozbot234 wrote:
| 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
| sneed_chucker wrote:
| 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.
| PurpleRamen wrote:
| > 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.
|
| Sublime has LSP since a while now.
| sneed_chucker wrote:
| > 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.
| PurpleRamen wrote:
| > 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.
| sneed_chucker wrote:
| I mean, aren't there whole web browsers and email clients
| written inside of Emacs? Isn't there a whole "Emacs is an
| operating system" joke?
|
| But in any case, I try to avoid bespoke custom editor
| setups unless there's a situation that really warrants
| it.
| tmtvl wrote:
| Only one web browser, I think. The w3m package exists,
| but that's just a communication layer between Emacs and
| w3m.
| PurpleRamen wrote:
| > 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.
| doix wrote:
| 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).
| JeremyNT wrote:
| 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.
| jokethrowaway wrote:
| I had the opposite experience.
|
| 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.
| CrendKing wrote:
| > 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.
| ziftface wrote:
| 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.
| jokethrowaway wrote:
| VS code is reasonably fast, sane defaults and language
| support, that's why it's popular.
|
| Plugins are overrated and I try not to use them as much as I
| can.
| alexbezhan wrote:
| Code folding is still not supported. It's a dealbreaker for me
| https://github.com/lapce/lapce/issues/749
| oneshtein wrote:
| 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.
| _a_a_a_ wrote:
| 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.
| billforsternz wrote:
| 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.
| tmtvl wrote:
| 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.
| littlestymaar wrote:
| > #2190: Rewrite with Floem UI
|
| 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?
| yjftsjthsd-h wrote:
| https://github.com/lapce/lapce says,
|
| > Lapce (IPA: /laeps/) 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.
| juliangmp wrote:
| Definetly a project I'm keeping my eyes on.
|
| The "killer feature" will be the plugin/extension support. Vscode
| got where its now mostly because of how extendable it is imo.
| ReleaseCandidat wrote:
| > 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.
| zamalek wrote:
| > Rewrote in FloemUI
|
| 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.
| emi2k01 wrote:
| > 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]
|
| [1]: https://blog.emi0x7d1.dev/improving-autocompletion-in-
| your-r... [2]:
| https://www.reddit.com/r/rust/comments/16x2kzi/improving_aut...
| zamalek wrote:
| 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.
| wvh wrote:
| 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.
| microflash wrote:
| It's great but unfortunately the lack of line wrapping[1] has
| actively prevented me using it.
|
| [1]: https://github.com/lapce/lapce/issues/945
| smohare wrote:
| 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.
| microflash wrote:
| For personal projects, where I'm in control of column size,
| this works nicely. Not so much for "work" projects.
|
| > Personally, I just find such "long" lines too difficult to
| navigate.
|
| This is where line wrapping helps me. It wraps the lines to
| my preferred column size preventing the horizontal scroll.
| vouaobrasil wrote:
| 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.
| Aerbil313 wrote:
| This is version 0.3. Calm down.
| vsskanth wrote:
| weird font rendering on non-retina windows makes this unusable
| for me.
| ckdot2 wrote:
| Syntax highlighting? Aaaaaand... it's gone!
| tomtheelder wrote:
| Does this mean you are rejecting it because it has syntax
| highlighting? It has theme support so you can absolutely turn
| that off if you'd like.
| chambored wrote:
| 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.
| norman784 wrote:
| 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.
| bobajeff wrote:
| 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.
| bogwog wrote:
| 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.
| bobajeff wrote:
| 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.
| Aerbil313 wrote:
| 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.
| dang wrote:
| Related. Others?
|
| _Lapce Editor, Release v0.2.0_ -
| https://news.ycombinator.com/item?id=32714191 - Sept 2022 (40
| comments)
|
| _Lapce - Fast open-source code editor_ -
| https://news.ycombinator.com/item?id=30708505 - March 2022 (224
| comments)
|
| _Show HN: Lapce - open-source code editor inspired by Xi-editor_
| - https://news.ycombinator.com/item?id=30526693 - March 2022 (2
| comments)
|
| _Lapce - Fast and Powerful Code Editor written in Rust_ -
| https://news.ycombinator.com/item?id=29549173 - Dec 2021 (145
| comments)
| deckar01 wrote:
| 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.
___________________________________________________________________
(page generated 2023-11-14 23:01 UTC)