Re: [O] Radio targets
Hello, R C writes: > Please see attached. The org file is just: > > * <<>> heading > The discussion in *abc* highlights the issue. Fixed. Thank you. Regards, -- Nicolas Goaziou0x80A93738
[O] org-protocol-check-filename-for-protocol obscures other errors
Hi, I've found that catching errors at this spot in org-protocol-check-filename-for-protocol (currently line 618 in the file): file:~/src/org-mode/lisp/org-protocol.el::(error Is causing a couple of problems. 1. Any error in the sub-protocol handler causes the handler to be called a second time with an old-style link string. I guess this is okay if the reason for the error is the handler's not handling new-style links, but if not, calling it a second time with the other string doesn't work. 2. Catching all errors here obscures any error in the sub-protocol handler. This makes it very difficult to debug the handler. For example, in my handler I was calling call-process-region with a final argument which should have been a string, but because of a bug in my code the argument was nil, and this caused call-process-region to give an error. But the error was caught and replaced with the warning, and then the handler was called a second time, which, of course, failed again. Even using edebug on the handler didn't help, because the error was still obscured. I had to take apart the handler and run each expression manually to get to the real error. (I tried temporarily removing the condition-case from org-protocol-check-filename-for-protocol, but for some reason that didn't help--I probably did something wrong.) Could this code be adjusted to help avoid this problem in the future? Thanks.
[O] ANN/RFC: org-recent-headings
Hi friends, I finally put together a package I've been thinking about for a long time: org-recent-headings. It keeps a list of recently accessed Org headings and lets you quickly jump to them using completing-read, Helm, or Ivy. It should be added to MELPA soon, but in the meantime I would greatly appreciate any feedback. You can find it here: https://github.com/alphapapa/org-recent-headings Thanks, Adam
Re: [O] Mathjax CDN to shutdown April 30th 2017
On Sat, Apr 15, 2017 at 12:22 PM, Nicolas Goaziou wrote: > > Is there a plan to move the default org-mode mathjax header link over to > > this by 30 April? It's a one line change in ox-htm.el for mathjax > options. > > I've attached that patch for convenience. However, after a bit of > > grepping, there should be some changes to the documentation which refers > to > > using the mathjax CDN and stuff. > > Would you want to provide a patch for that? > [...] > > Have you signed FSF papers? Otherwise, you need to include "TINYCHANGE" > at the end of your commit message before I can apply it. > I've included both changes, to doc and the the html export in the attached patch, now with properly commit message including the TINYCHANGE. I would like to also figure out why (still can't track it down right now) if you don't do the settings via (org-html-mathjax-options) you get orgmode.org's hosting of mathjax.js via HTTP. It would seem wiser to either host this under HTTPS so that the loading of mixed-content is not blocked when using HTTPS or change that to also using the cdn. -adam -- Adam J. Aviv, PhD *Asst. Professor* *Computer Science* *U.S. Naval Academy* *(410) 293- 6655 <(410)%20293-6655>* 0001-Updating-mathjax-CDN-links-to-reflect-cdnjs.com-as-c.patch Description: Binary data
Re: [O] Mathjax CDN to shutdown April 30th 2017
Hello, Adonay Felipe Nogueira writes: > I would personally try to avoid CloudFlare, because it currently forces > the site visitor to run non-(free/libre) software (automatically through > JavaScript). > > And even if it's prooven to be free/libre, it currently doesn't tell > this to the user/visitor in a clear way (next to the place where the > script is, with a license, and address of complete corresponding source > in case it's currently obfuscated/minified). AFAIU, it is only a default option. You can use something else. Would you want to suggest a better option as the default value? Regards, -- Nicolas Goaziou
Re: [O] Mathjax CDN to shutdown April 30th 2017
Hello, Adam Aviv writes: > I saw this blogpost recently about cdn.mathjax.org will be shutdown on > April 30th 2017. > > https://www.mathjax.org/cdn-shutting-down/ > > There's a replacement to use cloudflair hosting instead > > https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?... Thank you for the heads up. > Is there a plan to move the default org-mode mathjax header link over to > this by 30 April? It's a one line change in ox-htm.el for mathjax options. > I've attached that patch for convenience. However, after a bit of > grepping, there should be some changes to the documentation which refers to > using the mathjax CDN and stuff. Would you want to provide a patch for that? > On another note, the default option of using orgmode.org's hosting of > mathjax.sh should be updated to support HTTPS because most browsers block > scripts loaded under http if the page is loaded under https. Or, that > default should also change to the cloudflare cdn if it fits within the > terms of service. Perhaps that should be a discussion for another thread, > though. > > -aja > > -- > Adam J. Aviv, PhD > *Asst. Professor* > *Computer Science* > *U.S. Naval Academy* > *(410) 293- 6655* > From 80e5b49bd1666418a58124e74d7098fd4d5fcae5 Mon Sep 17 00:00:00 2001 > From: Adam Aviv > Date: Wed, 12 Apr 2017 09:16:31 -0400 > Subject: [PATCH] Fixing link to mathjax cdn as cdn.mathjax.org is shutting > down Apirl 30, 2017 > > --- > lisp/ox-html.el | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lisp/ox-html.el b/lisp/ox-html.el > index 251e1be..70d3bde 100644 > --- a/lisp/ox-html.el > +++ b/lisp/ox-html.el > @@ -1160,7 +1160,7 @@ See `format-time-string' for more information on its > components." > Template :: Mathjax > > (defcustom org-html-mathjax-options > - '((path > "http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS_HTML"; ) > + '((path > "https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS_HTML"; > ) > (scale "100") > (align "center") > (font "TeX") Have you signed FSF papers? Otherwise, you need to include "TINYCHANGE" at the end of your commit message before I can apply it. Regards, -- Nicolas Goaziou
Re: [O] Radio targets
Hello, R C writes: > Hi, > Please see attached. The org file is just: > > * <<>> heading > The discussion in *abc* highlights the issue. Thank you. Fixed. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] test-org/fuzzy-links
* Nicolas Goaziou [2017-04-15 16:53]: Rafael Laboissière writes: Function org-backward-heading-same-level fails in a specific case. Suppose the following org-mode file: == * first * second * third == where '* first' is right at the beginning of the file. When the cursor is at line '* third' and org-backward-heading-same-level is called, we go to the previous line correctly. However when the cursor is at '* second', org-backward-heading-same-level does bring us to the first line but emits an error "Beginning of buffer". It seems that the patch attached to this message fixes the problem. Thank you. I eventually applied a slightly different patch, and added some tests. Thanks. Best, Rafael
Re: [O] [PATCH] test-org/fuzzy-links
Hello, Rafael Laboissière writes: > Function org-backward-heading-same-level fails in a specific case. > Suppose the following org-mode file: > > == > * first > * second > * third > == > > where '* first' is right at the beginning of the file. > > When the cursor is at line '* third' and > org-backward-heading-same-level is called, we go to the previous line > correctly. However when the cursor is at '* second', > org-backward-heading-same-level does bring us to the first line but > emits an error "Beginning of buffer". It seems that the patch > attached to this message fixes the problem. Thank you. I eventually applied a slightly different patch, and added some tests. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] : org-link-search failing to find links created by clock table
Sorry, I'm trying out MailMate and forgot to select Plain Text when copying in from Emacs. * Example of the issue Emacs : GNU Emacs 25.2.1 (x86_64-apple-darwin16.4.0, Carbon Version 157 AppKit 1504.81) of 2017-03-07 Package: Org mode version 9.0.5 (release_9.0.5-351-g0e0fda.dirty @ /Users/stacey/.emacs.d/org-mode/lisp/) In this buffer the TODO keywords are FIXME and FIXED, as set by: #+SEQ_TODO: FIXME FIXED #+BEGIN: clocktable :maxlevel 4 :scope subtree :link t #+CAPTION: Clock summary at [2017-04-14 Fri 20:01] | Headline | Time | | | | |+---+-+---+---| | *Total time* | *1h 9min* | | | | |+---+-+---+---| | [[file:/tmp/test.org::Example%20of%20the%20issue][Example of the issue]] | 1h 9min | | | | | \_ [[file:/tmp/test.org::Test%20log][Test log]] | | 0h 4min | | | | \_ [[file:/tmp/test.org::Test%20log][FIXME Test log]] | | 1h 0min | | | | \_ [[file:/tmp/test.org::test%20with%20comment%20no%20to-do][COMMENT test with comment no to-do]] | | 0h 2min | | | | \_ [[file:/tmp/test.org::FIXME%20comment%20with%20to-do%20keyword][COMMENT FIXME comment with to-do keyword]] | | 0h 1min | | | | \_ [[file:/tmp/test.org::with%20a%20fraction][FIXME with a fraction]] | | 0h 1min | | | | \_ [[file:/tmp/test.org::with%20a%20percentage][FIXME with a percentage]] | | 0h 1min | | | #+END: ** Test log :LOGBOOK: CLOCK: [2017-04-11 Tue 23:20]--[2017-04-11 Tue 23:24] => 0:04 :END: ** FIXME Test log :LOGBOOK: CLOCK: [2017-04-11 Tue 22:20]--[2017-04-11 Tue 23:20] => 1:00 :END: ** COMMENT test with comment no to-do :LOGBOOK: CLOCK: [2017-04-14 Fri 17:29]--[2017-04-14 Fri 17:31] => 0:02 :END: ** COMMENT FIXME comment with to-do keyword :LOGBOOK: CLOCK: [2017-04-14 Fri 17:31]--[2017-04-14 Fri 17:32] => 0:01 :END: ** FIXME with a fraction [1/2] :LOGBOOK: CLOCK: [2017-04-14 Fri 17:42]--[2017-04-14 Fri 17:43] => 0:01 :END: - [X] One - [ ] two ** FIXME with a percentage [50%] :LOGBOOK: CLOCK: [2017-04-14 Fri 17:32]--[2017-04-14 Fri 17:33] => 0:01 :END: - [ ] one - [X] two * Patch Appears that change ebbc675bd9890c451ad01910fa2625fa78baac9b way back in 9.0.1 needed to also modify org-clock.el, or at least when I revert that change I get the behavior I'm used to back. Below is a patch which modifies org-clock.el; Though I'm sure it can be approved upon. #+BEGIN_EXAMPLE diff diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 0973cc21b..3e30d20f8 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -2801,12 +2801,17 @@ TIME: The sum of all time spend in this tree, in minutes. This time (- (match-end 1) (match-beginning 1 (<= level maxlevel)) (setq hdl (if (not link) - (match-string 2) + (org-get-heading t t t t) (org-make-link-string (format "file:%s::%s" (buffer-file-name) (save-match-data -(match-string 2))) + (org-make-org-heading-search-string + (replace-regexp-in-string +org-bracket-link-regexp +(lambda (m) (or (match-string 3 m) + (match-string 1 m))) +(org-get-heading t t t t) (org-make-org-heading-search-string (replace-regexp-in-string org-bracket-link-regexp #+END_EXAMPLE
[O] Bug: Using org-capture with a template adds an unnecessary newline regardless of flags set [9.0.5 (9.0.5-elpa @ /home/igor/.emacs.d/elpa/org-20170210/)]
Using a template with org-capture to create a new org entry will add an unwanted newline after it. This occurs regardless of the contents of the template file, whether or not the 'empty-lines 1' / 'empty-lines-after 1' checkboxes are ticked in org-customize, or `empty-lines` / `empty-lines-after` keys are set to 0 manually. I expected that there would be no newline added by default after a template is inserted into an org-capture buffer. This appears to happen because `org-capture-place-(entry/plain-text/etc)` defuns in org-capture.el have `(org-capture-empty-lines-after 1)` in them by default. Changing this to `(org-capture-empty-lines-after)` and byte-compiling the file fixes the issue. I am not aware of any reason for 1 to be the default forced value here. Emacs : GNU Emacs 25.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.30) of 2016-09-24 Package: Org mode version 9.0.5 (9.0.5-elpa @ /home/igor/.emacs.d/elpa/org-20170210/)
