[ANN] faster org-table-to-lisp
Hi The List. Here is an alternative, faster version of org-table-to-lisp. It can be more than 100 times faster. #+BEGIN_SRC elisp (defun org-table-to-lisp-faster (&optional org-table-at-p-done) "Convert the table at point to a Lisp structure. The structure will be a list. Each item is either the symbol `hline' for a horizontal separator line, or a list of field values as strings. The table is taken from the buffer at point. When the optional ORG-TABLE-AT-P-DONE parameter is not nil, it is assumed that (org-at-table-p) was already called." (or org-table-at-p-done (org-at-table-p) (user-error "No table at point")) (save-excursion (goto-char (org-table-begin)) (let ((end (org-table-end)) (row) (table)) (while (< (point) end) (setq row nil) (search-forward "|" end) (if (looking-at "-") (progn (search-forward "\n" end) (push 'hline table)) (while (not (search-forward-regexp "\\=\n" end t)) (unless (search-forward-regexp "\\=\\s-*\\([^|]*\\)" end t) (user-error "Malformed table at char %s" (point))) (let ((b (match-beginning 1)) (e (match-end 1))) (and (search-backward-regexp "[^ \t]" b t) (forward-char 1)) (push (buffer-substring-no-properties b (point)) row) (goto-char (1+ e (push (nreverse row) table))) (nreverse table #+END_SRC Bellow is an example of a large table borrowed from the Datamash software. On my PC, the reproducible benches show: - Traditional org-table-to-lisp: 130 seconds - Alternative org-table-to-lisp: 0.8 seconds (not compiled) It is faster because it operates directly on the buffer with (search-forward-regexp). Whereas the standard function splits a string extracted from the buffer. This function is a drop-in replacement for the standard one. It can benefit to Babel and Gnuplot. Would it make sense to upgrade Org Mode code base? Beware! The optional parameter has a slightly different meaning for both functions: - for the traditional function, it is a string representing an Org table - for the alternative function, it is a Boolean telling whether (org-table-at-p) has been called or not This difference makes no difference for the use cases in the code base. The function is always called without a parameter, or as: #+BEGIN_SRC elisp (org-table-to-lisp (buffer-substring-no-properties (org-table-begin) (org-table-end))) #+END_SRC Here is the reproducible bench. It is a self-contained, Org Mode file to be opened in Emacs. wget http://tbanelwebmin.free.fr/OrgMode/bench-org-table-to-lisp.org.gz
Re: How to properly set up reminders for paying cellphone fees in org?
Ah, great, thanks! I have been looking at the wrong node all the time. However, the manual node you're pointing to disagrees with the claim that those are equivalent: >If you need both a repeater and a special warning period in a deadline >entry, the repeater should come first and the warning period last > DEADLINE: <2005-10-01 Sat +1m -3d> However, the manual may be incomplete. Thank you, problem seems to be solved. Kyle Meyer 於 2020年4月30日 週四 13:02 寫道： > Vladimir Nikishkin writes: > > > I need to pay a fee by every 28th of the month, and I want this task > > to show up in the agenda from the 20th of the next not paid month. > > > > What's the proper DEADLINE format? > > > > DEADLINE: <2020-02-28 Sun .+1m -10d> ? > > DEADLINE: <2020-02-28 Sun -10d .+1m> ? > > Those are equivalent. Though you might consider whether you'd prefer > '+' or '++' for this rather than '.+'. See (info "(org)Repeated tasks") > if you're not aware of the differences. > > And note that a utility like datefudge or libfaketime is useful for > testing these sorts of things out. For example: > > $ datefudge "2020-02-18" emacs [...] >
Re: How to properly set up reminders for paying cellphone fees in org?
Vladimir Nikishkin writes: > I need to pay a fee by every 28th of the month, and I want this task > to show up in the agenda from the 20th of the next not paid month. > > What's the proper DEADLINE format? > > DEADLINE: <2020-02-28 Sun .+1m -10d> ? > DEADLINE: <2020-02-28 Sun -10d .+1m> ? Those are equivalent. Though you might consider whether you'd prefer '+' or '++' for this rather than '.+'. See (info "(org)Repeated tasks") if you're not aware of the differences. And note that a utility like datefudge or libfaketime is useful for testing these sorts of things out. For example: $ datefudge "2020-02-18" emacs [...]
How to properly set up reminders for paying cellphone fees in org?
Hello, everyone I need to pay a fee by every 28th of the month, and I want this task to show up in the agenda from the 20th of the next not paid month. What's the proper DEADLINE format? DEADLINE: <2020-02-28 Sun .+1m -10d> ? DEADLINE: <2020-02-28 Sun -10d .+1m> ? Thanks! -- Yours sincerely, Vladimir Nikishkin
Re: [PATCH] org-agenda.el: Complete multiple todo keywords
Thanks for the patch. Looks like a nice improvement to me. akater writes: > * lisp/org-agenda.el (org-todo-list): Use completing-read-multiple > instead of completing-read when selecting todo keywords to filter by > in Agenda. This and the rest of the lines were unwrapped. Could you wrap them ~70 characters? (The Org repo's .dir-locals.el sets fill-column to 70.) > * lisp/org-agenda.el (org-todo-list): Fix a typo in the prompt. Thanks for spotting that typo. I think it'd be more common to append this description to the entry above rather than adding another org-todo-list entry. > There is minor UX cost to Helm users: while candidates list used to > appear immediately to Helm users, now Helm users have to hit TAB to > see the list. Just the opinion of one Helm user, but needing to hit tab for crm-based completion has never bothered me too much. But if it did, Helm allows specifying that certain commands should go through the built-in completion. Out of curiosity I tried with the latest ivy (9e0803c), and I also needed to hit tab before seeing anything. > This inconsistency is not present in vanilla Emacs > completion. I'm confused by this. When I try with no customization (Emacs 26.3), I need to hit tab to see any of the candidates. > The issue had been discussed with experienced Helm developer who > insisted that current Helm behaviour should not change. I think this bit can be pruned from the commit message. > We opted to use custom separator that is more natural in context. Looks like you stuck with "|" as the separator, which seems like a good idea to me. > However, it is unfortunate that string patterns are strings themselves > and are thus indistinguishable from strings; it would be better if crm > exposed separator (the string) on its own in its interface. I'm not quite sure I follow what you're suggesting with the last bit. Could you rephrase the point in a way that is a bit more connected with the code change? This patch sticks with the same separator, so aside from being able to complete multiple things, there's no change in behavior/added restriction here, right?
Re: org-mode setting the browser with options
On 4/29/20 6:30 PM, Tim Cross wrote:
>
> Jude DaShiell writes:
>
>> Two different scripts one yproxy and the other nproxy.
>> Put the necessary running code in each.
>>
>> On Wed, 29 Apr 2020, Neil Cherry wrote:
>>
>>> Date: Wed, 29 Apr 2020 13:36:50
>>> From: Neil Cherry
>>> To: Org Mode
>>> Subject: org-mode setting the browser with options
>>>
>>> I need to use 2 different Windows browser (proxy and no-proxy is the
>>> reason).
>>>
>>> What I want to do is that if it's example.com use firefox (no options). If
>>> it's
>>> example.org use chrome --no-proxy-server. I'm not exacly sure how to
>>> approach this.
>>>
>>> Thanks
>>>
>>>
>
> I would look at browse-url built-in package. With browse-url you can set
> a function that will determine which browser to use based on the url and
> you can set the options for each supported browser.
>
Thanks, that got me thinking and search-fu found:
(setq
browse-url-browser-function
'(
("example\\.com" . browse-url-chrome)
("example\\.org" . browse-url-chrome)
("." . browse-url-default-browser)
))
Which works perfect!
Thanks
--
Linux Home Automation Neil Cherry nche...@linuxha.com
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/My HA Blog
Author of: Linux Smart Homes For Dummies
Re: org-mode setting the browser with options
Jude DaShiell writes: > Two different scripts one yproxy and the other nproxy. > Put the necessary running code in each. > > On Wed, 29 Apr 2020, Neil Cherry wrote: > >> Date: Wed, 29 Apr 2020 13:36:50 >> From: Neil Cherry >> To: Org Mode >> Subject: org-mode setting the browser with options >> >> I need to use 2 different Windows browser (proxy and no-proxy is the reason). >> >> What I want to do is that if it's example.com use firefox (no options). If >> it's >> example.org use chrome --no-proxy-server. I'm not exacly sure how to >> approach this. >> >> Thanks >> >> I would look at browse-url built-in package. With browse-url you can set a function that will determine which browser to use based on the url and you can set the options for each supported browser. -- Tim Cross
Re: org-mode setting the browser with options
Two different scripts one yproxy and the other nproxy. Put the necessary running code in each. On Wed, 29 Apr 2020, Neil Cherry wrote: > Date: Wed, 29 Apr 2020 13:36:50 > From: Neil Cherry > To: Org Mode > Subject: org-mode setting the browser with options > > I need to use 2 different Windows browser (proxy and no-proxy is the reason). > > What I want to do is that if it's example.com use firefox (no options). If > it's > example.org use chrome --no-proxy-server. I'm not exacly sure how to approach > this. > > Thanks > > --
org-mode setting the browser with options
I need to use 2 different Windows browser (proxy and no-proxy is the reason). What I want to do is that if it's example.com use firefox (no options). If it's example.org use chrome --no-proxy-server. I'm not exacly sure how to approach this. Thanks -- Linux Home Automation Neil Cherry nche...@linuxha.com http://www.linuxha.com/ Main site http://linuxha.blogspot.com/My HA Blog Author of: Linux Smart Homes For Dummies
[PATCH] org-agenda.el: Complete multiple todo keywords
* lisp/org-agenda.el (org-todo-list): Use completing-read-multiple instead of completing-read when selecting todo keywords to filter by in Agenda. * lisp/org-agenda.el (org-todo-list): Fix a typo in the prompt. There is minor UX cost to Helm users: while candidates list used to appear immediately to Helm users, now Helm users have to hit TAB to see the list. This inconsistency is not present in vanilla Emacs completion. The issue had been discussed with experienced Helm developer who insisted that current Helm behaviour should not change. We opted to use custom separator that is more natural in context. However, it is unfortunate that string patterns are strings themselves and are thus indistinguishable from strings; it would be better if crm exposed separator (the string) on its own in its interface. org-agenda.el: Complete multiple todo keywords * lisp/org-agenda.el (org-todo-list): Use completing-read-multiple instead of completing-read when selecting todo keywords to filter by in Agenda. * lisp/org-agenda.el (org-todo-list): Fix a typo in the prompt. There is minor UX cost to Helm users: while candidates list used to appear immediately to Helm users, now Helm users have to hit TAB to see the list. This inconsistency is not present in vanilla Emacs completion. The issue had been discussed with experienced Helm developer who insisted that current Helm behaviour should not change. We opted to use custom separator that is more natural in context. However, it is unfortunate that string patterns are strings themselves and are thus indistinguishable from strings; it would be better if crm exposed separator (the string) on its own in its interface. --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -4790,8 +4790,12 @@ (nth (1- arg) kwds (when (equal arg '(4)) (setq org-select-this-todo-keyword - (completing-read "Keyword (or KWD1|K2D2|...): " - (mapcar #'list kwds) nil nil))) + (mapconcat #'identity + (let ((crm-separator "|")) + (completing-read-multiple +"Keyword (or KWD1|KWD2|...): " +(mapcar #'list kwds) nil nil)) + "|"))) (and (equal 0 arg) (setq org-select-this-todo-keyword nil)) (org-compile-prefix-format 'todo) (org-set-sorting-strategy 'todo)
[PATCH] make org-attach-url download function as an option
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I found when network is bad and slow, or the download file is big, the org-attach-url will suspend Emacs for a long time. User might have to cancel downloading, and start again later. I hope to make "org-attach-url" download file asynchronously. But function org-attach-attach hardcoded this function for 'url method. Here is a patch to make it into an option. So user can specify a custom function to download file. # == BTW, I'm wandering why function "url-retrieve" download file is not complete and failed. Bellowing code snippets are my try: Use function ~url-copy-file~ works fine: #+begin_src emacs-lisp :eval no (url-copy-file "https://img1.doubanio.com/view/photo/s_ratio_poster/public/p2592521688.webp"; (expand-file-name "~/kk.webp")) #+end_src I check out function ~url-copy-file~ implement, try to implement an async version like this: #+begin_src emacs-lisp (defun url-copy-file-asynchronous (url newname &optional ok-if-already-exists &rest _ignored) "Copy URL to NEWNAME. Both arguments must be strings. Signal a `file-already-exists' error if file NEWNAME already exists, unless a third argument OK-IF-ALREADY-EXISTS is supplied and non-nil. An integer as third argument means request confirmation if NEWNAME already exists." (and (file-exists-p newname) (or (not ok-if-already-exists) (and (integerp ok-if-already-exists) (not (yes-or-no-p (format "File %s already exists; copy to it anyway? " newname) (signal 'file-already-exists (list "File already exists" newname))) (let* ((buffer (or (url-retrieve url (lambda (&rest ignored))) (signal 'file-missing (list "Opening URL" "No such file or directory" url (handle (with-current-buffer buffer (mm-dissect-buffer t (let ((mm-attachment-file-modes (default-file-modes))) (mm-save-part-to-file handle newname)) (kill-buffer buffer) (mm-destroy-parts handle))) (put 'copy-file 'url-file-handlers #'url-copy-file-asynchronous) #+end_src #+begin_src emacs-lisp (url-copy-file-asynchronous "https://img1.doubanio.com/view/photo/s_ratio_poster/public/p2592521688.webp"; (expand-file-name "~/kk.webp")) #+end_src But it download seems incomplete and failed. Don't know why. Also there are extra async libraries support download file asynchronously. Like "deferred", "async" etc. Those libraries can be used for user define their own functions. Is you have better idea, please tell me, thanks in advance. - -- [ stardiviner ] I try to make every word tell the meaning that I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6phdUUHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsNswQgAjuFtM/+WU0EXdpQOx3C4kymgUTex jEZgw96JlfHSP3JcoOuA5Ll2F+nXShWwIeGJAe1aRgjLTy9O5XSZO6BdlxoN2QRB RfrZvl5X5cJu9NIyiwhSYbIMM8+DJKHSp/nBGIimXwDoNU/ye43E4OmApVKfWjf0 TmMXUzLnXWSxdSubFe/M7SEGUaarFI5y2bNwytBMOQr7q1yY6UgynlB6Vda06mqb BO/AnJgYtP69XvghK14NJ6/X8nol5oFijLtt67QUNKBCdUlp3tx/G+6lFebGruHS kZ6PjTzoAwZOk5l7lTx9mG+dle1g/7rNce1TRVFP+cT1+qS5+7UHhwfnwg== =pYDj -END PGP SIGNATURE-
Re: Reconciling org-mode idiosyncrasies with Emacs core
Hello, Kévin Le Gouguec writes: > Nicolas Goaziou writes: > >> For example, having RET >> inserting a plain newline would be a disaster in many locations. > > I don't think I've seen anybody advocating for that! If you are > referring to this bit: > >> (Frustratingly, org-mode uses what I think of as the "old" convention >> to use RET as "plain newline" and C-j as "smart newline with indent".) No I wasn't. I was referring to Juri Linkov's idea of providing a minor mode to disable every single Org specific binding. > Do you think a patch that > > - tweaked org-return (bound to RET) to default its INDENT argument to > the current value of electric-indent-mode, > > - tweaked org-return-indent (bound to C-j) to call > electric-newline-and-maybe-indent (the new default binding for C-j > everywhere else in Emacs, which takes care of consulting > electric-indent-mode) instead of newline-and-indent, > > would be well-received? I would love to cook up such a patch, but I > would be loath to break the workflows of long-time Org users who have > come to rely on C-j indenting and RET inserting plain newlines … It will break some workflows (mine, at least), undoubtedly, but it is a step forward anyway. Org is a part of Emacs, there's no reason for the former to follow a different path than the latter. Besides, undoing the change is easy enough, since you only need to disable Electric Indent mode. The change will not appear overnight in Org, i.e., not in Org stable's branch (Org 9.3.X), and it will be announced in ORG-NEWS. I do think it is a very welcome change. Thank you. I cleaned a bit Cc header and added Org mode list for further comments. Regards, -- Nicolas Goaziou
Re: wip-cite status question and feedback
Hello, Am 25.04.2020 um 18:19 schrieb Nicolas Goaziou: Hello, I cannot answer all open questions as the thread would spread too thin. So, I'll try to subsume where Org is at the moment, and what need to be decided. Thanks for the suggestion. Looks like a pretty solid approach. There is a limitation for prefixes and suffixes: they cannot contain semicolons or closing square brackets. I'm not sure it is worth implementing some character escape mechanism, tho. What about using quotes if someone needs this, like so [cite: "common prefix; still common prefix"; pre @key post; pre @key2 post; common suffix] ? Now with styles: [cite/style: ...] [cite/style/substyle: ...] [cite/mycitationprocessor/fullcite: ...] [cite/foot/text: ...] [cite/style/substyle/subsubstyle/OMG: ...] The forward slash separator gives us local citation style and a name space. There's no limit on the depth of sub-styles. However style strings are limited to alphanumeric characters only. Good solution. I assume [cite:...] is the default citation style, defined at the citation processor's level. Styled citations override locally the default style. Again, a processor not handling a given style is expected to fallback to default style. As a consequence, there is no special syntax for "author-in-text" style. But we can suggest one for back-end processors. We might want to stick to the most complete one, BibLaTeX, IIUC, and /require/ processors to support, at least: [cite/text: ...] [cite/paren: ...] With this bare minimum, we ensure documents are somehow portable between processors, and, therefore, export back-ends. Hopefully we can move onto the next step: how should we interface citation processors and Org? First, I think we agreed on the BIBLIOGRAPHY keyword, with the following syntax: #+BIBLIOGRAPHY: file #+BIBLIOGRAPHY: "file" There can be multiple BIBLIOGRAPHY keywords in a document (and equivalent node properties). Also, I think Org should support a global variable, e.g., `org-citation-default-bibliography'. I also think we defined a keyword to insert a bibliography: #+PRINT_BIBLIOGRAPHY: ... options ... (may be specific to citation processors) Looks good. - Export :: In this case, we may want to allow multiple processors for various export back-ends. I thought about declaring active processors in a document with a keyword, e.g., #+CITATION_PROCESSOR: org-ref :default-style foo :back-ends (latex) #+CITATION_PROCESSOR: citeproc :default-style bar and with a global variable, e.g., `org-citation-export-default' which could be, e.g., '((default :defaut-style "authoryear" :back-ends (latex))) but could become, with appropriate libraries '((org-ref :defaut-style "authoryear" :back-ends (latex)) (citeproc-org :default-style "style-file.csl" :back-ends nil)) where more specialized back-ends are used first. Note that `latex' would mean `latex' and derived back-ends, e.g., `beamer'. Well, that's all for now. Again, I am not a citation specialist, so I need feedback. Let's keep the ball rolling! Does that mean you'll be able to have the same or different processors for different backends? (Like biblatex for latex and citeproc-el for ODT/HTML/etc.; or when you need identical output you can use citeproc-el even for latex?) Again, thanks for all your work here. All the best, Denis
