I intend to submit Master of Ceremonies to Non-GNU ELPA. I'm deciding what changes are necessary to facilitate that and looking for low-hanging fruit to improve user results.
- I'm likely to change the package file name and consequent naming over to mc. Please understand when this breaks use-package expressions.
- Autoloads are being made for 29.4 since there is no stable 30.x release to target right now
- Mark several customize variables as safe local variables
- Generate a manual just to point users towards likely entry points like `mc-focus' and `mc-present'
- More stable API for `mc-focus' playback
The following architecture and feature changes are planned (this is as much rubber ducking as it is communication):
One disappointment of mine that affects both dslide and mc is the lack of sufficient multi-monitor detection on XFCE even when xrandr is present. The feature I want to implement is to display a frame or presentation fullscreen on the "other" monitor because in dslide, the comments in the base buffer are visible and can be used for narration. At present, it appears I would need to interpret xrandr itself since the high-level interface Emacs ships with appears not to distinguish the two physical monitors when they are treated as a single virtual screen. Since we need a new frame either way, I may just do that for now and later add customize support to "guess" the correct location and fullscreen parameter of the new frame.
All region selection for `mc-focus' will be re-architectured to normalize onto the rectangle selection case. The non-rectangle case will be translated
internally to work like the rectangle case. The reason is that I need
to support trimming and to "do the right thing" when the user begins the
selection with indentation. The rectangle case is more general to every consequent problem. This path may also adapt to handle visual
lines better, injecting newlines when the column exceeds the window
column width.
I've realized a common mc workflow of mine is to hide some text completely rather than just highlight substrings. Subsequently, un-hiding creates the effect of building up a larger expression with all text remaining fixed in place, invaluable when presenting code.
The playback features of MC almost assuredly need keyword arguments. Display can be affected by the string, its text properties, overlays, and invisibility specs. One option is to merge all of the properties and overlays. A more flexible option for interactive explanation of display itself is to toggle the invisibility spec and overlays on the fly. This is unsupported during playback without retaining the "redundant" information of unmerged properties and overlays etc. I need to add support for propagating overlay priorities. Reducing all overlays is an option, but the rules for overlays that are fully contained etc are a bit tricky and I don't want to emulate all of the behavior within MC.
Images in theory can work. The size of the image needs to be adjusted according to the scale of the text overlay. There could be edge cases. Any specified space used for centering would need to be adjusted. That holds for text as well.