emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Org Capture Menu cannot be fully viewed


From: Jean Louis
Subject: Re: Org Capture Menu cannot be fully viewed
Date: Sun, 13 Dec 2020 18:12:10 +0300
User-agent: Mutt/2.0 (3d08634) (2020-11-07)

* Tim Cross <theophilusx@gmail.com> [2020-12-13 03:54]:
> 
> pietru@caramail.com writes:
> 
> > Dear All,
> >
> > When making a relatively long Org Capture Menu for Archaeological Field 
> > Management,
> > the relevant capture window cannot be scrolled down.  This becomes 
> > particularly
> > problematic with small field laptops.
> >
> 
> I'm assuming you mean the window which pops up where you select the
> capture template to use.
> 
> Just wondering if perhaps what we really need to do is provide some sort
> of support for using Emacs completion facilities to select
> templates?

That is very right. I have 1140+ "Sets" which are equivalent to
capture templates. Imagine if I would be "defining it" by using Emacs
custom, forget it, I would rather break my computer down and switch to
paper.

I define the set one time as a set. If I wish to capture into that set
I use quick relevance search or semantic access. I would not like
remembering any "keys" for that purpose.

> realise this is challenging because of the huge wealth of completion
> frameworks available in Emacs, but perhaps adding support for something
> like fido-mode would be beneficial.

Ah, no. Completions shall be available by standard. Emacs's standard
completion is just fine and any comletion package can extend it. That
is how it works.

Would org-capture functions be programmed in more functional style I
would already make the function. Maybe somebody else finds time to do
it.

Or somebody can help me and tell how to use function, which function,
to file into specific Org file from org-templates, then I will make
function for completing-read as it is trivial. I am missing only
that.

> To some extent, it feels like org is re-inventing a wheel here and
> we would be better off using an existing facility rather than
> develop/maintain an org specific version.

Good observation, welcome to club.

> I see a very similar problem with the export menu, but that is a
> more complex situation.

Since quite some time I am using Org mode as display mode, not editing
mode. The compiled related information about person is displayed as
Org mode on the fly. I can have persons' images, SMS sent, notes,
tasks, transactions, emails received, including statistics all in one
Org file as display that is read-only.

Similar derived mode could be used to display export menu and capture
menu. Instead they block user's interface, cursor cannot move to other
buffers, one has to interrupt those screens to do something
else. Incredibly user unfriendly.

(define-derived-mode my-org-view-mode org-mode "My View Org" "My Org View")
(define-key my-org-view-mode-map (kbd "q") 'kill-this-buffer)
(define-key my-org-view-mode-map (kbd "e") 'export-somewhere)
etc.

Even multiple screens for multiple org files can be made to work with
their buffer local text in a different way. One can export the other
file, the other this file, 

Same for Capture menu, just same. Make the Org file, define keys on
the fly or simply hyperlinks and let users capture where they wish
without limit.

Jean



reply via email to

[Prev in Thread] Current Thread [Next in Thread]