[I wrote this draft at 2018-11-25, but never came to go over it
a second time and send it.]
Hoi,
Philipp brought the whatnow topic up again (in private
conversation). I realized that I still don't use whatnow2, which
is a bad thing when we would want to drop whatnow in the next
release. Our last discussions on the topic are a year or so ago.
Bear with me that I start afresh and try to summarize the
situation and think aload about ways to go ...
Philipp wrote that in his eyes, the old whatnow would be dead and
we should switch to whatnow2 or something similar.
If we want to go this way, I need to drop whatnow from my workflow
and start using whatnow2 or alternatives, now. ;-)
Thus I had a(nother) look at whatnow2. AFAICS, it currently works
on the current message in the draft folder only. This collides
with my typical work scheme of drafting multiple messages in
different tmux shells in parallel. Hence I would need to switch
the current message in the draft folder explicitely all the time.
(It might be possible to solve that problem with different
contexts and private sequences, but I'm not sure, as I've never
used private messages.)
In the core of the problem lies the question: How does whatnow2
know which draft to work on?
The answer is: It cannot know it, unless we explicitely tell it.
The current message is the only automatic hint we have. This
however collides with parallel working on multiple drafts.
But let us look on the topic from a different angle: Let's think
without having any sort of whatnow/whatnow2. Comp/repl/forw/dist
would invoke the first editor on their own and after it exited
just leave the draft in the draft folder and exit to the shell.
Then we need replacements to these whatnow commands:
- edit already covered by `comp -use', we just need to care
for last-editor handling
- list already covered by `show' (no separate listproc
necessary, i'd say)
- send already covered by `send'
- delete already covered by `rmm +drafts'
- refile already covered by `refile -src +drafts'
- display new wrapper necessary for `show', which honors
mhaltmsg (i.e. soon a header in the draft)
- attach new wrapper necessary for `anno'
- alist new wrapper necessary for `anno'
- detach new wrapper necessary for `anno'
Thus the question: Why do we want whatnow2 at all? Wouldn't it be
much better to go for the above changes right away?
First, we should to move the draft environment variables into the
draft. Currently, Philipp uses a separate meta file for that in
whatnow2. I think we already had consensus for putting it as
mmh-* headers (or similar) in the draft. I'd say that this is
what we should do at first, because this change is conceptionally
worthwhile anyways, independent of any whatnow rework.
@Philipp: Are you already working on this or should I start with
it? [This I wrote on 2018-11-25 -- I was really keen to start
working on it ... but personal life made it impossible just at
that time. :-/ ]
Second, cover the yet uncovered tasks: display, attach, detach,
and alist. Two ways come to mind to do so:
1) Add each of those commands as a tool (shell script or C code),
wrapping show or anno, respectively.
2) Merge the tools:
- Display could be added as a switch to show.
- Attach/detach/alist could all be one tool:
attach
attach -d
attach -l
... I'm unsure what I like more ...
Nonetheless, I'd favor to drop whatnow/whatnow2 altogether, making
a compatibility-breaking release, and go for the conceptionally
better approach right away.
The first step, of moving the environment variables of whatnow or
meta files of whatnow2 into the draft, is worthwhile anyways and
can be done right away, independent of further decisions. This
should be done.
What do you think?
meillo
