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

221–229 of 229 posts

Re: Lapce

#221

Post by flexagoon »

ColonelPhantom wrote: post #214
nequo wrote: post #186

Earlier quoted context omitted.

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 us…

I don't have a lot of experience with Emacs, let alone evil (and none at all with meow or god). But my experience with it was that evil felt distinctly.. hacky? For example, Evil felt like it interfered with selecting restarts in Sly. I've had similar issues with VscodeVim being weird in VSC. Ultimately the text editor is so core to a text editor (duh) that deeply modifying it is bound to give a worse experience than…

> But my experience with it was that evil felt distinctly.. hacky?

Honestly that was my experience with all of Emacs, not just evil. I tried Doom Emacs a while ago, and while Doom does a great job at abstracting a lot of that hackiness away, whenever I tried to configure something myself it just felt like the entire Emacs ecosystem is based on random hacked-together 10000 line elisp scripts with 3 GitHub stars which abuse some weird undocumented legacy parts of Emacs. Basically everything except a few famous big packages (eg. Org, Magit, etc.) felt very weird to use.

Kinda surprising considering how comprehensive the Neovim ecosystem feels compared to Emacs', despite it also being a very niche editor

Re: Lapce

#222

Post by saurik »

dleink wrote: post #212
saurik wrote: post #144

Earlier quoted context omitted.

Something actively dropping inputs is an entirely different category of problem than it merely being slow to process them.

Yes, But for "confidence in inputs" the difference doesn't matter.

I honestly don't see that? If it drops inputs, you can't have confidence in your input; but, if it is merely slow to process them, then you don't lose confidence. If you know for sure that something will happen--and even that it will happen in the correct order, as in this case--you can just move on with your life. Have you never worked with a remote text editor over high latency? Or played a musical instrument that had a slow reaction time?

For avoidance of any doubt, I care deeply about my editor latency and agree that those terminals who claim to be "fast" and yet only care about average--not even common--throughout instead of latency misunderstand the problem space... and yet, I still can't say that it is reasonable to lose "confidence in your inputs" if a system is merely slow to process without losing any of your events. If an editor drops any of my inputs at all ever I 100% lose all confidence in what I'm doing; but if it always works then I can close my eyes and still use it without issue!

Re: Lapce

#223

Post by gitaarik »

BoppreH wrote: 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…

Try a Neovim distribution like NvChad, LazyVim, LunarVim, SpaceVim, AstroNvim, CosmicVim, etc.

Re: Lapce

#224

Post by efreak »

kjqgqkejbfefn wrote: post #80
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.

There are plenty of issues like this in Lapce (no support beyond qwerty layout for instance). Just go for Zed instead. https://github.com/lapce/lapce/issues/945#issuecomment-12853...

Isn't keyboard layout a function of the operating system? How is a usermode application supposed to support (or not support) different keyboard layouts?

Re: Lapce

#225

Post by spullara »

rstat1 wrote: post #110
spullara wrote: post #60

Earlier quoted context omitted.

Just a bunch of people optimizing for the wrong thing.

Optimizing for efficiency and performance is never "the wrong thing"

Optimizing for efficiency and performance over utility is absolutely the wrong thing.

Re: Lapce

#226

Post by stracer »

sph wrote: post #182
stracer wrote: post #58

Earlier quoted context omitted.

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.

Did some such editor succeed?

Re: Lapce

#227

Post by mafuyu »

saurik wrote: post #222
dleink wrote: post #212

Earlier quoted context omitted.

Yes, But for "confidence in inputs" the difference doesn't matter.

I honestly don't see that? If it drops inputs, you can't have confidence in your input; but, if it is merely slow to process them, then you don't lose confidence. If you know for sure that something will happen--and even that it will happen in the correct order, as in this case--you can just move on with your life. Have you never worked with a remote text editor over high latency? Or played a musical instrument that…

I think this gets at my feelings on latency as well.

Terminal emulators with GPU-accelerated rendering became popular, but I often found the latency to be quite bad. (I eventually settled on Kitty and foot.)

With VS Code in particular, it’s just not designed to be operated via keyboard. With enough effort, you can map/script everything, but many actions translate to opening a pane and then focusing it. It’s an implicit modality switch that often ignores input during the transition. Also, opening a new terminal is oddly slow, I think due to VS Code injecting things into zsh init.

With tmux+nvim, it’s much more predictable. For example, if I think “I want to copy three lines out of this file and paste it into a new shell”, it’s just: `3yy alt+enter ctrl+shift+v`, and I know it’s going to work every time. Not to mention the composability of keybinds in different scenarios.

(Also, hi saurik! Cydia on my OG iPod Touch is a big part of what got me into coding in the first place :)

Re: Lapce

#228

Post by mafuyu »

bemusedthrow75 wrote: post #79
mafuyu wrote: post #38

Earlier quoted context omitted.

It’s the small latencies that add up for me. I usually use a tmux + nvim setup, but for codebases that require a bit more language server support (eg. C++20 and sometimes Rust), I have a VS Code setup with the nvim plugin that I’ve spent way too many hours tweaking hot keys and things. Despite all my tweaking, VSCode sometimes just feels like it’s a beat behind, and keyboard commands get dropped in the transition bet…

You are a data point for the notion I mention in my own reply to the parent that keyboard-only navigators might be feeling this more than mouse/trackpad users. Which seems likely to me.

Agreed. I elaborated a bit more in a sibling comment about how many keybinds result in opening a pane and focusing it, and it’s just not built for being operated by keyboard. Although you could make the argument that using the mouse just hides all the latency. Scrolling through text buffers is super smooth… but at what cost?

Re: Lapce

#229

Post by warthog »

flexagoon wrote: post #172
warthog wrote: 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?

You can use codeium with cursor.so as it is a fork of VSCode.
Post reply on HN