Emacs mode (GUI)

[Ambrevar]

Like many semi-interactive programs, Demlo's user-experience feels limited on the commandline.
In particular, it can be frustrating to re-run Demlo over and over with different pre-/post-/scripts until we get the result right.

I've been thinking of writing an Emacs mode to provide for a better experience.
Why Emacs? Mostly because:

• of its textual nature;
• of its keyboard-based, power-user bindings;
• I use it, I know it, I can program it :)

Running Demlo from Emacs would produce a special buffer "à-la-Magit" where each audio file would contain the diff as it is currently displayed in shells.
The entry would be collapsable.

There would be two collapsable subsections:

• A subsection containing the list of scripts which could be turned on and off with a simple binding.

• A subsection containing the pre/post scripts which would be writable (in Lua mode, obviously).

A C-c C-c key press on a track section would update the "diff" by running Demlo with the changed made to the scripts in the subsections.
A C-u C-c C-c would do the same to all tracks.

Last but not least, the diff "after" fields would be writable. This would effectively allow for a very convenient way of hand-editing tags and other properties.

Finally, C-x C-s would process the track at point while C-x s would process all tracks.

[fictionic]

Uh oh. I'm a hardcore vim guy. Lol.

Three serious thoughts.

1. I have no problem with an Emacs plugin (if that's what they're called, I dunno) for Demlo that does this. I would however complain if it became the de-facto GUI. I think it unwise to require Emacs as a dependency for software that isn't really related to it.
2. If you're going to make a GUI for Demlo, you risk going down the route of Mp3Tag/PuddleTag, where there are tons of features, and it's not really a simple app anymore. Though I do know I'd appreciate an auto-numbering feature (for tracknumbers). That reminds me, I need to submit a feature request...
3. Is there a reason you're averse to allowing user interaction? I know it's written somewhere in the manual but I don't know if the philosophy is ever spelled out. As I envision it, cripts could just call a sandboxed function input() that would return as a Lua string one line of user input from readline (or something else). There would also need to be a non-debug print function, to tell the user what it's asking for. I suppose that's a large departure from how Demlo has works up until now. However, consider this: because Lua's booleans are really tri-valued (with nil), this opens up a possibility for user interaction. If a variable is set to true or false in a script, then that value is used; if it is unset (or set explicitly to nil), then the user should be prompted. That would be the paradigm for making scripts, is what I'm saying.

[Ambrevar]

1. I never said the commandline interface would step down :p Obviously the GUI will be completely optional.
   That said, like many Emacs packages (e.g. Magit), it's possible to run the package without any Emacs config.

2. See 1. Regarding auto-numbering, the issue is that Demlo (as opposed to Beets) does not have a "per-album awareness". There is a work-around though: disable parallel processing (-cores 1) and use a global variable to keep track of the numbers, then reset the number to 1 as soon as the album name changes. It's brittle and losing parallelization is a shame.
   If you can think of something better, I'd be happy to look at your request.

3. Demlo was designed as an unattended tool, which is why all the user interactions are meant to be done before starting the process.
   That said, you suggestion is not stupid. I don't think nil would work though, since an undefined variable is also nil.
   What about adding an input() function as you said and leaving it to each script to decide when input() should be called?

[fictionic]

2. Per-album awareness is definitely something I've wanted Demlo to have for a while and I do have some ideas about how it might work. That workaround is pretty interesting—does it process input files in the right order all the time though? Like, does it sort them by filename initially, or just use the order returned by the system call?

3. An undefined variable is also nil, yes. That's intentional. In my system, the scripts would prompt the user for decisions that it wasn't told to make. Defaults can be set by setting global variables to true or false in certain scripts; leaving them nil means "ask me if the issue ever arises" (some questions only come up in certain cases). Adding an input() function and letting each script decide when it would be called is exactly what I meant; sorry if that wasn't clear. I meant that whenever a global variable was unset, and a decision needed to be made, the scripts would prompt the user for an answer.

[Ambrevar]

does it process input files in the right order all the time though?

Indeed, it would require demlo to make sure the files are sorted.
Did you have any other workaround in mind?

I'll have a more in-depth look at your demloconf very soon. Thanks a lot for the hard work!

[fictionic]

Did you have any other workaround in mind?

Sadly I don't. I think you just have to do that if you want to do auto-numbering. Or at least some type of sorting. I know in Mp3Tag you can sort the files by any of the columns along the top, and then auto-number using the resulting order. So I guess a maximally general version of this feature would have a commandline option for how to sort the input files, like -order <string>, where <string> can be any element of the input table, e.g. tags.title or path.