[HN Gopher] Pulsar - A Community-Led Hyper-Hackable Text Editor
___________________________________________________________________
Pulsar - A Community-Led Hyper-Hackable Text Editor
Author : philonoist
Score : 107 points
Date : 2023-02-24 14:49 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| asah wrote:
| Does Pulsar support terminals over SSH? The reason I (only) use
| emacs and vi, is that they're available *everywhere* and work in
| literally every environment.
| animuchan wrote:
| This is a fork of Atom, right?
|
| It's funny the README doesn't mention it.
| leapon wrote:
| It is mentioned in the About Us page.
|
| The team behind Pulsar is a community that came about naturally
| after the announcement of Atom's Sunset and decided that they
| needed to do something about it to keep their favorite editor
| alive.
| rwalle wrote:
| Your comment is almost irrelevant to the original post. It's
| not in README which is what most people look at. I never look
| at "about us" unless I am _really_ interested in what 's
| going on. And this is just very strange when the entire
| foundation of the code is based on another project but they
| don't mention it in a visible way.
| Daeraxa wrote:
| Honestly we thought we had covered it enough without flying
| too close to any trademark misuse claims from GitHub but it
| appears not so we are going to look at seeing what we can
| do to make it more obvious.
|
| Edit - Have another look, we edited the readme to make it
| more obvious. The readme is due a massive branding overhaul
| but hopefully this addresses the immediate concern.
| untech wrote:
| It's a rebranded Atom, which was sunsetted recently.
| benrutter wrote:
| This is the community attempt to continue / revive atom right?
| Interesting that atom doesn't really get mentioned in the docs
| anymore- hopefully a sign that it's finding its feet and
| direction as a project in its own right.
| i_am_proteus wrote:
| From the about page of their web site (https://pulsar-
| edit.dev/about.html):
|
| "The team behind Pulsar is a community that came about
| naturally after the announcement of Atom's Sunset and decided
| that they needed to do something about it to keep their
| favorite editor alive. This is a true community-led project to
| modernize, update and improve the original Atom project into a
| contemporary, hackable and fully open editor."
| rwalle wrote:
| I don't think that's enough. It's not mentioned in github
| repository README. I actually thought this is a brand new
| editor until someone pointed out this is a fork of Atom. I
| have browsed at least hundreds of open source repositories
| and this stands out as very strange.
| Daeraxa wrote:
| We have it in a bunch of places around the GH org
| (literally the first two lines on the org readme), docs and
| blog posts. In no way do we want to hide it but we also
| made a decision that we didn't want any trademark disputes
| from GitHub's lawyers from misusing their Atom trademark
| anywhere. We very much acknowledge the Atom legacy
| (including hosting the full original Atom flight manual
| before the website went down alongside the rebranded docs).
|
| Edit - We have updated the main repo readme with the info
| to hopefully address some of these concerns
| capableweb wrote:
| I don't know, seems a bit weird not to mention Atom at all. At
| least "This project was forked from Atom" or whatever.
|
| Besides it being nice, it's also a requirement of the Atom
| license, that the copyright and license notices are preserved.
| Seems the only mention of their heritage is "Original work
| copyright (c) 2011-2022 GitHub Inc." in the LICENSE file but
| again, no mention of Atom.
| codetrotter wrote:
| The license in the original Atom repository
| https://github.com/atom/atom/blob/master/LICENSE.md has the
| following copyright notice:
|
| > Copyright (c) 2011-2022 GitHub Inc.
|
| IANAL but the terms of the MIT license says:
|
| > [...]
|
| > The above copyright notice and this permission notice shall
| be included in all copies or substantial portions of the
| Software.
|
| > [...]
|
| And they did preserve it all.
|
| https://github.com/pulsar-edit/pulsar/blob/master/LICENSE.md
|
| So IMO, they are pretty much fulfilling the requirements of
| the MIT license it looks like.
|
| Depends on whether the copyright notice and license is also
| presented somewhere (such as under the About menu) in
| distributed copies of the modified program as well. But I
| have no interest in installing Pulsar just to see if they do
| that or not.
| Daeraxa wrote:
| The LICENSE.md file in the root of the Pulsar repo is
| indeed available in the application under Help > View
| License.
| xpe wrote:
| Just a guess: perhaps GitHub prefers the credit? It depends
| who controls the Atom name I'd think.
| capableweb wrote:
| Shouldn't matter "who" prefers the credit, the project is a
| fork from Atom and should be mentioned as such. Right now,
| going to the website or the repository makes it seem like a
| brand new editor, which it is clearly not, but not so clear
| based on what information they willingly provide you with.
| [deleted]
| xpe wrote:
| I mostly agree. Still, project / owner names (as written
| in licenses) can change. So the entity in control makes
| the call, I would think.
| moremetadata wrote:
| Hasnt got a "scrollbar map" (known as MapMode[1] in Visual
| Studio), making it harder to navigate large chunks of code.
|
| [1] https://learn.microsoft.com/en-us/visualstudio/ide/how-to-
| tr...
| Daeraxa wrote:
| There is the Minimap community package which is one of the most
| installed ones. https://web.pulsar-edit.dev/packages/minimap
| ericyd wrote:
| 32% CoffeeScript is a _very_ interesting choice in 2023
| Daeraxa wrote:
| Working on bringing it down via the process of
| "decaffeination". Unfortunately this is Atom's legacy and not
| our doing.
| coldblues wrote:
| Atom was unbelievably slow. How will the performance be improved?
| Visual Studio Code somehow managed to surpass the awful Electron
| performance just enough to make it usable, and it's pretty
| unbelievable this project will come close to that.
| rcme wrote:
| I would interested in understanding how VS Code overcame these
| limitations. Did the VS Code team ever do a write-up anywhere?
| yencabulator wrote:
| You might enjoy https://news.ycombinator.com/item?id=11940043
| rcme wrote:
| That was very enjoyable. I think the tldr is that they use
| custom scrolling via translate3d, limit any computation on
| the file to just the visible lines, and they split the text
| into lines with regex to leverage native loops instead of
| trying to split the next manually via JS. Mono-spaced font
| probably makes this problem a lot easier as measuring text
| is pretty trivial.
| qbasic_forever wrote:
| Why couldn't they take the optimizations from vs code and
| integrate them? VS code is open source, it's only their
| proprietary extensions like remote dev that aren't open.
|
| I remember Atom in its later releases had significantly
| improved performance to the point I never noticed problems.
| bobajeff wrote:
| Looking at both projects vscode uses typescript heavily while
| this project mainly uses coffeescript. So that might be a
| hindrance. So I guess that might be part of it.
| Daeraxa wrote:
| We are actually looking to "decaffeinate" back to vanilla
| JavaScript. Unfortunately there is rather a lot of it still
| even after the Atom team's attempt to remove some of it.
| swatcoder wrote:
| For those who want fast and lightweight without falling all the
| way back to emacs/vim, I'm really digging Lite-XL.
|
| Lua for customization, thin accelerated rendering layer in
| SDL2+freetype, zero nonsense. Binary packages are like 2MB. The
| code itself is clean and readable.
|
| The plugin collection is still young and won't have everything
| you'd find in the Electron-family of editors, but that's also a
| plus when it comes to it staying lightweight and streamlined
| like some might want in these tools.
| jorvi wrote:
| No need to fall back to Vim, Sublime has stellar performance
| already.
| sourcecodeplz wrote:
| Have used: dreamweaver, vi, nano, notepad, ++, atom and
| sublime.
|
| Sublime so soo superior, it's not even fair. Haven't tried
| vscode but I understand it's a resource hog.
| ricardobeat wrote:
| I reluctantly switched from Sublime Text to VSCode about
| four years ago, but now it's simply unimaginable to go
| back. It's heavier, but fast enough to have four or five
| different workspaces open, in very large projects. The
| language support, intellisense, and plug-in ecosystem are
| miles ahead.
| bobajeff wrote:
| I'm curious as to why that is. I would think it's LSP
| support would close the gap on languages (and
| intellisense) at least.
| FunnyLookinHat wrote:
| Sublime performance can't be beat, but I'm seeing the end
| of the road for active plugin development. It's getting
| harder and harder to adopt new tools without farting around
| with configs all day.
|
| At least, this was my experience trying to get Deno
| development to feel "right". It feels like vim and VSCode
| are the platforms that get plugin support nowadays, and the
| rest are a hack.
| khimaros wrote:
| i'm keeping my eye on https://github.com/lapce/lapce
| khimaros wrote:
| native frontend (Rust/druid), LSP support, tree sitter
| syntax highlighting, command pallette, vim key bindings,
| modal editing, plugins in any language with WASI target,
| remote development, community led, open source plugin
| registry, it checks a lot if boxes. https://lapce.dev
| admax88qqq wrote:
| Electron is rarely the cause of performance problems itself.
| It's more that JavaScript makes it really easy to write slow
| memory bloated code. But it's possible to write really fast and
| efficient apps in JS.
|
| There are a few fundamental limitations with web/js. No shared
| memory concurrency, no reasonable storage layer, no integer
| types. Those can make some things hard to make performant but
| most apps I see are not limited by this.
|
| Most apps are slow due to a few common mistakes.
|
| - React/Anglular diff based rendering cycle.
|
| - Garbage collection due to careless allocation of objects in
| tight loops.
|
| - Poor client side data models, resulting in blocking on the
| network for simple things.
|
| - Careless use of the bad storage abstractions (bleh indexeddb)
| which requires copying data for every operation leading to GC
| pressure and wasted CPU.
|
| - V8 is a moving target in what it chooses to optimize well and
| what it fails to optimize.
|
| tl;dr fast electron apps are possible but the platform makes it
| easy to write slow apps by default.
| thatxliner wrote:
| For starters, I'm pretty sure their focused on updating the
| project and dependencies.
| hyperhopper wrote:
| Why is everybody building on top of electron (slow and bloated)
| instead of emacs or even vim?
|
| We don't need a new editor. Just make a spacemacs layer or doom
| plug-in.
| bstar77 wrote:
| I'm done with these JS/Electron editors. They are Ok (for the
| most part), but using Neovim in 2023 is such a huge step above
| everything else if you have the inclination to learn it. I'm
| integrating my workflow into Nixos and it's pretty incredible
| what is possible if you constrain your development to the
| terminal.
| heliostatic wrote:
| It's interesting to see this coming out of the atom community.
| I've been really impressed with Zed (https://zed.dev/) which is
| from the original atom folks and focused on speed and
| collaboration. Rapid improvements since initial launch.
| xd1936 wrote:
| This looks fantastic! Read through the homepage, clicked the
| "Download" button in the footer, page 404s. Joined the
| waitlist! We'll see.
| smodo wrote:
| I've been using Zed for a couple of months. It has replaced
| eMacs and VSCode for writing Rust. The integration is so well
| done, it's like a constant conversation with the compiler. I've
| got ten invites by the way.
|
| One thing I worry about a little is the business model. They
| want to target teams and charge for the cooperative features.
| But as a single user I'd love a way to just buy a lifetime
| license and feel that I can expect at least five years of use.
| I don't like when software I love treats me like a casual
| fling.
| return_to_monke wrote:
| the big question: is it going to be open source, tho?
| nextaccountic wrote:
| It's kind of maddening that both VSCode's remote dev
| extension AND Zed (which aims to be better than VSCode) AND
| JetBrains's remote dev AND repl.it AND <some other stuff> are
| all closed source.
|
| What's the state of art open source
| editor/extension/protocol/whatever that enables two or more
| persons work on the same open files in real time? Something
| better than the ssh access which forces one person to work at
| time, then save, then the other person reloads.
| hyperhopper wrote:
| ssh then attach to a tmux session
| nextaccountic wrote:
| Okay this works, but how's the latency?
|
| Can this made to work with a GUI editor? Like neovide or
| emacs but in X11/wayland not tty
| gaetgu wrote:
| Speaking with some of the devs, yes (asterisk). From what I
| understand, they are working out what they can open source
| while also retaining the ability to make money from the
| editor (mostly from the collaboration features)
| capableweb wrote:
| Care to share a binary or some other project that is actually
| beyond a closed alpha? Otherwise not a lot of point in sharing
| it as an alternative, it's not available to the public.
|
| Edit: signed up for the waiting list and received "Zed
| currently only targets macOS" so sounds like they only target
| ~10% of the actual market. Interesting strategy.
| odo1242 wrote:
| The strategy is that native macOS UIs are generally easier to
| develop than native Windows UIs, so they're trying to iterate
| on that platform first.
| saagarjha wrote:
| Isn't the whole selling point behind their thing that they
| _don't_ use the native macOS UIs but instead send
| everything to the GPU?
| capableweb wrote:
| If they're building a native macOS UI, how is it ever
| possible it'll be worthwhile to port that into native
| Windows UI or "native" Linux UI? If you wanna go cross-
| platform, you usually consider that from the start, not
| once you're 50% done, as you're gonna have to redo a lot of
| work you could have gotten "for free".
| imbnwa wrote:
| Arc browser is also doing this, and they're planning on
| debuting the Windows UI in Fall.
| EthicalSimilar wrote:
| The "engine" itself is likely cross-platform, with
| vendor-specific UIs.
|
| It's likely quicker to develop for a single OS and then
| build the additional UIs with a more feature-complete
| app.
| heliostatic wrote:
| I've got invites (and am not otherwise affiliated with the
| project) if you want to test it out. Username @ Gmail works.
| unsober_sailor wrote:
| If you have another invite to spare, I'd be very grateful
| to accept one! Email is: spidershred01@gmail.com
| capableweb wrote:
| If it's still Mac only, I don't have any real use for it,
| can only use editors that works across Windows, Linux and
| macOS, otherwise there is no real point in me trying them
| out :/ But I thank you for the offer, might reach out in
| the future if I hear it's available on more platforms.
| ab18 wrote:
| Send one my way - ashishbhatiya18@gmail.com
| meanmrmustard92 wrote:
| Folks who know Pulsar and Zed internals: which one of them is
| more likely to gain support for Atom packages? I find Hydrogen[1]
| invaluable as a data science scratchpad since it supports
| python/r/julia/etc under a common interface via jupyter, and have
| been unable to construct a comparable workflow in vscode or any
| other editor [using scripts as opposed to notebooks, which i find
| far too bloated].
|
| [1]: https://github.com/nteract/hydrogen
| Daeraxa wrote:
| Pulsar already supports (nearly _) all the Atom packages and
| has a brand new backend reverse engineered from the closed
| source Atom.io packages backend. I think it is unlikely you
| will get any Atom support in Zed any time soon.
|
| _ Some packages had to be removed due to incompatible licenses
| JaggerJo wrote:
| pass, because it's electron.
| ZitchDog wrote:
| I haven't read the docs lately but when I was hacking on Atom
| years ago, the plugin model was TOO freeform, and with plugins
| all running on the main thread, it was easy for a plugin to kill
| performance and slow down the editor. The vscode model strikes a
| better tradeoff between extensibility and performance. Extensions
| have less power but my editing experience is never ruined by a
| rogue extension.
| neurobashing wrote:
| One of the last things I remember about Atom was that by the
| time they'd figured out all the stuff they needed to fix,
| VSCode had come in and stolen all the eyeballs, so to speak. So
| they have a good roadmap, they just need to do the
| implementation.
| 29athrowaway wrote:
| > "Built on Electron"
|
| No, thanks.
|
| This one on the other hand, looks very promising
|
| https://lapce.dev/
| rwalle wrote:
| I am willing to bet $100 this thing never becomes mainstream
| based on my 2 decade software dev experience.
| 29athrowaway wrote:
| Like Atom after VS Code
| IncRnd wrote:
| Atom was introduced prior to VS Code. VS Code reuses
| electron as a framework, which was written for Atom
| (originally called electron shell).
| capableweb wrote:
| Bah, that's too easy. You can say that about 100% of all
| projects that hit HN and you'll be right 90% (or more) of the
| time.
|
| Save your comment for when you believe the opposite (that
| something for sure will become mainstream), that's when it
| gets interesting.
| haolez wrote:
| I've tried it out of curiosity and it's extremely unstable so
| far. Barely runs on my Linux box and couldn't get it to run
| without crashing on Windows.
| xrayarx wrote:
| Lapce, which is written in rust, is using Druid, which is
| discontinued.
| b1ue64 wrote:
| They're using their own fork:
| https://github.com/lapce/lapce/issues/2177
| imbnwa wrote:
| No wonder my Rust GUIs have long-standing display bugs, e.g.
| Neovide (neovim GUI frontend), Psst (Spotify GUI client)
| NoraCodes wrote:
| I'm enjoying the explosion in editor software going on right now.
| Even if most of them don't survive or gain a large audience, I'm
| sure the cross-pollination of ideas will lead to some great
| improvements in those that do.
| hackrnusr wrote:
| It would be nice to know what this offers that emacs doesn't
| already ... other than it being built on a more modern GUI
| framework (Electron).
| pasquinelli wrote:
| your comment makes me think:
|
| emacs already does everything-- no tool is ever going to do
| more than emacs (before you say it, i know this isn't
| literally true.)
|
| so when i already have a tool that does everything (actually
| multiple tools), what might i want in a different tool? to
| extend the metaphor of a tool: i'd want a tool that feels
| better in my hand, or a tool that does a specific job very
| well, or a tool that can fit better into tight and awkward
| spaces, or a tool that works by a different principle, or
| just a more beautiful specimen of the same tool that does
| everything. or maybe i'd want a different tool for one of the
| many reasons i'm sure i haven't thought of.
|
| just some stray thoughts, nothing original, but it makes me
| realize that i'm always looking for tools that work on a
| different principle to the ones i've got, and that's never
| occurred to me before now.
| imiric wrote:
| A new tool can certainly do things better. Emacs has many
| quirks, that are partly because of its age, and partly
| because it needs to remain compatible with its extensive
| ecosystem. A new editor that, for example, prioritizes
| performance, while not sacrificing extensibility, and maybe
| does it in a more mainstream language, could always start
| small and eventually gain traction.
| 0thgen wrote:
| I think it'll be a long time before something replaces emacs
| given that emacs is extremely niche and most text editors
| don't seem to be after the vim/emacs market
| thatxliner wrote:
| The whole point of it was being as customizable as Emacs, but
| easy to do with JavaScript.
___________________________________________________________________
(page generated 2023-02-26 23:01 UTC)