Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Zed Package Manager #90
Package Manager that's mostly done. Main thing it needs is documentation. Examples of extensions can be found here: https://github.com/TheKiteEatingTree/zed-extensions
To install those extensions you have to use the raw.github urls:
A few things I'm unsure about:
First of all: super cool! I've played with it, and OMG, it works :-)
So here are some thoughts:
Regarding your questions:
I'm pretty sure this is a bug in the prompt code, I've seen this happen too, I'll look into it, probably has to do with the event I'm listening to.
If I remember well, files only available in the static file system (so: hardcoded in the Zed app) show up as read-only, as soon as you put a version on the "user layer", that is: write to the file, which ends up on syncFS, it becomes writable again. I'm uncertain about whether we should force this
One thing that's on my todo list is to add a
Again, awesome work!
Thanks! It turned out to be a bit more work than I was anticipating, but it's turned into a fun little project.
My vote is also for the sandbox. Updating itself would be very cool. My only concern with it going 100% in the sandbox is that it would require an api that would allow any extension to delete every other extension.
Completely agree and on my todo list.
I definitely want to do custom hightlighting at some point. Using brackets seems like a good stop-gap solution though.
I noticed this, but it never occurred to me to do anything about it other than manually reload the list. Adding it to my todo list.
Definitely a good idea. We could limit the configfs APIs to only be able to write/delete files here as well then if we wanted.
This makes sense to me. My feeling was that it should be read only so someone doesn't edit it and cause themselves problems. I'm not really a big fan of being protected from myself though. And if something were to go wrong editing this file could be useful. If everything goes in the sandbox it could live at /ext/installed.json or /ext/zpm/installed.json. Or we could put it at /user/installed_extensions.json either way.
This sounds extremely useful. Thanks!
Regarding the ability for an extension to remove all files: I don't think that's something we have to prevent right now. The reason to put extensions in a sandbox (other than a clear security requirement for Chrome Apps) is prevent extensions from somehow killing the editor. Already today they have full write access to every file in a project, so giving them delete access to the config project is not that big a deal. If at some point we don't trust the extensions anymore we probably have to revisit the APIs anyway.
Main thing left is fixing the UI prompts. The install prompt is really annoying when launching from the installed extensions page. I think the issue is related to the prompt listening for keyup and the extension listening for keydown. I'll look into this when I get a chance.
Check the last commit message for things that I fixed/updated. Let me know if I missed something or you just want something changed!
I did a really quick test(I just changed the version and what a prompt says) surrounding zpm updating itself and it seemed to work. Is that something we want to do now or worry about later? I'm not sure how you'd want to set it up if it could update itself separate from zed itself.
Very cool stuff. So I've been thinking a bit about package management and editors and how I'd like it to work, let me know what you think:
As I see it, one important difference between how extensions/preferences/config works vs Emacs (and perhaps also Vim, not entirely sure) is that it's declarative rather than imperative. Emacs basically gives you a startup file with lisp commands to run to step-by-step build the environment you like, simply by executing lisp commands one at a time. Zed, with its JSON format for configuration is declarative: you specify the configuration you want and Zed just makes it happen (usually within a few seconds). In fact, the convenience commands for setting the font size etc simply update the preference in the configuration object and save it, and let Zed itself figure out what happened and apply the change.
I was thinking: can we make ZPM work the same way? Here's what I'm proposing:we add a "packages" key to the configuration JSON file format listing package URIs:
Now I used three types of URIs for packages, the first is a convenience notation for github (and translate to roughly the second example), the second one is a raw HTTP link, and the third is for packages hosted on bitbucket. We can add others, too.
Now, whenever the configuration is (re)loaded (a
Now I still think there should be a "ZPM Install" command that adds to this array automatically, and it should probably also support the
Now, this config-based approach unlocks a cool feature:
So, if you want your contributors to always have specific settings (tab size), or specific Zed extensions, you can specify this in
I think that's pretty cool.
So that's one thing. The other thing is that, inspired with how Github's new AtomEditor does things, is to basically rip out all current language modes and other extensions and put them in separate repos. This makes the Zed core much smaller.
However, we'd still list many of these packages under
So... this is all a lot of work (although, probably it's not that bad). The question is two-fold:
Let me know! I'll also link to this in the Zed user group to see if anybody has opinions.
I think the packages idea is brilliant. I was originally thinking about having an option to only apply packages to zedconfig.json instead of user.json, but it didn't seem useful enough to be worth the effort the way it works now. But if the same syntax that describes the package as applied also triggers it to install then it becomes incredibly useful. Setting up extensions for a project and sharing them with an entire team just by pushing zedconfig.json would be awesome.
I also agree with the folder structure and github/bitbucket shortcuts.
And almost everything that can be should be an extension. This just makes sense to me.
As far as who works on it, I don't really care to be honest. I'm definitely interested in continuing to work on this, but also want it done and in zed so I can use it! Also I will not have any time to work on it during the week, so if you do please do.
Made some small changes in the last 2 commits.
One minor thing I've thought of while starting to make my packages work again: Script URLs inside config.json. Right now I believe you have to write out the whole path to a script like this:
This is fine assuming everyone installs the package the same way, but if you install the package with https://raw.github.com/zedapp/spellchecker/master/ it won't work. I don't think this is a big deal since I can't imagine using the raw url over the github syntax, but thought I'd mention it.
Yes, I've been thinking about this too. I think I'll add relative paths that resolve relative to the .json file they're located in. — Zef
Sent from my iPhone
On Thu, Mar 6, 2014 at 8:06 AM, Andrew Stephan firstname.lastname@example.org