Re: [BUG] org-capture: %\N template expansion

[Ihor Radchenko]

Bruno Cardoso  writes:

> I'm having trouble expanding the '%\N' template in org-capture.
>
> For example, with the following template:
>
> (add-to-list 'org-capture-templates
>  '("t" "TEST" entry
>(file+headline "~/org/test.org" "TEST")
>"** TODO %?
> :PROPERTIES:
> :TITLE:%^{TITLE}
> :AUTHOR:   %^{AUTHOR}p
> :END:
> %\1 %\2"))
>
> The properties are read correctly, but "%\1 %\2" expands to "%^A %^B".

That's expected - you do need to escape \ in Elisp strings. \1 in string
is ^A (Ctrl-A) and \2 is ^B.

> Either escaping the backslashes ("%\\1 %\\2") or reading the template above 
> from a file throws an error:
>
> : org-capture: Capture abort: Wrong type argument: stringp, nil

That's because you can only use %\N placeholder for %^{prompt} but not
for %^{prompt}X.

Try

(add-to-list 'org-capture-templates
 '("t" "TEST" entry
   (file+headline "~/org/test.org" "TEST")
   "** TODO %?
:PROPERTIES:
:TITLE:%^{TITLE}
:AUTHOR:   %^{AUTHOR}
:END:
%\\1 %\\2"))

We can probably improve the error and the docstring to clarify this.

We may also make %^{prompt}X expansions to work with %\N, but it can
break the existing templates that are tuned to the current behaviour.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [FR] :noweb-wrap header arg

[Ihor Radchenko]

Amy Grinn  writes:

>> I recommend the following:
>>
>> If the value starts from ", use Elisp's `read':
>>|"# <<" ">>"
>>(read (current-buffer)) ; => "# <<"
>>otherwise, consider read until the first whitespace.
>>|#<<; >>;
>>(re-search-forward (rx (1+ (not whitespace
>>#<<;|
>>
>> However, there may be edge cases like
>>
>> "<< >>"
>> "<< >>
>> << << >>
>> << "asd" >>
>
> I didn't implement this recommendation yet; I still think the regex is a
> more clear way of putting it, even without using a temporary buffer:
>
> ;; If a pair of " is found separated by one or more
> ;; characters, capture those characters as a group
> (unless (eq i (string-match (rx (* space) ?\"
> (group (+ (not ?\")))
> ?\" (* space))
> raw i))
>   ;; Otherwise, capture the next non-whitespace group of
>   ;; characters
>   (string-match (rx (* space) (group (* (not space))) (* space))
> raw i))
>
> Let me know what you think!

Consider cases like

"< \"" "\" >"

or

"< >"

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] org-capture: %\N template expansion

[Bruno Cardoso]

On 2024-05-23, 11:13 +, Ihor Radchenko  wrote:

> That's because you can only use %\N placeholder for %^{prompt} but not
> for %^{prompt}X.
> ...
> We can probably improve the error and the docstring to clarify this.

Thanks for the explanation, Ihor. I expected it to work in both cases, as the 
property prompt with value completion is very useful. I feel the error and the 
docstring can be confusing in this regard.

> We may also make %^{prompt}X expansions to work with %\N, but it can
> break the existing templates that are tuned to the current behaviour.

I see. Would it make sense to have another placeholder for '%^{prompt}X'?

Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...))

[Bruno Barbier]

Hi Ihor,

Ihor Radchenko  writes:

> Bruno Barbier  writes:
>
>> I've pushed the modification to my branch.
>
> Thanks! Let's work further on the top comment.
>
>> ;; To lock a region, you need to do something like this:
>
> I think "something like this" can be just dropped.

Sorry, I'm failing to find a simpler accurate sentence.


>> ;;1. Call the function `org-pending' with the region to lock; use
>> ;;   the ON-OUTCOME argument to tell Emacs how to update the
>> ;;   region.  Keep the returned REGLOCK (you'll need it to send
>> ;;   updates).
>
> It would be nice to provide examples of `org-pending' call right in the
> top comment. Ideally, the example should also show how to modify REGLOCK
> fields to customize its behaviour.

I added an example below the 2 steps.

>> ;;2. Start "something" that computes the new content.  That
>> ;;   "something" may be a thread, a timer, a notification, a
>> ;;   process, etc.  That "something" must eventually send a
>> ;;   :success or :failure message (using
>> ;;   `org-pending-send-update'): Emacs will update the pending
>> ;;   region (using your ON-OUTCOME) and unlock it; at this point
>> ;;   the lock is "dead" (not live-p).
>
> Please also add information about sending updates to the REGLOCK, with
> examples. Otherwise, "receiving progress" in the next section is
> surprising.

Done in the example too.

>> ... (not live-p)
>
> Please name `org-pending-reglock-live-p' - it is more clear than forcing
> the readers search it themselves.

Done.

>
>>  Interface provided to the Emacs user
>> ;;
>> ;; The library makes locks visible to the user using text properties
>> ;; and/or overlays.  It diplays and updates the status while the
>> ;; region is locked: the initial status is "scheduled", then, when
>
> It would be nice to name `org-pending-reglock-status' here and use the
> actual status values - :scheduled, :pending, :success, :failure.
> Ideally, in table/list explaining what happens with buffer text,
> overlays, and user interaction, when REGLOCK has each of the listed
> status values.

I added a table describing the possible status values, the valid
updates, etc in the section above.


>
>> ;; receiving progress it becomes "pending" (with progress information
>> ;; if any).  Emacs allows to diplay a description of the lock.  From
>> ;; that description, the user may request to cancel that lock; see the
>> ;; field `user-cancel-function' of the REGLOCK object if you need to
>> ;; customize what to do on cancel.
>
> It is not very clear how user can interact with "description".
> Is it a  tooltip? A window? Something else? Please give a bit more details.

I added that it's like the function `describe-package'.

> Also, when "cancel" is requested, it is a good idea to state that
> `user-cancel-function' is called and describe what it does by default.

The function `user-cancel-function' is not always called; Emacs will
only call it if the lock is still live (see `org-pending-cancel').

I added a short sentence describing what is done by default (the
documentation of the field `user-cancel-function' of the reglock
object already fully document `user-cancel-function').


>> ;; When receiving the outcome (success or failure), after unlocking
>> ;; the region, the library may leave information about the outcome
>
> "may"?? Or does it always leave the information (by default)?

To mark the outcome, org-pending needs to know where it is.  If the
ON-OUTCOME function (see `org-pending` documentation) returns the
outcome region, org-pending will add a mark, else not.  By default,
ON-OUTCOME is nil, meaning no outcome region and no outcome marks.  I
added a sentence about that.


>> ;; (using text properties/overlays).  If that outcome information is
>> ;; (still) displayed, Emacs allows to display a description of that
>> ;; lock.  From that description, the user may decide to "forget" that
>> ;; lock; "forgetting the lock" removes the outcome visual marks, and,
>
> Is "forgetting" customizeable like `user-cancel-function'?

No.

>> ;; it allows Emacs to discard any information related to this lock.
>
> What does it mean?

Emacs is free to delete any data related to this lock.  This lock will
not be available anywhere anymore for the user. Concretely, this lock
is remove from the list of known locks, and, eventually, Emacs should
hopefully garbage collect the related data.

>
>> ;; The description of a lock (live or dead) provides information like
>> ;; the schedule time, the duration, the outcome time, the result (in
>> ;; case of success), the error (in case of failure), etc.  Customize
>> ;; the field `insert-details-function' of REGLOCK object to add your
>> ;; own information.
>
> Please show an example how to do it here.

Done.

>
>> ;; If the user kills a buffer, or, kills Emacs, some locks may have to
>> ;; be killed too be killed too.  The library will ask the user to
>  ^^^
> typo

T

Re: Bug: org-capture does not work if called from minibuffer (Org mode version 9.6.10 (9.6.10-n/a-g902975)

[Ihor Radchenko]

Clément Payard  writes:

> Version: Org mode version 9.7-pre (9.7-pre-n/a-g1c5492)
> (I hope it's the last, I use elpaca).
>
> No, the behavior is not actually the same: for me (hoping my configuration
> doesn't interfere), everything goes “as expected”, except that the second
> capture cancels the first.
>
> In other words, I can insert, in the title of the first one (using
> org-roam-node-insert):
>
> [[id:idOfTheSecondCaptureAlreadyDid][aDescription, the second capture]]
>
> BUT, when I finish the first one, I get the error:
> Error running timer 'org-capture': (error “Capture abort: Selecting deleted
> buffer”).
>
> So you can't stack captures?

You can stack captures.
Also, org-capture does not start any timers.
May you provide steps to reproduce the problem you are seeing starting
from clean Emacs?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

filling more narrowly --- or unfilling -- for export to email, upon ascii export

[Samuel Wales]

thanks both.

> I write my email using org syntax and then invoke
>
> M-x org-mime-htmlize RET
>
> just before sending.

i'm guessing that would solve all formatting issues.  not sure how quoting
[top post or interstitial] conversations would work.

however, last time i tried sending html through webmail, i couldn't gt it
to send as html, as opposed to html as text.  perthaps there is a trick to
it.


as for ihor's suggestion, i tried (setq org-ascii-text-width
most-positive-fixnum) and then realized that it would likely wrap plain
lists thus:

  - this is a list with a really long line which is like an unfilled
paragraph and here it is filling but not to the fill-prefix org fills it to


i'm guessing there is maybe no solution.  [i have had bad luck with geary
and thunderbird, and unfortunately setting up emacs mail is at this time is
too much for me [and not as accessible for me as webmail for various
reasons [including but not limited to full mouseability]].]

the workaround might be to set a really narrow fill column, i wonder?  not
sure.



-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com