Live data from Hacker News

Lapce

lapce.dev

181–190 of 229 posts

Re: Lapce

#181
post #154

I am constantly confused by text editors pitching themselves on speed. Is the world really full of developers going crazy with frustration because they’re waiting on vs code to do something? I opened a 100,000 line text file a few days ago & it rendered in like half a second, considering I do this about once a year it’s really more than good enough.

Gonna pile up. VS Code with barely any plugins on M1 is noticeably slower than IDEs I've used 15 years ago on a hardware from 20 years go. Slower to render, slower to react to my inpit. It's bordering on unusable on a x86 laptop from few years back. Better showcase on how ridiculous the tech stack is would be to open a 500 line file with a code and scroll. Startup isn't great either, though it isn't comically bad as…

What IDE do you use nowadays if not VS Code? I'm curious because I'm also using an M1 Mac and I've ran through the gamut (Sublime, PyCharm, Atom, etc).

Re: Lapce

#182
post #58
post #42

Making a fast editor is such a common hobby, everybody seems to be working on one these days apparently, yet memory safety and speed has never been a real problem in editors. It would be much more impressive to explore a novel approach for editors more extensible than Emacs, or with a more innovative editing model than vim's. If we are reinventing the wheel, why not at least try to make a better wheel that's never be…

Editors don't get made in Rust because people want better memory safety in an editor. They're made in Rust because people like Rust, and the Rust trademark makes anything associated more cool, no other language has reached such a godlike marketing status.

It's called a hype cycle. A decade ago it was editors written in Go.

Re: Lapce

#183
I’m a big fan of this project. A native, GUI, fast code editor is a welcome change from what VSC does to my laptop’s battery. Unfortunately, I have to step away from it while I figure out a potential data corruption issue. While editing a complex config file in lapce yesterday, I reopened it later to find all KINDS of errors—dozens of deleted, moved, and changed lines. I haven’t pinned it on lapce and it may well end up being something else, but it’s the primary suspect at the moment unfortunately. But to be crystal clear: if the problem is with lapce, that’s on me for using early stage software with a real document. It’s a great project and I don’t blame the software at all for my choice! (Just … ymmv at this stage.)

Re: Lapce

#184

Just installed this on windows 10. First time I tried to open it the window hung for 3 minutes until I killed it. The second time, I couldn't reposition the window by clicking and dragging. Third time I loaded it, it hung again. It's an exciting product pitch but isn't working for me. I see now that there's a "pre-alpha stage" disclaimer on the download page and wish that were in larger font.

My experience on Windows 11 wasn't as bad as yours, but I opened a small Rust project with Lapce (~20 files) and it uses 1400MB of RAM vs VS Code's 900MB, and has very noticeable latency when navigating the code and typing. But like you said, it's pre-alpha, and I hope this project succeeds. I'm sure these issues are solvable. It's exciting to see Rust-based non-web UI libraries finally starting to become usable for…

Lapce cannot use that much of memory, it's most likely that Rust Analyzer has allocated majority of it.

Re: Lapce

#185

Just installed this on windows 10. First time I tried to open it the window hung for 3 minutes until I killed it. The second time, I couldn't reposition the window by clicking and dragging. Third time I loaded it, it hung again. It's an exciting product pitch but isn't working for me. I see now that there's a "pre-alpha stage" disclaimer on the download page and wish that were in larger font.

Portable version loaded instantly for me on Windows 10. Remote SSH functionality doesn't work at all unfortunately[1]. Would be nice to try out but I don't do any local dev. 1: https://github.com/lapce/lapce/issues/2985

Correction: Remote SSH works fine, we haven't reimplemented the remote file picker in new GUI toolkit but that can be workarounded by using `lapce` CLI and built-in terminal.

Re: Lapce

#186
post #42

Making a fast editor is such a common hobby, everybody seems to be working on one these days apparently, yet memory safety and speed has never been a real problem in editors. It would be much more impressive to explore a novel approach for editors more extensible than Emacs, or with a more innovative editing model than vim's. If we are reinventing the wheel, why not at least try to make a better wheel that's never be…

> with a more innovative editing model than vim's I think Helix tries to do that

Kakoune too. But if a project focuses on a novel editing model and not some other aspect of an editor, then implementing it inside Emacs might be the best approach.

If implemented inside Emacs, then it composes with the rest of its package ecosystem. Kakoune, Helix, etc. are somewhat set back by having to reproduce functionality equivalent to Magit, Org, LSP mode, and so on in order to be on equal footing for many users.

Evil, Meow, and God mode seem to show that Emacs is a good platform for such experimentation.

Re: Lapce

#187
post #23

Just installed this on windows 10. First time I tried to open it the window hung for 3 minutes until I killed it. The second time, I couldn't reposition the window by clicking and dragging. Third time I loaded it, it hung again. It's an exciting product pitch but isn't working for me. I see now that there's a "pre-alpha stage" disclaimer on the download page and wish that were in larger font.

How is a project with 30,000 GH stars a pre-alpha stage project?

Be a team of 3-4 people working in their spare time to maintain cross-platform native GUI FOSS project that people seem to like

Re: Lapce

#188
post #35
post #23

Earlier quoted context omitted.

How is a project with 30,000 GH stars a pre-alpha stage project?

It boggles the mind. Good for the team building this, lots of respect entering this crowded and race to the bottom pricing product. But I don’t get how this differs from vs code or why someone would be excited about it. I get the feeling people like trying new editors so they throw stars around for every ide project they come across. None of the features advertised beat neovim nor does it have the crazy plugin ecosys…

People like their editor to be fast, work on more platforms, be open source, not being tied to Microsoft, etc.

Plenty of reasons why someone would choose Lapce over VS Code.

Re: Lapce

#189
post #162
post #135

Earlier quoted context omitted.

As a user, I certainly do not find it hostile. In a "batteries included" edit a service like copilot that expose all data to a third party is a terrible anti-feature. As for script-oriented plugins vs wasm - I see a tradeoff - and don't think neither are right or wrong. Cross editor plugins via a common wasm api might be fun, but perhaps not very practical. Edit: link to relevant issues and discussion: https://github…

Copilot has many fans, and for many, the ability to use Copilot is more important than all the other "batteries-included" features. It's not for me or anyone else to judge. Everyone should make their own choices. Regarding plugins, I'm with Helix from the beginning, i have read everything, and I understand the motivation well and can accept it. Perhaps this is what the ideal editor looks like for creators, but it def…

I still don't understand why you claimed that:

> [Helix]'s quite hostile towards its own community.

Re: Lapce

#190
post #4

Find a way to port plugins from VSC and I'm in!

We're not going to support VSCode extensions, it's not viable for us and would require to bring VSC/NodeJS runtime everywhere Lapce needs to run
Post reply on HN