Re: [PATCH] minor typo fix in org-tutorials/org-protocol-custom-handler.org
Tim Cross writes: > this is a trivial fix and should be applied. > > Atlas Cove writes: > >> From: Atlas48 >> >> As it says, this is a minor fix to worg. Turns out I have push access; in it goes!
Re: [PATCH] minor typo fix in org-tutorials/org-protocol-custom-handler.org
this is a trivial fix and should be applied. Atlas Cove writes: > From: Atlas48 > > As it says, this is a minor fix to worg. > > --- > org-tutorials/org-protocol-custom-handler.org | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/org-tutorials/org-protocol-custom-handler.org > b/org-tutorials/org-protocol-custom-handler.org > index 729ff30b..1e56102f 100644 > --- a/org-tutorials/org-protocol-custom-handler.org > +++ b/org-tutorials/org-protocol-custom-handler.org > @@ -235,7 +235,7 @@ nil) > > * General remarks > > - emacsclient compresses double and tripple slashes to one. That's why it > + emacsclient compresses double and triple slashes to one. That's why it >doesn't really matter how many slashes succeed the scheme part of the URL, >also known as /protocol/.
Re: [PATCH] Rename headline to heading
this patch looks pretty good to me. My only suggestion is that the need to update capture templates be made more explicit in the NEWS.org file. I'm assuming this patch would only be applied to the next release and not maint branch. Probably important to try and apply this before the main branch moves on too much to avoid merge issues. While none of what is in the patch is terribly complex, it does have a lot of tough points and I imagine it could be fragile wrt underlying branch changes. André A. Gomes writes: > Hi, > > As previously discussed, please find the patch below. > > I run the tests locally and they all pass. Let me know what you think. > > I'm still waiting for the FSF to send me back my form signed. I've sent > it on the 31st of July.
Re: [PATCH] Rename headline to heading
Maxim Nikulin writes: > On 05/08/2021 19:12, André A. Gomes wrote: >> @@ -963,7 +963,7 @@ Store them in the capture property list." >> (org-capture-put-target-region-and-position) >> (goto-char position)) >> (_ (error "Cannot find target ID \"%s\"" id >> -(`(file+headline ,path ,headline) >> +(`(file+heading ,path ,heading) > > I am sorry if is a false alarm. Does it mean that all users having > "file+headline" in their init.el files will have to immediately update > configuration? Shouldn't both variants be supported during transitional > period? > > P.S. https://orgmode.org/worg/dev/org-syntax.html consistently uses > "headline". I'm not convinced a transition period will help in this case. At some point, users will need to update their capture templates regardless. Provided this impact is clearly outlined in the NEWS.org file (I think there should be a specific reference to capture templates added in the patch to NEWS.org) and provided this change is applied to the next release only, no transition period is necessary. In this case, a transition period would add complexity to the code that would have to remain in place until the next major release and at that release, anyone who has not updated their templates will have the same breakage anyway. I feel there is a difference between changes in configuration and changes in code. Updating capture templates is trivial. Updating code is often more complex, which is why we have the obsolete mechanism for functions and variables. If we were making this change in a maintenance release, that would be a completely different story and a transition period would definitely be necessary. Users should expect some breakage in configuration when upgrading to a new major version.
Smart quotes for Greek (questions for a possible patch)
Hi, I would like to submit a patch to add smart quotes for Greek in `org-export-smart-quotes-alist', but I have a couple of questions. First of all, I am not a native speaker of Greek but of Spanish, so I would also like to have the opinion of some Greek native speaker, to see if my solutions are correct. The second question concerns the second-level quotation marks for Greek. The first level ones are the same as the Spanish or French quotes (without the extra space of French): «», so no problem. I follow here the rule that Yannis Haralambous explains in "From Unicode to Typography, a Case Study: the Greek Script" (1999, p. 20: http://web.archive.org/web/20120229131933/http://omega.enstb.org/yannis/pdf/boston99.pdf). According to Haralambous, on the second-level quotation marks (the emphases are mine): #+begin_quote Also interesting is the case of the second level quotes. Here, quotes of the size and shape of the English ones are used, but the opening quotes are inverted, similar in form to raised small round guillemets [...]. Fortunately these quotes are provided by the Unicode standard (*U+201F* and U+201D, the latter being the same closing double quotes as in English); *the author knows no other language in which this combination of double quotes might be used*. #+end_quote So the problem is in the character U+201F (assuming Haralambous is right). For the keywords `:utf8' and `html' no problem. But I don't know what to put in `:latex' or in `:texinfo': #+begin_src emacs-lisp (secondary-opening :utf-8 "‟" :html "‟;" :latex "??" :texinfo "??") #+end_src In fact, I think latex2e has no command or shorthand predefined for this character (see https://ibb.co/ZBGmwYP). There would be no problem with LuaTeX and XeTeX. But this character would be difficult to obtain in pdfTeX even using inputenc with the utf8 option. Best regards, Juan Manuel
Re: Custom function for killing the thing at point
John Kitchin writes: > alternatively, fall back to org-mark-element. I am not sure what > differences in what you are trying to achieve and this are, but this should > cover all org elements: Sounds more reasonable as a default. (org-mark-element) will mark everything including affiliated keywords and post-blank empty lines. (:begin .. :end) will not include the affiliated keywords and extra blank lines. Best, Ihor
Re: Function for retrieving the link of an Org Mode buffer
I would probably do it like this: (org-element-map (org-element-parse-buffer) 'link (lambda (lnk) (let ((lnkplist '())) (setq lnkplist (plist-put lnkplist :link (org-element-property :raw-link lnk))) (when (org-element-property :contents-begin lnk) (setq lnkplist (plist-put lnkplist :desc (buffer-substring-no-properties (org-element-property :contents-begin lnk) (org-element-property :contents-end lnk) lnkplist))) 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, Aug 13, 2021 at 9:16 PM Rodrigo Morales < moralesrodrigo1...@gmail.com> wrote: > > I've written the following function for retrieving the links from a > given Org Mode buffer. > > #+BEGIN_SRC elisp > (defun my/org-collect-links-in-buffer (buffer) > "Collect all the links in the current buffer. If the link has a > description, then it is also collected. > > Returns a list of PLISTS of the form: > > ((:link LINK) > (:link LINK :desc DESC) > (:link LINK))" > (with-current-buffer buffer > (save-excursion > (beginning-of-buffer) > (let (links) > (while (re-search-forward org-any-link-re nil t) > (catch 'done > (let* ((element (org-element-context)) >(type (org-element-type element))) > (unless (eq type 'link) > (throw 'done t)) > (let (obj > (link (org-element-property :raw-link element)) > desc) > (push link obj) > (push :link obj) > (when (and (org-element-property :contents-begin element) >(org-element-property :contents-end element)) > (setq desc (buffer-substring-no-properties > (org-element-property :contents-begin > element) > (org-element-property :contents-end > element))) > (push desc obj) > (push :desc obj)) > (push obj links) > links > #+END_SRC > > I would really appreciate any feedback. > >
Re: Custom function for killing the thing at point
alternatively, fall back to org-mark-element. I am not sure what differences in what you are trying to achieve and this are, but this should cover all org elements: (defun org-kill-element () (interactive) (org-mark-element) (call-interactively #'kill-region)) 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, Aug 13, 2021 at 9:45 PM Ihor Radchenko wrote: > Rodrigo Morales writes: > > > (t > >(error "The element at point couldn't be copied."))) > > I would fall back to region between :begin and :end of the element. > > Also, it might be helpful to print a short message about what element > have just been copied. > > Best, > Ihor > >
Re: return column from table as a column
On 13/08/2021 21:17, Roger Mason wrote: I need to extract a column from a table to use as input to a source block. I want the extracted column to be returned as a column but it is returned as a row. The following illustrates the problem: #+name: s1 | scale | scale1 | scale3 | jid | | - | 1.00402 | 0.952329 | 1632 | | - | 1.00402 | 0.962247 | 1633 | #+begin_src emacs-lisp :var data=s1[,3] data #+end_src #+RESULTS: | jid | 1632 | 1633 | I want: | jid | | 1632 | | 1633 | Is there some means of changing 'data=s1[,3]' to accomplish this? Notice that you can get vertical representation of results as a list #+begin_src emacs-lisp :results list The following is a variation of a recipe suggested by Juan Manuel: #+name: to-column #+begin_src emacs-lisp :var lst=() (mapcar #'list lst) #+end_src #+begin_src emacs-lisp :var data=s1[,3] :post to-column(lst=*this*) data #+end_src To transform more than one column, the following idea may be useful (defun rotate (list-of-lists) (apply #'mapcar #'list list-of-lists)) https://stackoverflow.com/questions/3513128/transposing-lists-in-common-lisp
Re: return column from table as a column
Hello Juan, Juan Manuel Macías writes: > You're welcome. Just a minor fix: although the code works fine, > naturally the asterisk in `let' was unnecessary. This is a new version > with the code explained, in case you find it useful: > > #+begin_src emacs-lisp :var data=s1 col=3 > (let* ( >;; return a list from elemens in column number `col' >(list-from-column (mapcar (lambda (r) (format "%s" (nth col r))) data)) >;; make a list of lists = a new table that contains one single column >(new-table (mapcar 'list list-from-column))) > new-table) > #+end_src Many thanks for this. A looong time ago I was capable of programming in emacs-lisp. Alas I have not maintained my skills. Best wishes, Roger
