[HN Gopher] Lapce
___________________________________________________________________
Lapce
Author : tosh
Score : 437 points
Date : 2024-02-18 17:36 UTC (5 hours ago)
(HTM) web link (lapce.dev)
(TXT) w3m dump (lapce.dev)
| not_your_vase wrote:
| Was just trying it out earlier this week. Or at least wanted to,
| after hearing all the good opinins about it over the net.
| Unfortunately using xmonad it simply refuses to display in
| certain positions. When I found a position where the interface
| was displayed, there was still no tooltip on the icons, which
| makes recognizing their function non-trivial. Anyway, after I
| spent 8 minutes trying to find a place to set custom include
| folder unsuccessfully for my project, I gave up, and went back to
| QT creator.
|
| Will try again next year.
| alluro2 wrote:
| Does anyone have insight into how Lapce and Zed compare to each
| other? I.e. what are the differences in project goals, current
| capabilities and roadmap? Thanks!
| ksynwa wrote:
| One thing I know of is that zed'a scope is a bit wider and
| includes some collaborative tools and enhancements. Don't know
| the exact details though.
| cultofmetatron wrote:
| it seemes closer ti what I actually need than zed. love zed's
| speed but remote development is mandatory in thus day and age
| SpaghettiCthulu wrote:
| What makes you say that remote development is mandatory? I
| think it has less to do with "this day and age" and more to
| do with your current employment.
| jsheard wrote:
| Lapce being cross-platform is a major difference for now, Zed
| plans to be eventually but it's currently only on Mac.
| nicoburns wrote:
| Now that Zed is open source they're actually quite similar in
| capability (even sharing a number of underling libraries). The
| biggest difference is probably that Zed is backed by a
| commercial company (and I believe they have plans to sell
| collaborative functionality on top of the core editor) whereas
| Lapce is more of a community open source project.
|
| Lapce is also cross-platform whereas Zed is currently macOS
| only. But they seem to be making rapid progress on linux
| support so this may not be relevant soon.
| cal85 wrote:
| This is my question too. I think I'm going to have to try both.
| AFAICT so far, Lapce is 'just' someone's open source project
| that has got popular, while Zed is made by a funded-looking
| startup with several employees that announced they were
| switching to open source just a couple of weeks ago. Zed also
| has Copilot built in. Both look like great editors at a glance.
| Zed has more easily findable information about their goals -
| there's a blog and a roadmap on their site. (I guess with Lapce
| it might be possible to get a sense of goals/vision by sifting
| through GitHub issues and comments, which I haven't done yet.)
| cellis wrote:
| Find a way to port plugins from VSC and I'm in!
| Alifatisk wrote:
| As long as it supports C and Ruby, I'm happy.
| guessmyname wrote:
| That will take a long time because plugins [1][2] are written
| in Rust too, e.g. Go LSP plugin [3][4].
|
| [1] https://plugins.lapce.dev
|
| [2] https://github.com/lapce-community
|
| [3] https://plugins.lapce.dev/plugins/panekj/lapce-go
|
| [4] https://github.com/lapce-community/lapce-
| go/blob/volt/src/ma...
| boomskats wrote:
| I think VSCode is also moving in the direction of wasi
| extensions[0], including for its serverside extensions
| host[1]. So there's a chance we get some of that for free.
|
| [0]: https://code.visualstudio.com/blogs/2023/06/05/vscode-
| wasm-w...
|
| [1]:https://github.com/microsoft/vscode-wasm
| fbdab103 wrote:
| That's exciting. While I have some minor gripes about
| VSCode, it is fine enough. What gets me worried is the
| plugin ecosystem continually becomes a selling point in
| which no other editor can compete. I want other editors to
| be built and have a chance to thrive, but it becomes
| impossible if all of the good development tools get locked
| to one program.
| pentaphobe wrote:
| From the landing page:
|
| "You can write a plugin for Lapce with any programing
| language that compiles to WASI."
| lima wrote:
| Doesn't appear to support UI scaling on Linux :(
| osmsucks wrote:
| They rewrote the UI recently in their own toolkit, Floem [^1],
| and that broke all scaling under X11 for me (now the UI and
| fonts are rendered so large that it's unusable). It works fine
| in Wayland though...
|
| Here's some issues that were filed for this same problem:
| - https://github.com/lapce/lapce/issues/2732 -
| https://github.com/lapce/lapce/issues/2773 -
| https://github.com/lapce/lapce/issues/2737
|
| [^1]: https://github.com/lapce/floem
| quibono wrote:
| I have my CapsLock key remapped to Escape with `setxbkmap` and
| yet it's not recognized in the modal editing mode (I have to
| actually press Escape) - anyone else experiencing that?
| whats_a_quasar wrote:
| 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.
| HPsquared wrote:
| I guess it had a lapse.
| throw10920 wrote:
| For an editor whose differentiating factor appears to be
| "written in Rust", having a first-time user experience of
| crashing/hanging is unfortunate.
| jjallen wrote:
| How is a project with 30,000 GH stars a pre-alpha stage
| project?
| qudat wrote:
| 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 ecosystem.
| FpUser wrote:
| Probably because it says in Rust. In Rust we trust.
| rymiel wrote:
| It doesn't work but it's memory safe in being non-
| functional
| paradox460 wrote:
| You can buy stars
| PreInternet01 wrote:
| Not sure if you tried the installer or the portable version,
| but for me, running the latter required me to put it in a
| location where it had permissions to create the 'lapce-data'
| sub-folder. (And no, there was no sensible error message when
| that inevitably failed).
|
| Having said that, there doesn't seem to be very much "there"
| there, right now. I managed to open a C# project using the
| 'csharp-ls' language server, but, other than suggesting some
| refactorings that I couldn't successfully apply, there wasn't
| much that indicated that this actually worked. Debugging
| certainly didn't.
|
| It _did_ load very fast, though, so that might make it worth
| checking out again in, oh, a year or so...
| Fervicus wrote:
| No opinions on the editor itself yet, but just wanted to chime
| in here to say that I didn't have any such issues on Windows
| 10.
| posix86 wrote:
| 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.
| kjqgqkejbfefn wrote:
| 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...
| verve_rat wrote:
| How are they going to run Zed on Windows?
| nickstinemates wrote:
| 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
| roarcher wrote:
| 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 reasonably complex apps.
| avocadoburger wrote:
| haha linkin park logo
| thunkle wrote:
| No... It's 30 degrees different.
| dako2117 wrote:
| wow, a code editor
| ilaksh wrote:
| On Ubuntu for me on my laptop, it opens, then I try to drag the
| top status area and it sort of hides under the icon bar at the
| left part of the screen. Then I try to click on it again and it
| is completely hidden. The icon is still there though.
| 29ebJCyy wrote:
| As someone who uses Neovim, I would love to have a near-vim
| experience in something that has all of the convenience of VSC +
| a great plugin ecosystem. However, I'm not sure about the fact
| that in `normal` mode `:` just brings up the `cmd+shift+p`
| command dialog. Maybe I could get used to it, but the fact that
| something as simple as my muscle memory for "I'm in `normal`
| mode, better type `:w` just to make sure I've saved"
| automatically bringing up that dialog and then suggesting I
| `Close current window` immediately... is not helpful. If the
| command experience is going to be so different from vim them it's
| not really going to ever be a suitable replacement even for brief
| stints/pairing IMO. It's a shame because the VS Code vim plugin
| leaves a _lot_ to be desired.
| twp wrote:
| Use https://github.com/vscode-neovim/vscode-neovim instead.
| tuan wrote:
| Since v1.0+ of this extension I have been constantly having
| issues with neovim's and VSCode's buffers got out of sync. I
| cannot reliably reproduce the issues however. There are a few
| similar reports, e.g. https://github.com/vscode-
| neovim/vscode-neovim/issues/1624. I've switched to other VIM
| extension (VSCodeVim) which I found more reliable, albeit
| less powerful.
| koonsolo wrote:
| That's funny, because I switched from VSCodeVim to NeoVim
| for a similar reason.
|
| I guess both have issues. But still, the power of VSCode
| with vim keybindings is still my best setup.
| e12e wrote:
| Not vim (by design) - but have you tried helix?
|
| https://helix-editor.com
| ribelo wrote:
| 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
| works, but my expectations do not align with what the
| creators offer, so I give them the freedom to choose. I keep
| my fingers crossed for its development, but I personally use
| something else.
| jupblb wrote:
| "good and well-managed" vs "[merges everything] users want"
| - pick one
| ribelo wrote:
| I pick to stay with neovim.
| e12e wrote:
| 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.com/helix-
| editor/helix/discussions/3806#discu...
|
| https://github.com/helix-editor/helix/issues/122
|
| https://github.com/helix-editor/helix/issues/1927
| ribelo wrote:
| 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 definitely doesn't
| look like the ideal editor for me. I respect their
| decision, but I'm sticking with Neovim and might switch
| to ZED when Linux support becomes available.
| qudat wrote:
| What are you missing from neovim?
|
| There are plenty of out of the box configs that do most of the
| work for the user in terms of configuration that begs the
| question: why demand vim in other code editors?
|
| https://neovimcraft.com/c
| retrochameleon wrote:
| Agreed. : should be standard Vim commands. Command pallete
| should be a separate keybind.
| lsllc wrote:
| Neovim with Lazyvim is pretty good out of the box. In the old
| days, both Emacs and (Neo)vim although highly extensible, well,
| it was hard to configure and set up for the things you wanted
| to do.
|
| Now, we have Spacemacs, Doom Emacs and Neovim with Lazy, Packer
| etc., so I really can have a 1st class "IDE" without needing to
| learn LISP or Vimscript (or Lua). So you do need a little bit
| of that to be able to edit the package.el or init.lua, but it's
| pretty much uncomment or cut & paste.
|
| If you're looking for a (Neo)vi(m) tutorial, try this:
|
| https://www.barbarianmeetscoding.com/boost-your-coding-fu-wi...
| szundi wrote:
| How easy it is to underestimate the effort needed to compete with
| the status quo.
|
| There would be no sane individuals to try to siege it if this was
| evident for everyone though!
| debrisapron wrote:
| 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.
| tasn wrote:
| Nowadays I just assume "lighting fast" means "written in Rust".
| Even if it's actually slower than the status quo.
|
| I'm a Rust fanboy, so not dunking on Rust. Just an observation.
| mafuyu wrote:
| 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 between panes and such. Even just scrolling with
| nvim keybinds feels a bit off. My key repeat rate is fairly
| high, and I'll hold down ^D to skim through a source file.
| VSCode's renderer struggles to keep up smoothly sometimes.
|
| This is all nitpicky stuff, not enough for me to swear off
| VSCode or anything. But it's just annoying enough that every
| once in a while I end up in some rabbit hole of VSCode
| internals and css tweaks, instead of doing actual work. Most
| coding does not require a ton of bouncing around, but it does
| feel very liberating to have confidence in my inputs as I
| navigate around.
| bemusedthrow75 wrote:
| 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.
| dleink wrote:
| Wow, that's a great way to phrase it. I'm currently setting
| up a basic laptop with speed like you're describing as a
| goal. "Confidence in my inputs" is an underrated value in
| HCI. Of course websites have to implore users to not click on
| this again while it loads, they don't have confidence in
| their inputs!
| saurik wrote:
| Something actively dropping inputs is an entirely different
| category of problem than it merely being slow to process
| them.
| Fraterkes wrote:
| Vscode is nearly unuseable when my 5 year old thinkpad isn't
| plugged in. So yeah.
| franky47 wrote:
| Frustration often comes with extensibility: adding extensions
| on top of VSCode that need to run at file save time (eg:
| formatters) can lead to pretty significant performance drops.
|
| This extensibility is probably what made VSCode popular though,
| especially for web devs since the extension mechanism is
| JavaScript-based.
|
| Makes me wonder if those Rust-based tools (Lapce, Zed) will
| have as much success with Rust-based extensions authoring.
| maleldil wrote:
| I don't know about Lapce, but the plan for Zed is to have
| WASM extensions.
| jahsome wrote:
| Yes. I have an org issued machine with crap specs and dozens of
| repos I switch between all day long. Waiting 30s-2m doesn't
| sound like much but it breaks flow and leads to a lot of "what
| was I doing again...?" Sidetracks
| jonathankoren wrote:
| What are you waiting two minutes to do?
| formerly_proven wrote:
| With corporate Windows laptops the real question is "what
| _aren 't_ you waiting two minutes to do?"
| Cort3z wrote:
| Sounds like your org is bad at basic arithmetic. 12 _2_ 30s =
| 12 minutes per day minimum. Assuming an engineering salary at
| perhaps 100k usd /year, that is about 40,7 usd per hour, they
| would save money by giving you a max specced
| frame.work(2500$) after 307 days (maximum). Assuming you do
| this more than "2 dozen" times per day, as you say "all day
| long", at minimum they would make that money back in 7.7
| days. The same numbers for a max specced MacBook Pro (at 7200
| usd) is 22.1 to 884,5 days.
|
| I get mad at this attitude from some companies. It's like
| telling a carpenter that they have to build a house, but are
| not allowed power tools. It makes no sense.
|
| Edit: typo
| reaperman wrote:
| Except carpenters bring their own tools, so they can
| determine the price: value that's right for their
| pocketbook.
| jimbokun wrote:
| A lot of developers would be ecstatic to have a tools
| allowance and the ability to use whatever laptop they buy
| on the corporate network.
| arghwhat wrote:
| This is the case for most orgs with corp IT. Their KPIs are
| around security, which often manifests itself as a game of
| "how many security products can one run in parallel".
| Crapware like Cisco Secure Endpoint (not to mention
| Umbrella), Thycotic, Netskope, and whatever else is the
| current cool way for a corp to MITM itself and introduce
| kernel vulnerabilities.
|
| This in turn puts departments at odds, as their argument
| for speed is turned into an argument against security,
| which is a very hard position to be in if your department
| is a few layers down the corp stack.
| Cort3z wrote:
| I don't understand. How does speed implies inverse
| security, even with corporate blinders on? Let's say the
| add all the bloatware in the world, how would a slower
| developmental speed compromise the security? That their
| ability to push code goes up and their potential for bugs
| increase?
| arghwhat wrote:
| Security solutions impact speed, rendering reasonable and
| performant machines borderline useless. There is no
| implication that working fast is bad for security.
| akdjidensb wrote:
| We should be clear that it isn't ALL of corporate IT that
| is on board with this, or probably even the majority. Its
| the windows sysadmins that have to deal with non-
| technical end users, and are constantly being hounded
| about trivial shit like people clicking on phishing
| emails and that sort of thing. In fairness to the windows
| people, you probably wouldn't believe just how awful the
| majority of workers are with computers. So it's
| understandable why windows sysadmins become hyper
| paranoid and irrational in a lot of cases. The low pay
| doesn't help either. Windows sysadmin is usually a lower
| tier job within IT and is the most likely to suffer cost
| cutting and be forced to "outsource" security work to a
| pile of rotten security software. It's also entry level,
| and so sometimes they are only marginally better with
| computers than their end users.
|
| Ideally, most programmers should be in IT or have some
| kind of alignment with IT and able to give some pushback
| about this during CAB for instance, and/or get some
| exceptions but that is increasingly difficult the more
| 'agile' an organization becomes and the more it seeks to
| silo infrastructure people from application people. A
| good IT department imo is one that doesn't do this and
| retains a more traditional culture where programmers are
| part of IT and able to actually influence the technical
| direction of the company, not just be treated like a
| product factory for business units.
|
| Just from personal experience working as a programmer on
| the infrastructure side...complaining about windows
| sysadmins was the favorite past time of probably the
| majority of higher tier IT employees. It makes our jobs
| incredibly difficult for the same reason it makes
| application developers jobs difficult.
| arghwhat wrote:
| Problem is that most corps in my experience are run by
| such windows sysadmins, and when you're a subsidiary or
| two away from the IT department it doesn't matter whether
| you're all greybeards - you don't have authority. Best
| you can do is manage to fly under the radar.
|
| On the other hand, you'd be surprised by just how many
| career programmers are completely inept at sysadmin work
| and have no sense for security (nothing like CI pipelines
| using personal credentials and committing keys into
| public repos), so just letting all programmers do
| whatever isn't a great policy either...
| Cort3z wrote:
| This assumed by the way that the speed goes to infinity,
| which is untrue. But the result would most likely be
| indistinguishable from instantaneous from the point of view
| of the developer.
| baby wrote:
| 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.
| jlengrand wrote:
| Not that I disagree, but IntelliJ has a free version, and
| they're building up Fleet as an attempt to compete. Future
| will tell.
| FireBeyond wrote:
| 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.
| andrepd wrote:
| I'm happy with it even with "slow updates". What features
| are you looking forward to?
| FpUser wrote:
| Not sure about how Jetbrains does in general but I have zero
| hesitation paying for perpetual license of their all
| inclusive package. It is peanuts compared to value. I still
| use VS code to do some remote editing / debugging as it is
| somewhat better experience. Hopefully Jetbrains catches up in
| this department one day.
|
| So yes. These two are THE editors for me.
|
| I only deviate from these when I need to do Delphi /
| Freepascal development.
|
| Notepad++ / Notepadqq are being used as in place hotkey
| invoked text editors.
|
| I still try new ones out of curiosity but I have hard time
| understanding why any would succeed. How they're going to get
| the same amount of extensions / plugins in order to match
| functionality?
| pandemic_region wrote:
| Is anybody else finding Intellij more and more getting in the
| way in an obtrusive manner? Code completion suggestions are
| getting worse, formatting ability is basically none existent
| if your statement is missing a comma or a lambda, it keeps
| reindexing my local maven repo, code completions are slow to
| appear... I was a huge fan of their products but now I'm
| getting more and more annoyed. Maybe I'm getting old?
|
| Several times I have been on the brink of trying out spacevim
| for java development , out of pure frustration but the amount
| of config and tweaking needed scares me. I don't need much,
| lightning fast auto complete, auto import and Google code
| formatter integration. One of these weekends I'll bite the
| bullet I think and set it all up.
| antisthenes wrote:
| 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.
| stracer wrote:
| 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?
| antisthenes wrote:
| Yes, the files themselves open quite quickly, but I will
| admit that it's a complicated diff (lots of expected
| differences), and VSCode is not primarily a diff tool.
|
| But also 10k line file should be nothing for a modern PC.
| stracer wrote:
| 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.
| mattlondon wrote:
| You're probably not going to be able to install random
| binaries from the internet on those kinds of machines though.
| stracer wrote:
| Sadly true... Maybe in a few years, if it gets popular
| enough, and the key decisionmaker gets wooed into allowing
| it.
| akdjidensb wrote:
| Don't need to install them if they are portable (most
| everything can be made portable with some work, see scoop
| packager manager for instance). As long as the company
| isn't batshit crazy and has the resources and IT spend to
| afford to use something like applocker, in which case I'd
| seriously recommend looking for other employment if you
| cannot get explicit guarantees about administrative access.
| tomlin wrote:
| They are saying it's made in rust, so they are probably trying
| to counter concerns.
| Keyframe wrote:
| For me it's the latency. It's not a deal breaker, of course.
| It's more of a first world problem akin to I don't know,
| guitars? High vs low action if you know guitar "problems".
| There's no coding problem where it's dependent on speed of
| typing; programming is mostly about reading anyways. It's more
| about the feel of it, like we're picky about keyboards and
| touch feedback we get. I guess spoiled, but nonetheless...
| bemusedthrow75 wrote:
| Hm, except high action is also a positive choice for some,
| not an inherent problem.
|
| (Though I like the attempt at an analogy and I see how it
| works for you at least)
|
| I am a high-action player --- I know I know, a monster! (but
| also a brass and heavy glass slide player)
| spullara wrote:
| Just a bunch of people optimizing for the wrong thing.
| rstat1 wrote:
| Optimizing for efficiency and performance is never "the wrong
| thing"
| systems wrote:
| 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
| jwells89 wrote:
| 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.
| bemusedthrow75 wrote:
| I have a sneaking feeling that the people who use only their
| keyboards to navigate are the ones who really notice latency in
| e.g. VSCode.
|
| I navigate with the trackpad on a Mac and seem not to ever feel
| it, but I know others do not like this way of working, which is
| fair enough.
|
| Lapce is interesting to me for other reasons: it is one of the
| few[0] GUI text editors with a remote dev option that matches
| what VSCode can do. And it might have a smaller footprint on
| the remote machine/in the container while doing it.
|
| VSC's remote dev support is very nearly non-negotiable for me
| now, so I say more power to them; I intend to try it again
| properly soon.
|
| [0] there is another editor that was mentioned here recently
| that can achieve this with a plugin, but I forget the name
|
| Update: Zed is that editor.
| veber-alex wrote:
| It's like phones with 120Hz displays.
|
| You don't know you need it but once you have it it's hard to go
| back.
| bloopernova wrote:
| Similarly with monitors, 60Hz LCD panels are OK, but 120Hz
| panels are just so much easier on the eyes. At least for me.
| Try dragging windows around or scrolling quickly, and you'll
| see the difference between 60 and 120 very fast.
| FpUser wrote:
| I can spot the difference but the value proposition is
| zilch to me. I would not pay 1 extra cent for it. If I was
| a gamer this would of course matter.
| serf wrote:
| if vs code felt as responsive as emacs or vim, i'd use it. I
| don't really care about 'start-up time', and if I did then
| using emacsclient or some such with a daemon takes care of that
| issue entirely.
|
| there is no convenient way for me to 'plug-in' the
| responsiveness of something like vim or emacs into vs code.
|
| to be clear : responsiveness is things like opening a context
| menu of any kind, switching contexts, text drawing and blanking
| ; just things that add up to create a quick feeling piece of
| software. vs code/atom/whatever and other 'larger' graphic-
| heavy text editors _feel slow_.
| myaccountonhn wrote:
| Yeah I find delays make me lose my train of thought and can be
| frustrating. Especially once you've experienced an editor where
| everything is instant (kakoune).
| xutopia wrote:
| If you pair program every ms counts. In video conference
| another half second does a huge hit.
| SCdF wrote:
| 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 obvious.
| It's just so much more pleasant. Like going from being hunched
| over a tiny laptop screen to sitting in front of an all
| encompassing ultrawide, or going from an old laptop to a new
| desktop.
|
| It doesn't mean that VSCode is an unusable pile of garbage,
| just as a tiny laptop screen isn't unusable. But the
| difference, at least to me, is undeniable.
| nox101 wrote:
| my machine must be faster than yours. I have both. I can't
| tell the difference
| lrhegeba wrote:
| i guess which and the number of extensions will have a
| significant effect on lag
| Bjartr wrote:
| Also, some people are just more sensitive to it than
| others.
| robin_reala wrote:
| Also, size of files. Less of an issue for typical
| codebases, but VS Code historically has slowed to a
| standstill on anything remotely large.
| nox101 wrote:
| I regularly work on a code base with 250k files. Haven't
| noticed any slowdown
| sebastiennight wrote:
| I think the comment you're replying to was blaming
| slowdowns on the size (in lines of code) of individual
| files, rather than the total size (in number of files) of
| the codebase.
| moritzwarhier wrote:
| In this case it's important to note though that this is a
| necessary side-effect of offering a powerful extension
| API. If you - for example - install some badly coded
| extension that blocks the main thread to parse the open
| file into an uncached AST on every keystroke _before_
| rendering the input, that 's the extensions fault.
|
| Take my example with an ounce of saltt as I've never
| coded a VSCode extension. It is very well possible that
| the extension API prevents this particular example. I
| guess normally things like parsing source files have to
| follow guardrails that prevent this kind of bug, or at
| least discourage coding this way. And ASTs are exposed by
| VSCode's core for the natively supported languages.
|
| Still, it's probably safe to assume that there is a lot
| of badly written code out there that does not pay
| attention to performance, or follows an "optimize-later"
| mindset.
|
| Features surely often seem tempting to implement in a
| slow and unoptimized way, and anyone can contribute to
| VSCode extensions.
| yjftsjthsd-h wrote:
| To be fair, that's always true; I've managed to make even
| vim stutter with the right extensions/configuration.
| amelius wrote:
| 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.
| samtheprogram wrote:
| Same, and despite this, Vim over SSH feels better than
| regular VSCode (assuming a decent internet connection).
| rpacut wrote:
| Ever tried the Remote-SSH plugin from Microsoft? With it
| I had the exact opposite experience, I'd regularly forget
| I was working on a remote dev machine!
| yjftsjthsd-h wrote:
| I was under the impression that the smallest time humans
| can perceive is like ~30ms, in which case 10 is effectively
| instantaneous
| Swizec wrote:
| VSCode is blazing fast on my 5 year old personal laptop.
| VSCode is frustratingly slow on my M2 work laptop full of
| corporate nannyware.
|
| It's not VSCode's fault ;)
|
| JS-based apps happen to interact terribly with nannyware for
| some reason. I see it every time I run one of our node
| services, everything just grinds to a halt while the
| antivirus freaks out about how dare I run a piece of
| uncompiled code.
|
| Slack and friends have the same problem. Discord actually
| runs better in a browser than as a standalone app.
| whizzter wrote:
| This probably needs far more attention than it's given.
|
| A half-wild guess here is that because viruses uses various
| ways to hide themselves the anti-virus software probably
| scans W^X codepages on changes, so anything JIT compiled
| (all modern JS engines) will trigger a lot of spurious
| scans (kinda like how compiling and writing .exe files can
| grind turnaround times to a halt).
| buzzerbetrayed wrote:
| > JS-based apps happen to interact terribly with nannyware
| for some reason
|
| I mean, yeah.. because they're slow and resource intensive.
| Your comment directly contradicts itself: It IS VSCodes
| fault.
|
| And BTW, it doesn't have anything to do with "nannyware".
| They slow down on any computer that is under the tiniest
| load.
| dan-allen wrote:
| I have exactly the same workflow: VSCode when I want a
| specific extension and Sublime as a fallback.
|
| I think a lot of people don't notice the difference but I
| can't un-notice it.
|
| Huge generated files and whatnot, VSCode just spins but
| Sublime opens them instantly.
|
| Not to knock VSCode: it's amazing what they've done
| especially comparing it to other web-stack apps (like what is
| Slack doing that it's slower than VSCode with 6 extensions
| running?!).
|
| Even when things are running smoothly, the just-perceptible
| delay in switching files or a slight stutter scrolling feels
| like the digital equivalent of working with a cheap tool.
|
| The cheap ratchet is a little sloppy and occasionally the
| pawl doesn't catch but it still does all the same stuff. Yet
| Snap-On still has customers.
| serial_dev wrote:
| 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.
| akdjidensb wrote:
| It's less about waiting for vscode to do something and more
| about the general feel and experience of movement and typing in
| the editor.
|
| "Speed" is probably the wrong word, it's latency that matters.
| pcthrowaway wrote:
| > Is the world really full of developers going crazy with
| frustration because they're waiting on vs code to do something?
|
| If programming in Rust on a medium-to-large project, you might
| be waiting minutes for your editor to finish checks to
| highlight compilation errors every time you save. That was me
| on a Rust project last year when I was trying to program on a
| 2019 macbook air with 16GB of RAM and 1.1 GHZ quad-core intel
| processor. Typical wait times to check what I'd written would
| be 30 seconds to just over a minute. It was excruciating.
|
| I finally demanded the employer set me up with a cloud VM that
| I could use when working with that codebase, as the network lag
| with VS code opening the project remotely was so much more
| tolerable
| Daeraxa wrote:
| I'm on the team working on Pulsar, the community fork of Atom.
| You have no idea how much we hear "Atom is slow", "are you
| making it fast?" etc. I have honestly yet to work out exactly
| what is meant by it. Startup times, sure, you are never going
| to get Pulsar/Atom or VSCode to launch as fast as a terminal
| editor or a super lightweight native one but that isn't how I
| personally use that kind of editor - once it is open it stays
| open for a long time. Keystrokes, context menus, highlighting
| performance, I honestly don't see where this perceived slowness
| is.
|
| I'm not saying it isn't valid criticism but I guess the way I
| work with an editor just isn't the same as others who
| experience this.
| maccard wrote:
| > Startup times, sure, you are never going to get Pulsar/Atom
| or VSCode to launch as fast as a terminal editor or a super
| lightweight native one
|
| Would you consider something like emacsclient's approach - a
| daemon running in the background that a window connects to?
| danielheath wrote:
| A few years back, someone built a webpage that had various text
| fields with different typing latencies.
|
| A bunch of my friends tried it, and it was really interesting
| to see that many of them were not bothered in the slightest by
| even quite high latency numbers.
|
| Personally, I was mildly bothered by the "single frame of
| latency" example and _intensely_ bothered by all the higher
| numbers. It just felt really yuck to use; I would hate to be
| doing that all day.
|
| I can't tell you what exactly it is, but yes: the world
| contains many developers going crazy with frustration - not
| because of a 30 second wait, but because of a 30ms render
| delay.
| giancarlostoro wrote:
| As someone who owns a Sublime Text license if its not an IDE it
| better be as fast as Sublime or im just going to use Sublime
| instead.
| nicoburns wrote:
| > Is the world really full of developers going crazy with
| frustration because they're waiting on vs code to do something?
|
| Absolutely. How new/fast is your developer machine? A lot of
| developers are working on computers that are several years old
| and may not have been that high-spec to begin with. It's
| generally not basic editing that's slow on it's own. It's
| trying to run several editor windows at once (say a frontend
| and several backend services) along with all the other things
| required for work: the project itself, compilers, video calls,
| etc.
|
| As a reference point my 2015 MacBook Pro struggled with VS Code
| + Google Meet at the same time.
| rplnt wrote:
| 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 it used to be.
|
| So yeah, I want to see the authors of any desktop software to
| address this modern problem of writing slow UI. Otherwise I
| might assume they don't care.
| jmrm wrote:
| Some people need to use at least one time in life IDEs like
| Visual Basic 6 in a Pentium 4 to feel what it's like to use a
| fast IDE
| pwython wrote:
| 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).
| camel_gopher wrote:
| Is it as fast as vim or emacs? If not then a tough sell from my
| view. Same with chewing up cpu cores.
| umanwizard wrote:
| Emacs is not known for being particularly fast.
| perrygeo wrote:
| It's not about speed in terms of absolute cumulative time. It's
| about the interleaving, the user experience of latency, and the
| effect that has on our cognition.
|
| A few ms of noticeable latency here and there, a few hundred ms
| freeze every once in a while, it's maybe an extra minute per
| day in clock time. If it was just a 1 minute startup penalty,
| that would be different. But this 60,000 ms is split up
| throughout the working day into hundreds of small pauses,
| making the system feel laggy and unpredictable. If you're
| lucky, it's merely a subconscious drag on your attention. If
| you're unlucky it will, have you constantly breaking
| concentration to wonder "is my editor frozen? Oh wait, never
| mind." Hundreds of times a day.
|
| Now contrast that to a text editor with literally zero
| instances of noticeable lag. It's not that it has zero latency,
| it's that the I/O latency on modern hardware is faster than our
| fingers and eyes can work. So we don't experience it.
|
| Hundreds of noticeable pauses versus zero pauses. Once you
| cross the threshold below which our fingers type and brain can
| read, you're lag free. Getting a faster text editor doesn't
| just slightly improve the lagginess, it completely solves it.
| Sytten wrote:
| I still don't understand how Zed or Lapse can build a viable
| business out of an OSS editor but at the same time there is an
| OSS VC funded Python linter so it's probably me.
| anton-107 wrote:
| getting acquired by a big tech who wants to catch up with
| Microsoft's dominance in developer tools is one possible out
| timeon wrote:
| As far as I know Lapce is not business.
| Daeraxa wrote:
| Absolutely, they won't even accept donations.
| behnamoh wrote:
| 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
| anton-107 wrote:
| Warp terminal comes to mind as well. But I believe they are
| just plain closed-source. What makes these projects fake open-
| source?
| Arch485 wrote:
| Can you elaborate on how this is "fake" open-source?
| flexagoon wrote:
| 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
| sushidev wrote:
| Please improve the UI before adding all the features of VSCODE
| but better :-) On a positive note, just to be sure I tried to run
| Eclipse - its UI is much worse. HN: please suggest open source
| code editor with great UI for MacOS.
| jasonjmcghee wrote:
| I try this editor every few months to see how it's progressing
| and is still way too early to use as a daily driver.
|
| People suggest this over Zed very frequently. In my experience
| Zed is way more mature and stable. That being said, it's no one
| near as usable as neovim with a good plugin setup, let alone a
| mature ide like Jetbrains products.
|
| Jetbrains IDEs might be slow, but I'll get a hell of a lot more
| done in 8 hours with it. Once you learn to use the features well,
| it's incredibly powerful. I love vim, but generally use
| jetbrains.
|
| If Jetbrains took 500ms to load a file vs 1ms to load, my
| productivity isn't going to change dramatically. It's fast
| enough. Yes initial indexing is slow, but it's easily worth it.
|
| All this being said, I think Lapce is very informative as a
| resource to anyone trying to build an editor in rust.
| manithree wrote:
| I've tried Lapce several times over the past year or 2, and
| have never gotten more than 5 minutes in without it hanging or
| crashing. I wish I was a rust programmer, but Lapce is not a
| good poster-child for the language, IMO.
|
| It's not the speed, or even the phoning home that make me rage-
| quit VSCode on the regular. It's the RAM. EVERYTHING slows down
| if you only have 24GB and try to use VSCode.
| Avicebron wrote:
| I'm not sure what the selling point is, not criticizing the
| product, but as an emacs user of some odd ten years, I feel like
| as soon as I open the page I should see _something_ that would
| entice me to switch.
| qudat wrote:
| "All the features of vs code but 'fast'" even though as you'll
| read in this thread, people are highly questioning that
| assertion.
| sph wrote:
| 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 been done before?
| stracer wrote:
| 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.
| oconnor663 wrote:
| 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.)
| flexagoon wrote:
| > with a more innovative editing model than vim's
|
| I think Helix tries to do that
| oorza wrote:
| Opened in macOS and it appears impossible to open a folder of any
| sort. I type the folder path into the Open Folder thing at the
| top and it just silently fails.
|
| There's no menu or anything to open a folder either. This seems
| lacking some _basic_ UX principles that should never be
| overlooked.
|
| I did eventually figure it out and the TS integration doesn't
| work at all. The file browser icons constantly and consistently
| do not render correctly.
|
| Guess this is something to check back in on in a year or three.
| It's a long way away from being complete, let alone usable.
| bemusedthrow75 wrote:
| > Opened in macOS and it appears impossible to open a folder of
| any sort. I type the folder path into the Open Folder thing at
| the top and it just silently fails.
|
| That sounds like it _could_ be Lapce failing to handle macOS
| full disk /folder security permissions (which you can grant in
| the System Preferences app)
| hollerith wrote:
| 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.
| dflock wrote:
| The nightly builds got word wrap a few weeks ago, not been
| released yet afaik, but will be in the next one.
| hollerith wrote:
| Thank you for letting me know! I will definitely be giving it
| a try!
|
| Can it wrap at column 80 or does it only wrap at the right
| border of the window?
| BoppreH wrote:
| 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+D to remove everything until the end of the line
|
| - `.` to repeat the last action
|
| It's a good start, and I'll definitely check it again in the
| future, but I'd hold on advertising "Vim-like" editing until the
| support gets better.
|
| The rest of the editor is awesome, no complaints so far.
| bradly wrote:
| > Shift+U to undo all changes done to the current line
|
| Been using Vim for over 15 years and didn't know this one.
| pandemic_region wrote:
| I know right!
| LorenDB wrote:
| It's refreshing to see a new IDE that isn't using Electron. Yes,
| I know Zed is native as well, but it only is macOS compatible,
| and I use Linux.
|
| I am using Qt Creator, and it is absolutely amazing for C++/CMake
| based development, but I will have to give Lapce a try and see
| how it stacks up.
| lchen_hn wrote:
| What's the benefit for a neovim user? Meaning I already got LSP,
| treesitter, it works in a terminal. I cannot think of a reason to
| even try this.
| zozbot234 wrote:
| With neovim you're still dependent on plugins written in some
| scripting language, and their overhead can add up. Lapce
| plugins are compiled to WASM/WASI, so they should run a bit
| smoother.
| eikenberry wrote:
| Lua is not some random scripting language, it is designed for
| embedding and is very fast with minimal overhead. I'm not
| saying that using WAS* is bad but bashing Neovim when it uses
| the one of the best proven technologies for extension is just
| silly.
| warthog wrote:
| 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
| SubiculumCode wrote:
| does cursor.so allow use of local llms?
| flexagoon wrote:
| Why not just use basically any editor with codeium.com?
| smhaziq wrote:
| It consume 2GB of memory to load a typescript codebase. VSC just
| need 600MB of memory to load the same codebase.
| meet_squad wrote:
| Who knew that the existential crisis of the modern developer
| would be choosing between milliseconds of latency and the perfect
| shade of syntax highlighting :)
| andrepd wrote:
| Might be some ocd type of stuff or just people being different,
| but yeah those milliseconds of latency absolutely _do_ get in
| my nerves.
| k_bx wrote:
| Given that the plugins are written in Rust, how does it
| dynamically load/use them? Is there a good description?
| lilyball wrote:
| The plugins use WebAssembly.
| jollyoldpirate wrote:
| I remember the old days of using tinyIRC which boasted that it
| was hand-written in assembly. And indeed, it was great to use.
| But there's nothing really notable about any of this today when
| so many editors are flexing speed. Two weeks can't go by without
| a new editor coming out. I'm still on VS Code after ST shit the
| bed.
| tempodox wrote:
| I could use a decent Rust IDE. I can't believe I'm saying this,
| but the VSCode plugin for Rust seems to be the best there is at
| the moment, way better than the JetBrains plugin. This cannot be
| the last word on that.
| dzhou121 wrote:
| 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 community developed. But still, GUI is
| just such a beast of complexity, which consumes lots of time and
| energy which we already lack. That said, we had developed our own
| cross platform GUI toolkit called Floem, because as you may know
| there aren't any good ones that exist.
|
| The journey was fun and challenging, but the aim of the project
| isn't a toy, and we believe by taking slow but firm steps, we'll
| reach production quality, one day. Before that, please do bear
| with us, and help us if you can (as in code).
| nicoburns wrote:
| Just wanted to stick a link the Floem GUI toolkit mentioned
| above:
|
| https://github.com/lapce/floem
|
| because IMO it's as interesting as Lapce in it's own right.
| roarcher wrote:
| Don't apologize! It's not like you've taken anyone's money. HN
| can be a tough audience, but I don't see any (serious) comments
| that are putting down what you've done--just pointing out
| issues they personally experienced. I posted one myself.
| Informal bug reports.
|
| Honestly this is about what I'd expect from pre-alpha software,
| though I do agree with other commenters that that label should
| be more prominent on the website to manage expectations.
|
| Taking on something like VS Code as a competitor is ambitious,
| as is building a native UI library from scratch. Personally I
| applaud your effort and I hope this project succeeds.
| jmrm wrote:
| 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
| mark_l_watson wrote:
| Looks like it doesn't support Lisp languages?
|
| I like the idea of natively compiled editors - fast!
|
| For two days, I have been using the Lem editor written in Common
| Lisp, super fast and responsive.
| skykooler wrote:
| On Manjaro I opened it and it stuttered for a bit and then
| crashed my entire desktop to a TTY. I get that it's pre-alpha but
| I was not expecting it to be _that_ unstable.
| denysvitali wrote:
| To be honest, if an application manages to crash your whole
| Window Manager, I don't think it's the fault of the application
| dang wrote:
| _Lapce: Fast and Powerful Code Editor Written in Rust_ -
| https://news.ycombinator.com/item?id=38796524 - Dec 2023 (63
| comments)
|
| _Lapce Editor 0.3_ -
| https://news.ycombinator.com/item?id=38262775 - Nov 2023 (98
| comments)
|
| _Lapce - A code editor with LSP and DAP support_ -
| https://news.ycombinator.com/item?id=38100570 - Nov 2023 (2
| comments)
|
| _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)
___________________________________________________________________
(page generated 2024-02-18 23:01 UTC)