Tor-björn Claesson <[email protected]> writes:
>>> +(org-menu-define org-attach ()
>>
>> You forgot autoload cookie from the original version.
>>
> Does this mean "add ;;;###autoload before (org-menu-define org-attach ()
> ...)"?
>
> If I do this compilation complains alot along the lines of:
>
> WARNING: No org-loaddefs.el file could be found from where org.el is loaded.
> You need to run "make" or "make autoloads" from Org lisp directory
>
> Is there some kind of dependency issue, that org-menu is not autoloaded? I
> have
> not found any good resource on this in the manual yet, pointers would be
> appreciated!
I think we need to make the macro autoloadable with declare form:
Elisp manual:
16.5 Autoload
If you write a function definition with an unusual macro that is not
one of the known and recognized function definition methods, using an
ordinary magic autoload comment with a call to the macro would require
autoloading the macro definition itself to work. Doing so copies the
whole macro definition into the autoload file. If that is not desired,
you can use the special declare form ‘(autoload-macro expand)’ in your
macro definition (*note Declare Form::), instead of autoloading it.
This indicates to the autoload system that calls to your macro following
‘;;;###autoload’ should be expanded, similar to how the special
functions listed above are handled. For example, a macro which wraps
‘define-minor-mode’ can request expansion, so that proper ‘autoload’
calls for the function it defines are generated.
>>> +;;; Minor mode
>>> +(define-minor-mode org-menu-mode
>>> + "Org menu mode.
>>> +When Org menu mode is enabled, a menu prompting the user for an action
>>> +will be presented upon activating certain objects.
>>
>> This is no longer accurate after we generalized the org-menu.
>
> I do not understand this, is it related to the following?
Consider org-attach menu. "activating certain object" has little to do
with attachments. It was clearly written with citations in mind, but no
longer fits.
> I think we have differing ideas about what org-menu should be. Let's
> discuss and find and agreement!
>
> When we discussed the scope of org-menu previously (now years ago!),
> I came away with the understanding that it would be menus, not dialogues with
> state, and that specifically not to replace org-export (for this we though
> that for example a transient would work better.)
I think you are talking about
https://list.orgmode.org/orgmode/878qsifufe.fsf@localhost/ and your
followup that I forgot to answer.
My thinking there was - if we can make it work for all the menus, it
would be great. If not, limit the scope. But first focus on making the
simpler version of om.el working.
Now, we have om.el more or less done and working. So, I am trying to see
if we stretch the goals and make it work for everything we have in Org.
> I have worked under the assumption that org-menu should be for simple
> pop up menu-style selection things.
>
> What should be our path forward? Could it be any of
> 1. Broaden org-menu to also encompass dialogues with state/toggles. Now we
> limit
> the possible menu-system backends, but can use org-menu to replace more
> things.
> 2. Use org-menu for the simple pop up menu use case and use transient or some
> abstraction (org-dialogue?) for more complicated things. This way org-menu
> can
> use more diverse backends for the menu-systems, and stay relatively simple.
> 3. Drop org-menu and use transients to replace menus and dialogues. This is a
> very clean solution, transient is mature and we do not have to reinvent the
> wheel, but can replace a multitude of ad hoc dialogues with a uniform and
> well known UI. Are there people who do not like or can not use transient?
> That could be a problem.
>
> I would favor 2 or 3. I feel that if we broaden the scope to include things
> like
> org-export, we will have a more complicated abstraction, with fewer suitable
> menu-systems, and I think the choice of different menu-systems is the point of
> org-menu.
>
> What do you think? Are there other options?
My thinking is the following:
1. The current state of om.el already allows introducing transients for
all available menus in Org mode. It also naturally provides a way to
switch between the "classic" and transient menus with C--.
So, if we limit menu systems to "custom" and transient only, we can
basically introduce transient variants for all menus in Org without
breaking backwards compatibility for users preferring the classic
menus.
2. Beyond transient/custom, we can *almost* make things work for simple
toggles like in org-export-dispatch. I did quick testing, and calling
menu popup from inside transient prefix will keep transient-scope
with the default values of switches available. As a result,
which-key, tmm, and popup menus should "just work" once we tweak
`org-menu--specification-to-menu' just a little. There will be no
actual toggles, but the defaults will already work.
So, why not?
3. If we can make toggles work as well, even better. Although, I am not
sure if it is going to be easy. If not, no need to bother.
Basically, we can accept that some menus will not support all the
features of transient, but we can implement a bare minimum.
In other words, my general thinking is - try to make om.el support as
many as possible transient features, as long as the code is not too
complex. Once we hit the complexity wall, call it done.
WDYT?
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
