That's meta-ish question but google isn't helpful in this case.

Are there any standardized habits of where/how/whether one should look for feedback on his (or her) new emacs package? Especially - before publishing it.

My particular case is that I started extracting and packaging longer and possibly reusable parts of my .emacs (first item is theme-switcher, but I have a few further ideas). As it is possible that someone else would benefit from this code (and maybe offer improvements), I consider publishing it to melpa. Still, my elisp knowledge is, well, very basic, so I hesitate offering my package without any screening – and unfortunately I have no colleagues who know elisp.

Is there a place where one could post here is my package, could you review it question? Is this stackexchange right place? Or mayhaps some newsgroup or email list?

  • 3
    You get basic code feedback upon submitting a MELPA pull request if there's anything problematic lurking in there.
    – wasamasa
    Mar 3 '15 at 10:39
  • On a related note, I'm missing a discussion forum covering Emacs-related issues that don't fit into the question-answer form of this, otherwise, excellent system. Mar 3 '15 at 12:43
  • 1
    @Lindydancer One option is chat.stackexchange.com/rooms/17392/scratch It is minimally threaded, but it is persistent and searchable.
    – dcorking
    Mar 3 '15 at 14:19

I believe this is a great question considering elisp seems to be a language that's geared to be easy to learn, yet not a language many people manage to master (as in, learning how to do anything in it the best/most appropriate way possible).

You can ask for feedback on specific issues on the #emacs IRC channel on the Freenode network. Perhaps the chats on this Stackexchange might work out as well, I've seen a bunch of specific ones where people interact on topics like starter kits.

There is no such thing as an official place where you can get proper reviews. A question on the emacs-devel mailing list was about ways to make it a nicer place for newcomers which also involved reviews of packages that might be desirable in the GNU ELPA package repository. There's also other reviews happening on it, such as for basic patches. Here's a different example.

As a side note, if you've found someone willing to review your code, WTFs per minute should be a good indicator of its quality :)

  • The discussions on emacs-devel and "mentoring" idea is exactly sth I am looking for. Pity there are just 2 or 3 threads of this kind, all at similar time, and that's all. Also, numerous big names present on the list make it psychologically difficult to post simple code on such a forum. Still, that's a best shot and I will think about it.
    – Mekk
    Mar 4 '15 at 8:06
  • I have bad personal experience with IRC used for technical discussion (I perceive IRC as place of chaotic talks which consume a lot of time and are tough to track and summarize, and where even if I get sb's attention, he or she ma be distracted at any time).
    – Mekk
    Mar 4 '15 at 8:06
  • I accept this reply as I suppose this is just a state of things as they are.
    – Mekk
    Mar 4 '15 at 8:07
  • I hate to say this, but I'm afraid mentoring is generally something very rare in open source projects. Once money gets into the equation however...
    – wasamasa
    Mar 4 '15 at 9:35

Here's another suggestion: Post (a URL to) your library on mailing list gnu-emacs-sources@gnu.org. And you can even ask for feedback in your message.

  • Isn't this list intended for discussions about emacs "own/internal" code?
    – Mekk
    Mar 3 '15 at 20:57
  • If you mean gnu-emacs-sources, no. It is for anyone's code. It is for letting people know about code availability, new versions of a library, etc. And people sometimes offer feedback. And people posting links to libraries sometimes ask for feedback. It is generally a low-volume mailing list. Just one more resource.
    – Drew
    Mar 3 '15 at 23:48
  • I checked a few months of recent archives and I did not find any kind of discussion of the type I mean (mostly there are numerous ELPA announcements, and few manual, but those got no comments)
    – Mekk
    Mar 4 '15 at 7:49
  • It's mean for announcements. Your announcement would be that you have got this great new package that you want to discuss with folks who've got more experience and it interested in the issue you are trying to solve... The discussion would likely be via other means. emacs-help might be another good mailing list.
    – rasmus
    Mar 4 '15 at 11:03
  • @rasmus: FWIW, I disagree that help-gnu-emacs@gnu.org would be a good mailing list for this (if that's the list you meant). That's really for asking and answering questions about Emacs. Nothing prevents using it for this also, but this is not really what it is there for.
    – Drew
    Mar 4 '15 at 15:08

You might also get some useful feedback by creating a page on Emacs Wiki about your package (and explicitly encouraging feedback!). You can also post the code itself to the wiki, in its Elisp Area. I, for one, have received lots of useful feedback for code I've posted to the wiki.

  • I definitely agree about posting on emacswiki. Read the page at emacswiki.org/emacs/ElispArea to see how to get started. It's simple to use.
    – m43cap
    Mar 4 '15 at 16:41
  • Considering my code is already versioned elsewhere, what is the proper way to link it on emacswiki instead of copying and pasting ?
    – Mekk
    Mar 5 '15 at 12:49
  • @Mekk: Just type the URL - it automatically becomes a link.
    – Drew
    Aug 24 '16 at 20:21

This is just an idea (I've never seen it done), but you can push it to a Github repo, open an issue requesting feedback, and then post a bounty on the issue.

If you do that, you'll want to be very descriptive of what you're looking for in your bounty and probably announce it somewhere like r/emacs, our chat room, and/or #emacs IRC channel.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.