Live data from Hacker News

Lapce

lapce.dev

171–180 of 229 posts

Re: Lapce

#171
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

Re: Lapce

#172
post #97

The reason I am sticking with cursor.so is the AI. It is convenient to be able to a) let AI read whole files b) feed in direct documentation of a certain package to have proper context. Might not be worth to expert coders out here but definitely saves a lot of time for me debugging or onboarding into a new framework Wish Lapce had that. Also Zed does not have the quite depth for AI compared to Cursor

Why not just use basically any editor with codeium.com?

Re: Lapce

#173
post #93

Earlier quoted context omitted.

I would invert that: when was the last time you tried using a text editor that boasts speed instead of VSCode? I am forced to use VSCode for extension-based reasons, but have Sublime Text installed as well that I can very occasionally use. The difference each time is staggering, like a slap in the face. Scrolling smoothness, input latency, snappyiness to jump between files, or search workspaces. Each time it's so obv…

I'm often coding on a server with like 10ms round trip latency, so I'm not bothered by the small latency that my editor introduces. I'm using Vim, by the way.

I was under the impression that the smallest time humans can perceive is like ~30ms, in which case 10 is effectively instantaneous

Re: Lapce

#174
post #102

Earlier quoted context omitted.

my machine must be faster than yours. I have both. I can't tell the difference

i guess which and the number of extensions will have a significant effect on lag

To be fair, that's always true; I've managed to make even vim stutter with the right extensions/configuration.

Re: Lapce

#175

No thanks, I don't want fake open-source apps anymore. Some fake open-source software that are actually in it for the money: - Langchain (and most "open-source" LLM software) - Zed

Huh? Both this and Zed are fully open source and licensed under a FOSS license

> actually in it for the money

Neither "open source" nor "free software" have anything to do with being non-profit and not trying to make money

In fact, GNU directly says this: "Actually, we encourage people who redistribute free software to charge as much as they wish or can." [1]

And that's GNU. Which is FSF - the most obnoxious open-source absolutists you'll ever find. And even they don't discourage for-profit open-source.

[1]: https://www.gnu.org/philosophy/selling.en.html

Re: Lapce

#176
post #93

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.

I would invert that: when was the last time you tried using a text editor that boasts speed instead of VSCode? I am forced to use VSCode for extension-based reasons, but have Sublime Text installed as well that I can very occasionally use. The difference each time is staggering, like a slap in the face. Scrolling smoothness, input latency, snappyiness to jump between files, or search workspaces. Each time it's so obv…

I'm in almost the same boat. Speed absolutely matters, but you only notice it when you don't have it.

I'm working on a large Dart project and a long time ago someone thought that having the project split up into 100 packages would be a great idea (it's not).

My previous editor was IntelliJ as I am used to its keyboard shortcuts, but it struggled with our setup: constant freezes and even if it didn't freeze, it would take seconds until the suggestions came up (or when I wanted to rename a local variable, smh).

I was so frustrated by it, that I installed helix, it was fast so I'm now learning to use it as my daily driver.

I have now both open, doing my editing on helix, and if I feel like I can go something faster in IntelliJ (which now happens less and less often), I do that little thing in IntelliJ and come back to helix.

Why helix: it's "great by default" and I didn't have much success with setting up and customizing NeoVim (it didn't feel good, the plugin were annoying to learn, and it started to slow down). I'm sure it a skill issue, but helix just works for me, and I can live without plugins for now.

Re: Lapce

#177
post #47

Earlier quoted context omitted.

I think it's just that everybody has been looking for THE editor, and so it is natural that people would develop their own. I think what we're seeing is that VSCode is becoming THE editor (if it's not already there). At this point it's hard to compete. I think the biggest contender is IntelliJ, as many people really seem to enjoy it, but I would predict that it's going to be hard to fight against free.

I had such high hopes for Sublime Text, but then development slowed to what seemed like a glacial pace, with every upgrade requiring another licensing fee.

I'm happy with it even with "slow updates". What features are you looking forward to?

Re: Lapce

#178

Who knew that the existential crisis of the modern developer would be choosing between milliseconds of latency and the perfect shade of syntax highlighting :)

Might be some ocd type of stuff or just people being different, but yeah those milliseconds of latency absolutely do get in my nerves.

Re: Lapce

#179

Lapce dev here. Firstly sorry for the bad experience for some people. Just a bit of context here to explain the status of the project. The first line of code was started around 2018 as a personal project. And as of today, we still don't have anyone who works on it full time. We don't want to defend ourselves too much here, because there are very good quality code editors out there such as Helix, which is also communi…

Thanks your contribution! I just downloaded it, installed the Rust add-on, and it automatically used rust-analyzer showing all the information of types and structs. It maybe needs some polishing, but looks like it works like it should, and it does it really fast. I'll test it better tomorrow, the running and debugging interface seems really simple and interesting tbh

On the side of the GUI, what made you make Floem instead of using egui or other similar library? As far as I looked, looks like a non-native reactive GUI using some 2D graphics library like the other ones. Does the granularity in that reactivity have a big importance in that?

Apart from that, if Floem is easier to use than other graphical libraries for complex designs, or if you make a GUI designer like you have in Visual Studio, Qt, and similar, it can help a lot of people developing apps in Rust

Re: Lapce

#180
post #95
post #74

I'm shopping for an IDE with Vim keybindings, but this doesn't seem to be it yet. Points for having Vim-like support out of the box, but most of what I tried failed, including: - Exiting insertion mode with ctrl+c or ctrl+[ - Shift+U to undo all changes done to the current line - `di[` to delete the contents inside the current [ - `dta` to delete everything until the next `a` - Shift+[ and shift+] to jump paragraphs…

> Shift+U to undo all changes done to the current line Been using Vim for over 15 years and didn't know this one.

I know right!
Post reply on HN