Max Nikulin writes:
> On 21/06/2022 14:37, Arthur Miller wrote:
>> Emacs as a whole is not designed to work in the way I
>> percieve it has clean separation between contexts in each frame. Menu
>> buffer is "global" for entire Emacs process, and there are other
>> features of Emacs that does not
On 19/06/2022 22:34, Arthur Miller wrote:
Max Nikulin writes:
I believe, multiple capture menus should be possible in parallel even within
single frame since it may contain several windows and user experience should be
better than now. Keymap-based selection opens a road in this direction since
On 21/06/2022 14:37, Arthur Miller wrote:
Emacs as a whole is not designed to work in the way I
percieve it has clean separation between contexts in each frame. Menu
buffer is "global" for entire Emacs process, and there are other
features of Emacs that does not work well in such scenarion. Some
Max Nikulin writes:
> On 26/06/2022 11:50, Arthur Miller wrote:
>> Max Nikulin writes:
>>>
>>> By state I mean some structure opaque to menu package. It just receives it
>>> from
>>> caller as an optional argument and (when given) later passes it to
>>> handler. Maybe it is alien approach in LIS
On 26/06/2022 11:50, Arthur Miller wrote:
Max Nikulin writes:
By state I mean some structure opaque to menu package. It just receives it from
caller as an optional argument and (when given) later passes it to
handler. Maybe it is alien approach in LISP, but in C (where closures are
impossible)
Ihor Radchenko writes:
> Arthur Miller writes:
>
>> Ihor Radchenko writes:
>>
>>> Arthur Miller writes:
>>>
I have reworked a bit org-capture, but I haven't yet worked on org-agenda
restrictions and other details.
>>>
>>> I do not think that you need to prioritize re-creating
>>> org
Max Nikulin writes:
> On 22/06/2022 19:13, Arthur Miller wrote:
>> Max Nikulin writes:
>> Menu should and application should be separated in my eyes. Menu is just a
>> graphical/audio? presentation of selectable choice to the user. As such it
>> should display choices, let user pick a choice, and
Arthur Miller writes:
> Ihor Radchenko writes:
>
>> Arthur Miller writes:
>>
>>> I have reworked a bit org-capture, but I haven't yet worked on org-agenda
>>> restrictions and other details.
>>
>> I do not think that you need to prioritize re-creating
>> org-capture/org-agenda/etc The main poin
Ihor Radchenko writes:
> Arthur Miller writes:
>
>> I have reworked a bit org-capture, but I haven't yet worked on org-agenda
>> restrictions and other details.
>
> I do not think that you need to prioritize re-creating
> org-capture/org-agenda/etc The main point is making sure that org-select
>
Arthur Miller writes:
> I have reworked a bit org-capture, but I haven't yet worked on org-agenda
> restrictions and other details.
I do not think that you need to prioritize re-creating
org-capture/org-agenda/etc The main point is making sure that org-select
provides the required functionality.
On 22/06/2022 19:13, Arthur Miller wrote:
Max Nikulin writes:
Menu should and application should be separated in my eyes. Menu is just a
graphical/audio? presentation of selectable choice to the user. As such it
should display choices, let user pick a choice, and return to the application
the pi
Max Nikulin writes:
> On 21/06/2022 11:07, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> The other question is altering the org-capture code.
>> I think that it is too early to discuss org-capture part just yet.
>> Lets first finalize the generic library itself and discuss the
>> appropriate ad
On 21/06/2022 11:07, Ihor Radchenko wrote:
Max Nikulin writes:
The other question is altering the org-capture code.
I think that it is too early to discuss org-capture part just yet.
Lets first finalize the generic library itself and discuss the
appropriate adjustments to
org-capture/org-agenda/
Max Nikulin writes:
> On 20/06/2022 19:10, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> Sure. I was hinting about such functionality in the new library we are
>> discussing. Multiple capture menus are not possible now anyway, so it
>> will be a new feature if we decide that we need it (I am no
Ihor Radchenko writes:
> Max Nikulin writes:
>
>> Consider the following case. A user has 2 virtual desktops dedicated to
>> rather independent tasks and an Emacs frame on each desktop. On desktop
>> 1 she opens help for some function with aim to evaluate if it is
>> appropriate for some part
Max Nikulin writes:
> Consider the following case. A user has 2 virtual desktops dedicated to
> rather independent tasks and an Emacs frame on each desktop. On desktop
> 1 she opens help for some function with aim to evaluate if it is
> appropriate for some particular purpose. Next she has to
On 20/06/2022 19:10, Ihor Radchenko wrote:
Max Nikulin writes:
Sure. I was hinting about such functionality in the new library we are
discussing. Multiple capture menus are not possible now anyway, so it
will be a new feature if we decide that we need it (I am not 100% sure
if having multiple me
Max Nikulin writes:
>>> Ihor, magic is impossible. If several captures may be requested in
>>> parallel then snapshot of data required to fill capture template should
>>> be stored somewhere at the moment when capture is initiated. Otherwise
>>> the user may kill the buffer she is going to captur
Max Nikulin writes:
> On 18/06/2022 22:05, Arthur Miller wrote:
>> Max Nikulin writes:
>>> On 11/06/2022 12:26, Ihor Radchenko wrote:
Max Nikulin writes:
> Imagine what would happen if Emacs decided to show several capture menus
> with keymap non-blocking interface in different
On 18/06/2022 15:25, Ihor Radchenko wrote:
Max Nikulin writes:
Note that there is not much happening when capture menu is called. Only
the link is stored into link ting. Otherwise, no capture data is
altered. All the fragile staff is happening after selecting capture
template.
Ihor, magic is
On 18/06/2022 22:05, Arthur Miller wrote:
Max Nikulin writes:
On 11/06/2022 12:26, Ihor Radchenko wrote:
Max Nikulin writes:
Imagine what would happen if Emacs decided to show several capture menus
with keymap non-blocking interface in different virtual desktops.
Different Emacs processes,
Max Nikulin writes:
> On 11/06/2022 12:26, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
>>> However if two org-protocol handlers are launched without specified
>>> template then behavior of Org becomes confusing. I meant this case.
>>> Currently reading key from minibuffer serves as a kind of
On 06/06/2022 06:05, Tim Cross wrote:
One very big warning I would like to raise to ensure it is taken into
consideration is accessibility. This can have two significant effects
with respect to the types of things you are doing -
Out of curiosity, you mentioned export menu. Would it help if if
Max Nikulin writes:
>> Note that there is not much happening when capture menu is called. Only
>> the link is stored into link ting. Otherwise, no capture data is
>> altered. All the fragile staff is happening after selecting capture
>> template.
>
> Ihor, magic is impossible. If several captures
On 11/06/2022 12:26, Ihor Radchenko wrote:
Max Nikulin writes:
However if two org-protocol handlers are launched without specified
template then behavior of Org becomes confusing. I meant this case.
Currently reading key from minibuffer serves as a kind of
synchronization tool.
Imagine what wo
Ihor Radchenko writes:
> Arthur Miller writes:
>
>> this example the mode map approach seems slightly more convenient. I don't
>> know,
>> in org-agenda-test, I haven't implemented all of org-agenda, restrictions,
>> prefixes and some other stuff, mostly because I don't really understand the
Arthur Miller writes:
> Anyway, I have been playing and testing a bit, and didn't want to prolong
> discussion untill I have something to show. So here is a small prototype. It
> is
> just a rough sketch of the idea.
Thanks!
I will not comment on Elisp part just yet. Let's first settle down the
Ihor Radchenko writes:
> Tim Cross writes:
>
>> I'm not sure I really understand the exact goal you have here. To me, it
>> feels like yet another input selection/menu/completion scheme and I'm
>> not clear on how it will be an improvement or why do something
>> 'different' in org compared to ot
Max Nikulin writes:
>> so are we talking about menus then? is there truly a need to make
>> /menu state/ persistent or yakshaveable?
>
> As soon as capture template is chosen, content is landed to the target
> file and may be autosaved. I do not expect problems here.
>
> However if two org-prot
On 07/06/2022 10:09, Samuel Wales wrote:
i must be confused. menus aside, you can currently capture and it
uses the org forest itself, so it is both crash-proof and snappy. and
you can yakshave as much as you want, starting a capture while doing a
capture. those were design goals.
you can eve
Tim Cross writes:
> I think I totally get where your coming from and I agree with all
> points. However, I don't quite get exactly what Arthur is proposing at a
> concrete level.
>
> Overall, I guess my main concern is that this is one of those areas
> where it looks deceptively easy to improve
Ihor Radchenko writes:
> Tim Cross writes:
>
>> I'm not sure I really understand the exact goal you have here. To me, it
>> feels like yet another input selection/menu/completion scheme and I'm
>> not clear on how it will be an improvement or why do something
>> 'different' in org compared to
Samuel Wales writes:
> [accessbilty/refactoring aside, i want to say i really like many
> aspects of the care taken to make many of our menus. e.g. kw
> selection or tag selection use colors, have low key count. date
> selection too. i wonder how much of this will survive?]
Everything must su
Tim Cross writes:
> I'm not sure I really understand the exact goal you have here. To me, it
> feels like yet another input selection/menu/completion scheme and I'm
> not clear on how it will be an improvement or why do something
> 'different' in org compared to other modes etc. However, I also d
Arthur Miller writes:
> The command will then make a temporary buffer listing all entries
> that can be selected with a single key, and all the single key
> prefixes. When you press the key for a single-letter entry, it is selected.
> When you press a prefix key, the commands (and maybe further
Arthur Miller writes:
>> Could you provide a bit more details? How exactly will the usage differ
>> from read-key?
>
> Short here: it will be ordinary text buffer, read only of course, with its own
> major mode derived from special mode and buffer local key maps, instead of
> major
> mode global
[i put an unnecessary and not really meant word truly there.
accessbililty reasons could of course make it necessary.]
i think it is needed to do accessibility and great to do factoring.
shows our maturity as a project and developers.
[accessbilty/refactoring aside, i want to say i really like ma
i must be confused. menus aside, you can currently capture and it
uses the org forest itself, so it is both crash-proof and snappy. and
you can yakshave as much as you want, starting a capture while doing a
capture. those were design goals.
you can even be in the middle of a capture, get distra
On 05/06/2022 22:07, Arthur Miller wrote:
Max Nikulin writes:
After input from Ihor I agree that it isn't the best way, and was
able to refactor org-mks to create a menu where I can execute any lisp form,
when it comes in a list like this : ("h" "hello-word" (message "Hello,
World")), where thir
Arthur Miller writes:
> Ihor Radchenko writes:
>
>> Arthur Miller writes:
>>
>>> However before I continue, I am thinking of ditching the 'read-key'
>>> completely
>>> and switching to "standard" Emacs way of implementing interactivity via
>>> mode and
>>> mode-map. I am currently playing w
Ihor Radchenko writes:
> Arthur Miller writes:
>
>> However before I continue, I am thinking of ditching the 'read-key'
>> completely
>> and switching to "standard" Emacs way of implementing interactivity via mode
>> and
>> mode-map. I am currently playing with such implementation, which to me
Max Nikulin writes:
> On 04/06/2022 22:35, Arthur Miller wrote:
>>
>> However before I continue, I am thinking of ditching the 'read-key'
>> completely
>> and switching to "standard" Emacs way of implementing interactivity via mode
>> and
>> mode-map. I am currently playing with such implementa
On 04/06/2022 22:35, Arthur Miller wrote:
>
However before I continue, I am thinking of ditching the 'read-key' completely
and switching to "standard" Emacs way of implementing interactivity via mode and
mode-map. I am currently playing with such implementation, which to me appears
both simpler (
Arthur Miller writes:
> Hello again; I have been playing with this, and so far the biggest problem is
> that I get too many ideas as longer I refactor the existing code :).
:)
> However, I have a question: would it be acceptable for org-capture to change
> the
> input model?
>
> I have impleme
Ihor Radchenko writes:
>>> The above statement is a hint that patches are welcome :)
>>
>> As said, I am not that well familiar with org in-depth, and with other places
>> that might need to be factored out, so I don't promise anything. Initially I
>> just got a quick idea while working on a proj
oal as you present here.
Sorry for a bad formatting, I am typing this from my phone.
Originalmeddelande
Från: Max Nikulin
Datum: 2022-05-31 18:37 (GMT+01:00)
Till: Arthur Miller
Kopia: emacs-orgmode@gnu.org
Ämne: Re: Proposal: 'executable' org-capture-templaes
On 30/0
On 30/05/2022 09:04, Arthur Miller wrote:
Ihor Radchenko writes:
Arthur Miller writes:
Simplicity comes from the org-templates. Me, and I guess other people are
familiar with org-catpure templates already, and I mean, can it be simpler to
create a menu of choices then a simple list:
'(("key1"
Ihor Radchenko writes:
> Arthur Miller writes:
>
>> Instead of hardcoding the actual work in the conditional statement, there
>> should
>> be a function to be called, so org-capture would setup its own work, some
>> random
>> "exec" menu like here would setup its own and so on. I haven't look
Arthur Miller writes:
> Instead of hardcoding the actual work in the conditional statement, there
> should
> be a function to be called, so org-capture would setup its own work, some
> random
> "exec" menu like here would setup its own and so on. I haven't look at other
> parts of org you have
Ihor Radchenko writes:
> Arthur Miller writes:
>
>>> By "generic" I did not mean general-purpose all-functional framework.
>>> We just need something to remove code duplication in
>>> org-export-dispatch, org-agenda, org-capture, org-set-tags-command, etc
>>> They all share pretty similar code t
Arthur Miller writes:
>> By "generic" I did not mean general-purpose all-functional framework.
>> We just need something to remove code duplication in
>> org-export-dispatch, org-agenda, org-capture, org-set-tags-command, etc
>> They all share pretty similar code to generate dialogues.
>>
>> As f
Ihor Radchenko writes:
> Arthur Miller writes:
>
>> Simplicity comes from the org-templates. Me, and I guess other people are
>> familiar with org-catpure templates already, and I mean, can it be simpler to
>> create a menu of choices then a simple list:
>>
>> '(("key1" "label1" exec (lambda ()
Arthur Miller writes:
> Simplicity comes from the org-templates. Me, and I guess other people are
> familiar with org-catpure templates already, and I mean, can it be simpler to
> create a menu of choices then a simple list:
>
> '(("key1" "label1" exec (lambda () ...))
> ("key2" "label2" exec (
On 27/05/2022 19:17, Arthur Miller wrote:
Ihor Radchenko writes:
Is there any reason why you dislike transient (now part of Emacs core)?
It is not about me disliking transient, I am sure it is a great library. It is
more about simplicity and efficiency. Entire org-capture is ~2/3 of the size
Ihor Radchenko writes:
> Arthur Miller writes:
>
>> I was playing with org-capture today, and it strike me that it could be used
>> as
>> a simple and lightweight alternative to create GUIs for user options,
>> somewhat
>> resembling the use of well-known hydra/transient or built-in help macro
Arthur Miller writes:
> I was playing with org-capture today, and it strike me that it could be used
> as
> a simple and lightweight alternative to create GUIs for user options, somewhat
> resembling the use of well-known hydra/transient or built-in help macro or
> easy
> menu.
Is there any re
Hi guys,
I was playing with org-capture today, and it strike me that it could be used as
a simple and lightweight alternative to create GUIs for user options, somewhat
resembling the use of well-known hydra/transient or built-in help macro or easy
menu.
I would like to propose a small 'feature/c
57 matches
Mail list logo
