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

[Jean Louis <bugs@gnu.support>]

* Ihor Radchenko <yantar92@posteo.net> [2023-01-07 12:04]:
> As I said, the requirement to get it into the core is re-creating
> previous layout and bindings. The layout and bindings may be
> customizable, but they must be available.

You have got the concept, you may implement it.

> > The Concept and More Ideas:
> > ---------------------------
> >
> > 1. You can create derived mode, for example Org derived mode.
> 
> This has pros and cons. Org derived mode means that personal
> customization, including key bindings and themes, may affect menus. This
> may or may not be desired.

It was example of the mode. You may use any mode you wish. I said it
is example. 

Though I do not know how personal customization may affect the
generated temporary Org buffer which sole purpose is to invoke
functions.

If for example, export of body only is somewhere customized than
package similar to RCD Org Export may set those variables
correspondingly, or recognize user's options.

> > 3. You can create read-only, temporary buffers for export in that
> >    derived mode.
> 
> I am not sure what you are referring to.

You have to review the concept I have sent. A temporary generated
buffer is used as menu, in read-only mode. Of course you don't want to
users to write into temporary generated buffer (RCD Org Export), but
if they really want, they can turn off read-only-mode. Because you
wish to setup key bindings, you should use derived mode. I am
referring to concept how you would do the non-blocking menu.


> > 4. Because it is read only, similar to modal modes, you do not need
> >    complicated key bindings, you don't need to use C-combinations for
> >    few simple things, use simply letter. 
> 
> Same as what we do now in the menus. I do not think that we need to
> change the existing bindings (by default).

All is your choice. I am giving you concept on which you can build.

> > 5. Though it implies you can use same key bindings for
> >    "compatibility", but I would say it rather honestly for bad habits,
> >    as in the derived.
> 
> As I said earlier, "bad habits" is a judgment. We will not break user
> experience if we don't have to. It includes existing bindings.
> 
> Introducing alternatives is possible though.

Of course it is judgment, and nothing wrong with it, I keep judging
it, that is why I don't use it, it is disturbing. All opinions are
judgments. Though my judgments are based on experience with Org and
many other software, it is informed opinion, not just a biased opinion
without inspection. It is opinion with a solution. People make
opinions all the time, that something is judgment is obvious.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/