Live data from Hacker News

Zas Editor

zeditor.app

321–330 of 362 posts

Re: Zas Editor

#321

Earlier quoted context omitted.

It's still possible to ship cross-platform native software. People just pretend like it doesn't exist because it's too hard, and so I respond by pretending like their software doesn't exist.

What's the correct way to ship cross platform native software that doesn't require me to write it in C or C++?

Depends on how much compromise you want.

For minimal compromise, you'd write it in Rust/C/C++ with a GUI toolkit that leverages the native stylesheet to render everything out. It'll be fast, it will run cross-platform, and it will take forever to build. However, this is the """right""" way to do it, and the one that people will complain least about. There's a number of tools that are distributed this way, but again, it's a pain.

For medium compromise, you'd probably end up with a runtime like Java or dotnet. These runtimes have well-established, long-running GUI projects that seek to tackle this exact issue, and for most people they balance ease of development, speed and "good enough" UI. It's not perfect, but a lot of one-man dev teams will end up choosing this when they want to get on every platform with a native-enough UI.

For maximum compromise, you can ship Electron with JS bindings to a native UI. This sucks. Please don't do this. It's an option though, and I'd be remiss if I didn't mention it. It's barely better than just putting a website in a desktop runtime, and if you aren't careful you can end up making it a whole lot worse.

It's definitely possible to do, though. If you want to charge money for your application, I should hope you're building a minimal-compromise program.

Re: Zas Editor

#322
post #4

Hi everyone! I'm the lead developer of Zas Editor. I wanted to share some details about the editor you might be interested in. The text-storage data structure, syntax highlighting and search features are written in Rust, and the UI is written in Swift since we wanted to create a native macOS experience. The Swift and Rust code talk to each other using C FFI, and no, that doesn’t take away the safety features of both…

Any plans to support other languages, specifically Zig? It would be nice if it even just supported wiring in any LSP like Sublime Text LSP and Neovim LSP do.

Re: Zas Editor

#323

Earlier quoted context omitted.

Once you've learn vim keybinds and combinations, nothing comes close for productivity.

Once you've learned vim why do you care if any other editor has vim bindings? What can you do with vim-mode ZasEditor that you couldn't do in vim?

One has a choice between learning enough about Vim to replicate arbitrary workflows/functionality in it, or using other softwares that do those things out of the box and clicking the "Vim mode" check box in the settings.

Both are perfectly valid, but they are going to appeal to different kinds of people, with different priorities.

Re: Zas Editor

#324
When I see these kind of super-polished UIs, I wonder why can't we have that in Windows? Or Linux, for that matter, but I get the why on Linux.

GUIs are so much better in Mac, it's not even close. What's stopping Microsoft from getting closer?

Re: Zas Editor

#325
post #205

Earlier quoted context omitted.

> my rust/LSP experience with Emacs doesn't hold 5 seconds in front of what I've just seen on the Zas website My preferred way of working after 20+ years in the industry, is finding the "best tool" for the job. Vim is my "goto" editor for everything that doesn't have a better tool, but any perceived performance gain from being familiar with an editor needs to be compared to the performance gains of using the speciali…

My 35+ years experience (ah ah!) tells me that emacs is the best :-) Just kidding... I code small stuff nowadays, so emacs is just fine. But if I had to get into something big, I'd certainly use a tool with powerful and fast code navigation, and something that works out of the box. LSP mode on emacs is not easy to set up. I mean, you can get it 90% working in 15 minutes, sure, but then come the little things such as:…

I think it depends on the language server - metals for Scala, jdtls for Java, pyright for python,jstls for Javascript/Typescript and omnisharp-roslyn for c# are all pretty good. Cold startup time for lsp servers in bigger languages (scala/java/c#) are akin to IntelliJ/Rider import times.

I don't have all the same refactorings as intellij, but then I don't have to pay a license to edit c# code, either. Most people that I watch use IntelliJ don't use it to its fullest extent. I will open it to pair with other IntelliJ users. But I'm faster in emacs. I've also used it professionally for almost twenty years. To get me to switch an ide would have to be as extensible, keyboard centric, cheap (both free and in terms of memory usage), and portable (across platforms and languages) as emacs has been.

That's a tall order.

Re: Zas Editor

#326

Earlier quoted context omitted.

Once you've learn vim keybinds and combinations, nothing comes close for productivity.

Once you've learned vim why do you care if any other editor has vim bindings? What can you do with vim-mode ZasEditor that you couldn't do in vim?

* pairing/mobing with people who are more familiar with their IDE

* Believe it or not, there are things no vim plugin can do, for example rendering mardown, which Viscose has lots of plugins for that work well

Re: Zas Editor

#327

A lot of this is possible in Xcode, but kudos to the team for packaging everything so nicely in this editor, and there are a few standout features I haven’t seen in other editors/IDEs: - multifind - find in all enums (declaration/structure-specific search) - the “minimap” Like another poster said, just the few niche functions alone would be a cool acquisition target for Apple. I’d love to see the best/unique parts of…

minimap exists in Xcode but it's not quite the same. It only shows `// MARK: ` comments.

Would love for Xcode to have more language support. Maybe an lsp client.

Re: Zas Editor

#328

Earlier quoted context omitted.

This just shows how important first impression is, and how difficult it is to rebuild trust after that. Asking people to delete their comments/reviews is not a good approach.

You can't expect everyone to have perfect judgement on the first go. They admitted a mistake openly, and they're simply asking for that to be reflected in a top comment. Otherwise what's the point of admitting a mistake if few people notice it's been amended?

I’m not saying not to admit a mistake. I’m saying that such a trivial mistake should not have happened in the first place. Who’d have known that people might have several Macs and would want to use a code editor on several of them?

Re: Zas Editor

#329

Earlier quoted context omitted.

It's 2022 and still shipping [insert platform here]-only binaries?

If you want performance, then yes. Shoo! Go back to Electron!

On my laptop, in a VM even, VSCode is fast, hasn't been an issue. I'm surprised "everyone" complains

(But VSCode's search functionality is annoying! Here Zas looks lovely ... But, Mac, so, no)

Re: Zas Editor

#330
post #33
post #11

Earlier quoted context omitted.

You might want to put supported languages more front and center and not buried on a hard-to-find faq page. Might also want to allow folks to sign up to be alerted when their favorite language is supported, which will also let you gather data about where there's the most interest.

Thank you for the feedback. We made a change to the landing page, it should be more clear what languages are supported now. The first sentence now is "A new, capable, and fast code editor for Go and Rust, focused on both reading and writing code". A signup is missing, but you can follow us on Twitter @ZasEditor in the meanwhile.

And it'd be nice to get notified if: It starts working on Linux, and it becomes open source or source-available. (Having to pay for it is fine :-) of course)
Post reply on HN