Ihor Radchenko <[email protected]> writes:
> 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.
>
Making the declare form
(declare (indent defun)
(autoload-macro expand))
does not work, and this paragraph is not present in my local elisp
manual or at
https://www.gnu.org/software/emacs/manual/html_node/elisp/Autoload.html
Is this a new feature in an unreleased version of emacs?
Thanks to your manual link I found this trick, which works :-)
;;;###autoload (autoload 'org-attach "org-attach")
>>>> +;;; 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.
>
Aah, thanks!
>> 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.
>
Ok, cool! Then I understand!
>> 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?
This sounds good! I will get on this. Right now is family time, so it
will take a short while for me to get back.
Cheers
Tor-björn
