It might be a bit controversial notion. But when I try to look for extensions say for completion framework there are many available and I used ido and then moved to ivy. I knew helm existed and is much more powerful in terms of feature-set, but never used it.
I read that emacs can report on keyboard usage (I think from xahlee’s posts). Can it be repurposed to monitor which extensions are used often in users setup and they can share that report if they wish to public say via melpa like services. I suppose that melpa downloads can be used as a measure of usage.
I suppose that melpa downloads can be used as a measure of usage.
Not necessarily; lots of people would test some stuff and than perhaps not use it, or after some time go over to something else and so on. I wouldn’t rely on download stats.
which extensions are used often in users setup
It would be certainly possible to monitor which files are required in your Emacs session, and you could setup a public server somewhere on the Internet where such stats are uploaded, putted together and published for viewing. But what would that matter to you what I or some other Joe are using? Learn a thing and build on it instead of switching and trying. As long as it solves your problems who cares what others are using?
Melpa downloads might not be a 100% accurate measure for usage, but I think it’s still 100x times better than a measure that relies on user reporting their key-strokes.
Not keystrokes, but the frequently used commands.
When I hear of a package that may be interesting, I immediately check its repo page to see how many issues and PRs are still open. I look to see whether they have garnered any responses, especially if the submissions are of high quality. Years of issues building up isn’t a good sign. This isn’t 100% reliable, as different skilled developers approach issues and PRs quite differently, but it gives you some information. And there are outliers, like multiple-cursors, whose developer is very skilled and motivated, but whose popularity overwhelmed his resources.
For simple package, “no updates” for 5 years is usually fine. But before investing energy in a larger new package, I want to know whether it will still be working well in the next 5 years.
Instead of wondering about what everyone else is using, why not try each one and see what works for you? Ultimately, that’s all that matters.
This type of extension FOMO is nuts. Just pick one, use it and see if it suits your needs. If not, move to something else.
From a technical perspective maybe this is achievable through a mix of dribble files (see
open-dribble-file) and simple heuristics for guessing which functions are associated with a package (see here maybe?)I agree with others in that this might be a flawed way of measuring usage, but I think it still would be somewhat interesting to see those stats for fun!
Also after a bit more thought I think implementing this would be useful for a totally different purpose: programmatically finding underused keybindings/functions could help a lot with discoverability!