I think the heat you're getting here is from the very slick website that makes Lapce look more finished than it is. It might be a good idea to adjust the text to manage people's expectations.
Great job!
Anything like this that progresses the cross-platform remote model that we now have with VSC, particularly if the endpoint is fast and memory-efficient, is really important, because of the variety of dev environments.
What I would _really_ like, of course, is an iPad editor that could do the same.
If you could make an iPad editor that has VSC-style remoting, that is genuinely a killer app right now for a lot of people.
That would be "just enough" editor for me so I could travel for a few days and still do a couple of hours of work here and there, without the laptop commitment.
I am not big on iOS subscription apps and I'm budget-constrained, but I'd pay $50 per year (probably more, and I figure I wouldn't be alone), without hesitation, for a fast remoting iOS editor that had 80% of the functionality of VSCode Remote and had a viable built in browser to avoid the process switch.
The code-server project definitely works for this, but something a bit more native would be amazing.
(code-server is basically the open source parts of this from what I understand, and the back-end impact is really no different at all, except needing to open a port for the web interface.)
I'm not sure whether vscode.dev will be able to connect to my own remotes yet; need to test that!
The main problem is as far as I am aware the same; the browser-side connection can drop quite easily because of the limits of iOS (you can't switch away without losing it).
That is obviously not something even a native version of Lapce would be able to totally avoid, but an iOS native app might have a few more strategies for maintaining background remote connections for a little while (SSH apps do for example).
But Visual Studio Code's remote thing really is on another level -- you can do things like run the git session remotely but with the GUI-side tools, do find and replace on the remote side; all the extensions (PHP syntax stuff etc.) install and run on the remote side as well as they do locally etc.; it's almost completely seamless.
EDIT: aha, just saw this, downthread:
> "The main problem is as far as I am aware the same; the browser-side connection can drop quite easily because of the limits of iOS (you can't switch away without losing it)."
The other way round -- an in-editor browser -- could be the better way to work. GoCoEdit does this (and it really is rather good!) as does Panic's Code Editor (formerly Coda for iOS), which is good, but not as good. And you arguably get a terminal more easily this way too, particularly where SSH keys are involved.
It will, it's in the DNA. L comes before P.
> " L comes before P."
?
I.e. Lightning-fast comes before Powerful.
slainte!
Some things I'm really excited for: - Remote development as a first-class citizen! I use code-server a ton now, but getting away from browser jank would be nice. - In the future I wonder if something besides SSH would work for the connection. SSH doesn't handle bad connections or closing a laptop and moving very well. I use wireguard to connect to my code-server instance right now and it's pretty close to feeling like I develop locally. - Lighter and faster. Why does my laptop always have to be burning... - A more FOSS ecosystem. VS Code is "open source" but not really in practice. Some important extensions (from Microsoft) have non-foss licenses and the standard distribution is built with non-foss tidbits. There are projects like Codium that rectify these issues to some degree.
I don't know how people text edit without the vim keybindings. I'll never go back!
Switched to vim, and the tendonitis resolved itself in about two months. That was back around 1990.
I wonder if you've considered kakoune style modal editing rather than vim? If you've not come across it, it might be worth looking at, as I think it's a better paradigm and one that I expect will go nicely with the multiple cursors you're working on.
I like that this is native though. VS Code is one of the rare good electron apps but native is still nicer IMO. Will give it a try.
I don't know if it's fixed now. Previously when I was using VSCode, sometimes the "go to definition" hangs and it will freeze the whole editor, which was unacceptable. So in Lapce, nothing blocks the main thread other than your key press.
is EOL and should be treated as such.
Windows 7 EOL was 2 years ago though. (I know it's the last version of Windows that isn't an add-bloated spyware but still)
https://www.microsoft.com/en-US/windows/windows-7-end-of-lif...
> I'm currently working on the missing pieces, like multi cursor support(in master but not released yet), mouse support, sane default key bindings(probably I'll stick to an existing editor), basic UX etc.
Website claims "Native GUI" but this is not native GUI. I'd rather have basic UX before multi cursor or anything else nice to have but totally optional things. On Windows open dialog is broken, you can't select drives, you have to enter the drive letter manually, but in input field delete key is not working. That's as far as I got trying it out.
I was wondering if you were learning Rust and decided that you needed a project to reinforce your learning? Or you were designing and editor and decided you should do it in Rust?
And my recent professional work was writing Rust, and I felt Rust would be really suitable for my editor.
As it should be. Well done.
A Flatpak may have to ship with an independent copy of a lot of basic developer tools, and even then I don't know whether I want two different versions of git access the same local repository with a chance of incompatible repository formats.
FWIW I was recently able to get a "passable" but not ideal Rust/LSP/Rust-Analyzer/Cargo setup mostly functional via use of the kate build plugin and e.g `flatpak-spawn --host cargo build`...
...and... `flatpak-spawn --host cargo run | sed --unbuffered 's/\x1b\[[0-9;]*m//g'`.
Excuse the cough. :D (It was necessary to remove the ANSI colour codes produced by some logging library the project used.)
(My preference would be to use AppImage but unfortunately recent Kate AppImage versions have a hang-on exit bug.)
https://docs.flatpak.org/en/latest/introduction.html#reasons...
> Flathub only hosts stable application releases, and not development snapshots.
from https://github.com/flathub/flathub/wiki/App-Submission
> If there’s an app that you'd like to be distributed on Flathub, the best first course of action is to approach the app’s developers and ask them to submit it. Remember that for some projects or communities, this may be the first that they have heard of the Flatpak technology or interacted with somebody who advocates it.
Also from the above link.
Anyway, development-wise these are minor issues in a project of this size. Nice work!
Yeah, unfortunately it seems like there's a (possibly recently introduced?) bug that appears to break arrow-key/list interactions.
I was able to get code completion & command palettes to work by supplying a custom keymap I posted here: https://github.com/lapce/lapce/issues/133#issuecomment-10715...
My impression is that the non-modal keymap isn't as regularly updated given the developer's preference for modal interaction. I'm happy enough I can at least still edit the keymap to workaround the issue. :D
I'm aware that Lapce lacks lots of basic stuff. It's a personal project so the initial set of features and key bindings are tight to my personal preferences.
I'm currently working on the missing pieces, like multi cursor support(in master but not released yet), mouse support, sane default key bindings(probably I'll stick to an existing editor), basic UX etc.
Feel free to submit a feature request or bug report in Github Issues or leave your feedback here.