Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lapce

lapce.dev

Post reply on HN
Print view View original

61–70 of 229 posts

Re: Lapce

#61

Post by systems »

debrisapron wrote: post #25

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.

for me its the plugins speed

a good example is magit on emacs, magit seems great, and i really want to learn it and use it, but its very slow (at least on windows its slow enough to make you unable to practically use it)

in short, speed changes everything

Re: Lapce

#62

Post by mattlondon »

stracer wrote: post #51
debrisapron wrote: post #25

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.

Some corporate employees use a notebook loaded with extremely invasive and performance-degrading security and spying software that can't be uninstalled. When your available cpu and disk time is 10% of what the hardware can do, you need as efficient editor as you can get.

You're probably not going to be able to install random binaries from the internet on those kinds of machines though.

Re: Lapce

#63

Post by jupblb »

ribelo wrote: post #43
e12e wrote: post #33

Earlier quoted context omitted.

Not vim (by design) - but have you tried helix? https://helix-editor.com

Helix is a very good and well-managed project, but it's quite hostile towards its own community. There are no plugins, and they won't be in Wasm like users want, but in Scheme dialect named Steel, that nobody want... if at all. Missing features like copilot or file browser expected by the community are essentially never merged into the master. This might be a better path than total dispersion and destruction of what…

"good and well-managed" vs "[merges everything] users want" - pick one

Re: Lapce

#64

Post by stracer »

antisthenes wrote: post #48
debrisapron wrote: post #25

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.

Okay, just as a counterpoint, I opened 2 10,000 line files and tried to do a diff between them in VSCode. It took more than 20 seconds? Yes, it breaks workflow and is incredibly slow. Just like refreshing elements in UI shouldn't take multiple seconds, or a webpage shouldn't take multiple seconds to load on a good connection.

I tried the same in my Linux terminal emulator, and it took 0.2s, when I added colors, 0.3s. That's 100x faster - maybe diff in VSCode means something different than running diff and printing the output? Did you include the time needed to open the files?

Re: Lapce

#65

Post by oconnor663 »

stracer wrote: post #58
sph wrote: 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.

Counterpoint: The only really pleasant + mainstream + cross-platform languages for new client/desktop software today are Go and Rust. Depending on the Python interpreter or the JRE or whatever is a huge pain when you don't control the environment. Just spitting out a native binary really helps. (I say this as someone who doesn't personally find Go pleasant, but I understand that lots of other people do, and I respect the tradeoffs it made.)

Re: Lapce

#66

Post by jwells89 »

debrisapron wrote: post #25

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.

Sometimes it’s actually speed that’s the issue (when e.g. opening massive text files) but usually “speed” is more about responsiveness in editing, text navigation, etc, which some people are very sensitive to. The time between action and reaction is best minimal as possible.

Re: Lapce

#67

Post by Arch485 »

behnamoh wrote: post #27

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

Can you elaborate on how this is "fake" open-source?

Re: Lapce

#68

Post by stracer »

mattlondon wrote: post #62
stracer wrote: post #51

Earlier quoted context omitted.

Some corporate employees use a notebook loaded with extremely invasive and performance-degrading security and spying software that can't be uninstalled. When your available cpu and disk time is 10% of what the hardware can do, you need as efficient editor as you can get.

You're probably not going to be able to install random binaries from the internet on those kinds of machines though.

Sadly true... Maybe in a few years, if it gets popular enough, and the key decisionmaker gets wooed into allowing it.

Re: Lapce

#69

Post by hollerith »

I'd give this a try if I could find some way to configure it to wrap long lines.

By "wrap long lines", I mean that I will never see a horizontal scroll bar even if there is a very long line of text in the buffer.

Re: Lapce

#70

Post by posix86 »

whats_a_quasar wrote: post #9

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.

Experience on Ubuntu: It opens, but double clicking the header doesn't make it expand. Then `Open Directory` doesn't do anything; no typing, no nothing. So close again, and open from command line with the directory as agument, works. Now I can't see my mouse.
Post reply on HN