Re: [emms-help] mpv player alternative with json-ipc

[Mike Kazantsev]

On Sat, 26 May 2018 01:42:47 +0200
Pierre Neidhardt <address@hidden> wrote:

> Yoni Rabkin <address@hidden> writes:
> 
> > None that I can think of, unless we move to emms-plr-... or
> > something, which isn't a huge improvement; I think that players
> > should have their own namespace.
> >
> > I've always kind of visually "tuned out" the long names. I guess I
> > could also write up some code to abbreviate the display of these
> > names on the Emacs-level.
> >
> > What do other people think of this?  
> 
> What about https://github.com/Malabarba/names ?

It does look like a nice solution.

Applying it to existing code was not entirely without surprises to me,
despite the claim, as one has to keep in mind that quoted symbols
aren't namespaced (as documented), so prefix will poke through
abstraction in some cases.


Abbreviating prefix in editor (or some post-save mangler hook) shouldn't
have such issue, and doesn't impose extra runtime/learning dependency,
so at first glance looks like a better idea.

But on the other hand it actually requires everyone in the target reader
audience to setup such ad-hoc abbreviation to apply, which is probably a
lot more work than figuring out what that "define-namespace" thing does.

So if not already widespread (similar to something like git), IMO a
non-starter for anyone but authors, who maybe don't benefit much from it
anyway, being most familiar with the code in question.

I think "(define-namespace ...)" is a better idea, if the goal is to
remove significant amount of visual noise and boilerplate from the code.


Whether that "visual noise" due to prefix is significant enough to
e.g. include whole additional dependency maybe can be best
tested by an example:

 - Check out this code:
   https://gist.github.com/mk-fg/04f12b67e3c5f53ff3e93d764991ef73

   ...especially places outside of defcustom/defvar and such, i.e.
   actual implementation stuff:

   
https://gist.github.com/mk-fg/04f12b67e3c5f53ff3e93d764991ef73#file-emms-player-mpv-el-L426-L460
   
https://gist.github.com/mk-fg/04f12b67e3c5f53ff3e93d764991ef73#file-emms-player-mpv-el-L327-L371

 - Compare to this - same two highlights:

   
https://gist.github.com/mk-fg/a3976db50206b54e1f13d78507d77837#file-emms-player-mpv-el-L430-L464
   
https://gist.github.com/mk-fg/a3976db50206b54e1f13d78507d77837#file-emms-player-mpv-el-L331-L375

 - How much noise is there: https://i.imgur.com/10rw9Mo.jpg
   It's pretty much on every other line, outside of headers.

Both gists have working code.

emms-player-mpv- is maybe among the longest prefixes, so improvements
aren't necessarily that clear elsewhere.

Also note that weird indentation of the code above never uses
alignment, which would probably make even more difference, as it
drastically reduces available space on the line where applied.


Where names.el notably breaks abstraction in this case:

 - All hooks, timers, make-process-likes, some map-like calls.

   I.e. ":filter 'emms-player-mpv-ipc-filter" still have to be
   pre-expanded, same as "(run-hooks ...)" and "(run-at-time ...)".

 - All docstrings with links like `emms-player-mpv-stuff'.

 - Macros and string names.


I'd say these downsides are still worth large improvement in
readability, and looks like it'd be much easier to work with as well.
So definitely would include names.el into project with long prefixes.

But don't think it should be up to me here, and I'm not sure about
copyright issues, though header in names.el seem to suggest assignment.

Maybe someone unfamiliar with code above can provide an opinion?
I'm definitely in a worst position to judge whether it's readable :)


Thanks a lot for a great suggestion, Pierre.

Didn't consider such option at all, though admittedly never looked into
the issue either.


-- 
Mike Kazantsev // fraggod.net