Re: Is there a better (built-in) way to insert an org link with title as description?

[Arthur Miller]

Ihor Radchenko  writes:

> Arthur Miller  writes:
>
>>> (org-link-set-parameters "http" :insert-description #'your-function)
>>> (org-link-set-parameters "https" :insert-description #'your-function)
>>
>> Thanks, after some thinkering I got it:
>>
>> ...
>> (org-link-set-parameters "http" :insert-description 
>> #'org-desc-from-clipboard)
>> (org-link-set-parameters "https" :insert-description 
>> #'org-desc-from-clipboard)
>> #+end_src
>>
>> And I can do it async too, *but*; this will affect all insertions of links,
>> right?
>
> Indeed. By design, `org-insert-link' is synchronous - it expects the
> link and description to be available upon request.
>
>> I am not sure if it is safe/possible always to access the internet or do
>> it asynchronously, so I'll abandon the ship and revert to home-cooked one 
>> just
>> for the precautios measures:
>
> What you can do is (1) make url descriptions be something like  be retrieved>; (2) add an :after advice for `org-insert-link' that will
> queue asynchronous url fetching; (3) replace 
> with the fetched title upon finishing the request. If the request fails,
> the description will remain .

Yes of course, placeholders could work. Another option is to use url as
a placeholder, so if the retrieval failed the url would still be visible
which is a bit more informative than some generic placholder.

> Or you can run description retrieval independently, as a minor mode
> that will search for  marks and try to fetch
> them.

True. I could also run an idle timer on my notes file and try to patch
all urls without descriptions. Would need to put something as a marker
into a desription for dead links, or just remove them, so they are not
fetched over and over again.

However, I am ok with doing it on the request only, when I actually
create a note :).

But if someone adds something similar to org, I'll gladly use it :).

Thanks and sorry the  late response. My memory is like a gold fish,
sometimes when GNUS remove a mail from my view I totally forget about
it.

/a

Re: Is there a better (built-in) way to insert an org link with title as description?

[Arthur Miller]

Ihor Radchenko  writes:

> Arthur Miller  writes:
>
>> I want to auto insert a title from an HTML page as description for an org 
>> link in
>> my notes. I stumbled upon some old message by Miro Bezjak on this list:
>>
>> https://lists.gnu.org/archive/html/emacs-orgmode/2012-09/msg01435.html
>>
>> I have seen the replies, but I am not sure how to use
>> org-make-link-description-function
>
> Since that time, Org got a capability to set description function
> per link type. Just use
>
> (org-link-set-parameters "http" :insert-description #'your-function)
> (org-link-set-parameters "https" :insert-description #'your-function)

Thanks, after some thinkering I got it:

#+begin_src emacs-lisp
(defun my-org-insert-link ()
  "Insert org link where default description is set to html title."
  (interactive)
  (let* ((url (or (current-kill 0) (read-string "URL: "
(org-insert-link nil url)))

(defun org-desc-from-clipboard (url _desc)
  "Insert an org link into current buffer from an URL in clipboard."
  (with-current-buffer (url-retrieve-synchronously url t)
(goto-char (point-min))
(let ((title "\\(.*\\)\\(/>\\|\\)"))
  (if (re-search-forward title nil t)
  (string-trim (match-string-no-properties 1))
url

(org-link-set-parameters "http" :insert-description #'org-desc-from-clipboard)
(org-link-set-parameters "https" :insert-description #'org-desc-from-clipboard)
#+end_src

And I can do it async too, *but*; this will affect all insertions of links,
right?

I am not sure if it is safe/possible always to access the internet or do
it asynchronously, so I'll abandon the ship and revert to home-cooked one just
for the precautios measures:

#+begin_src emacs-lisp
(defun org-link-from-clipboard ()
  "Insert an org link into current buffer from an URL in clipboard."
  (interactive)
  (let ((marker (point-marker))
(url (or (current-kill 0) (read-string "URL: "
(url-retrieve
 url
 (lambda (_status title)
   (goto-char (point-min))
   (when (re-search-forward title nil t)
 (setq title (string-trim (match-string-no-properties 1
   (with-current-buffer (marker-buffer marker)
 (save-excursion
   (goto-char (marker-position marker))
   (org-insert-link
nil url (or title url)
 '("\\(.*\\)\\(/>\\|\\)") t t)))
#end_src

But it was a bit of learning, thanks for pointing me in the right direction.

Re: Is there a better (built-in) way to insert an org link with title as description?

[Arthur Miller]

Max Nikulin  writes:

Hi thank you for the thorough and well-informed answer.

> On 19/07/2023 19:06, Arthur Miller wrote:
>> I want to auto insert a title from an HTML page as description for an org 
>> link in
>> my notes.
>> (defun org-link-from-clipboard ()
> ...
>>(url-retrieve url
>> (lambda (buffer)
>>   (goto-char (point-min))
>>   (when (re-search-forward "\\(.*\\)" nil t)
>
> What are origins of your links?

> If it is an URL opened in browser then `org-capture' or
> org-protocol:/store-link/ may be used. There are a number of browser 
> extensions
> for that.

I do use org-protocol, and I do have it in my FFX, so I am aware of it. But
sometimes I copy a link from a readme file or a piece of code or elsewhere and
wish to stash it away in a note but not necessary open in a browser. You know,
"todo" to come back later for it :).

> More metadata sometimes desired and just page title is not enough. For
> extracting it within Emacs see e.g. Ihor's
> https://github.com/yantar92/org-capture-ref
> Search for its discussions on this mailing lists.
>
> Some complications:
> - titles may have &...; entities
> - Not all pages have , so heuristics have to be used.
Yepp, I am aware, the goal was not to be 100% fool proof. I had experienced
sometimes a couple of characters that Emacs can't dissambiguate, but it is not a
problem and yes, in case of no title it will prompt; the other strategy I used
was to return just url itself or "no description". Perhaps I should revert to
just the url.

> - Some HTML files contains nothing besides JavaScript to load actual content
> - Some URLs are from minifiers or obfuscated by Outlook "protection",
>   trampolines to prevent leaking of data through the Referer header, etc. 
> Likely
>  redirection target should be saved, not original URL.
> - Some sites like GitHub have API that allows to get metadata in JSON format. 
> It
>  is better than parsing HTML with regexp.

Yes, I am aware and completely agree with you!

Luckely I am getting quite old by now and don't visit too many sites or sites of
dubious JS character, so for my needs IDC :).

Miros idea served me well for several years now, I just improved it a bit the
other day to skip prmpting for the URL and used asynchornous download to skip
that slight second or two of delay in some links.

> Anyway I suggest to split non-interactive part of the command to allow code
> reuse (for drag and drop, etc.).

Tell me more here? Can I drag a link from one buffer into a note buffer, or how
can I use it?

Thank you for the answer.

Is there a better (built-in) way to insert an org link with title as description?

[Arthur Miller]

Hello Org experts,

I want to auto insert a title from an HTML page as description for an org link 
in
my notes. I stumbled upon some old message by Miro Bezjak on this list:

https://lists.gnu.org/archive/html/emacs-orgmode/2012-09/msg01435.html

I have seen the replies, but I am not sure how to use
org-make-link-description-function, so I coded my own version of Miros idea:

#+begin_src emacs-lisp
(defun org-link-from-clipboard ()
  "Insert an org link into current buffer from an URL in clipboard."
  (interactive)
  (let ((marker (point-marker))
(url
 (if (string-match-p "^\\(http\\|https\\)://" (current-kill 0))
 (current-kill 0)
   (read-string "URL: ")))
(title nil))
(when url
  (url-retrieve url
   (lambda (buffer)
 (goto-char (point-min))
 (when (re-search-forward "\\(.*\\)" nil t)
   (setq title (string-trim (match-string-no-properties 1
 (with-current-buffer (marker-buffer marker)
   (save-excursion
 (goto-char (marker-position marker))
 (org-insert-link
  nil url (or title (read-string "Description: "))
   nil t t
#+end_src

While my function is not very big, I would still like to learn how to use the
suggested built-in stuff from that discussion. I also dislike the interactive
fallback in asynchronous callback if the title is not found, but I would also
dislike to have a bunch of "No description found" strings in my notes too, so I
am not sure which one is less evil there.

Thankful for any help and advice.

RE: Problem with let/cl-letf binding stuff with org-capture

[arthur miller]

Hemma thanks, for some reason, my Emacs does not display the link but it 
does for other functions. Strange.

Thanks for the help!


 Originalmeddelande 
Från: Bruno Barbier 
Datum: 2023-02-15 14:18 (GMT+01:00)
Till: Arthur Miller 
Kopia: Ihor Radchenko , emacs-orgmode@gnu.org
Ämne: Re: Problem with let/cl-letf binding stuff with org-capture

Arthur Miller  writes:

>
> Anyway, a follow question: Where is the source code?!

lisp/textmodes/string-edit.el

> Normally the help window says "... is a Lisp function in ."
>

My Emacs tells me it's an autoloaded function with the usual link.

Bruno

Re: Problem with let/cl-letf binding stuff with org-capture

[Arthur Miller]

Ihor Radchenko  writes:

> Arthur Miller  writes:
>
>> Based on a Reddit thread:
>>
>> https://www.reddit.com/r/emacs/comments/10xhvd8/a_little_readstring_utility_using_an_org_mode/j7xziao/?context=3
>>
>> I did a small experiment to see if I can re-use org-capture, to just capture 
>> a
>> string from a buffer, without actually writing to any file.
>
> You can use a template target set to function pointing to temporary
> buffer. + org-capture-before-finalize-hook

I did try something this:

#+begin_src emacs-lisp
(defun my-func ()
  (with-current-buffer (get-buffer-create "my-capture-buffer")))

(defun my-hook ()
  (with-current-buffer 
  (try-completion "CAPTURE" (mapcar #'buffer-name (buffer-list)))
(let ((content (buffer-string)))
  (kill-buffer)
  content)))

(defun my-read-string ()
  (let ((org-capture-templates
 `(("s" "string" plain (function my-func
(org-capture-before-finalize-hook #'my-hook))
(org-capture nil "s")))
#+end_src

But that does not work well, because capture will put buffer it is called from
as original buffer and write to that one. To prevent that I can call capture
from a temporary buffer:

#+begin_src emacs-lisp
(defun my-read-string ()
  (with-current-buffer (get-buffer-create "my-capture-buffer")
(let ((org-capture-templates
   `(("s" "string" plain (function ignore
  (org-capture-before-finalize-hook #'my-hook))
  (org-capture nil "s"
#+end_src

but than capture complains about the buffer not being a file buffer, despite the
before finalize hook. I could point it to some temp file like /tmp/my-capture, 
by
manipulating capture plist myself, but it seems to be too expensive to create a
temp file just for a hack to read a string form a buffer. There is probably some
other way, but I give up here, especially since you point our
read-string-from-buffer :)

Anyway, thanks for the input and help.

/a

Re: Problem with let/cl-letf binding stuff with org-capture

[Arthur Miller]

Bruno Barbier  writes:

> Hi Arthur,
>
> Arthur Miller  writes:
>
>> Bruno Barbier  writes:
>>
>> ...  but I feel a
>> bit of passive aggressivity here, for no good reason tbh.
>
> I'm just trying to help, giving some valid or invalid advices.  I'm
> sorry that what I wrote, and how I wrote it, made you feel that way.

It is ok, I just don't want us to go into social media discussion style where
there is more important to assert own ego then to come into some insight.

>>>
>>> Yes, let binding is fundamental. But I think it's the first time I see
>>> 'cl-letf' with the 'symbol-function' place.
>>
>> https://nullprogram.com/blog/2017/10/27/
>> https://endlessparentheses.com/understanding-letf-and-how-it-replaces-flet.html
>> https://stackoverflow.com/questions/39550578/in-emacs-what-is-the-difference-between-cl-flet-and-cl-letf
>>
>
> Thanks for these links. I like cl-flet and cl-labels :-)

They are good for introducing *new* bindings, not so for overriding locally.

>>>> but I am not sure if I can do anything here without introducing at-least an
>>>> extra keymap, to not install into the org-capture-mode-map, so I can as 
>>>> well
>>>> create a minor mode, but at this point it is not much different than
>>>> re-invinting the read-string, so I'll terminate my experiment here :).
>>>
>>> You can replace the buffer keymap with a keymap that only contain your 
>>> custom
>>> keys, and inherits everything else from org-capture-mode-map.
>>
>> Isn't that what I wrote: introducing an extra keymap?
>> Of course I can solve the problem differently, but that was not what question
>> was about :).
>
> Right. Even when inheriting from the old keymap, it's still building a
> new keymap.  Sorry :-)
>
>
>> Well, I definitely understand you, and agree that overwriting function for
>> everyone and everything is not the best idea, but unfortunately bindings 
>> work as
>> they do in Emacs. I would prefer to have a local binding, with cl-flet, but 
>> this
>> does not work in Emacs:
>>
>> (defun my-read-string (prompt)
>>   (let ((delta 20 )
>> (minibuffer-mode-map org-mode-map))
>> (window-resize (minibuffer-window) delta)
>> (cl-flet ((org-ctrl-c-ctrl-c ()
>> (interactive)
>> (let ((s (buffer-string)))
>>   (exit-minibuffer) s))
>>   (minibuffer-mode () #'org-mode)
>>   (minibuffer-complete-and-exit () #'org-return)
>>   (org-kill-note-or-show-branches () #'keyboard-escape-quit))
>>   (read-string (concat "# Press C-c C-c to continue, C-c C-k to 
>> cancel\n# "
>>   prompt "\n\n")
>
> Yes. cl-flet looks safe to me :-)
>
>>
>> Hooks serve a different purpose. Advice can serve same purpose with exactly
>> same side effect, and some other limitations. With some care, let-binding is
>> still more "local" then advice. With other words, I agree with you about the
>> problems, but not with dogmatic approach that it should never be done, and
>> that hooks and advices are the replacement.
>
> Sorry if my words sounding dogmatic.
> Else, I agree too :-)
>
>
>>>
>>>> I am very interested to hear more on the topic, since I would definitely 
>>>> like to
>>>> learn more about different techniques.
>>>
>>> Variables are designed to be overriden (let bounds). Functions are not
>>
>> I have never heard before that functions are not designed to be overriden. I
>> think of them as two slots in a symbol structure; let creates bindings for 
>> value
>> slot, and flet for function slot. Functions are just objects or data as any
>> other value in lisp.
>>
>>> (as there is only one binding at any given time).
>>
>> Yes, unfortunately, in Emacs it is so;
>
> ok. We do really agree then :-)
>
>
>> but I don't think it should be > :).
>
> ... oh no ! ;-)
>
>
>>
>> There is an interesting package by Nick Ferrier
>>
>> https://github.com/nicferrier/emacs-noflet
>
>> but it does not seem to work, at least not for me.
>
> It's almost like a temporary advice ;-)
>
>
> About your use case, if what you need is asynchronous editing, maybe the
> with-editor package will be of interest to you:
> https://github.com/magit/with-editor/blob/main/lisp/with-editor.el
> 
> It allows sub-processes to call Emacs for editing tasks. It's used by
> magit. It's easy enough to reuse. I'v

Re: Problem with let/cl-letf binding stuff with org-capture

[Arthur Miller]

Bruno Barbier  writes:

> Arthur Miller  writes:
>
>> Bruno Barbier  writes:
>>
>>> Arthur Miller  writes:
>>>
>>> The hook `org-capture-mode-hook' will be run in your special
>>> capture buffer. You can override the "C-c C-c" binding only there.
>>
>> Yes and in every other capture buffer
>
> No. If you modify the hook only during your call to 'org-capture', it
> will be called only once in your buffer.
>
>>> Even if I could let bind the function at the right time, I would avoid
>>> that solution, as I can't garantuee that this global hack will not break
>>> other parts of Emacs (other captures, output filters, threads, timers,
>>> etc.).
>>
>> Why do you think it will break other parts? This is not a global hack, on 
>> contrary it
>> exactly tries to prevent to be "global" in entire Emacs, by let-binding a 
>> name
>> to a local lambda, which becomes "global" only in that buffer. If that
>> explains.
>
> You are assigning a local value to the global binding. Everything in
> Emacs will use your functions until you exit the cl-letf. It's like if
> you were using 'fset'.

Yes, you are totally correct; unfortunately binding with cl-flet or cl-labels,
does not work, so binding the global is the only one that works.

> Here is an example that uses cl-letf. Note that the call to
> async-shell-command is outside the "local" binding, yet, the cl-letf
> breaks it. You should try this in an other Emacs, just in case.
>
> (defun oops ()
>   (let ((v (async-shell-command "date" "!sh async")))
> (cl-letf
> (((symbol-function 'comint-output-filter)
>   (lambda (proc string)
> (message "async-shell-command is using my binding: %s" string)
> (read-string "What's the password?"
>   (read-string "what: ")
>   )))
> (oops)

Yes, I definitely agree with you about the concerns, which are certainly
valid, but you would get same effect with advice, it is not different at
all. The difference is that let-binding is automatically removed and installed,
and only active during the cl-letf, while advice is manually installed and
active until manually removed. It is not about the tool, but what you do with
the tool.

>> Here is another version on the same theme, where I don't think you could 
>> modify the local
>> environment without let-binding at all:
>>
>> #+begin_src emacs-lisp
>> (defun my-read-string (prompt)
>>   (let ((delta 20 )
>> (minibuffer-mode-map org-mode-map))
>> (window-resize (minibuffer-window) delta)
>> (cl-letf (((symbol-function 'org-ctrl-c-ctrl-c)
>>(lambda ()
>>  (interactive)
>>  (let ((s (buffer-string)))
>>(exit-minibuffer) s)))
>>   ((symbol-function 'minibuffer-mode) #'org-mode)
>>   ((symbol-function 'minibuffer-complete-and-exit) #'org-return)
>>   ((symbol-function 'org-kill-note-or-show-branches) 
>> #'keyboard-escape-quit))
>>   (read-string (concat "# Press C-c C-c to continue, C-c C-k to 
>> cancel\n# " prompt "\n\n")
>> #+end_src
>
> I hope I've convinced you to not do that. I definitely will not try it,
> as Emacs needs a working minibuffer for plenty of things: debugging,
> saving, quitting, etc.

Your minibuffer will continue to work during and after that function. If you
don't use recursive minibuffer, that will only affect the internal buffer
created by read-string.

If recursive minibuffer is enabled, yes they will also be affected. Of course,
there is no reason for you to try that, that was just an example, but I feel a
bit of passive aggressivity here, for no good reason tbh.

>> read-string is written in C and creates its own minibuffer, which is deleted 
>> by
>> the time read-string exits. I don't know of any other way to cutomize exactly
>> *that* minibuffer, without installing a hook or advising some functions, 
>> which I
>> think is way less clean and much more "global" than just running the 
>> function in
>> a local environment. As I understand, let binding for this purpose is a 
>> normal
>> technique in lisps, but I am not an expert as said; I am actually 
>> experimenting
>> with this for the purpose of learning and seeing what is possible.
>
> Yes, let binding is fundamental. But I think it's the first time I see
> 'cl-letf' with the 'symbol-function' place.

https://nullprogram.com/blog/2017/10/27/
https://endlessparentheses.com/understanding-letf-and-h

Re: Problem with let/cl-letf binding stuff with org-capture

[Arthur Miller]

Bruno Barbier  writes:

> Arthur Miller  writes:
>
>>> Bruno Barbier  writes:
>>> If you really want to just get the piece of text, you might be able to
>>> use the hook `org-capture-mode-hook' to replace the key binding to
>>> 'C-c C-c' in the capture buffer, so that it calls your own function that
>>> will take the string and call `org-capture-kill'.
>>
>> In this case you wouldn't like to replace the key binding, it would affect 
>> all
>> org-capture buffers; the point is just to replace it when called in certain
>> context (my-read-line). Let-binding the function in this context achieves
>> exactly the same effect of C-c C-c beng bound to my function but without
>> affecting all org-capture-buffers.
>
> The hook `org-capture-mode-hook' will be run in your special
> capture buffer. You can override the "C-c C-c" binding only there.

Yes and in every other capture buffer, so I would either have to test on some
variable, make another mode, or mode-map or something similar. Just to customize
on the key, instead of the value bound to that key.

>>
>> Yes, I am aware of both hooks and advising; but again, with those I would 
>> affect
>> all uses of the function, and that would lead to checking some global state 
>> or
>> variable to switch on, which is not optimal either. With let-binding we can 
>> have
>> different behaviour only in a certain context.
>
> Even if I could let bind the function at the right time, I would avoid
> that solution, as I can't garantuee that this global hack will not break
> other parts of Emacs (other captures, output filters, threads, timers,
> etc.).

Why do you think it will break other parts? This is not a global hack, on 
contrary it
exactly tries to prevent to be "global" in entire Emacs, by let-binding a name
to a local lambda, which becomes "global" only in that buffer. If that
explains.

Here is another version on the same theme, where I don't think you could modify 
the local
environment without let-binding at all:

#+begin_src emacs-lisp
(defun my-read-string (prompt)
  (let ((delta 20 )
(minibuffer-mode-map org-mode-map))
(window-resize (minibuffer-window) delta)
(cl-letf (((symbol-function 'org-ctrl-c-ctrl-c)
   (lambda ()
 (interactive)
 (let ((s (buffer-string)))
   (exit-minibuffer) s)))
  ((symbol-function 'minibuffer-mode) #'org-mode)
  ((symbol-function 'minibuffer-complete-and-exit) #'org-return)
  ((symbol-function 'org-kill-note-or-show-branches) 
#'keyboard-escape-quit))
  (read-string (concat "# Press C-c C-c to continue, C-c C-k to cancel\n# " 
prompt "\n\n")
#+end_src

read-string is written in C and creates its own minibuffer, which is deleted by
the time read-string exits. I don't know of any other way to cutomize exactly
*that* minibuffer, without installing a hook or advising some functions, which I
think is way less clean and much more "global" than just running the function in
a local environment. As I understand, let binding for this purpose is a normal
technique in lisps, but I am not an expert as said; I am actually experimenting
with this for the purpose of learning and seeing what is possible.

Of course, we can always write our own read-string function and re-implement the
function from scratch, which author of that blog actually did. The experiment
was to test if I can modify the existing functionality to re-use, rather than to
re-invent something. Since read-string functions does not let us specify buffer,
mode, etc, let binding is one way of doing it locally.

Considering how org-capture works, the same technique of just modifying the
local environment is not really applicable; now when you reminded me that
capture buffer lives longer then let-binding, I understand what happens. I can
access the buffer after org-capture exits, in my-read-string:

(with-current-buffer
(try-completion "CAPTURE" (mapcar #'buffer-name (buffer-list)))
 (  do the thng  )

but I am not sure if I can do anything here without introducing at-least an
extra keymap, to not install into the org-capture-mode-map, so I can as well
create a minor mode, but at this point it is not much different than
re-invinting the read-string, so I'll terminate my experiment here :).

But I wouldn't speak in some generic terms like "use hooks" or "advise" instead
of let-binding. Let binding is a powerful and legitimate technique to modify
local environment of functions. I am not really sure where it stands in
abstraction, if it is sort-of template, or interface programming, since I am not
that familiar with lisp (yet), but I do understand it has very good and powerful
uses. Consider this 

Re: Problem with let/cl-letf binding stuff with org-capture

[Arthur Miller]

Bruno Barbier  writes:

> Arthur Miller  writes:
>
>> However I see that the binding for the org-capture-finalizer, in capture 
>> buffer,
>> is still the default 'org-capture--default-finalize' and not my lambda.
>>
>> I am really not an expert on emacs lisp; and I do understand that this is
>> somewhat "creative" use of org-capture (to put it nicely :-)), but I would 
>> like
>> to understand what is going on here.
>>
>> I don't understand why let-binding here does not work?
>
> Your bindings probably work. But, as the function `org-capture'
> just *starts* the capture process, they are removed when exiting the
> 'let', before you even begin editing your capture.

Yes of course :) I am quite aware that org-capture just setups the buffer, and
that org-capture-finalize finnishes by writing stuff to files etc, and yet I
have tottally forgott it when writing this. This for opening my eyes.

> I'm not sure I understand your use case:  if you have a piece
> of org text, you can put it anywhere (possibly using refiling).

it is just a fun test. I wouldn't do that myself normally and I have no idea why
the blog author needs it either. If I wanted to input multiline
text into some dokument I would open dokument itself. But this was just a
thought I am testing; you can read in the link I posted in the first mail.

> If you really want to just get the piece of text, you might be able to
> use the hook `org-capture-mode-hook' to replace the key binding to
> 'C-c C-c' in the capture buffer, so that it calls your own function that
> will take the string and call `org-capture-kill'.

In this case you wouldn't like to replace the key binding, it would affect all
org-capture buffers; the point is just to replace it when called in certain
context (my-read-line). Let-binding the function in this context achieves
exactly the same effect of C-c C-c beng bound to my function but without
affecting all org-capture-buffers.

>You can usually use hooks (like `org-capture-mode-hook'):
>   (info "(elisp) Hooks")
>
> or, if it's not possible, you can advise the functions:
>
>   (info "(elisp) Advising Functions")

Yes, I am aware of both hooks and advising; but again, with those I would affect
all uses of the function, and that would lead to checking some global state or
variable to switch on, which is not optimal either. With let-binding we can have
different behaviour only in a certain context.

Anyway, thanks, I needed the reminder above.

cheers
/arthur

Re: Problem with let/cl-letf binding stuff with org-capture

[Arthur Miller]

Ruijie Yu  writes:

> Hi Arthur,
>
> Please excuse my brevity and semi-random line of thought, as I’m replying on 
> mobile right now.  See below. 
>
>> On Feb 10, 2023, at 23:11, Arthur Miller  wrote:
>> 
>> 
>> Based on a Reddit thread:
>> 
>> https://www.reddit.com/r/emacs/comments/10xhvd8/a_little_readstring_utility_using_an_org_mode/j7xziao/?context=3
>> 
>> I did a small experiment to see if I can re-use org-capture, to just capture 
>> a
>> string from a buffer, without actually writing to any file.
>> 
>> My plan was to just let-bind org-capture-finalize with cl-letf:
>> 
>> #+begin_src emacs-lisp
>> (defun my-read-string ()
>> (cl-letf (((symbol-function 'org-capture-finalize) ;; C-c C-c
>>   (lambda ( _) (interactive "P") (buffer-string)))
>>  ((symbol-function 'org-kill-note-or-show-branches) #'kill-buffer)) 
>> ;; C-c C-k
>>  (let ((org-capture-templates '(("s" "string" plain (function ignore)
>>(org-capture nil "s"
>> #+end_src
>
> Based on my somewhat-limited experience with CL (and elisp), I have never seen
> this particular type of letf structure.  What I am used to seeing and writing 
> is
> the following:

It uses "place" or "field" to set the symbol binding, as in setf or incf.

You can read more on SX:

https://stackoverflow.com/questions/39550578/in-emacs-what-is-the-difference-between-cl-flet-and-cl-letf

> (cl-letf ((f (x) (1+ x))
>(1+ (f 2)))
> ; => 4
>
> In particular, IIUC, I don’t think you would need symbol-function here.  Maybe
> you can learn more from the docstring of cl-letf than me trying to drain my
> memory on this topic without reference.
>
> Also, in the code snippet you provided, what *should* org-capture-finalize 
> be?  A function that can be called like this:
>
>(org-capture-finalize arg1 arg2)
>
> ? Or a variable containing a function (reference) that can be called like 
> this:
>
>(funcall org-capture-finalize arg1 arg2)
>
> ?  In the former case you might be able to use cl-letf, and in the latter 
> case you should use let with a lambda value. 
>
>> Unfortunately, that does not work. Regardless of binding, and if I used 
>> cl-letf
>> or cl-flet or cl-labels, or old let, or something brewed on the internet, the
>> binding org-capture see for org-capture-finalize, is the original one from
>> org-capture.el.
>> 
>> My second experiment was to abstract the finalize function into a funcallable
>> fariable in org-capture.el (I have patched org-capture.el with this):
>> 
>> #+begin_src emacs-lisp
>> (defvar org-capture-finalizer #'org-capture--default-finalize)
>> 
>> (defun org-capture-finalize ( stay-with-capture)
>> "Finalize the capture process.
>> With prefix argument STAY-WITH-CAPTURE, jump to the location of the
>> captured item after finalizing."
>> (interactive "P")
>> (funcall org-capture-finalizer stay-with-capture))
>> 
>> 
>> (defun org-capture--default-finalize ( stay-with-capture)
>> "Default implementation for org-capture finalizer function."
>> 
>> ;; this is the original org-capture-finalize just renamed to 
>> "default-finalize"
>> )
>> #+end_src
>> 
>> So I could then have something like this (never mind C-c C-k function being
>> removed):
>> 
>> #+begin_src emacs-lisp
>> (defun my-read-string ()
>> (let ((org-capture-templates '(("s" "string" plain (function ignore
>>  (org-capture-finalizer
>>   (lambda ( _) (interactive "P") (buffer-string
>>  (org-capture nil "s")))
>> #+end_src
>> 
>> However I see that the binding for the org-capture-finalizer, in capture 
>> buffer,
>> is still the default 'org-capture--default-finalize' and not my lambda.
>
> I guess this answers part of my question in my previous paragraph.  Is
> org-capture-finalizer defined via defvar?  If so, does it help if you put an
> empty defvar before the let binding?  If not, maybe someone actually using 
> Emacs
> right now can be of more help here.

These were two different examples; one that let-binds the function
'org-caputre-finalize', via cl-letf and the latter one that was completely
different in which I have defvared a symbol so I can let-bind it as a variable.

>   If not, maybe someone actually using 
> Emacs
> right now can be of more help here.

Don't worry; thanks for the help anyway!

/a

Problem with let/cl-letf binding stuff with org-capture

[Arthur Miller]

Based on a Reddit thread:

https://www.reddit.com/r/emacs/comments/10xhvd8/a_little_readstring_utility_using_an_org_mode/j7xziao/?context=3

I did a small experiment to see if I can re-use org-capture, to just capture a
string from a buffer, without actually writing to any file.

My plan was to just let-bind org-capture-finalize with cl-letf:

#+begin_src emacs-lisp
(defun my-read-string ()
  (cl-letf (((symbol-function 'org-capture-finalize) ;; C-c C-c
 (lambda ( _) (interactive "P") (buffer-string)))
((symbol-function 'org-kill-note-or-show-branches) #'kill-buffer)) 
;; C-c C-k
(let ((org-capture-templates '(("s" "string" plain (function ignore)
  (org-capture nil "s"
#+end_src

Unfortunately, that does not work. Regardless of binding, and if I used cl-letf
or cl-flet or cl-labels, or old let, or something brewed on the internet, the
binding org-capture see for org-capture-finalize, is the original one from
org-capture.el.

My second experiment was to abstract the finalize function into a funcallable
fariable in org-capture.el (I have patched org-capture.el with this):

#+begin_src emacs-lisp
(defvar org-capture-finalizer #'org-capture--default-finalize)

(defun org-capture-finalize ( stay-with-capture)
  "Finalize the capture process.
With prefix argument STAY-WITH-CAPTURE, jump to the location of the
captured item after finalizing."
  (interactive "P")
  (funcall org-capture-finalizer stay-with-capture))


(defun org-capture--default-finalize ( stay-with-capture)
  "Default implementation for org-capture finalizer function."

;; this is the original org-capture-finalize just renamed to "default-finalize"
)
#+end_src

So I could then have something like this (never mind C-c C-k function being
removed):

#+begin_src emacs-lisp
(defun my-read-string ()
  (let ((org-capture-templates '(("s" "string" plain (function ignore
(org-capture-finalizer
 (lambda ( _) (interactive "P") (buffer-string
(org-capture nil "s")))
#+end_src

However I see that the binding for the org-capture-finalizer, in capture buffer,
is still the default 'org-capture--default-finalize' and not my lambda.

I am really not an expert on emacs lisp; and I do understand that this is
somewhat "creative" use of org-capture (to put it nicely :-)), but I would like
to understand what is going on here.

I don't understand why let-binding here does not work? If I take (symbol-functon
'org-capture) I see it is a closure. I am not sure if it has something with the
problem to do? I have tested to disable lexical binding, re-eval things, but
the let-binding seems rock stable :). Nothing makes org-capture to reconsider
using my local let-binding.

I would really like to understand this, so please if someone can explain it, I
will appreciate to hear.

Thanks in advance
/arthur

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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 work well in such scenarion. Some people
>> prefer to keep an Emacs process per project/task for that reason.
>
> A side note rather unrelated to menu for Org mode.
>
> My impression is that Emacs process per task scenario is not supported.

I am not sure if we think of same thing, but "process per task" means simply how
people use Emacs. Some people open each file in a new Emacs process, some people
like to keep different tasks in different instances of Emacs, for example Gnus
in one Emacs, and editing work in another etc. It is not that Emacs has some
feature that would make one prohibit to start Gnus in other session, or to load
same set of files in different Emacs processes, but I don't think it is
necessary either.

> almost certainly requires different init files, but request for a command line

Again, I am not sure if we think of same things here, but I don't think it is
needed, but anyway: 

> option overriding init.el was refused:

do we need it? Aren't -q and -l option enough to load a different file after
startup? There is also -e and -f option that could be used for the purpose of
more customization. 

> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15539
> setting user-emacs-directory at command line invocation
>> So I think the conclusion to this long thread was that we don't want to
>> add a specific switch for this, and instead people can say
>> "XDG_CONFIG_HOME=/whatever emacs" when they want to change these paths.
>> So I'm closing this bug report.
>
> Unfortunately initialization in Emacs is rather tricky and
> emacs -q -l init.el
> may behave differently.
>
> On the other hand the latest variant of org-select is quite close to 
> reasonable
> level of support of multiple instances of the same menu.
>
>>>>> Currently several capture menu instances may be requested though
>>>>> org-protocol (or calling org-capture from emacsclient). The behavior is
>>>>> rather confusing. New menu may help to fix the issue, that is why I
>>>>> raised the question about parallel captures.
>>>> I am not sure which behavior you have in mind.
>>>
>>> try the following commands without selecting a template in an Emacs frame in
>>> between
>>>
>>>  emacsclient 'org-protocol:/capture?url=url-A=title-A=body=A'
>>>  emacsclient 'org-protocol:/capture?url=url-B=title-B=body=B'
>>>
>>>> What I was thinking as a conservative implementation that would not
>>>> introduce any new features is replacing the old menu with the new one
>>>> every time the same menu is called. So, every time the user calls menu
>>>> (e.g. capture menu), only the last capture environment is preserved. The
>>>> previous, potentially unfinished, capture menus will be destroyed.
>>>
>>> Causing loss of user data. Currently it is hard to start new capture before
>>> selecting a template.
>> Current org-capture is one at a time because of how org-mks works. There
>> is nothing that prevents org-capture to open enumerated buffers,
>> org-caputre<1>, org-capture<2> etc. User has to manually serialize data
>> anyway, via C-c C-c from withing capture buffer? So in principle it is
>> still one capture buffer at a time that manipulates the file on the disk
>> itself?
>
> I would like to avoid confusion here. "*CAPTURE*" buffers are created after
> selection of template. Menu is gone away and content is already added to the
> target document, so it will be saved in response to C-x C-s or autosaved after
> some interval. There is no need of additional persistence at this stage.
>
> And to be clear, example I provided is broken, it creates 2 template selection
> menus existing at the same time, but second request overwrites capture
> data. When one template is selected, menu disappears, but session is still
> blocked by waiting for a key specifying second template. It is really ugly. I
> expect that new menu implementation will allow to improve user experience.
>
> I was writing about interval between invocation of `org-capture' and selection
> of some template. During this period capture data exist only as values of
> runtime variable. Currently it is acceptable because it is almost impossible 
> to
> do anything else in Emacs till capture template is selected.
>
> Non-blocking menu

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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 LISP, but in C (where closures are
>>> impossible) it is a widely used technique. Functions having callback 
>>> argument
>>> usually have another void* one that is later passed as an argument of the
>>> callback function in addition to other data.
>> I understand, I have done my share of C, and know what you mean. Say
>> posix thread will take a void* to user data, and pass it on. This is
>> exactly what this is about. It is just that we don't need an extra
>> structure to pass around. We have a menu entry, which *is* the user
>> data.
>
> You a right, it is not strictly necessary that menu should be aware of state. 
> I
> expect some helper though, e.g.
>
> ;;; -*- lexical-binding: t; -*-
> (defun org-menu-multiinstance-stateful (menus  args)
>   (let* ((buffer-name (or (plist-get args :buffer-name)
> "*Select menu*"))
>(state (plist-get args :state))
>(handler (plist-get args :handler))
>(handler-closure
> (and handler
>  state
>  (lambda (entry  _)
>(funcall handler entry state)
> (when state (org-plist-delete args :state))
> (when handler (org-plist-delete args :handler))
> (plist-put args
>  :buffer-name
>  (generate-new-buffer-name buffer-name))
> (apply #'org-select
>  (if handler-closure
>  (mapcar
>   (lambda (menu)
> (append menu (list :org-select-handler
>handler-closure)))
>   menus)
>menus)
>  args)))
> (provide 'org-multimenu)
>
> To be able to call menu as
>
> (load (expand-file-name "org-multimenu"))
> (org-menu-multiinstance-stateful
>  `((("1" "one" 1)
> ("2" "two" 2)))
>  :state (format-time-string "%T")
>  :text "Some heading"
>  :buffer-name "*Test menu*"
>  :handler (lambda (entry state)
>   (org-select-quit) ; it does not kill the buffer
>   (message "handler %S %S" entry state)))

I might be missunderstanding you now, but from this example it seems to me that
you see menu entries as something that aims for the menu itself, while state is
some user data?

The "menu data" here is just: "1" and "one" in the first entry, and simillary
"2" and "two" in the second entry. After those, client code can put whatever it
desires: ("1" "one" . lots of client state .). So for example client
could have something like ("1" "one" 1 (format-time-string "%T")).

However that might be tedious to type for each entry, so maybe we could pass an
optional "menu-global" state (or entry) that is passed to the user. So it would
be:

(lambda (entry  state)
(org-select-quit) ; it does not kill the buffer
(message "handler %S %S" entry state)))

Reason for optional: I prefer simplicity. I think the idea to lump together
menu selection with user state as it is done in org-capture-templates is really
good. Kudos to whomever came up with that one!

I like it because it puts everything into one place, we don't need to update
display and logic separately but everything is in an entry. I think it is good,
and I would like to keep that simplicity. I wouldnt like to suddenly separate
user state and menu state, because it would negate that fundamental idea.

> I do not like how to closures are represented in elisp stack traces
> (e.g. JavaScript engines in browsers tries hard to give some debug names for
> anonymous functions). It should not be a problem when passed handler is a 
> named
> function (not a lambda) despite closure in the adjacent frame.
>
> However I would expect that menu handler is not aware if menu is implemented
> using buffers. From my point of view handler should not have buffer argument.

I understand, and I agree it is not very beautiful design :). The problem is 
when
client code provides its own handler. In the beginning I used a flag,
org-select-transient, to signal the menu should go away, but that wasn't very
clean either. The solution is maybe to never give total control to user handler,
but to always wrap/call user handler and finnish in menu's own handler. That way
we can use a flag to signal som

RE: Convert a Lisp expression to a tree diagram

[arthur miller]

This one draws graph of cons cells (lists):

https://github.com/amno1/draw-cons-tree

I never tried with random s-expressions, but I guess you could pass them in as 
lists?


 Originalmeddelande 
Från: Juan Manuel Macías 
Datum: 2022-06-30 16:20 (GMT+01:00)
Till: orgmode 
Ämne: Convert a Lisp expression to a tree diagram

Hi all,

Sorry for the slight offtopic. I'd like to be able to graphically
convert (from a src block) a Lisp expression to a tree diagram, similar
to trees used in (human) syntax and grammar, especially generative
grammar (this is a web app for generating such trees:
http://www.ironcreek.net/syntaxtree/). I think I can try some LaTeX hack
using the 'forest' package (here's a related thread with pros and cons:
https://tex.stackexchange.com/questions/140812/drawing-a-lisp-expression-as-a-tree),
but I was wondering if anyone knows of any more emacs/elisp/org friendly
packages/solutions. Some time ago I saw an Emacs package that could
convert a Elisp expression into an ascii text tree diagram, but I can't
remember its name and I can't find it anywhere...

Best regards,

Juan Manuel

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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-capture/org-agenda/etc The main point is making sure that org-select
>>> provides the required functionality.
>>
>> That is just my way to test if it provides features needed, and how they
>> would reflect on real use-case such as org-capture and org-agenda. It is
>> just for demo purpose so to say.
>
> Demo is fine.
> However, since you are already asking about comments on the elisp parts,
> docstrings would be helpful to understand the code. Without docstrings
> and following the conventions, it is much harder to read the code.
>
> Best,
> Ihor

Yepp, I understand. I'll think of it for the next patch.

best regards
/a

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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 return to the application
>> the picked choice. Compare to completing-read, or org-mks. I don't think we
>> should mingle application states and menu states.
>
> 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) it is a widely used technique. Functions having callback argument
> usually have another void* one that is later passed as an argument of the
> callback function in addition to other data.

I understand, I have done my share of C, and know what you mean. Say
posix thread will take a void* to user data, and pass it on. This is
exactly what this is about. It is just that we don't need an extra
structure to pass around. We have a menu entry, which *is* the user
data. Well at least most of it :). This structure looks like:

(key label user-data)

Where user-data is any elements in the list user wishes to pass on. I
don't even require the list to be a well-formed property list, I thought
it is left to the user. key = shortcut used to create mode-map and label
is the string displayed in the buffer. Later this string could be used
for compleating read/isearch or whatever, if it is desired to provide
such interface. But really those two elements are the required
ones and in the first place in the template. The rest is up to client
code.

Compare to org-capture-templates as illustration. We don need to keep it
compatible with org-capture, so it has to recognize two-elements form:
(key label) which has special meaning, and that translates to all other
clients. I could transform those, but I don't think it is worth work. I
will also see if I can rework it to use another two element form:

(:separator separator-string).

I disslike the tripple nesting of lists: a menu is a list of tables
which are each list of lists. I used this approach to implicitly tell
where separators are to be drawn, but after second thought, I think it
will be prettier and more intuitive for client code to explicitly note
where separator is. Maybe I could even mix vertical and horizontal
separators in same menu. I'll see if I have time and interest to
implement that one :).


> (org-buffer-menu
>  '(("a" "Option A" (1))
>("b" "Option B" (2)))
>  :handler
>  (lambda (entry state)
>   (message "value %S state %S" (nth 2 entry) state))
>  :state
>  '(1 2 3))
>
> Menu caller does not care whether some buffer is created to present menu. Menu
> has no idea what state may contain, it just passes it to the handler. When 
> menu
> is implemented as a buffer with keymap then state is stored as a buffer-local
> variable.

Exactly, and this is exactly what happens when you pass in a
handler. The handler gets the entry, which can contain whatever client
data is. Again, compare to org-capture-template.

One can mentally see a menu entry as two lists:

(key label) and (user-data1 ... user-dataN).

They are just lumped into one list (key label user-data1 ... user-dataN).

There is no point of separating this into two lists, since we need
backward compatibility with org-capture-templates.

> As to your current implementation of org-select, I do not like that it is
> responsibility of caller to create different buffer names to enable multiple
> instances of menu. I would prefer to control single/multiple instances 
> through a
> boolean argument of org-select.

How can we know what client application would be called? In which way
can we guess we are called from org-capture or org-agenda org some
user-app? Or I don't udnerstand what you mean here?

Reason I removed :transient as the flag to say the menu should dissapear
after the choice is made, is that it puts control into two places and
messes up the code. Since a hanlder can do anything anyway, it has to be
checked in both places. So I removed the transient flag, and lets just
the handler do it. In that case we know where the buffer handling
happens. I think it eases up usage and implementation. If you have some
cleaner approach sure, it is appreaciated. 

> Arthur, I see that I should response to more your comments. However I am 
> unable
> to identify source of disagreement, likely it is some different

I didn't know we are in disagreement :-).

>  likely it is some different
> assumptions. 

Could be. Could be that we think about same thing, but we see it a bit
differently. People solve things differently, so would probably have

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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
> provides the required functionality.

That is just my way to test if it provides features needed, and how they
would reflect on real use-case such as org-capture and org-agenda. It is
just for demo purpose so to say.

> I'd prefer to first finalize the API and get a cleaner code of
> org-select itself.
 
Yes, that is my goal too. I just thought it was illustrative in context
of those two.

>> (define-minor-mode org-select-mode ""
>>   :interactive nil :global nil)
>
> Why don't you just make it a major mode derived from special-mode? It
> will make more sense considering that you are setting special-mode,
> keymap, etc.

I don't remember any more :). The first version I made was derived from
special mode, but than I switched to minor mode. I don't remember why
atm, to be honset, but I don't think there is anything prohibitive to
derive it from special mode either.

>> (defun osl--prop (property list)
>>   "Return value of PROPERTY from irregular plist LIST."
>>   (cadr (member property list)))
>
> FYI, there is plist-get

Yes I know, I have been using it. However this one is a bit
different. plist-get works on regular lists, this one works on
irregular. This one just match key-value in any list, or to be correct,
it matches key and return next element as the value.

I should have documented, but I meant to document them later on, this
is just for my testing and demoing.

>> (defun osl--init ()
>>   (buffer-local-value 'osl--init (current-buffer)))
>
> This is no different than just saying osl--init.
>
>> (defun org-select-abort ()
>>   (interactive)
>>   (org-select-quit "Aborted"))
>
> Please make sure that all the functions and variables have docstrings.
> This is not just a boring convention, it really helps when you come back
> to the code in future and when other people are reading your code.

Yepp. As said, this was just while I am testing and demoing. Since I
tend to change lots in the code, I am finding myself constantly typing
and erasing stuff, but I guess I should have been more clear when
sending in code to others. I also forgott to make patch and sent in
everything, wasn't really meaning :):

>> (defun osl--longest-line ()
>>   "Return the length of the longest line in current buffer."
>>   (let ((n 1) (L 0) (e 0) (E (point-max)) l)
>> (while (< e E)
>>   (setq e (line-end-position n)
>> l (- e (line-beginning-position n))
>> n (1+ n))
>>   (if (> l L) (setq L l)))
>> L))
>
> Please do not use single-char variable names for non-trivial variables.
> It is always better to provide self-explanatory names. It is not a
> programming context. We are targeting better readability, not fast
> typing.

Ah, that one is special :). e = end, l = line length L = longest
length. I espect myself to rework that one, but yes normally I use
self-docummented code. Sure np, I'll try to not send in short-named ones.

>>   (dolist (menu menus)
>> (cond ((symbolp menu) (setq menu (eval menu)))
>>   ((symbolp (car menu)) (setq menu (eval (car menu)
>> (let ((handler (osl--prop :org-select-handler menu)))
>>   (when handler
>> (setq menu (delete :org-select-handler (delete handler menu
>
> Destructive modifications of arguments is a bad idea. I expect future
> bugs in such code. Please avoid this approach.

Ok. I can rework it by copying the list, but I am not sure if it adds
much of the value since the original one is not used after this
point. But if it is believed to lead to bugs, I can of course change it,
its not a problem.

>> ;; we send in the entire menu so we can return next piece in chain,
>> ;; but *the* entry we work with is just the very first one (car menu)
>> (defun osl--do-entry (menu handler)
>>   "Display a single entry in the buffer."
>
> AFAIU, the comment on top belongs to the docstring. At least the part
> talking about the return value. If the function is expected to return
> something, it should be documented. Otherwise, I expect bugs in future.

Ok.

>> (defun org-select-run (entry  _org-select-buffer)
>>   "Try to execute form found in ENTRY if any leave ORG-SELECT-BUFFER live.
>>
>> This handler provides an easy way to use the framework for the simple
>> use-cases for multiple choices. It relies on the user to press built-in 
>

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

 such points are ignored in the beginning, it may become
> impossible later.

It's lisp, anything is possible ^^ ;-).

No, but serioiusly, there is not much of extension points here. It is a keymap
and buffer text generated automatically from a list of templates and few
"visual" options. An application can even discard entire buffer and draw its own
text out of templates as it pleases, it wouldn't matter.

My goal was to create something very simple to use from a programming
perspective. Compared to other similar options like make-help-screen and org-mks
this puts both key handling, actions and labels into same spot, so there is only
one place to maintain later on, and client code needs needs just to specify the
most minimal lisp one is interested to execute, ie. I don't need to create
lambdas if some function is not already defined. Sort of, that is how at least I
would like to use it. I don't know if that is good or bad practice, or how
robust the code is, I am not super familiar with lisp and org-mode to be honest.

Attached is another experiment. In this version each entry can have attached
handler, and I provide two simple handers: run-once and run-multiple times. For
applications that need more advanced handling, they are supposed to provide own
handler and to take care of killing the menu buffer.

I do have thoughts to rework the drawing code once more to allow entries in form
of: (:separator sepeartor-string), similar as it takes group entries for
submenus. It would allow for mixing horizontal and vertical layouts, but I am
not sure if that is a good feature to have. It certainly isn't needed.

I have reworked a bit org-capture, but I haven't yet worked on org-agenda
restrictions and other details.

;;; org-select.el --- Build custom menus from declarative templates  -*- 
lexical-binding: t; -*-

;; Copyright (C) 2022  Arthur Miller

;; Author: Arthur Miller 
;; Keywords: tools

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <https://www.gnu.org/licenses/>.

;;; Commentary:

;; Org-select is a selection framework meant to be simple and easy to use. Its
;; job is to display a list of choices for a user to pick from and to hand in
;; the selection to the client application. Org-select can be used to allow
;; either a single selection at a time, or for repeated selections from a
;; menu-like text-buffer. 

;; One of goals with this framework is to be easy to setup for the client
;; code. For that reason, org-select uses simple template language modeled after
;; org-capture templates.

;;; Code:

(require 'org-macs)

;;; User vars

(defgroup org-select nil
  "Create menus from declarative templates."
  :prefix "org-select-"
  :prefix "osl--"
  :tag "Org Select"
  :group 'org)

(defcustom org-select-back-key [f10]
  "Used to render string for the horizontal separator."
  :type 'character
  :group 'org-select)

(defcustom org-select-horizontal-separator "|"
  "Used to render string for the horizontal separator."
  :type 'string
  :group 'org-select)

(defcustom org-select-vertical-separator "-"
  "Used to render string for the vetical separator."
  :type 'string
  :group 'org-select)

(defcustom org-select-key-decorator-chars ""
  "Characters used to decorate shortcut keys.

This string should contain only two characters, the first one for the left
decorator and the second one for the right decorator.

Example: string \"[]\" will render key \"C\" as \"[C]\"."
  :type 'string
  :group 'org-select)

(defcustom org-select-label-decorators (cons "..." "...")
  "Used to render string for the vetical separator."
  :type 'cons
  :group 'org-select)

;;; Implementation

(defvar-local osl--init nil)
(defvar-local osl--args nil)
(defvar-local osl--buffer nil)
(defvar-local osl--menu-begin nil)
(defvar-local osl--buffer-menu nil)
(defvar-local osl--longest-label 0)
(defvar-local osl--buffer-window nil)
(defvar-local org-select-mode-map nil)
(defvar-local osl--horizontal-layout nil)
(defvar-local osl--current-menu-column nil)

(defvar-local osl--handler-fn nil
  "The handler invoked when per-menu handler is not specified.

The default one is org-select-run-once.")

(define-minor-mode org-select-mode ""
  :interactive nil :global nil)

 Help-

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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 not 100% sure
>> if having multiple menus is not going to be confusing).
>
> In my opinion application logic should be consistent with UI. Do you think
> current behavior of help buffers has no problems? If so I have no chance to
> convince you that upgrade of menu should be accompanied by changes in
> org-capture.
>
> 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 switch to another task and applications 
> for
> it reside on virtual desktop 2. To proceed further she has to read several 
> help
> pages relevant for task 2. After completion of this task it is time to resume
> task 1 and to switch to virtual desktop 1. Does a window with the help buffer
> still display the same content as before switching to task 2? No, context on
> desktop 1 lost due to some actions in the Emacs frame on desktop 2.
>
> Such synchronization is against multitasking and I do not like the idea to get
> it for org-capture as well. Currently read-key and modal prompt is a kind of
> excuse, but the idea of new menu library is non-blocking keymap-based 
> selection.

Yes, that is true, current Emacs help-buffer implementation is not
designed with your use-case in mind. If we leave out "virtual desktops",
it is unimportant detail. What you speak about is that user is working with
two different contexts at the same time and prefers to keep each context
in it's own frame. 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 people
prefer to keep an Emacs process per project/task for that reason.

I can agree with you, that it would be nice if things were not designed
the way they are, but I don't have an opinion how org-capture should
behave in that regard, and how much work would it be to design it the
way you suggest. With other words, I say neither yes or no to anything
:). I would just like to remind that we are speaking of two things here;
one is menu buffer, that is replacing org-mks & co, as in org-agenda and
other places Ihor mentioned in earlier mails, and the other one is
org-capture itself.

>>> Currently several capture menu instances may be requested though
>>> org-protocol (or calling org-capture from emacsclient). The behavior is
>>> rather confusing. New menu may help to fix the issue, that is why I
>>> raised the question about parallel captures.
>> I am not sure which behavior you have in mind.
>
> try the following commands without selecting a template in an Emacs frame in
> between
>
> emacsclient 'org-protocol:/capture?url=url-A=title-A=body=A'
> emacsclient 'org-protocol:/capture?url=url-B=title-B=body=B'
>
>> What I was thinking as a conservative implementation that would not
>> introduce any new features is replacing the old menu with the new one
>> every time the same menu is called. So, every time the user calls menu
>> (e.g. capture menu), only the last capture environment is preserved. The
>> previous, potentially unfinished, capture menus will be destroyed.
>
> Causing loss of user data. Currently it is hard to start new capture before
> selecting a template.

Current org-capture is one at a time because of how org-mks works. There
is nothing that prevents org-capture to open enumerated buffers,
org-caputre<1>, org-capture<2> etc. User has to manually serialize data
anyway, via C-c C-c from withing capture buffer? So in principle it is
still one capture buffer at a time that manipulates the file on the disk
itself?

Problem would arise if serialization takes long time, i.e. there is lots
of data to write to file, and user switches to another org-capture
buffer and tries to save that one. So the serialization itself has to be
guarded somehow, but a mutex or file lock or something. At least I think
so, I am not sure if I am correct completely. Just trying to think loud
about it.

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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 particular purpose. Next she has to switch to 
>> another task and applications for it reside on virtual desktop 2. To 
>> proceed further she has to read several help pages relevant for task 2. 
>> After completion of this task it is time to resume task 1 and to switch 
>> to virtual desktop 1. Does a window with the help buffer still display 
>> the same content as before switching to task 2? No, context on desktop 1 
>> lost due to some actions in the Emacs frame on desktop 2.
>>
>> Such synchronization is against multitasking and I do not like the idea 
>> to get it for org-capture as well. Currently read-key and modal prompt 
>> is a kind of excuse, but the idea of new menu library is non-blocking 
>> keymap-based selection.
>
> I understand.
> From the perspective of the library being discussed, what you want does
> not look impossible.
>
> 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/org-export/org-todo/etc code later.
>
I think it sounds like a wise proposal :).

Thanks.

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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 virtual desktops.
>> Different Emacs processes, or just different Emacs frames?
>
> I mean single Emacs process perhaps with multiple frames spread over monitors
> and virtual desktops. I am unsure if Emacs can create windows for different 
> X11
> displays, but let's leave it aside and inter-process file locks as well.

Allright then; in that case what Ihor suggests, a variable somewhere, should
do. I suggest that variable be the capture buffer itself. I'll try to implement
this in a day or two; just need some time from other things in life.

>> In case of different Emacs processes, there is no way to guarantee 
>> consistence
>> unless one locks file in the file system. Windows can do it, I am not sure 
>> what
>> is Linux API to do this, don't know if Emacs exposes this functionality, have
>> never tried.
>> Otherewise, if it is only different Emacs frames/clients, the capture should
>> always find the capture buffer and return that one instead of creating new
>> ones. That way there is only one capture buffer, so multiple captures should 
>> not
>> be possible, i.el, it creates same effect as locking the input to 
>> minibuffer. I
>> am not sure how org-capture does, I haven't studied the code in-depth yet, 
>> but
>> what I see currently a user cancels it with C-c C-k. org-capture buffer could
>> setup hooks to clean everything, even if user kills buffer by other means, 
>> c-x
>> k, or whatever. It maybe already does, as said I haven't looked at those
>> details.
>
> Arthur, be reasonably skeptical concerning my ideas or suggestions, it seems I
> have not managed to convince e.g. Ihor.

:-). I think this would be quite a big and radical change in some important
parts of Org, so I really want to make sure that a fundamental error does not
happen. It would be a horrible thing if someones file with maybe lots of data
from the past gets messed up. That must not happen, so I really value the input
and would like to make sure use cases we have to take care of.

> 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
> menu may be non-modal, but it requires a bit different design.

That sounds like a new feature. You are correct, keymaps do open in that
direction. That would be possible to tuck on the routine that saves the
temporary buffer (whatever is called with C-c C-c). When user press C-c C-c in a
capture buffer, that is the only time when interaction with real a file on the
disk happends, right? Everythign else is done in a temporary buffer in ram. User
can physically press it only in one capture buffer, so it least in theory,
multiple capture shouldn't be impossible or too hard to implement. But, lets do
it after the rework of the menu thing?

> Waiting for return value to get capture template is not possible any more. A
> kind of continuations should be passed to the function creating menu buffer
> instead. E.g. it can be some state object that stores snapshot of data 
> necessary
> to fill capture template, export options, etc. and functions in menu entries
> that accept this state object as argument or obtain it from a dynamic
> variable. The state object likely should be a buffer-local variable. For
> non-blocking menu, entries should contain callbacks or menu may have single
> callback that is able to process static data from menu entries.

I happened to send the code yesterday by misstake only to one participant,
unfortunately, it wasn't ment; I seem to have pressed S w instead of S W and
wasn't looking at the address on top, so unfortunately you probably haven't seen
the code. However I have to rework it again because I did a bit bad design in
handling of one feature; I'll try to do it tomorrow.

However the idea is that the selection menu framework have no idea who is
calling it and why. It can not possibly know that either. It is entirely up to
the caller, so for that reason a caller can setup a handler that gets entire
template passed back and can do what it wants with it.

Current org-mks & Co don't really know who is calling than and why, but locking
happens automatically due to nature how the input is read (via minibuffer). In
case of new menu handling, the client has to do locking on its own, so it is a
bit more extra, but client can just buffer-get

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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
>>> synchronization tool.
>>>
>>> Imagine what would happen if Emacs decided to show several capture menus
>>> with keymap non-blocking interface in different virtual desktops.
>>> Capture data should be saved somewhere till the user would discover
>>> initially hidden menu.
>> 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 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 capture before selecting particular template.
>
> There are enough side band communication channels in Org. I did not remember a
> variable from which properties are obtained. Before I have realized that it is
> `org-store-link-plist', I noticed at least `org-overriding-default-time',
> `org-capture-initial'. Unsure that the list is complete.

I have a question here: what is meant by this:

>>> Imagine what would happen if Emacs decided to show several capture menus
>>> with keymap non-blocking interface in different virtual desktops.

Different Emacs processes, or just different Emacs frames?

In case of different Emacs processes, there is no way to guarantee consistence
unless one locks file in the file system. Windows can do it, I am not sure what
is Linux API to do this, don't know if Emacs exposes this functionality, have
never tried.

Otherewise, if it is only different Emacs frames/clients, the capture should
always find the capture buffer and return that one instead of creating new
ones. That way there is only one capture buffer, so multiple captures should not
be possible, i.el, it creates same effect as locking the input to minibuffer. I
am not sure how org-capture does, I haven't studied the code in-depth yet, but
what I see currently a user cancels it with C-c C-k. org-capture buffer could
setup hooks to clean everything, even if user kills buffer by other means, c-x
k, or whatever. It maybe already does, as said I haven't looked at those
details.

I just haven't done that in demo yet, so that is why I said when I posted the
code, I haven't implemented that "correctly", bit I am quite sure it is not very
hard to do.

Am I correct about the principle? If not, than I will have to rething about it.

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

I really don't have problem with "read key". Originally I just wanted to extend
org-capture templates to do a bit extra :).

Actually org-mks and similar approach is really efficient in terms of
resource (no minor/major modes etc). It is only the thing if same framework is
to be used by non-modal applications too, than there have to be other way to
read user input, and since the other way are keymaps, read-key becomes 
redundant.

Sometimes, something like 'read-key' is what is needed, and sometimes that is
just enough. When I first thought of using org-capture templates for
"executable" definitions, I really didn't know how org-capture worked under the
hood. Max is correct about wrapper, that is how org-capture works. But since it
is so easy, we can also automate it and skip writing wrappers and lambdas every
time we use it. That is the idea behind the "default handler" in the
example.

Big difference with org-mks vs ordinary mode-map based menu, is that org-mks
locks entire session. Modal behaviour is used to ensure that just one task at
the time is manipulating org files. I think it can be achieved by other means
too. I have not done it correctly in the example :), but I think it is possible.

I am including also an older test which I have later refactored, that has
"read-key" interface (in org-select-modal); i.e it behaves similar to org-mks,
just to show that such modal interface can be tucked on. It just reads a key
from the user and then invokes the command from the mode map. It is very crappy,
but it shows that both

@Tim
Thank you for mentioning emacspeak. I have never used it so I don't know how it
works, but I have taken a look at some code in Emacspeak after your mail.

Also if I understand what you and Ihor say, it needs to get labels echoed to
minibuffer in order to work with Emacspeak? I have done it so, I am not sure if
works always though :).

@Max
I agree with you that completing read is a good alternative, but it is a bit
like discussion about GUI vs. terminal. I am personally heavy user of Helm, but
not everyone is I believe.

About the name: org-select; i really have no idea what to call it, so better
name would be nice. Sorry for the bugs, I am aware of many, but it still
displays the idea I think.

;;; org-select.el --- Build custom menus from declarative templates  -*- 
lexical-binding: t; -*-

;; Copyright (C) 2022  Arthur Miller

;; Author: Arthur Miller 
;; Keywords: tools

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <https://www.gnu.org/licenses/>.

;;; Commentary:

;; 
;; 

;;; Code:

(require 'org-macs)

;;; User vars

(defgroup org-select nil
  "Create menus from declarative templates."
  :prefix "org-select-"
  :prefix "osl--"
  :tag "Org Select"
  :group 'org)

(defcustom org-select-back-key [f10]
  "Used to render string for the horizontal separator."
  :type 'character
  :group 'org-select)

(defcustom org-select-horizontal-separator "|"
  "Used to render string for the horizontal separator."
  :type 'string
  :group 'org-select)

(defcustom org-select-vertical-separator "-"
  "Used to render string for the vetical separator."
  :type 'string
  :group 'org-select)

(defcustom org-select-key-decorator-chars ""
  "Characters used to decorate shortcut keys.

This string should contain only two characters, the first one for the left
decorator and the second one for the right decorator.

Example: string \"[]\" will render key \"C\" as \"[C]\"."
  :type 'string
  :group 'org-select)

(defcustom org-select-label-decorators (cons "..." "...")
  "Used to render string for the vetical separator."
  :type 'cons
  :group 'org-select)

;;; Implementation

(defvar-local osl--init nil)
(defvar-local osl--args nil)
(defvar-local osl--buffer nil)
(defvar-local osl--menu-begin nil)
(defvar-local osl--buffer-menu nil)
(defvar-local osl--longest-label 0)
(defvar-local osl--buffer-window nil)
(defvar-local org-select-mode-map nil)
(defvar-local osl--horizontal-layout nil)
(defvar-local osl--default-handler-fn nil)
(defvar-local osl--current-menu-column nil)

(define-minor-mode org-select-mode ""
  :interactive nil :global nil)

 Help-functions
(defun osl--arg (key)
  (plist-get osl--args key))

(defu

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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 
>> appears
>> both simpler (code reduction) and more flexible, but it does change the 
>> mental
>> model of how clients of org-mks are used, for example org-capture.
>>
>> I don't think it should be a deal-breaker, but that is my personal opinion, 
>> so I
>> would like to hear if that change would be acceptable or not?
>
> Could you provide a bit more details? How exactly will the usage differ
> from read-key?

I just wrote a much more detailed descrpition of what I have done so far, and
some dificulties I have to solve before I continue, and some discussion of how
it might work in answer to Mikulins question and concerns.

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 maps, so user can just press a key in the buffer itself instead of
being prompted.

Single task workflow, I believe, can be guaranteed by allowing
only one menu buffer per application, for example one org-capture menu at a
time, but multiple applications could work since they will have different named
buffers.

This is a suggestions. I really dislike the read-key implementation of org-mks,
I don't think it is very easy to hack it in order to extend it, but I don't know
if it is possible to block Emacs when using ordinary key map mechanism. If
someone knows how to do it, I am all ears :).

Hope it explains a bit.

Thanks for the help!

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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 implementation, which to me 
>> appears
>> both simpler (code reduction) and more flexible, but it does change the 
>> mental
>> model of how clients of org-mks are used, for example org-capture.
>
> Frankly speaking, I am quite confused concerning what you are trying to do in
> particular. At some moment I had an impression that you were going to factor 
> out
> of `org-capture' the menu that is already a separate function `org-mks'.

>From the beginning I relized I can easily create menus with org-capture, bu 
>just
definiing org-templates, which are simply lists, and wanted to generalize the
org-capture to create menus that can execute ordinary functions, which 'exec'
keyword did. 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 third element is just a lisp form. I have something like this:

#+begin_src emacs-lisp

(defun demo1 ()
  "Simple illustration to recreate org-capture menu (visually only)."
  (interactive)
  (let ((quick-menu-key-decorator-chars "[]")
(return
 (quick-menu
  ;; table
  test-templates
  ;; description
  '(:label "*Quick Select*"
   :text "Select a capture template\n=")
  ;; more tables
  '(("C" "Customize org-capture-templates"
 (customize-variable 'org-capture-templates))
("q" "Abort" (user-error "Abort"))
(if (called-interactively-p 'interactive)
(message "%S" return)
  return)))

(defun demo3 ()
  "Illustrate nested menus, unicode separator and alternative decorator."
  (interactive)
  (let ((quick-menu-key-decorator-chars "<>")
(quick-menu-vertical-separator ?─))
(quick-menu
 ;; table
 '(("g" "Greetings")
   ("gh" "Hello, World!" (message "Hello, World!"))
   ("gb" "Bar" (message "Hello, Bar!")))
 ;; description
 nil
 ;; more tables
 '(("f" "Functions")
   ("ff" "Find File" (call-interactively #'find-file))
   ("fo" "Open File" (flet ((next-read-file-uses-dialog-p () t))
   (call-interactively 'find-file
 '(("q" "Abort" (user-error "Abort"))
 
"quick-menu" is my refactoring of org-mks, definition looks like this:



(defun quick-menu (table  description  tables)
  "Select a member of an alist with multiple keys.

TABLE is an alist which should contain entries where the car is a string.
There should be two types of entries.

1. prefix descriptions like (\"a\" \"Description\")
   This indicates that `a' is a prefix key for multi-letter selection, and
   that there are entries following with keys like \"ab\", \"ax\"...

2. Select-able members must have more than two elements, with the first
   being the string of keys that lead to selecting it, and the second a
   short description string of the item. 

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 prefixes)
under this key will be shown and offered for selection.

DESCRIPTON is a property list containing following members:

:text  a string placed over the selection in the buffer.
:label a string used for the selections buffer name.
:prompta string used when prompting for a key.
:alwayswhen `t', this menu is shown; even descended into submenus
:horizontalwhen `t', if multiple menus are present they are rendered from
left to right, otherwise from top to bottom.
:key-decorator a two-character string used to decorate command characters. When
this string is specified, it will take precedence over the global variable
`quick-menu-key-decorator-chars'.

TABLES are additional menus in the same format as TABLE. If there are more
then one menus, they will be separated by a separator line rendered with
character as specified in `quick-menu-vertical-separator'")

#+end_src

I have paramterized decorator character for s

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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 project of mine with org-capture, 
>> and
>> hacked the 'org-capture' function to implement my idea :).
>
> Feel free at ask anything if you encounter difficulties. It is not
> always trivial to convert something that works for you personally into
> something suitable for all the people using Org.

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 implemented more flexible replacement for org-mks, and refactored it out
of org-mode under new nick 'quick-menu' to indicate that it does not pull any of
org mode with it. I have one implementation based on "read-key" function from
org-macs and used in original org-mks. A proptotype works, but I am not done
completely.

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 (code reduction) and more flexible, but it does change the mental
model of how clients of org-mks are used, for example org-capture.

I don't think it should be a deal-breaker, but that is my personal opinion, so I
would like to hear if that change would be acceptable or not?

RE: Proposal: 'executable' org-capture-templaes

[arthur miller]

Hi Max, thank you for the answer.

I have abandoned the idea . Yes, org-mks is the one that does the lifting, you 
can see my other answers to Ihor., where I am playing with an example "usage 
pattern", that uses org-select-template which uses org-mks underto achieve a 
similar goal 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/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" "label1" exec (lambda () ...))
>>>("key2" "label2" exec (labmda () ...))
>>> ...
>>> )
>
> I am not really familiar with those other dialogues but org-capture, so I only
> had that one in the mind.

There is `org-insert-structure-template' C-c C-,

Doesn't the following code do what you are asking for?

(let ((entry (org-mks `(("a" "A entry" ,#'identity)
   ("b" "B entry" ,(lambda (x) (* 2 x
 "A or B")))
   (funcall (nth 2 entry) 10))

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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 at other
>> parts of org you have mentioned, so I am not yet sure if the approach would 
>> work
>> for all the kids in the block. I don't think it would that much harder to
>> refactor this out, but I might be wrong, since I am not that familiar with 
>> org code.
>
> There are several slightly more complex things in org-agenda (you can
> set extra switches in agenda menu to affect the subsequent command - see
> agenda restriction), but please by all means go ahead if you have
> interest in this area.
>
>> Factoring this out of Org itself, as suggested by RMS in the link you posted
>> might be much more work though. I haven't looked at that, and question is if
>> that is really worth the effort? I would agree with him that things like
>> org-table and date/time handling would be great to have in entire Emacs, 
>> without
>> need to load org, at least bigger parts of it. If I remember well, table mode
>> started outside of org as its own minor mode and got merged into org.
>
> This is not an immediate goal. Rather a justification that we generally
> aim for a more modular code structure.
>
>>> 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 project of mine with org-capture, 
>> and
>> hacked the 'org-capture' function to implement my idea :).
>
> Feel free at ask anything if you encounter difficulties. It is not
> always trivial to convert something that works for you personally into
> something suitable for all the people using Org.

Thank you for the help, I'll come back if I have to ask something for sure. I
have looked little bit into org-agenda-capture and org-mks that does the real
work, but I will have to familiarize myself more with org-agenda and other
places before I dare to suggest something.

best regards
/a

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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 to generate dialogues.
>>>
>>> As for familiarity, I understand and it is exactly the reason why I
>>> suggested to factor out the menu code from capture templates.
>>
>> I am not really familiar with those other dialogues but org-capture, so I 
>> only
>> had that one in the mind. Yes, I agree if the similar code is used/shared in
>> several places than it does make sense to refactor it out.
>
> This refactoring could be a practical way to get something similar to
> your proposal into Org core. At least, if the menus are factored out
> appropriately.

As I see from 'org-capture' function, it does not seem to be terribly hard to
factor menu creation out. There seem to be two parts: template selection which
is already done by 'org-capture-select-template' function, and then the main
work that one has to implement on its own, which is specific to whatever one
would like to implement. I just did a quick refactor to test the idea:

#+begin_src emacs-lisp
(require 'org-capture)
(defun org-menu ( goto keys)
  (interactive "P")
  (let* ((entry (org-capture-select-template keys)))
(cond
 ((equal entry "C")
  (customize-variable 'org-capture-templates))
 ((equal entry "q")
  (user-error "Abort"))
 (t
  (let ((f (nth 2 entry)))
(if (not f) (error "Missing function specification.")
  (if (commandp f) (call-interactively f)
(if (functionp f) (funcall f)
  (error "Invalid function specification.")

(defun org-capture-some-menu ()
  (interactive)
  (let ((org-capture-templates
 `(("F" "Functions")
   ("Fh" "Hello World"
(lambda ()
  (message "Hello, World")))
   ("Ff" "Find file" ,(function find-file)
(org-menu)))

(define-key global-map (kbd "C-S-m") #'org-capture-some-menu)
#+end_src

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 mentioned, so I am not yet sure if the approach would work
for all the kids in the block. I don't think it would that much harder to
refactor this out, but I might be wrong, since I am not that familiar with org 
code.

Factoring this out of Org itself, as suggested by RMS in the link you posted
might be much more work though. I haven't looked at that, and question is if
that is really worth the effort? I would agree with him that things like
org-table and date/time handling would be great to have in entire Emacs, without
need to load org, at least bigger parts of it. If I remember well, table mode
started outside of org as its own minor mode and got merged into org.

> 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 project of mine with org-capture, and
hacked the 'org-capture' function to implement my idea :).

/a

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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 () ...))
>>   ("key2" "label2" exec (labmda () ...))
>>...
>>)
>>
>> People are already writing those as part of org-capture, so there is a
>> familiarity factor. Transient has to be learned, and the complexity is much
>> bigger.
>
>>>   If anything, capture
>>> menu might be factored out to a generic menu framework.
>>
>> Please no. Not every single piece of Emacs has to be a generalized
>> framework. Generalized frameworks add an extra layer of complexity, and it 
>> this
>> case, as you point out, we have other frameworks, so yet another framework is
>> *definitely* not what I ask for.
>
> 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 for familiarity, I understand and it is exactly the reason why I
> suggested to factor out the menu code from capture templates.

I am not really familiar with those other dialogues but org-capture, so I only
had that one in the mind. Yes, I agree if the similar code is used/shared in
several places than it does make sense to refactor it out.

> I am strongly not in favor of adding exec to org-capture itself. It's
> a bit like if you were to add :activate-func for a link that actually
> downloads some file from internet, then generates and exports agenda,
> and meanwhile also restarts your remote server. This will also kind of
> save the code, but completely out of purpose of :activate-func. Of
> course, I am exaggerating here, but just want to make my point clear.

I understand, it is ok :).

>>> We actually had multiple threads discussing possibility to port all the
>>> Org dialogues to transient.
>>
>> I have unfortunately missed those discussions. But as said, I am not in to 
>> argue
>> for or against transient at all. I would just like to re-use the org-capture
>> code, since it is already in-place.
>
> The last one was
> https://orgmode.org/list/8c364693bf6856e60cdd3e8b63ab0c9284d16733.ca...@heagren.com
> And we had multiple complaints that Org menus are not searchable and do
> not allow recursive edit.

I am not sure what complain about searchability is/was, so I should not say much
there, but those are just a list of lists, saved in a well-known place,
org-caputre-templates var, so one can always traverse that list, or search the
menu buffer itself. Anyway thanks for the link, I have read through
that discussion. Seems to me like most of you are in favour of refactoring org
to use transient everywhere?

>>> It seems to be quite out of scope of org-capture.
>>
>> Maybe, but than what is in scope of org-mode or org-capture or Emacs? We are
>> constantly bending code to do what it is not really meant to do. Since to be 
>> a
>> DNA of Emacs :).
>
> Sure. But another feature of Emacs is being consistent. Emacs does
> provide flexible interfaces, but they stick to they purpose. Abusing
> them is up to the user (with no guarantees to work in future versions),
> but not up to Emacs itself.
>
> If we were to include your suggestion, we would also need to maintain
> the new generalized functionality in future. Even if we need to change
> some internals of org-capture. Over-generalization will put an extra
> burden on future maintenance.

Np, I understand. Thanks for the answer anyway.

Best regards
/a

Re: Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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 or 
>> easy
>> menu.
>
> 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 of
transient alone, and as an org user I have org-mode loaded almost always, while
I don't have transient loaded, since I am using magit very, very rarely, which I
believe is the only consumer of transient in my Emacs. So it is more about
lightness and efficiency. 

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 (labmda () ...))
   ...
   )

People are already writing those as part of org-capture, so there is a
familiarity factor. Transient has to be learned, and the complexity is much
bigger.

For the record, there are other alternatives to transient that were already in 
Emacs
for example macro 'make-help-screen', as used in Emacs help, but the complexity
is also bigger, I am sure you are aware of it's usage, but for other readers, an
example usage is in help.el, starting on line 238, where help menu is built. It
is not terribly complicated to use, but it is still more involved then
org-capture template would be.

Of course, those are more capapble than org-capture, but most often we need just
a simple choice.

> We actually had multiple threads discussing possibility to port all the
> Org dialogues to transient.

I have unfortunately missed those discussions. But as said, I am not in to argue
for or against transient at all. I would just like to re-use the org-capture
code, since it is already in-place.

>> I would like to propose a small 'feature/change' to org-capture templates, to
>> inlude a new target: 'exec'. It should be followed by a function to be
>> executed.
>>
>> I believe that this is a simple change that does not intrude on anything 
>> else in
>> org-capture, you can see the attached patch. The goal is to just circumwent 
>> the
>> createion of capture buffer, bookmark and other processing done by 
>> org-capture
>> etc. However there might be things I am not aware of, so if someone have more
>> insight, it is welcomed to hear.
>
> It seems to be quite out of scope of org-capture.

Maybe, but than what is in scope of org-mode or org-capture or Emacs? We are
constantly bending code to do what it is not really meant to do. Since to be a
DNA of Emacs :).

>   If anything, capture
> menu might be factored out to a generic menu framework.

Please no. Not every single piece of Emacs has to be a generalized
framework. Generalized frameworks add an extra layer of complexity, and it this
case, as you point out, we have other frameworks, so yet another framework is
*definitely* not what I ask for.

> already have transient achieving the same goal.

Yes, and other alternatives, but to higher cost mentally and computationally.

I just wish to use org-capture for its simplicity and lighntess. Considering
it's five lines of code, and no additional learning required to use it, I think
it is rather "cheap". We also had easy-menu and make-help-screen when we got
org-capture and transient. I can still understand the feeling that it is "out of
scope", but I don't think it is terribly out of org-capture waters.

Anyway, it is a proposal, and if you don't want it in org it is OK. I personally
think it could make life simpler in cases people need a simple choice menus to
fire up an action, and it comes with very small cost.

best regards
/arthur

Proposal: 'executable' org-capture-templaes

[Arthur Miller]

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/change' to org-capture templates, to
inlude a new target: 'exec'. It should be followed by a function to be
executed.

I believe that this is a simple change that does not intrude on anything else in
org-capture, you can see the attached patch. The goal is to just circumwent the
createion of capture buffer, bookmark and other processing done by org-capture
etc. However there might be things I am not aware of, so if someone have more
insight, it is welcomed to hear.

There is a small illustration in the attached patch as well.

The error handling could probably be much better, so I would like to hear
opinion and suggestion how can I improve it.

best regards
/arthur

>From b8a910235c688d9ea1cb717a186699da489987af Mon Sep 17 00:00:00 2001
From: Arthur Miller 
Date: Thu, 26 May 2022 17:15:37 +0200
Subject: [PATCH] Introduce 'executable' org-capture-templates

* etc/ORG-NEWS: Documented new feature.
* doc/misc/org.org: Documented new template target.
* lisp/org/org-capture.el: 'org-capture' add handler for 'exec' target.
---
 doc/misc/org.org| 14 ++
 etc/ORG-NEWS| 28 
 lisp/org/org-capture.el |  5 +
 3 files changed, 47 insertions(+)

diff --git a/doc/misc/org.org b/doc/misc/org.org
index 3dce83c936..2445c57942 100644
--- a/doc/misc/org.org
+++ b/doc/misc/org.org
@@ -7629,6 +7629,20 @@ Now lets look at the elements of a template definition.  Each entry in
 the target entry or as a top-level entry.  The target file should
 be an Org file.
 
+  - ~exec~ ::
+
+An executable function. Function will be executed and the result
+returned immidiately. No further processing by org-capture will be
+performed, no capture buffer will be created, no last capture
+bookmark etc, will be created. The eventual other template
+parameters are ignored. Use this when you need to execute a Lisp
+function for the side effects. Useful if you would like to create
+lightweight GUIs for user choices based on org-capture mechanism.
+
+Simple example:
+
+'("h" "Say hello" exec (lambda () (message "Hello, World!")))
+
   - ~item~ ::
 
 A plain list item, placed in the first plain list at the target
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 37a39131d9..53ac10ba45 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -108,6 +108,34 @@ If you prefer to keep the keybinding, you can add it back to
 #+end_src
 
 ** New features
+*** 'Executable' org-capture-templates
+
+New target, "exec" is added to templates which provides an easy option
+to run a function from within org-capture dialog. It is meant as a
+lightweight option to create GUIs for user options based on
+org-capture mechanism.
+
+Exec should be followed by a lisp function, a lambda or a function
+object that will be executed and result returned without further
+processing by org-capture. As a consequence other template parameters
+are not used with this target.
+
+Illustration:
+
+#+begin_src emacs-lisp
+(defvar my-templates
+  `(("h" "Hello World" exec
+ (lambda ()
+   (message "Hello, World")))
+("f" "Find file" exec ,(function find-file
+
+(defun simple-menu ()
+  (interactive)
+  (let ((org-capture-templates my-templates))
+(org-capture)))
+
+(define-key global-map (kbd "C-S-n") #'simple-menu)
+#+end_src
 
 *** New citation engine
 
diff --git a/lisp/org/org-capture.el b/lisp/org/org-capture.el
index 2fd9a9c74d..1a9b59de2f 100644
--- a/lisp/org/org-capture.el
+++ b/lisp/org/org-capture.el
@@ -665,6 +665,11 @@ org-capture
 	(remove-text-properties 0 (length annotation)
 '(read-only t) annotation))
   (cond
+   ((equal (nth 2 entry) 'exec)
+(let ((f (plist-get entry 'exec)))
+  (if (not f) (error "Missing function specification.")
+(if (commandp f) (call-interactively f)
+  (if (functionp f) (funcall f) (error "Invalid function specification."))
((equal entry "C")
 	(customize-variable 'org-capture-templates))
((equal entry "q")
-- 
2.36.1

What would be "cheapest" way to toggle emphasized text?

[Arthur Miller]

Hello,

can anybody tell me what is the reason why org-mode has to be restarted when
'org-fontify-emphasized-text' is changed?

If I would like to have an interactive "toggle" to control rendering of
emphasized text, is there any "cheaper" way to achieve that but to restart
org-mode?

#+begin_src emacs-lisp
(defun org-mode-toggle-emphasized-text ()
  (interactive)
  (setq org-fontify-emphasized-text
(not org-fontify-emphasized-text))
  (org-mode-restart))
#+end_src

I have tried to go through the buffer and reset text properties for org-emphais
text property and to re-fontify buffer but I didn't manage to find any way but
to restart the org-mode. I would like to skip all the work done in
initialization if possible.

Thanks for help

Read only org view mode

[Arthur Miller]

Hi mailing list,

is something like this of interest to add to org-mode?

Attached is a prototype to a read-only view mode. It tries to hide as much of
markup as possible to make it more "readable". It uses built-in view-mode to
make the buffer read only and enable some common commands. I plan to add more
"dired like" movement though.

I don't claim it is very well written or efficient; I appreciate input on that
regard. To note is that I use minor-modes as "toggles", to make the
functionality avialable as "solo pieces" as well as a code generation tool.

I am just checking interest here. More info and a screencast are avialable at:

https://github.com/amno1/org-view-mode

;;; org-view-mode.el --- Read-only viewer with less markup clutter in org mode 
files  -*- lexical-binding: t; -*-

;; Copyright (C) 2021  Arthur Miller

;; Author: Arthur Miller 
;; Keywords: convenience, outlines, tools

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <https://www.gnu.org/licenses/>.

;; Author: Arthur Miller
;; Version: 0.0.1
;; Keywords: tools convenience
;; Package-Requires: ((emacs "24.1"))
;; URL: https://github.com/amno1/org-view-mode

;;; Commentary:

;; A minor mode to help reduce clutter in org-mode files by
;; hiding/unhiding org-mode markup language
;;
;; To turn it on execute:
;;
;;  `M-x org-view-mode'.
;;
;; To turn it off execute the same command.

;;; Issues

;;; Code:
(require 'org)

(defgroup org-view nil
  "Hide tags in org-headings."
  :prefix "org-view-"
  :group 'org)

(defvar-local org-view-center-credentials nil
  "Whether to align title and author in center or not.

Centering is done pixel wise relative to window width.")

(defcustom org-view-diminish-mode t
  "Hide lighters for individual minor modes when org-view-mode is on."
  :type 'boolean
  :group 'org-view)

(defvar org-view-stars-re "^[ \t]*\\*+"
  "Regex used to recognize leading stars in org-headings.")

(defvar org-view-credentials-re "[ \t]*#\\+\\(TITLE\\|AUTHOR\\):"
  "Regex used to update author and title lines.")

(defun org-view--update-tags (visibility)
  "Update invisible property to VISIBILITY for tags in the current buffer."
  (save-excursion
(goto-char (point-min))
(with-silent-modifications
  (while (re-search-forward org-view-stars-re nil t)
(goto-char (line-end-position))
(when (re-search-backward org-tag-line-re (line-beginning-position) t)
(put-text-property
 (match-beginning 1) (match-end 1) 'invisible visibility))
  (forward-line)

(defun org-view--update-keywords (visibility)
  "Set VISIBILITY for each line starting with a keyword from KEYWORDS list."
  (org-with-wide-buffer
   (save-excursion
 (with-silent-modifications
   (goto-char (point-min))
   (while (re-search-forward "^[ \t]*#\\+.*$" nil t)
 (goto-char (match-beginning 0))
 (unless (looking-at-p org-view-credentials-re)
   (put-text-property
(1- (match-beginning 0)) (match-end 0) 'invisible visibility))
 (goto-char (match-end 0)))

(defun org-view--update-properties (visibility)
  "Set invisible property to VISIBILITY for properties in the current buffer."
  (org-with-wide-buffer
   (save-excursion
 (with-silent-modifications
   (goto-char (point-min))
   (while (re-search-forward org-property-drawer-re nil t)
 (put-text-property
  (match-beginning 0) (match-end 0) 'invisible visibility))
   (goto-char (point-min))
   (while (re-search-forward "^[ \t]*#\\+PROPERTY:.*$" nil t)
 (put-text-property
  (1- (match-beginning 0)) (1+ (match-end 0)) 'invisible 
visibility))

(defun org-view--update-stars (visibility)
  "Update invisible property to VISIBILITY for markers in the current buffer."
  (org-with-wide-buffer
   (save-excursion
 (goto-char (point-min))
 (with-silent-modifications
   (while (re-search-forward org-view-stars-re nil t)
 (put-text-property
  (match-beginning 0) (match-end 0) 'invisible visibility))

(defun org-view--update-credentials (visibility)
  "Set invisible property to VISIBILITY for export settings."
  (org-with-wide-buffer
   (save-excursion
 (with-silent-modif

Re: frustrations

[Arthur Miller]

Timothy  writes:

> Hi Jan,
>
> Not that I’m unsympathetic to your issues, however I must say that your email
> seems to have little to do with Org, and this *is* the Org mailing list.
>
> Perhaps you would be better served by something like emacs.stackexchange.com.
>
> Jan Ulrich Hasecke  writes:
>
>> Hi all,
>>
>> after happily using straight for quite a while I am currently frustrated by a
>> couple of problems.
>>
>> In a different thread I asked about exporting citations, which does not
>> work for me at all.
>>
>> Today I discovered that pamparam does not work anymore with an error
>> message mentioned here:
>> 
>>
>> Even to get to this error, as pamparam didn’t start at all, I had to
>> manually fix something in worf.el
>> 
>>
>> If I understand correctly, straight uses the bleeding of packages from
>> github. Maybe this is not what I want. Maybe in the past I just was
>> lucky not to hit a bug or an incompatible change.

I don't think luck is not something you should count on. :)

Don't use straight and bleeding edge repositories with branches and what
not. It's a recipe for spaghetti setup and hard to find bugs.

Built-in package.el + elpa/melpa/nelpa should give you stable setup.

>> There are some more issues. Startup time of my emacs is more than 30
>> seconds even after optimizing something with esup. I have 10.000+ files
>> in my org-roam and fear that I hit some limitation either of org-roam or
>> my hardware.

No idea how you managed to collect 10.000+ notes and what not, but if you are
trying to read them in all at startup, or even index them at startup, it is
going to reflect on the startup time. I don't know what you do, or not, but if
something like that is happening, you should find some solution to the problem,
like index files offline or something else.

30 secs for Emacs startup sounds like a lot even for slowest hardware. My Emacs
on my "fast" gnu/Linux start up in 0.3 seconds, and on very slow old laptop we
have in ~3 seconds, with exact same setup. 

>> How do you configure your emacs using current versions like org 9.5 but
>> at the same time avoiding problems with incompatible packages or newly
>> introduced bugs?
We don't use "bleeding edge" repositories and custom branches.

>> In a few days I’ll get a new computer and I have serious doubt whether
>> to copy my settings.org to the new one, because there are too many
>> problems in the last couple of weeks.
>>
>> Any hints?

For the speed, lazy-evaluate everything at startup; i.e. load things "on
demand", when they are asked for.

'with-eval-after-load' and mode hooks are your friends. There is no need for
neither straight, use-package and/or general.el if you use it too. If you don't
know how to use those properly, so please read about those in the manual that
comes with your Emacs.

Just properly use with-eval-after-load and mode hooks, and you'll be ok.

Also, this question is probably better asked on Reddit, SX, or
help-gnu-em...@gnu.org than in this list.

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

[Arthur Miller]

Tim Cross  writes:

> Arthur Miller  writes:
>
>> I haven't tested the updated version of JK's proposal, but looking at the 
>> source
>> it seems to be a tad bit resource heavy. If it isn't a hassle for the OP to 
>> use
>> aliases like lt, gt or similar, I would suggest that either using macros or
>> simple defalias to rename those few functions, <,<=,> and >= is more resource
>> effective way. If code is tangled and byte compiled, macros will be expanded 
>> in
>> byte code, so effectively the runtime cost is almost none.
>>
>
> Have to say I really don't like that proposal as a work-around. Main
> reason is that it obscures the code intent (readers of the code need to
> know 'gt" means greater than while '>' intention is much clearer) and it
> requires all code generated (such as via tangle) to include the macro
> definitions. However, above all, it just feels wrong to require code
> alteration in order to address a limitation in the tool being used to
> create the code.

Well, in this case it is a tool deficiency, if you don't like gt, than use
use "greater-than", it can't be more clear intent? After all, this is a lisp, 
and
'>' is just a symbol name, like any other. For the inclusion of code, yes, but
that is why we have (with-eval-after-load 'org ...).

Don't get me wrong, I am not saying it is a proper way; it is a hack, everyone
can use whatever they like. I personally find org-babel already to be slow when
I have lots of code and blocks, and wanted something simple and efficient.
I found this to work quite well. It is much cheaper in terms of processing
to just defalias 4 symbols. I don't know, maybe it is just me; I am a practical
person who prefer simple solutions. Maybe someone writes a tree-sitter backend
now when we are getting tree-sitter into core? 

>>> I have to wonder why it hasn't
>>> given how long this issue has been known about?
>>
>> That is a good question, maybe proper solution is very hard if not 
>> impossible?
>> Like you said, Emacs is really not meant to be used with several major modes
>> active as once. Seems like this is one of those places where it shows off.
>
> That is my suspicion as well, but I'm wasn't sure as I don't understand
> the internals sufficiently to assess the impact of the regex search. I do
> think the underlying point is correct i.e. adjusting the syntax table
> entry for the < and > characters. This would seem to be the result of
> the one buffer one mode design as you only have a single syntax table
> per buffer. 

Yes I know. I was thinking several times of this and have come to this
limitation in another little project. I would like to have major mode per
region, where region is a continuous span of buffer between two points. That
could help for some cases, for example in this particular case. I don't know how
 difficult that would be to implement, if even possible.

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

[Arthur Miller]

Tim Cross  writes:

> John Kitchin  writes:
>
>> My previous solution seems like it stopped working for some reason. Here is 
>> a new version that "should" only change syntax
>> inside src-blocks, but not inside strings.
>>
>> It looks like this does not impact html blocks, or xml blocks.
>>
>> It is probably possible to make it mode specific if needed.
>>
>> (defun scimax-org-mode-<>-syntax-fix (start end)
>>   "Change syntax of characters ?< and ?> to symbol within source code 
>> blocks."
>>   ;; I think this gets run in a special edit buffer for src-blocks. For now I
>>   ;; only run this in the src blocks, so that outside the src-blocks these 
>> still
>>   ;; act like b=open/close brackets.
>>   (when (org-src-edit-buffer-p)
>> (let ((case-fold-search t))
>>   (goto-char start)
>>   ;; this "fixes" <>, {} and [] that fixes some issues in src blocks, but
>>   ;; makes some new issues, which is now you cannot use them as brackets.
>>   ;; this tries to be fancy and not change the syntax in strings.
>>   (while (re-search-forward "[[<{]\\|[]>}]" end t)
>> (unless (ppss-string-terminator (syntax-ppss (point)))
>>  (put-text-property (point) (1- (point))
>>  'syntax-table (string-to-syntax "_")))
>>
>> (defun scimax-fix-<>-syntax ()
>>   "Fix syntax of <> in code blocks.
>> This function should be added to `org-mode-hook' to make it work."
>>   (setq syntax-propertize-function 'scimax-org-mode-<>-syntax-fix)
>>   (syntax-propertize (point-max)))
>>
>> (add-hook 'org-mode-hook
>>  #'scimax-fix-<>-syntax)
>>
>> John
>>
>> ---
>> Professor John Kitchin (he/him/his)
>> Doherty Hall A207F
>> Department of Chemical Engineering
>> Carnegie Mellon University
>> Pittsburgh, PA 15213
>> 412-268-7803
>> @johnkitchin
>> http://kitchingroup.cheme.cmu.edu
>>
>> On Fri, Sep 3, 2021 at 9:47 AM Tim Cross  wrote:
>>
>>  I think what is happening here is that org is bumping up against
>>  fundamental design limitations of Emacs. In basic terms, much of Emacs'
>>  underlying design is based on an assumption that a file only has a
>>  single major mode. Org works hard to get around this limitation, but it
>>  comes with cost - usually either performance or complexity.
>>
>>  I think this could probably be characterised as a bug without a workable
>>  solution. While there are things youc an do, they all seem to have
>>  unwanted side effects. To what extent those side effect impact you
>>  depends on your use case (as John points out, if you have blocks of HTML
>>  or XML or JSX etc, changing the syntax table to make < and > 'normal'
>>  characters would fix the elisp issue, but break things in those source
>>  blocks.
>>
>>  So really, what we have is an issue without a clean solution. Best
>>  anyone can do is select one of the proposed work-arounds which has
>>  minimal impact on the user. Personally, I never edit source blocks
>>  except in the special edit mode, so don't really notice the problem with
>>  mismatched parens.
>>
>
> If this does work without unwanted side effects or negative performance
> impact, then it probably should be considered for inclusion in org as it
> seem pretty clean and straight-forward. 

I haven't tested the updated version of JK's proposal, but looking at the source
it seems to be a tad bit resource heavy. If it isn't a hassle for the OP to use
aliases like lt, gt or similar, I would suggest that either using macros or
simple defalias to rename those few functions, <,<=,> and >= is more resource
effective way. If code is tangled and byte compiled, macros will be expanded in
byte code, so effectively the runtime cost is almost none.

> I have to wonder why it hasn't
> given how long this issue has been known about?

That is a good question, maybe proper solution is very hard if not impossible?
Like you said, Emacs is really not meant to be used with several major modes
active as once. Seems like this is one of those places where it shows off.

Re: Greater than, less than bug in emacs-lisp source block

[Arthur Miller]

John Kitchin  writes:

> I think this issue is described in
> https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch.
>  There are also some
> solutions there.

I wasn't able to get that to work in my Emacs. I did something simpler though,
that seems to work for me:

#+begin_src emacs-lisp
(defmacro gt (n1 n2)
  `(> ,n1 ,n2))

(defmacro gte (n1 n2)
  `(>= ,n1 ,n2))

(defmacro lt (n1 n2)
  `(< ,n1 ,n2))

(defmacro lte (n1 n2)
  `(<= ,n1 ,n2))

;; example usage

(dolist (s templist)
 (while (lt (length s) l)
 (setq s (concat s " ")))
 (push (concat "[ " s " ]") kwdlist))

#+end_src

Re: org-attach-sync uses directory-empty-p (new in Emacs 28)

[Arthur Miller]

Kyle Meyer  writes:

> Hi Marco,
>
> In 61e083732 (org-attach: Possibly delete empty attach directory,
> 2021-07-09), you added a call to directory-empty-p.  This function was
> introduced in Emacs's 0806075520 (Add directory-empty-p and new argument
> COUNT for directory-files-*, 2020-11-02) and hasn't yet made it into a
> release.
>
> Could you update org-attach-sync to avoid using directory-empty-p (e.g.,
> by inlining it or by adding a compatibility alias)?
>
> Thanks.

Can this help:

#+begin_src emacs-lisp

(when (version< emacs-version "28")
  (defun directory-empty-p (file-name)
"Check if a directory contains any other files then dot-files"
(when (file-directory-p file-name)
  (null (directory-files file-name nil
 directory-files-no-dot-files-regexp t)

#+end_src

Re: Helo for defun/macro arguments list in minibuffer when in org-babel src blocks?

[Arthur Miller]

Tim Cross  writes:

> Arthur Miller  writes:
>
>> Tim Cross  writes:
>>
>>> Hi,
>>>
>>> when you are editing source blocks are you using org-edit-special, normally
>>> bound to C-c ') or are you just editing the source blocks directly within 
>>> the
>>> org buffer?
>> No I don't narrow.
>
> Note that org-edit-special isn't really narrowing. Rather, it opens a
> new buffer (there are options to control how it does this i.e. replace
> org buffer, split to open in new buffer, open in new frame etc) which puts 
> the source block
> into the native mode for the language being edited.  For example, if
> your editing an emacs-lisp block, the edit special buffer will be in
> emacs-lisp-mode and will have all the facilities you would normally have
> when opening an emacs lisp file.
>
> What it sounds like you want to do is just have all the (for example)
> emacs-lisp mode and associated minor modes activated when your cursor is
> within a source block within the org buffer. This is extremely difficult
> to. Part of the problem is that modes like emacs-lisp-mode are designed
> to operate on buffers.

Yes indeed. I am quite aware of difficulties involved. I did myself a
small [[https://github.com/amno1/dired-auto-readme][hack to dired mode to "auto 
show" readme files]], and got into all
those problems there.

That one major mode per buffer is starting to be a limitation. What we
really would need is a major mode per region, or some other mean to be
able to combine modes. Maybe something like a "primary mode" which would
be what Emacs opens into when a file is loaded, i.e. 'org-mode' in this
example and secondary modes, which would be other major modes loaded,
and somehow activated per region or I don't know. But that is a
day-dreaming :). It would require rebuilding entire machinery.

>There are some 'special' packages, like mmm-mode
> which try to support this type of functionality, but to be honest, I've
> never found them very good and they often have significant performance
> problems.

Yes I know. I tried with mmm-mode, didn't really work well for me.

> Of course, this is emacs and you can probably get something mostly
> working, but it will take considerable effort and may well have
> performance hits as well as other unexpected side effects. I think your
> definitely 'swimming against the flow' and suspect that in the end, you

Haha, definitely :-). But that is the story of my entire life ;-).

Yes, in this case, that is correct. What I am doing here is bending
entire org-mode to do something it is not supposed to do. If you are
interested you can take a look at 
[[https://github.com/amno1/.emacs.d/blob/main/init.org][my little app on my 
github]]:

Look at "org hacks" under generator heading.

> will spend far more time trying to maintain your hacks rather than
> actually focusing on the work you want to get done. I originally went down a

That is what is hapening, but I started this as a hobby project as well
as a learning experience. I really suck at both Emacs internals and
elisp, so I need something like this as a learning project.

> Anyway, good luck.

Thanks, and thank you for the tips and feedback.

Re: Helo for defun/macro arguments list in minibuffer when in org-babel src blocks?

[Arthur Miller]

Tim Cross  writes:

> Hi,
>
> when you are editing source blocks are you using org-edit-special, normally
> bound to C-c ') or are you just editing the source blocks directly within the
> org buffer?
No I don't narrow.

> The functionality you are referring to sounds like eldoc minor mode.
Yes it is, I was just looking at elisp-mode.el, and saw the eldoc
support. I tried to defadvice around with that scimax spoof function
from J.K's article, but I don't really get it to work.

> If you open a dedicated buffer to edit a file in the same language as your
> source blocks, do you see the behaviour you want. For example, open a file
> called test.el and edit some Emacs lisp. If you don't see the behaviour your
> after, you need to configure emacs-lisp-mode to load eldoc mode. Try typing 
> M-x
> eldoc-mode  and see if you then get the behaviour your after. If you do,
> then read up on eldoc-mode and how to enable it.

>   Using org-edit-special ensures this occurs when necessary.
> Editing the source blocks directly does not.

I know, I would kind of like to skip to narrow back and forth. I
understand I maybe stretching it a bit, but kind-a cool if it could work
directly in src blocks without narrowing. 

> The environment you get with a dedicated buffer and that you get with
> org-edit-special should be roughly the same. So the trick is to get things
> working how you like them using a dedicated *.el buffer and then use
> org-edit-special whenever you need to edit source blocks. There is also 
> another
> good reason to use org-edit-special - there are some situations where org 
> needs
> to add some special escaping characters in source blocks to enable things to 
> be
> parsed correctly.

Indeed. I had to introduce some macros because of <>[] chars being
parsed wrongly so syntax highlight and identation in src blocks get
screwed. I think I asked for helped about it. J.K. posted his answer in
SX, but I couldn't get that to work, so I just wrote few simple macros
that fixed at least syntax and indenting. Lispy is also really badly
screwed in org-buffer directly, at least for me cursor jumps all over
the place.

Anyway, after trying the "scimax-hack" (if I can call it so), which
works so fine with keymaps, I thought it might work with eldoc and
company too. I am just not sure which things to hook into that spoof
function.

(advice-add 'eldoc-mode :around 'scimax-spoof-mode)

That one let me enabke eldoc-mode which otherwise does not want to run
in org mode (for me at least). However I still don't see the defun
signature in echo area. I tried to hook via those two below:

(advice-add 'elisp-completion-at-point :around 'scimax-spoof-mode)
(advice-add 'elisp-eldoc-documentation-function :around 'scimax-spoof-mode)

but still nothing in echo area :).

Anyway, thanks for any help!

> Arthur Miller  writes:
>
>> I have been doing quite some programming with elisp in org mode, and one
>> thing I am missing is this help that Emacs shows in minibuffer for
>> functions and macros. You can see the example in the attached image. I
>> am not sure what I have to enable (or disable? :)) to get it to work in
>> babel src blocks? Or is it even possible?
>>
>> Some few days ago I stumbled on a blog post by J. Kitchin about enabling
>> orignal mode maps in src block:
>>
>> <https://kitchingroup.cheme.cmu.edu/blog/2017/06/10/Adding-keymaps-to-src-blocks-via-org-font-lock-hook/>
>>
>> That was another thing I was missing, and that one work really well.
>> Thank yuu John!
>>
>> Can that hack be used to enable this help to pup up in minibuffer as
>> well. I am not familiar what causes that lookup, but I see it happends
>> even when Emacs is started with -Q option, so it is something built-in
>> and enabled by default, probably in elisp-mode itself.
>>
>> Last thing I miss is company doing it's thing. I can complete by
>> pressing TAB, but I would still like it to happen automatically. Is it
>> just me being noob and not enabling something, or is it bit more
>> coplicated than so?
>>
>> Sorry for the long writing, but basically what I ask is, can we get more
>> of usualy elisp stuff hanpening in babel src blocks?
>>
>
>
> Regards,
>
> Tim
>
> --
> *Tim Cross*
>
> /For gor sake stop laughing, this is serious!/

Helo for defun/macro arguments list in minibuffer when in org-babel src blocks?

[Arthur Miller]

I have been doing quite some programming with elisp in org mode, and one
thing I am missing is this help that Emacs shows in minibuffer for
functions and macros. You can see the example in the attached image. I
am not sure what I have to enable (or disable? :)) to get it to work in
babel src blocks? Or is it even possible?

Some few days ago I stumbled on a blog post by J. Kitchin about enabling
orignal mode maps in src block:

https://kitchingroup.cheme.cmu.edu/blog/2017/06/10/Adding-keymaps-to-src-blocks-via-org-font-lock-hook/

That was another thing I was missing, and that one work really well.
Thank yuu John! 

Can that hack be used to enable this help to pup up in minibuffer as
well. I am not familiar what causes that lookup, but I see it happends
even when Emacs is started with -Q option, so it is something built-in
and enabled by default, probably in elisp-mode itself.

Last thing I miss is company doing it's thing. I can complete by
pressing TAB, but I would still like it to happen automatically. Is it
just me being noob and not enabling something, or is it bit more
coplicated than so?

Sorry for the long writing, but basically what I ask is, can we get more
of usualy elisp stuff hanpening in babel src blocks? 

Best regards and thanks for help

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

Christopher Dimech  writes:

>> Sent: Friday, May 14, 2021 at 5:30 PM
>> From: "Dr. Arne Babenhauserheide" 
>> To: "Arthur Miller" 
>> Cc: "Jarmo Hurri" , emacs-orgmode@gnu.org
>> Subject: Re: The fate of ditaa.jar (9.4.5.)
>>
>> 
>> Arthur Miller  writes:
>> 
>> > Exactly, so it is enough to just download a single file and point your
>> > org to it with one `setq' in your init file. So it does not need a
>> > pacakge managmenet on os level.
>> 
>> Package management is how users should install software. Otherwise you
>> quickly reach the point where they blindly curl and run untrusted
>> shell-scripts from shady websites.
>
> I agree with the assessment regarding shady websites.
>  
>> > However, Org could also simply say: use another distro that has ditaa in
>> > it's repository, such as Arch Linuz (in AUR).
>> 
>> That would be openly hostile.

No is not. There are so many distributions that are half-done,
unmaintained, etc. By the way, if your distro does not have a package
for ditaa, then you might maybe consider doing a community service and
provide a package script for your distro? I guess your distro have some
way for users to contribute a package?

> If there exists the serious problem of not finding ditaa, then ditaa should 
> be provided.
> For the rest there exist no problem and users can easily install from their 
> Package Manager.
>
> You can't brush off a boyfriend and expect him to do you a favor using Free 
> Software
> by telling him to use another distro.  ;)
>  

:-) It is just the usual one: "you deserve a better one "

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

"Dr. Arne Babenhauserheide"  writes:

> Arthur Miller  writes:
>
>> Jarmo Hurri  writes:
>>
>>> Greetings.
>>>
>>> "Dr. Arne Babenhauserheide"  writes:
>>>
>>>> Arthur Miller  writes:
>>>>
>>>>> By the way, how difficult is to download one file from the internet
>>>>> (ditaa.jar) if you are an user?
>>>>
>>>> That’s not the point. The point is that every single user with a ditaa
>>>> block has to do it.
>>>>
>>>> Ask the other way round: What is the benefit of removing ditaa from
>>>> org?  If you want to force most current org-ditaa users to unbreak
>>>> their setup after update, there should be a significant tangible
>>>> benefit.
>>>
>>> I agree.
>>>
>>> One thing I like about org is that most things work out of the box.
>>
>> If bundled ditaa is not compatible with jre installed on users
>> computer, or there is no jre installed, and user is not a programmer or
>> used to Java, how many steps it adds to such a user to sort out why org
>> does not work for him/her "out of the box"? Just to save some experienced
>> user an extra step, that probably does not even affect them since they
>> already have java and ditaa on their computers.
>
> The difference is not about the difference between experienced or
> beginner. The difference is that „use your package manager to get Java“
> or „get openjdk“ is an operation that only uses standard installation
> processes.
>
> „Get this jar-file from somewhere and drop it somewhere and then change
> this configuration to point to it“ is not a standard installation
> action.
>
> If Java is missing, org can simply report „no java found, please install
> openjdk from  https://adoptopenjdk.net/installation.html>“ and the user can install it
> like any other software.
So can org also say: "ditaa is missing, please install from the link
... " :-)

> This is not the case with ditaa. Ditaa is no standard application with
> installer/setup/…, but a jar-file.

Exactly, so it is enough to just download a single file and point your
org to it with one `setq' in your init file. So it does not need a
pacakge managmenet on os level.

However, Org could also simply say: use another distro that has ditaa in
it's repository, such as Arch Linuz (in AUR).

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

Jarmo Hurri  writes:

> Greetings.
>
> "Dr. Arne Babenhauserheide"  writes:
>
>> Arthur Miller  writes:
>>
>>> By the way, how difficult is to download one file from the internet
>>> (ditaa.jar) if you are an user?
>>
>> That’s not the point. The point is that every single user with a ditaa
>> block has to do it.
>>
>> Ask the other way round: What is the benefit of removing ditaa from
>> org?  If you want to force most current org-ditaa users to unbreak
>> their setup after update, there should be a significant tangible
>> benefit.
>
> I agree.
>
> One thing I like about org is that most things work out of the box.

If bundled ditaa is not compatible with jre installed on users
computer, or there is no jre installed, and user is not a programmer or
used to Java, how many steps it adds to such a user to sort out why org
does not work for him/her "out of the box"? Just to save some experienced
user an extra step, that probably does not even affect them since they
already have java and ditaa on their computers.

> Comparing ditaa to latex/java/C/such does not feel fair, since distros
Ditaa requires jre to work. Should org distribute a version of jre too
to make it sure it works on user computer "out of the box"?

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

"Dr. Arne Babenhauserheide"  writes:

> Arthur Miller  writes:
>
>> Christopher Dimech  writes:
>>
>>> If org-mode wants to support ditaa, it is a requirement to inform the user 
>>> how to
>>> get the software and install it.  Moving into into a separate repository 
>>> without
>>> appropriately telling the user introduces the problem that users will miss 
>>> out
>>> on free software that they would otherwise have used.  Using org should not 
>>> be made 
>>> more difficult than it already is. 
>>>   
>> Another problem I didn't mention in previous replay, is that user can
>> have wrong (outdated) version of Java installed on his/her machine which
>> might not be compatible with ditaa version org mode ships, which may
>> introduce further questions and problems. IMO I think it is better to
>> leave out 3rd party applications and let users install those on their
>> own. 
>
> The old version should just keep working. It requires a Java older than
> Java 8, and Java 8 is available everywhere.
I don't think that would be the case. Java is considered unsafe software
so I wouldn't rely on older versions being pre-installed and avialable 
everywhere.

> I would bundle the old version to keep old documents working (I do not
> want org-mode to be volatile software[1] that breaks existing documents
> with an update), but notify the user that a new version exists.

Since you already have Java and ditaa installed on your computer, your
older documents won't get broken. 

By the way, how difficult is to download one file from the internet
(ditaa.jar) if you are an user?

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

>   I find it harder to write good
> documentation than good code!

Yes indeed, takes so much more time than to just write the code :).

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

TEC  writes:

> Tim Cross  writes:
>
>> I also had to install textlive, plantuml, graphviz, taskjuggler,
>> ledger, sqlite and many other things.
>
> Perhaps it would be good to make a table of
>
> | software | needed for | package name | download page |

Maybe there could be a hash table where one can register a function with
a software, similar to how autoload works. but instead of specifying
file where function is found, we could specify a sotware/package name
and a link to download/main page?

Maybe function level is too granular, maybe per feature level?

> and/or prompt users when an action requiring another executable is
> undertaken if it isn't found.
>
I think it's a good idea.

A minor mode that can be turned off for experienced users but on by
default and maybe with knowledge where to find the required software,
i.e. a link that Emacs can open in default a web browser for the
user. Ultimate would be to offer a download, but considering all the
distros and possible dead links, probably better to go just for download
or main page.

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

"Dr. Arne Babenhauserheide"  writes:

> Java is available in my distribution, ditaa is not. Removing ditaa from
> org means that I have to do manual installation and configuration, while
> with ditaa bundled, org-mode can simply note that I need java installed.
>
>> If we bundle it, we also need to ensure it is updated if/when new jar
>> versions are released.
>
> We can do that, but we don’t have to. As long as the bundled jar works,
> it is much better than no jar.
Depending on what users have on their machines it may not work on their
machine. The bundled jar might ask for a version of Java runtime that
users does not have. There is no guarantee that every distribution comes
with java bundled either. For you it maybe works, for someone else it
might generate 1001 question and confusion when things don't work.

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

Christopher Dimech  writes:

> If org-mode wants to support ditaa, it is a requirement to inform the user 
> how to
> get the software and install it.  Moving into into a separate repository 
> without
> appropriately telling the user introduces the problem that users will miss out
> on free software that they would otherwise have used.  Using org should not 
> be made 
> more difficult than it already is. 
>   
Another problem I didn't mention in previous replay, is that user can
have wrong (outdated) version of Java installed on his/her machine which
might not be compatible with ditaa version org mode ships, which may
introduce further questions and problems. IMO I think it is better to
leave out 3rd party applications and let users install those on their
own. 

>> Sent: Tuesday, May 11, 2021 at 8:49 AM
>> From: "Arthur Miller" 
>> To: "Dr. Arne Babenhauserheide" 
>> Cc: emacs-orgmode@gnu.org
>> Subject: Re: The fate of ditaa.jar (9.4.5.)
>>
>> "Dr. Arne Babenhauserheide"  writes:
>> 
>> > Russell Adams  writes:
>> >
>> >> On Mon, May 10, 2021 at 02:28:57PM +0300, Jarmo Hurri wrote:
>> >>> I pulled the latest master and noticed that contrib has been moved into
>> >>> a separate repository. I also cloned this contrib repository, but can
>> >>> not find the file
>> >>>
>> >>> scripts/ditaa.jar
>> >>>
>> >>> in the repo. In fact, there is no directory scripts in the repo.
>> >>
>> >> I actually never considered this might be packaged with Org. I always
>> >> thought I had to install it separately, like my Latex distribution or
>> >> PlantUML.
>> >
>> > Bundling this makes ditaa code blocks just work. Otherwise they won’t
>> > work on every org-install.
>> 
>> The user still needs a Java runtime installed on his/her compute, so
>> bundling ditaa.jar gives no guarantee at all that ditaa blocks will just
>> work on every org-install.
>> 
>> Instead a less informaed user, not used to run java programs, might be
>> left with a not working application that fails silently or to the user
>> incomprehensible error message.
>> 
>> Better to point user to ditaa's sources/releases and inform it is
>> optional with org. That way non-informed user will have to install java
>> and ditaa and will at least have an idea where to look when things go wrong.
>> 
>>

Re: The fate of ditaa.jar (9.4.5.)

[Arthur Miller]

"Dr. Arne Babenhauserheide"  writes:

> Russell Adams  writes:
>
>> On Mon, May 10, 2021 at 02:28:57PM +0300, Jarmo Hurri wrote:
>>> I pulled the latest master and noticed that contrib has been moved into
>>> a separate repository. I also cloned this contrib repository, but can
>>> not find the file
>>>
>>> scripts/ditaa.jar
>>>
>>> in the repo. In fact, there is no directory scripts in the repo.
>>
>> I actually never considered this might be packaged with Org. I always
>> thought I had to install it separately, like my Latex distribution or
>> PlantUML.
>
> Bundling this makes ditaa code blocks just work. Otherwise they won’t
> work on every org-install.

The user still needs a Java runtime installed on his/her compute, so
bundling ditaa.jar gives no guarantee at all that ditaa blocks will just
work on every org-install.

Instead a less informaed user, not used to run java programs, might be
left with a not working application that fails silently or to the user
incomprehensible error message.

Better to point user to ditaa's sources/releases and inform it is
optional with org. That way non-informed user will have to install java
and ditaa and will at least have an idea where to look when things go wrong.

Re: Checkboxes in headings - opinions wanted

[Arthur Miller]

Ihor Radchenko  writes:

> Arthur Miller  writes:
>> ... Example can be seen in attached screenshot from
>> my init file where I use org headings to form a list of packages to
>> install, and checkboxes to indicate if a package configuration is used
>> or not. 
>
> Depending on details of your workflow, you might also use
> org-toggle-comment for indication of configuration usage. As a bonus, if
Actually I am thinking of re-purposing TODO for "pin to repository"
purpose, so that is why I needed a more general checkbox independent of
TODO states. I am using planning on using tags for some other stuff.

> you use literate config, commenting the heading will also disable
> tangling for that heading.
>
I don't use tangling
from org-mode, I tangle all code myself. I have written a small
optimizer so I am generating actual init file from the literal config,
it is a small application in org-mode. You can see hacked TODO (per
file) in "Generator" section below the ";; og hacks" comment of
init.org, if you are interested.

https://github.com/amno1/.emacs.d

Re: Checkboxes in headings - opinions wanted

[Arthur Miller]

Russell Adams  writes:

> Arthur,
>
> Could you just use unicode checkbox symbols instead of TODO and DONE?
>
> https://kdr2.com/tech/emacs/1405-orgmode-checkbox-unicode.html
>
> That ought to be just a string, and need no patch.

No, I am sorry, that is completely off.

I have done this minor mode to make it independent of TODO states. Just
replacing TODO and DONE (as I already did as described in other thread 2
days ago), is effectively locking TODO to ack as checkboxes. I would
like to be able to use TODO states together with a checkbox,
independently of each other, so no, I need something more general then
just renamed todo states.

Also unicode will depend on some font to be installed, I don't want to pay
that dependency, since I am using this for my init file.

By the way, this is not a patch, this is a small minor mode that can be
installed and enabled/disabled like an extra package.

By the way, there is a widghet.el library included in Emacs, if I wanted
to use checkboxes as in screenshot there, I could use that library, but
that would be much more involved than those few lines to write the code
I attached in first mail.

> On Mon, May 03, 2021 at 09:00:40AM +0200, Arthur Miller wrote:
>
>>
>> Last night I have been playing with a minor mode to enable a checkbox in
>> a heading, or rather to fake a checkbox. To be honest, it was a 10
>> minute job. Took me way moare time to figure out avialable key
>> combination to use (which I didn't found).
>>
>> In general, enable mode and use S+up/down to toggle a checkbox. A
>> heading with a checkbox is of form [ \t]*\\*+.*? followed by a [ ] or
>> [x] before a heading. It means a [ ] can be placed somewhere after the
>> leading stars, whitespaces ignored.
>>
>> This has nothing todo with my previous hacks of todo keywords. This one
>> does not uses todo states at all so it can be used with todo states.
>>
>> It is just a small prototype. I will use something else than
>> replace-string later on.
>>
>> Just wonder if the approach is sane.
>>
>> There is also a repo on gh for interested one:
>>
>> https://github.com/amno1/org-heading-checkbox

>
>
> --
> Russell Adamsrlad...@adamsinfoserv.com
>
> PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/
>
> Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Checkboxes in headings - opinions wanted

[Arthur Miller]

Timothy  writes:

> Bastien  writes:
>> For now you can use statistics cookies in headline:
>> https://orgmode.org/manual/Checkboxes.html
>>
>> What would perhaps make sense would be to support [ ]/[X] on top of
>> the already supported [0%]/[100%] and [0/n]/[n/n].
>
> I've always used
> * TODO heading [/]
>
> as a substitute for
> + [  ] task [/]
>
> Other than it not automatically switching to done upon reaching 100%,
> I've been pretty happy with this.
>
> Just my 2c.

I am affraid I am not that familiar with org-mode to note what you are
suggesting there :-). I am sorry, it is on my.

What I needed as I just wrote in answer to Bastien, is something
independent of TOTO states, so I can use it side by side with TODO
labels. I am not sure how your proposal fits into that, but that is
mostly because I am really not very good with org-mode.

Re: Checkboxes in headings - opinions wanted

[Arthur Miller]

Bastien  writes:

> Hi Arthur,
>
> Arthur Miller  writes:
>
>> Last night I have been playing with a minor mode to enable a checkbox in
>> a heading, or rather to fake a checkbox.
>
> Interesting, thanks.
>
> For now you can use statistics cookies in headline:
> https://orgmode.org/manual/Checkboxes.html
>
> What would perhaps make sense would be to support [ ]/[X] on top of
> the already supported [0%]/[100%] and [0/n]/[n/n].
>
> What do you think?  (I tried your mode and unless I didn't try it
> correctly, it does not seem to do that.)

Indeed, it does not do that :). It was explicitly designed to work
independently of TODO tasks/progress, so I can use it side by side with
TODO labels. With other words I just needed a plain old GUI-style
checkbox to indicate on/off value. As I understand stats checkboxes are
displaying progress based on TODO tasks and list checkboxes, so they can
not be used independently of TODO states. Maybe I am wrong, I never used
them to be honest, so I am not sure how much and what is possible there.

Anyway, I am not sure how interesting is this to a wider org-mode
community. Org-mode seems to be geared mostly toward process tracking
which is of course great for project and tasks tracking. However, I see
lots of useful things in org-mode outside of project tracking for some
other strucutured data. Example can be seen in attached screenshot from
my init file where I use org headings to form a list of packages to
install, and checkboxes to indicate if a package configuration is used
or not. 

I was able to re-purpose TODO keywords to act as checkboxes, the other
day, and it worked very well, I can "switch on/off states" with
S-left/right arrows, and I was able to disable initial and done states,
so arrows just shift between [x] and [ ] states. But that locks todo
states to this particular sequence. If I would like to be able to use
TODO states in their normal context, I can't. I needed a more "general
purpose" checkbox, so I wrote that small minor mode.

The biggest problem is, I am not sure how to connect a function per
checkbox in some convenient and simple to use way yet, I am still
thinking what would be the easiest way to add programmability, and I am
not sure why empty checkbox losses fontification.

Checkboxes in headings - opinions wanted

[Arthur Miller]

org-heading-checkbox.el
Description: application/emacs-lisp

Last night I have been playing with a minor mode to enable a checkbox in
a heading, or rather to fake a checkbox. To be honest, it was a 10
minute job. Took me way moare time to figure out avialable key
combination to use (which I didn't found).

In general, enable mode and use S+up/down to toggle a checkbox. A
heading with a checkbox is of form [ \t]*\\*+.*? followed by a [ ] or
[x] before a heading. It means a [ ] can be placed somewhere after the
leading stars, whitespaces ignored.

This has nothing todo with my previous hacks of todo keywords. This one
does not uses todo states at all so it can be used with todo states.

It is just a small prototype. I will use something else than
replace-string later on.

Just wonder if the approach is sane.

There is also a repo on gh for interested one:

https://github.com/amno1/org-heading-checkbox 

Re: Programmatically set TODO labels per file?

[Arthur Miller]

Arthur Miller  writes:

If anyone is interested, this is how I understand the org TODO per file
parsing:

The file is parsed in org-collect-keywords-1 in org.el.

Each #+TODO: line is lumped into one single string, which is a problem
when strings with spaces a concerned. Multiple #+TODO: lines will end up
in final multiple strings added into an alist which has a first element
a "TODO" string. The right thing would be to parse multiple strings per
each #+TODO: line. Now the org-collect-keyword-1 is not a trivial one,
so it would take me quite some time to understand, so I'll pass.

The thing I did that worked for me is wrong super-hackish thing, just an
experiment, so to say.

I have simply refactored the code where the string obtained from
org-collect-keywords is parsed, which is the very last part of
org-set-regexps-and-options, where main action seems to take place. That
let's me do what I wanted. It will completely replace whatever was
specified with #+ syntax, and the fontification won't be done
either. Also if file is reverted than #+ will completely replace what
was set with lisp. So not a clean thing, probably nothing to be used by
anyone, but it does what I roughly need for my init file :-).

#+TODO: one two
#+TODO: three
#+TODO: four

#+begin_src emacs-lisp
(defun org-todo-per-file-keywords (kwds)
  "Sets per file TODO labels. Takes as argument a list of strings to be used as
labels."
  (let (alist)
(push "TODO" alist)
(dolist (kwd kwds)
  (push kwd alist))
(setq alist (list (nreverse alist)))
;; TODO keywords.
(setq-local org-todo-kwd-alist nil)
(setq-local org-todo-key-alist nil)
(setq-local org-todo-key-trigger nil)
(setq-local org-todo-keywords-1 nil)
(setq-local org-done-keywords nil)
(setq-local org-todo-heads nil)
(setq-local org-todo-sets nil)
(setq-local org-todo-log-states nil)
(let ((todo-sequences alist))
  (dolist (sequence todo-sequences)
	(let* ((sequence (or (run-hook-with-args-until-success
			  'org-todo-setup-filter-hook sequence)
			 sequence))
	   (sequence-type (car sequence))
	   (keywords (cdr sequence))
	   (sep (member "|" keywords))
	   names alist)
	  (dolist (k (remove "|" keywords))
	(unless (string-match "^\\(.*?\\)\\(?:(\\([^!@/]\\)?.*?)\\)?$"
  k)
	  (error "Invalid TODO keyword %s" k))
	(let ((name (match-string 1 k))
		  (key (match-string 2 k))
		  (log (org-extract-log-state-settings k)))
	  (push name names)
	  (push (cons name (and key (string-to-char key))) alist)
	  (when log (push log org-todo-log-states
	  (let* ((names (nreverse names))
		 (done (if sep (org-remove-keyword-keys (cdr sep))
			 (last names)))
		 (head (car names))
		 (tail (list sequence-type head (car done) (org-last done
	(add-to-list 'org-todo-heads head 'append)
	(push names org-todo-sets)
	(setq org-done-keywords (append org-done-keywords done nil))
	(setq org-todo-keywords-1 (append org-todo-keywords-1 names nil))
	(setq org-todo-key-alist
		  (append org-todo-key-alist
			  (and alist
			   (append '((:startgroup))
   (nreverse alist)
   '((:endgroup))
	(dolist (k names) (push (cons k tail) org-todo-kwd-alist))
(setq org-todo-sets (nreverse org-todo-sets)
	  org-todo-kwd-alist (nreverse org-todo-kwd-alist)
	  org-todo-key-trigger (delq nil (mapcar #'cdr org-todo-key-alist))
	  org-todo-key-alist (org-assign-fast-keys org-todo-key-alist))
;; Compute the regular expressions and other local variables.
;; Using `org-outline-regexp-bol' would complicate them much,
;; because of the fixed white space at the end of that string.
(unless org-done-keywords
  (setq org-done-keywords
	(and org-todo-keywords-1 (last org-todo-keywords-1
(setq org-not-done-keywords
	  (org-delete-all org-done-keywords
			  (copy-sequence org-todo-keywords-1))
	  org-todo-regexp (regexp-opt org-todo-keywords-1 t)
	  org-not-done-regexp (regexp-opt org-not-done-keywords t)
	  org-not-done-heading-regexp
	  (format org-heading-keyword-regexp-format org-not-done-regexp)
	  org-todo-line-regexp
	  (format org-heading-keyword-maybe-regexp-format org-todo-regexp)
	  org-complex-heading-regexp
	  (concat "^\\(\\*+\\)"
		  "\\(?: +" org-todo-regexp "\\)?"
		  "\\(?: +\\(\\[#.\\]\\)\\)?"
		  "\\(?: +\\(.*?\\)\\)??"
		  "\\(?:[ \t]+\\(:[[:alnum:]_@#%:]+:\\)\\)?"
		  "[ \t]*$")
	  org-complex-heading-regexp-format
	  (concat "^\\(\\*+\\)"
		  "\\(?: +" org-todo-regexp "\\)?"
		  "\\(?: +\\(\\[#.\\]\\)\\)?"
		  "\\(?: +"
		  ;; Stats cookies can be stuck to body.
		  "\\(?:\\[[0-9%%/]+\\] *\\)*"
		  "\\(%s\\)"
		  "\\(?: *\\[[0-9%%/]+\\]\\)*"
		  "\\)"
		  "\\(?:[ \t]+\\(:[[:alnum:]_@

Re: Programmatically set TODO labels per file?

[Arthur Miller]

Nick Dokos  writes:

> Arthur Miller  writes:
>
>> I have a simple question, but I wasn't able to find answer on the web,
>> so finally I'll try my luck here.
>>
>
>> I know I can setq org-todo-keywords with a list '((sequence "TODO"
>> DONE")), as an example. But what variable is used for per-file keywords?
>> Once that are set with #+TODO: ... line?
>>
>> I guess when org mode parses a file when starting up the mode, it has to
>> parse that line into some var, where do I find it?
>>
>
> It is parsed into a buffer-local variable by the name of
> `org-todo-keywords-1'. Do `C-h v org-todo-keywords' and `C-h v
> org-todo-keywords-1' for all the details.
>
> BTW, when the interwebs fail you (or even before that), use the source :-)

Yes indeed! I used the source Luke! :)

I found that one, unfortunately it is not enough to set that one to my
keywords. There are also two lists in play org-todo-kwd-alist and
org-todo-key-alist which are set in one mastodont method, but I think I
can refactor that out. I have to figure out how to build alist comming
from out org-collect-keywords which is input to that part of
code. Didn't had time last night, will see if I have time today.

Re: Programmatically set TODO labels per file?

[Arthur Miller]

Samuel Wales  writes:

> as you discovered, spaces can work for todo kw for at least some
> purposes.  [i have one, because i prefer space to snake_case and
> kebab-case might not search well.]  but you should check to see if it
> is guaranteed to work.  i vaguely recall spc is not allowable.
>
> if it were guaranteed to work, then there would likely be a mechanism
> to include it in the #+ syntax.  :)

Indeed, I am aware that spaces are not so welcome in some places
:). However this works fine:

(setq org-todo-keywords '((sequence "first label" "second label")))

If it is guaranteed or not I have no idea, maybe some other APIs in org
are expecting labels to be single words, but for simple purpose it seems
to work. #+ could actually use just "" as grouping items or {}. For
example: 

#+TODO: "item one" "item two" ... "item n"

or with {}

#+TODO: {item one} {item two} ... {item n}

When I tried, I got citation characters included in my label, which
wasn't really what I wanted either :).



>
>
> On 4/29/21, Arthur Miller  wrote:
>> Russell Adams  writes:
>>
>>> On Thu, Apr 29, 2021 at 10:49:54PM +0200, Arthur Miller wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I have a simple question, but I wasn't able to find answer on the web,
>>>> so finally I'll try my luck here.
>>>>
>>>> I know I can setq org-todo-keywords with a list '((sequence "TODO"
>>>> DONE")), as an example. But what variable is used for per-file keywords?
>>>> Once that are set with #+TODO: ... line?
>>>>
>>>> I guess when org mode parses a file when starting up the mode, it has to
>>>> parse that line into some var, where do I find it?
>>>>
>>>> Thanks in advance!
>>>>
>>>> Best regards
>>>> /a
>>>>
>>>
>>> https://orgmode.org/manual/Per_002dfile-keywords.html
>>
>> Thanks Rusell; but I have seen the manual as I wrote. I am aware I can
>> use
>>
>> #+TODO:
>>
>> syntax to set per file keywords. I wanted to do this from lisp, since I
>> can't use labels with multiple words with that syntax since spaces are
>> used as delimiters for keywords, but I can pass strings (with spaces)
>> with lisp.
>>
>>
>>

Re: Programmatically set TODO labels per file?

[Arthur Miller]

Russell Adams  writes:

> On Thu, Apr 29, 2021 at 10:49:54PM +0200, Arthur Miller wrote:
>>
>> Hi all,
>>
>> I have a simple question, but I wasn't able to find answer on the web,
>> so finally I'll try my luck here.
>>
>> I know I can setq org-todo-keywords with a list '((sequence "TODO"
>> DONE")), as an example. But what variable is used for per-file keywords?
>> Once that are set with #+TODO: ... line?
>>
>> I guess when org mode parses a file when starting up the mode, it has to
>> parse that line into some var, where do I find it?
>>
>> Thanks in advance!
>>
>> Best regards
>> /a
>>
>
> https://orgmode.org/manual/Per_002dfile-keywords.html

Thanks Rusell; but I have seen the manual as I wrote. I am aware I can
use

#+TODO:

syntax to set per file keywords. I wanted to do this from lisp, since I
can't use labels with multiple words with that syntax since spaces are
used as delimiters for keywords, but I can pass strings (with spaces)
with lisp.

Re: Programmatically set TODO labels per file?

[Arthur Miller]

 writes:

> On Thu, Apr 29, 2021 at 10:49:54PM +0200, Arthur Miller wrote:
>> 
>> Hi all,
>> 
>> I have a simple question, but I wasn't able to find answer on the web,
>> so finally I'll try my luck here.
>> 
>> I know I can setq org-todo-keywords with a list '((sequence "TODO"
>> DONE")), as an example. But what variable is used for per-file keywords?
>> Once that are set with #+TODO: ... line?
>> 
>> I guess when org mode parses a file when starting up the mode, it has to
>> parse that line into some var, where do I find it?
>
> Use a file local variable?
>
> That said (or rather, asked), I don't know whether there is a specific
> Org way to achieve that.

As I understand the manual, the org specific way is to use per file
variable, but instead of using Emacs _*_ for file variables, org uses #+
and they do their own parsing seems like. I might missunderstand, but
the syntax to use is: 

#+TODO: keyword1 keyword2 ... keywordN

I was looking around in org.el a bit now, and I see there are three vars
associated with per-file todo keywords: org-todo-keywords-1
org-todo-kwd-alist and org-todo-key-alist which seem to be set in
org-set-regexps-and-options function. I'll see if I can refactore
something out from there for my purpose. 

Programmatically set TODO labels per file?

[Arthur Miller]

Hi all,

I have a simple question, but I wasn't able to find answer on the web,
so finally I'll try my luck here.

I know I can setq org-todo-keywords with a list '((sequence "TODO"
DONE")), as an example. But what variable is used for per-file keywords?
Once that are set with #+TODO: ... line?

I guess when org mode parses a file when starting up the mode, it has to
parse that line into some var, where do I find it?

Thanks in advance!

Best regards
/a

Re: bug#47937: 27.1; Invisible text property updated only for a portion of buffer

[Arthur Miller]

Eli Zaretskii  writes:

>> From: Arthur Miller 
>> Cc: 47...@debbugs.gnu.org
>> Date: Wed, 21 Apr 2021 22:10:45 +0200
>> 
>> >> Because you have font-lock-mode turned on.  And JIT font-lock begins
>> >> by wiping out all the text properties.
>> >
>> > I should clarify this, I guess: this is specific to Org buffers, see
>> > org-unfontify-region.  And "all text properties" is an exaggeration:
>> > it removes many properties, but not all of them.
>> 
>> Allright, thank you for the excellent clarification. I guess I should go
>> for custom visibility spec instead of plain invisible property, so that
>> my text property survive font lock.
>> 
>> Please close the bug and thanks.
>
> I'm closing the bug, but I suggest to take this up with Org
> developers, because I think org-unfontify-region removes too many
> properties in a way that is too indiscriminate.  They should ideally
> only remove the properties they themselves add.

I just today looked at the function, and I see docs says it should
remove fontification from links, which can partly be set to invisible
since org mode hide markup, so it is probably legit what they do. I am
not sure if that function runs on entire buffer. I'll CC this to
org-mail list so we can see what they say.

I am not really at home with font-lock and text properties, but as it
seems to me from this experience, is that proper way would be to use
visibility spec, and create custom property, since so many different
modes vill fight for default 'visibility property. However I was lazy,
so I just made sure to fontify entire buffer before I do my thing, but
it is not very robust approach :).

Re: Font lock in org+elisp confused with ?\[

[Arthur Miller]

John Kitchin  writes:

> This is related to the issues with <> in src blocks. [ and ] have open and 
> close syntactical meanings like < and > do in org files. A similar solution 
> as found in
> https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch
>  seems to work to fix it.

Indeed, the code from SX works, I took the simpler version and converted
it to work with square brackets:

#+begin_src emacs-lisp
 (defun org-mode-sqbr-syntax-fix (start end)
   (when (eq major-mode 'org-mode)
 (save-excursion
   (goto-char start)
   (while (re-search-forward "[]\\[]" end t)
 (when (get-text-property (point) 'src-block)
   ;; This is a ?[ or ?] in an org-src block
   (put-text-property (point) (1- (point))
  'syntax-table (string-to-syntax 
"_")))

 (defun org-setup-sqbr-syntax-fix ()
   "Setup for characters ?[ and ?] in source code blocks.
  Add this function to `org-mode-hook'."
   (setq syntax-propertize-function 'org-mode-sqbr-syntax-fix)
   (syntax-propertize (point-max)))

 (add-hook 'org-mode-hook 'org-setup-sqbr-syntax-fix)
#+end_src

I have confirmed that code runs when I load my org file, but there seems
to be something else than that callback involed, later on, evaluating
and changing those properties back. I still see same error in the
babel-block. However when I run fix explicitly on that code block (I
converted it to interactive "r" for test), then syntax is fine. So it
seems there is some other callback involved.

Sorry little bit late answer, I thought I sent this a day ago or so, but
apparently I didn't.

Thanks for the help.

Include org-pretty-table by Matus Goljer (Fuco1) in org-mode

[Arthur Miller]

Hi guys,

Can we get org-pretty-table into org-mode?

https://github.com/Fuco1/org-pretty-table

It replaces ascii chars with unicode box-drawing characters.

It might be a bit rough around the edges, and Matus himself does not
seem to be currently interested to work on, but it seems to work
satisfying for me.

I would like to have it in org-mode by default as a coplement to
org-pretty-entities and inline images and links.

Attached is the latest source for those who don't like to download
themselves from Github.

I am not sure if I am the best person to work on this; I am not very
well acquainted with org-mode, but I can try to help as much as I can.

;;; org-pretty-table.el --- Replace org-table characters with box-drawing 
unicode glyphs.

;; Copyright (C) 2013 Matus Goljer

;; Author: Matus Goljer 
;; Maintainer: Matus Goljer 
;; Keywords: faces
;; Version: 0.0.1
;; Created: 29th November 2013

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see .

;;; Commentary:

;; This replaces the characters - | and + in `org-mode' tables with
;; appropriate unicode box-drawing glyphs, see
;; http://en.wikipedia.org/wiki/Box-drawing_character

;;; Code:

(defconst org-pretty-table-regexp (regexp-opt '("-" "+" "|")))

(defsubst org-pretty-table-is-empty-line ()
  (memq (following-char) '(? 10 ?#)))

(defun org-pretty-table-propertize-region (start end)
  "Replace org-table characters with box-drawing unicode glyphs
between START and END.

Used by jit-lock for dynamic highlighting."
  (save-excursion
(goto-char start)
(let (table-end)
  (while (re-search-forward org-pretty-table-regexp end t)
;; reached the end of the current table
(if (and table-end
 (> (point) table-end))
(setq table-end nil))

;; check if the current match is a table if we are not in a
;; table right now
(unless (and (not table-end)
 (not (save-match-data
(org-at-table-p

  ;; get the end of the table if we found a new table, so we
  ;; don't have to check (org-at-table-p) again until then
  (unless table-end
(save-match-data
  (setq table-end (org-table-end
  
  ;; determine the context of the character
  (let ((match (match-string 0)))
(cond
 ((equal "-" match)
  (backward-char 1)
  (re-search-forward "-+")
  (put-text-property (match-beginning 0) (match-end 0) 'display 
(make-string (- (match-end 0) (match-beginning 0)) ?─))
  t)
 ((equal "|" match)
  (cond
   ((and (eq (following-char) ?-)
 (save-excursion
   (forward-line 1)
   (not (org-pretty-table-is-empty-line)))
 (save-excursion
   (forward-line -1)
   (not (org-pretty-table-is-empty-line
(put-text-property (match-beginning 0) (match-end 0) 'display 
"├")
t)
   ((and (save-excursion
   (backward-char 1)
   (eq (preceding-char) ?-))
 (save-excursion
   (forward-line 1)
   (not (org-pretty-table-is-empty-line)))
 (save-excursion
   (forward-line -1)
   (not (org-pretty-table-is-empty-line
(put-text-property (match-beginning 0) (match-end 0) 'display 
"┤")
t)
   ((and (save-excursion
   (backward-char 1)
   (eq (preceding-char) ?-))
 (save-excursion
   (forward-line -1)
   (org-pretty-table-is-empty-line)))
(put-text-property (match-beginning 0) (match-end 0) 'display 
"┐")
t)
   ((and (save-excursion
   (backward-char 1)
   (eq (preceding-char) ?-))
 (save-excursion
   (forward-line 1)
   (org-pretty-table-is-empty-line)))
(put-text-property (match-beginning 0) (match-end 0) 'display 
"┘")
t)
   ((and (eq (following-char) ?-)
 

RE: Re Org 9.4 is out. Can you help? // breaking apart Org Mode

[arthur miller]

Not long time ago I posted a bug report about superscripts and subscripts not 
rendered when in-between italics markings, '/'. I would definitely like to see 
that code, and rest for  prettie-fying entities factored out into a minor mode 
that can be activated in any Emacs  buffer.

What do you think, is it to much work and where can you point out (just 
generally) where to look in the source for the code responsible for that?



 Originalmeddelande 
Från: Bastien 
Datum: 2020-09-23 10:21 (GMT+01:00)
Till: "William Rankin via General discussions about Org-mode." 

Kopia: William Rankin , emacs-de...@gnu.org
Ämne: Re: Re Org 9.4 is out. Can you help? // breaking apart Org Mode

Hi William,

thanks a lot for bringing this up.

Of course, Org would benefit from code cleanup and code refactoring.

And yes, we can collectively push toward (1) modularizing Org a little
more, (2) making Org features better interact with Emacs core features
and (3) integrating some of Org's features into Emacs core as Emacs
features.

IMHO the good examples you give fall into one of the category above,
and I think such efforts are likely to happen in that order: 1, 2, 3.

The better way to make this happen is to start a discussion with a
patch explaining how it makes 1, 2 or 3, then discussing the patch
here on this list - the smaller the better.

If you cannot make a patch, first discuss your idea, and once the
implementation seems clear, call for help by using a mail header:

  X-Woof-Help: Help with making X a new module

Thanks,

--
 Bastien