capturing and filling

capturing and filling

[Samuel Wales]

when i use the superb org-capture extension in firefox, there is only
one icon, so any decisions about formatting have to be
one-size-fits-all at capture time in elisp.  here are my ideas, but
not implementation.  the decisions i'd make are:

1.  fill long unfilled paragraphs vs. preserve verbatim lines

if i capture code, i don't want it filled.  if i capture prose that is
unfilled, as in a long line, i probably want it filled at capture.

heuristic: loop through every line.  if the line qualifies by some
sub-heuristic, and is more than 2x (window-width), then fill at
capture time, but only that line, not contiguous ones that do not meet
the sub-heuristic (different prefix etc.).

what does one do to loop through paragraphs?  is this a reasonable
heuristic?  anybody tried it?  this is all too much for me atm but i
thought i'd pu out the idea in case anybody has thought of these
things.

alternative: figure out and use an emacs minor mode that makes
unfilled paragraphs look like filled ones, including fill-column,
filling word boundary heuristics, fill prefix, etc.  this would still
interfere with diff and such.  it might be best reserved for this
purpose rather than ridding me of my m-q filling habit.  that would be
drastic.

2.  region on org heading vs. in body

heuristic: if selected text is zero length, i.e. nonexistent, then
link on org heading.  if it is short, "text -- [link]".  if long, then
i'm not sure which i like better: short part of first line on header
and then rest and then "-- [link]", or link on header.


-- 
The Kafka Pandemic

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

Re: capturing and filling

[Max Nikulin]

On 07/04/2023 10:29, Samuel Wales wrote:
> when i use the superb org-capture extension in firefox, there is only
> one icon, so any decisions about formatting have to be
> one-size-fits-all at capture time in elisp.

Samuel, in your case, it is your requirement to have non-distracting 
single-click capture.

I admit that the feature is not implemented in browser add-ons.

A workaround is to define 2 capture template: for prose text and for 
code. Browser extension should not add template=x query parameter to 
org-protocol URI.

Extension may determine if the captured text pre-formatting, however 
there are some complications. Besides <pre> and <code> tags, there may 
be <div> and <span> elements with white-space: pre-wrap CSS property and 
similar. Selection may consist of several regions, each one with mix of 
regular and pre-formatted text.

