Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more powerful built in formatter descriptions #85

Closed
mohkale opened this issue Apr 9, 2022 · 6 comments
Closed

Add more powerful built in formatter descriptions #85

mohkale opened this issue Apr 9, 2022 · 6 comments

Comments

@mohkale
Copy link
Contributor

mohkale commented Apr 9, 2022

Hi,

Atm I'm maintaining a relatively large collection of formatters in my dotfiles and I'm curious whether there's any interest to backport some of them back into apheleia proper.

@raxod502
Copy link
Member

Yep, I think that would be fantastic. See also lassik/emacs-format-all-the-code#170, and specifically lassik/emacs-format-all-the-code#170 (comment), where I propose importing also the formatter definitions from format-all into the Apheleia format (or, really, into a new package that could be used as a dependency of both Apheleia and format-all, as well as potentially other formatting packages).

Looks like you've got some neat customization variables as well for your formatter definitions, I see no reason we can't include those as a new abstraction into Apheleia.

You've done a lot of good work for Apheleia in general, so, I'm also adding you as a collaborator on the repository, so you can more conveniently make quick fixes if you like. I'm still happy to review pull requests, but I trust your judgment.

@mohkale
Copy link
Contributor Author

mohkale commented Apr 10, 2022

Looks like you've got some neat customization variables as well for your formatter definitions, I see no reason we can't include those as a new abstraction into Apheleia.

Great. I'll try to open a PR a little later (might be busy for the foreseeable future). Since this doesn't seem like a core apheleia thing, I think it might be worth adding a new file like apheleia-formatters.el where these are defined. Thoughts?

You've done a lot of good work for Apheleia in general, so, I'm also adding you as a collaborator on the repository,

Great, thanks. I'll likely still defer to you for most changes since I'm relatively inexperienced maintaining packages like this but I appreciate the trust :-).

@raxod502
Copy link
Member

doesn't seem like a core apheleia thing

Well, it kind of is insofar as they're required for basic operation if they are used in the default apheleia-formatters alist. But, it never hurts to spread code over multiple files, so I wouldn't see any issue with moving the formatter definition list, and all accompanying user options, to a separate file that is loaded from apheleia.el.

@mohkale
Copy link
Contributor Author

mohkale commented Apr 10, 2022

Makes sense. How's about we keep core definitions including formatters in apheleia.el and move the formatter runner to a separate apheleia-runner.el?

@raxod502
Copy link
Member

That also seems fine to me. The interface to external callers is just that they will load apheleia.el and expect functions to be available, so as long as we load all the sub-files from apheleia.el, we can move these around as much as we want.

@mohkale
Copy link
Contributor Author

mohkale commented Apr 20, 2023

Going to go ahead and close this as resolved with #166.

@mohkale mohkale closed this as completed Apr 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants