When to publish
Opened this issue · 12 comments
Today I just successfully formatted an Emacs buffer for the first time using this extension and the latest version of the @unibeautify/cli from npm 😄 In fact, it's working surprisingly well for basic usage, doing M-x unibeautify to manually beautify a source file (M-x is Emacs-speak for the key combinationMeta-x, i.e. Alt-x). I made it match up Emacs modes with the corresponding Unibeautify language names so Emacs can automatically pick the right language for Unibeautify.
@Glavin001 @szeck87 Since it's already usable, I'd like to publish this package in the main third-party Emacs package archive, MELPA. They usually approve new packages within 1-2 weeks. But waiting longer is fine with me if you'd like to polish some of the NPM packages first. Emacs users expect MELPA packages to mostly work well, but are understanding it there is an occasional hitch, especially with new packages. I'll write some explanatory comments saying that this is work in progress and if they want it done sooner please contribute on GitHub :P
They usually approve new packages within 1-2 weeks.
Wowee, makes me thankful for npm!
... if you'd like to polish some of the NPM packages first.
The Emacs package will be separate from the npm package itself though, right? The user must install the Unibeautify CLI themselves and the Emacs package will wrap their currently installed version?
Overall, I am in favour of getting this process started. @lassik are you OK taking this on? I would appreciate it, as I have no background with Emacs or MELPA. Thank you!!! 🎉
They usually approve new packages within 1-2 weeks.
Wowee, makes me thankful for npm!
The initial submissions take so long because they are hand-vetted for quality by the maintainers (they actually read your code and offer constructive criticism), and the project is badly understaffed right now. After that it's smooth sailing, their CI server picks up any commits from our GitHub master branch and creates a new package in hours. In my experience the system is an extremely good compromise between quality and convenience, apart from the current staff shortage.
... if you'd like to polish some of the NPM packages first.
The Emacs package will be separate from the npm package itself though, right? The user must install the Unibeautify CLI themselves and the Emacs package will wrap their currently installed version?
Exactly right on both counts :) I think it's also best to keep them separate, as there is no clean way to have the Emacs package manager call npm. Emacs users are also very used to this arrangement: other external programs, such as grep and git, are also managed entirely separately from Emacs, usually via the OS package manager. I can write a short introduction for the Emacs package that points to the Unibeautify installation instructions (what would be the best URL, by the way?)
@lassik are you OK taking this on?
Sure, no problem :) I've published several MELPA packages so I'm familiar with the process.
Hey @lassik . Just checking in. I hope you are doing well 😃.
Did they approve the package? Any updates, such as installation instructions, you would like to make to the README.md or https://unibeautify.com/docs/editor-emacs ? Thanks again for your contribution to Unibeautify!
Hi. Thanks, you are very courteous.
I put off publishing it due to perfectionism basically - I wanted to add a framework for migrating settings between Emacs and .unibeautifyrc. But since that's still work in progress on the CLI side (unibeautify --dump-config-json option, etc.) we could just publish the current version. It doesn't have anything besides a manual unibeautify command but that already works fine. And packages don't need to be extremely polished to be submitted to MELPA. I could do it this week.
Sounds good. Thank you!
For those following this issue, here is the related issue for unibeautify --dump-config-json: Unibeautify/cli#19
@Glavin001 I'm ready to submit this to MELPA. Please check the newest commit in the proposed-commentary branch, are these introductory blurbs (README.md and the ;; comments at the top of the .el file) OK with you? The ;; comments are also used by MELPA as the introductory text on the webpage that it generates for the package.
Looks great! Feel free to edit https://github.com/Unibeautify/website/blob/master/docs/editor-emacs.md with any Emacs related instructions. Awesome work, @lassik !
No problem, the work was mostly copy-pasting from existing code :)
Just realized that we should really resolve Unibeautify/cli#81 (How to specify which beautifiers to use with the CLI) before publishing this. Right now the Emacs package doesn't give any config options to the CLI (it only gives it the programming language) so it relies entirely on the CLI to pick which beautifier to use.
Does it use the .unibeautifyrc.yml config files? I think this should be sufficient. Ideally I do not want to encourage alternatives for configuration and really focus on utilizing the configuration file.
The Emacs package doesn't read any configuration files at the moment. I would like to keep it so that it doesn't even have to know that .unibeautifyrc* files exist. The unibeautify CLI program would be the one that checks for the existence of such config files, reads them and applies the settings. This would be the clearest policy IMO, for multiple reasons (also for other plugins besides Emacs).
Whether the .unibeautifyrc* parsing is done in the CLI or in Unibeautify core doesn't matter to Emacs. I suppose it would be good to have it in core (perhaps as an option so callers can opt to read those files or not) since some editor plugins are skipping the CLI and using the core directly. In any case, I think the best policy is to only have one piece of code parse those files. The process is actually very complex when you put together all the little details involved :)
Agreed. Emacs should not have to deal with the configuration file, only Unibeautify CLI itself 👍 .
In your tests, is this working already? Or is Unibeautify CLI not there yet? Unfortunately, it's been a while since I've taken a closer look at the CLI status.
No problem, we are all volunteers here :) It's working fine, but Emacs relies entirely on the CLI to use whatever default options the CLI has. Emacs tells the CLI what programming language it should expect, and the CLI somehow selects a default beautifier with default options for that language.