Actually it is possible to convert selected text to Org markup. use

     %(insert (shell-command-to-string "xclip -t text/html -o | pandoc 
-f html -t org -"))

in your capture template. Possible caveats: headers, especially <h1> may 
give undesired effect.

Re: capturing and filling

[Samuel Wales]

hi max,

more below.

On 4/6/23, Max Nikulin <manikulin@gmail.com> wrote:
> Samuel, in your case, it is your requirement to have non-distracting
> single-click capture.

... but one icon for prose/filling and one for lines/nonfilling would
be great for me.  or even the existing single icon for whichever one i
use most, with a right-click menu for other options.   maybe other
templates.

> A workaround is to define 2 capture template: for prose text and for
> code. Browser extension should not add template=x query parameter to

i was thinking that would be a great solution.  however, i cannot
implement it.  i was thinking elisp workaround might be more
straightforward.

i am guessing you mean s/should not/should/ here?

> org-protocol URI.
>
> Extension may determine if the captured text pre-formatting, however
> there are some complications. Besides <pre> and <code> tags, there may
> be <div> and <span> elements with white-space: pre-wrap CSS property and
> similar. Selection may consist of several regions, each one with mix of
> regular and pre-formatted text.

i was thinking figuring it out from the selection and the html  would
be horrendously complex and brittle and error prone.  but i could be
wrong.

>
> Actually it is possible to convert selected text to Org markup. use
>
>      %(insert (shell-command-to-string "xclip -t text/html -o | pandoc
> -f html -t org -"))
>
> in your capture template. Possible caveats: headers, especially <h1> may
> give undesired effect.

i selected one line and it printed that line.  i selected your above
lines and got Error: target text/html not available.

>
>
>


-- 
The Kafka Pandemic

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

Re: capturing and filling

[Max Nikulin]

On 07/04/2023 11:40, Samuel Wales wrote:
> 
> On 4/6/23, Max Nikulin wrote:
>> Samuel, in your case, it is your requirement to have non-distracting
>> single-click capture.
> 
> ... but one icon for prose/filling and one for lines/nonfilling would
> be great for me.  or even the existing single icon for whichever one i
> use most, with a right-click menu for other options.   maybe other
> templates.

An extension can not add 2 buttons. It may define context menu for right 
click or it may open a popup with menu (implemented as an HTML page) on 
simple (left) click.

Till it is not implemented you may use an org-protocol handler that 
displays menu from e.g. a shell script:

printf 'Prose\nCode\n' |
     zenity --list --title "Capture template" \
         --text "Capture type" --column Template

or

zenity --question --title "Capture template" --text "Capture type" \
     --ok-label Prose --cancel-label Code

>> A workaround is to define 2 capture template: for prose text and for
>> code. Browser extension should not add template=x query parameter to
> 
> i am guessing you mean s/should not/should/ here?

If template is not passed then script can just append &template=x to the 
URI, otherwise it may call e.g. sed to replace existing parameter.

>>       %(insert (shell-command-to-string "xclip -t text/html -o | pandoc
>> -f html -t org -"))
>>
> i selected one line and it printed that line.  i selected your above
> lines and got Error: target text/html not available.

Select some text on a web page in Firefox (or similar application 
supporting rich text copy, e.g. libreoffice writer) and try

     xclip -t TARGETS -o

I have realized that `insert' should not be added to template, the code 
above is more suitable for evaluation by M-:

Next revision (with escaped quote characters)

"* %:description
<%:link>

%(shell-command-to-string \"xclip -t text/html -o | pandoc -f html -t 
org -\")
"

Re: capturing and filling

[Max Nikulin]

On 07/04/2023 10:29, Samuel Wales wrote:
> heuristic: loop through every line.  if the line qualifies by some
> sub-heuristic, and is more than 2x (window-width), then fill at
> capture time, but only that line, not contiguous ones that do not meet
> the sub-heuristic (different prefix etc.).

Somebody should debug such heuristics. Fortunately no modification of 
Org is necessary to evaluate if it may be implemented. Something like 
the following may be added to capture template.

%(let* ((query (plist-get org-store-link-plist :query))
         (body (plist-get query :body)))
     ;; wrap lines in body accordingly e.g. to `fill-column'
)

Of course, there should be a function that implements heuristics to 
facilitate debugging and to allow unit tests.

Re: capturing and filling

[Samuel Wales]

i am very sorry, i got myself in over my head.  i do not undestrand
what you are suggesting.  if a change on the ff side i cannot do it,
bu perhaps you are suggesting making emac pop up an x seector that
chooses the filing option.

for yers i have used an unsophisticated heursitic in the template
simiilar to your teplate suggestion.

but now the problem is htat this essential ff extension is completely
broen for me.  i upgraded firefox, and now it is popping up a window
asking [unselectable text paraphrasing] whether i want emacsclient
oprning protocol iink.

i affirm but no capture occurs.

so no capture at all, never mind a choice of filling.



On 4/6/23, Max Nikulin <manikulin@gmail.com> wrote:
> On 07/04/2023 11:40, Samuel Wales wrote:
>>
>> On 4/6/23, Max Nikulin wrote:
>>> Samuel, in your case, it is your requirement to have non-distracting
>>> single-click capture.
>>
>> ... but one icon for prose/filling and one for lines/nonfilling would
>> be great for me.  or even the existing single icon for whichever one i
>> use most, with a right-click menu for other options.   maybe other
>> templates.
>
> An extension can not add 2 buttons. It may define context menu for right
> click or it may open a popup with menu (implemented as an HTML page) on
> simple (left) click.
>
> Till it is not implemented you may use an org-protocol handler that
> displays menu from e.g. a shell script:
>
> printf 'Prose\nCode\n' |
>      zenity --list --title "Capture template" \
>          --text "Capture type" --column Template
>
> or
>
> zenity --question --title "Capture template" --text "Capture type" \
>      --ok-label Prose --cancel-label Code
>
>>> A workaround is to define 2 capture template: for prose text and for
>>> code. Browser extension should not add template=x query parameter to
>>
>> i am guessing you mean s/should not/should/ here?
>
> If template is not passed then script can just append &template=x to the
> URI, otherwise it may call e.g. sed to replace existing parameter.
>
>>>       %(insert (shell-command-to-string "xclip -t text/html -o | pandoc
>>> -f html -t org -"))
>>>
>> i selected one line and it printed that line.  i selected your above
>> lines and got Error: target text/html not available.
>
> Select some text on a web page in Firefox (or similar application
> supporting rich text copy, e.g. libreoffice writer) and try
>
>      xclip -t TARGETS -o
>
> I have realized that `insert' should not be added to template, the code
> above is more suitable for evaluation by M-:
>
> Next revision (with escaped quote characters)
>
> "* %:description
> <%:link>
>
> %(shell-command-to-string \"xclip -t text/html -o | pandoc -f html -t
> org -\")
> "
>
>
>
>
>


-- 
The Kafka Pandemic

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

Re: capturing and filling

[Max Nikulin]

On 15/04/2023 08:36, Samuel Wales wrote:
> but now the problem is htat this essential ff extension is completely
> broen for me.  i upgraded firefox, and now it is popping up a window
> asking [unselectable text paraphrasing] whether i want emacsclient
> oprning protocol iink.
> 
> i affirm but no capture occurs.

Please, start a new thread specific to org-protocol configuration and 
Firefox. Post Firefox, Emacs, Org versions, content of your .desktop 
file for org-protocol. There are enough subtle issues and dedicated 
thread may help other user in troubleshooting of similar problems.

Re: capturing and filling

[Max Nikulin]

On 15/04/2023 08:36, Samuel Wales wrote:
> i am very sorry, i got myself in over my head.  i do not undestrand
> what you are suggesting.  if a change on the ff side i cannot do it,
> bu perhaps you are suggesting making emac pop up an x seector that
> chooses the filing option.

My idea is to setup as org-protocol: URI handler a simple script (e.g. 
shell) that displays a GUI dialog what template should be used, modifies 
the received URI to set &template= parameter, and passes the URI to 
emacsclient. There is a number of GUI dialog utilities for using from 
shell scripts: zenity, kdialog, gxmessage, yad, etc. Such implementation 
does not require any modification of browser extension or Org code.