Re: Export Org with Org concept -- Re: Problems with C-c C-e file.org,

[Ihor Radchenko <yantar92@posteo.net>]

Jean Louis <bugs@gnu.support> writes:

> If you mean formatting of the text, how it looks like, then retain
> formatting of text. That is choice. That is not part of the offered
> concept. 

Yes, that's what I was referring to. I am not against non-blocking
interface per se.

> QUESTION: Should I now add the ordinary layout and keybindings and
> show you how it works?

It will be a good first step forward, yes.
If we move in this direction, we will need to find some way to replace
all the menus, like agenda menu, attach menu, clock menu, capture menu,
export menu, tag menu, etc.

We have one shared interface in `org-mks', which might be tweaked a
starting point.

> From your side I expect that you tell me how do you use Org functions
> to discover new exports as to see how to automatically include such.

For export menu, the relevant function is `org-export--dispatch-ui'.

> You have defined constraints to be the formatting (layout) and key
> bindings.
>
> Is there anything else?

I don't think so. The basic idea is to not break workflows that worked
in the past.

> I believe there is something in org that recognizes various export
> options and implements menu, is it? 

Mostly a collection of ad-hoc code all across Org. See the above.

>> In the video, you are using Org mode commands inside menu, which is a
>> new concept for me.
>
> I can't understand what you mean. Which Org mode command do you mean?
>
> Is it on this first video:
> https://gnu.support/files/emacs/packages/rcd-org-export/2022-12-19-23:36:10.ogv

Here. <RET> on the menus toggling the checklist.
The approach used in the existing menus is entering a dedicated key or
key sequence to select/unselect options.

> Regarding formatting: I don't think that formatting and layouts were
> pretty dependant on the interface in the manner how it began in past,
> and then programmers kept using that concept for the sake of the
> interface, not for sake of users. If you are bound to foundation
> lacking usability, of course programmers must stick to that
> foundation. However, that does not help users become swift in
> exporting. And thus it is not bad to escape the formatting for
> something better.

You may be right, but, as stated in the article I referenced, "I won't
lecture you [the user] on why the new experience is better."

If you think that we need to throw that existing approach away
completely and use the one you proposed, I'd suggest implementing the
better menu framework as independent package instead, allow plugging it
into Org, and then maybe switch to it in future if many users use the
alternative framework instead of the default one.

Combining the two is better though. IMHO.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
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>