Re: [O] Ediff org files starts folded

[Stig Brautaset]

Oleh Krehel  writes:

> Here's what I use:
>
> (defun ora-ediff-prepare-buffer ()
>   (when (memq major-mode '(org-mode emacs-lisp-mode))
> (outline-show-all)))
>
> (add-hook 'ediff-prepare-buffer-hook 'ora-ediff-prepare-buffer)

Thank you! This works very well for me. It's been on my TODO list to
figure out how to do this for a while.

Stig

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

[Tim Cross]

Allen Li  writes:

> On Wed, Nov 1, 2017 at 9:56 PM, Tim Cross  wrote:
>>
>
>> To correctly fix this, I feel more analysis is warranted. I'm prepared
>> to look at this and present a summary and options, but it will have to
>> wait until after 21st when I start leave from work. It is a complex area
>> and perhaps my skills won't be up to it, but I should at least be able
>> to identify the main areas needing attention/decisions.
>
> My initial approach would be to do some refactoring here, especially
> among org-2ft, org-matcher-time, and org-parse-time-string, each of
> which calls the others in a cycle and each share a part of the logic
> for interpreting Org mode timestamps.
>
> I'm not familiar with refactoring FOSS code via mailed patches, nor if
> Org maintainers would welcome such patches, but I would be willing to
> do some refactoring here.
>

I think what I will do is start with adding/extending the tests relating
to timestamps and clock tables. This should

- help ensure I understand the required functionality
- may help identify existing bugs
- help ensure any refactoring does not have undesired side effects or
  loss of functionality

I also suspect it will be a good way for core org maintainers to verify
I'm on the right track and haven't missed anything before making any
changes to the code base. I'm not a big TDD advocate, but when working
with an unfamiliar code base, I've found developing tests first is a
good approach to ensure you really do understand existing and required
functionality.

regards,

Tim

-- 
Tim Cross

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

[Nick Dokos]

Allen Li  writes:

> ...
> I'm not familiar with refactoring FOSS code via mailed patches, nor if
> Org maintainers would welcome such patches, but I would be willing to
> do some refactoring here.
>

See http://orgmode.org/worg/org-contribute.html

-- 
Nick

Re: [O] ``make test'' failure

[Nick Dokos]

Nicolas Goaziou  writes:

> There is a non-deterministic part in that failure since neither our
> Build nor my machine can reproduce it.
>
> Could you try the following patch and tell me if the test succeed?
>

Yes, indeed: the test passes here with the patch.

Thanks!
--
Nick

[O] [PATCH] org-capture: cannot abort cleanly after inserting at end of buffer

[Xavier Martinez-Hidalgo]

Hi,

After the following steps:

- Start a capture.
- Move to end of capture buffer (M->).
- Type some text.
- Abort capture (C-c C-k).

the capture is aborted but its contents are not removed from the
target buffer and the following message is shown:

  "Capture process aborted, but target buffer could not be cleaned up
  correctly"

I am a attaching a patch that adds a test case showing up the problem
and includes a proposed fix (setting the capture kill end marker
insertion type).

I am not sure whether the fix might affect something else.  Does the
fix makes sense?
From 24130d37652acda6e3554d83b1506e93efc42a14 Mon Sep 17 00:00:00 2001
From: Xavier Martinez-Hidalgo 
Date: Thu, 2 Nov 2017 11:47:19 +0100
Subject: [PATCH] org-capture: Fix aborting after inserting text at end of
 buffer

* lisp/org-capture.el (org-capture-mark-kill-region): Set end marker
  insertion type so that it advances when inserting text at the end of
  the capture buffer.

* testing/lisp/test-org-capture.el (test-org-capture/insert-at-end-abort):
  Add test case.

Inserting text at the end of the capture buffer does not advance the
end kill marker.  This causes the narrowing region and the kill
markers to get out of sync, which prevents 'org-capture-finalize' from
correctly cleaning the target buffer when aborting the capture.

Setting the kill end marker insertion type fixes this.

TINYCHANGE
---
 lisp/org-capture.el  |  1 +
 testing/lisp/test-org-capture.el | 13 +
 2 files changed, 14 insertions(+)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 25af674b8..59561d666 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1313,6 +1313,7 @@ Of course, if exact position has been required, just put it there."
   "Mark the region that will have to be killed when aborting capture."
   (let ((m1 (move-marker (make-marker) beg))
 	(m2 (move-marker (make-marker) end)))
+(set-marker-insertion-type m2 t)
 (org-capture-put :begin-marker m1)
 (org-capture-put :end-marker m2)))
 
diff --git a/testing/lisp/test-org-capture.el b/testing/lisp/test-org-capture.el
index 4d5dfb713..5e41f972b 100644
--- a/testing/lisp/test-org-capture.el
+++ b/testing/lisp/test-org-capture.el
@@ -146,5 +146,18 @@
 	 (list file1 file2 (buffer-file-name)
 
 
+(ert-deftest test-org-capture/insert-at-end-abort ()
+  "Test that capture can be aborted after inserting at end of capture buffer."
+  (org-test-with-temp-text-in-file "* A\n* B\n"
+  (let* ((file (buffer-file-name))
+	 (org-capture-templates
+	  `(("t" "Todo" entry (file+headline ,file "A") "** H1 %?"
+	(org-capture nil "t")
+	(goto-char (point-max))
+	(insert "Capture text")
+	(org-capture-kill))
+  (should (string= "* A\n* B\n" (buffer-string)
+
+
 (provide 'test-org-capture)
 ;;; test-org-capture.el ends here
-- 
2.11.0

Re: [O] MathJax beyond org-html-mathjax-options?

[Rasmus]

Lawrence Bottorff  writes:

> I'm trying to get a typical Latex strikethrough with MathJax in an HTML
> export, i.e., \cancel{thing} puts line through "thing". This
>  tells me how. But I
> don't know how to include this MathJax markup in an org file for HTML
> export. If I forego MathJax -- i.e., #+OPTIONS: tex:dvipng instead
> of #+OPTIONS: tex:t -- \cancel works, but I need to use MathJax. It doesn't
> look like orhg-html-mathjax-options is expandable. . . .

For now this works for me:

#+html: \(\require{cancel}\)
\begin{equation}
\cancel{x = 1}
\end{equation}

Cf. http://docs.mathjax.org/en/latest/tex.html#tex-and-latex-extensions
You could also autoload the extension, cf. 
https://github.com/mathjax/MathJax/blob/master/test/sample-autoload.html


That being said, I don’t think extensions were available at the time
#+HTML_MATHJAX was introduced.  We could add extension support, but the
questions would be whether to add them to #+HTML_MATHJAX or make a new
keyword, e.g.

#+HTML_MATHJAX_EXTENSIONS: ext1 ext2 ... extN

I guess it would default to the "autoload-all" extension.

One issue is that some of them have configuration options, like "noError".

If you want, you can try the attached patch.

Rasmus

-- 
Vote for proprietary math!
>From 229bddbaed66a476ebed588853a0250cfe68fdcf Mon Sep 17 00:00:00 2001
From: Rasmus 
Date: Thu, 2 Nov 2017 13:59:17 +0100
Subject: [PATCH] ox-html: MathJax extensions support

* lisp/ox-html.el (org-html-mathjax-options):
(org-html-mathjax-template):
(org-html--build-mathjax-config): Add MathJax extensions support.
* doc/org.texi (HTML Specific export settings):
  (Math formatting in HTML export): Mention #+HTML_MATHJAX_EXTENSIONS.
---
 doc/org.texi| 12 +-
 lisp/ox-html.el | 73 +
 2 files changed, 69 insertions(+), 16 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 77da6d335..6ac22aff9 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -11626,6 +11626,12 @@ Options for MathJax (@code{org-html-mathjax-options}).  MathJax is used to
 typeset @LaTeX{} math in HTML documents.  @xref{Math formatting in HTML
 export}, for an example.
 
+@item HTML_MATHJAX_EXTENSIONS
+@cindex #+HTML_MATHJAX_EXTENSIONS
+@vindex org-html-mathjax-options
+Extensions for MathJax (@code{org-html-mathjax-options}).  This can be used
+to e.g. add additional macro support to MathJax.
+
 @item HTML_HEAD
 @cindex #+HTML_HEAD
 @vindex org-html-head
@@ -11947,9 +11953,13 @@ options can be configured via @code{org-html-mathjax-options}, or in the
 buffer.  For example, with the following settings,
 @smallexample
 #+HTML_MATHJAX: align: left indent: 5em tagside: left font: Neo-Euler
+#+HTML_MATHJAX: cancel.js noErrors.js
 @end smallexample
 equation labels will be displayed on the left margin and equations will be
-five ems from the left margin.
+five ems from the left margin.  In addition, it loads the two MathJax
+extensions @samp{cancel.js} and @samp{noErrors.js}@footnote{See
+@uref{http://docs.mathjax.org/en/latest/tex.html#tex-extensions, TeX and
+LaTeX extensions} in the @uref{http://docs.mathjax.org, MathJax manual} to learn about extensions.}.
 
 @noindent See the docstring of
 @code{org-html-mathjax-options} for all supported variables.  The MathJax
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 1c3dd8090..4f9e69fdf 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -121,6 +121,7 @@
 (:html-link-home "HTML_LINK_HOME" nil org-html-link-home)
 (:html-link-up "HTML_LINK_UP" nil org-html-link-up)
 (:html-mathjax "HTML_MATHJAX" nil "" space)
+(:html-mathjax-extensions "HTML_MATHJAX_EXTENSIONS" nil "" space)
 (:html-postamble nil "html-postamble" org-html-postamble)
 (:html-preamble nil "html-preamble" org-html-preamble)
 (:html-head "HTML_HEAD" nil org-html-head newline)
@@ -1168,7 +1169,8 @@ See `format-time-string' for more information on its components."
 (indent "0em")
 (multlinewidth "85%")
 (tagindent ".8em")
-(tagside "right"))
+(tagside "right")
+(extensions ("autoload-all.js")))
   "Options for MathJax setup.
 
 Alist of the following elements.  All values are strings.
@@ -1190,23 +1192,28 @@ autonumberHow to number equations.  Valid values are \"None\",
 tagindent The amount tags are indented.
 tagside   Which side to show tags/labels on.  Valid values are
   \"left\" and \"right\"
+extensionsWhich extensions to load.  See http://docs.mathjax.org/en/latest/tex.html#tex-extensions
 
 You can also customize this for each buffer, using something like
 
 #+HTML_MATHJAX: align: left indent: 5em tagside: left font: Neo-Euler
+#+HTML_MATHJAX_EXTENSIONS: colors noErrors
 
 For further information about MathJax options, see the MathJax documentation:
 
   http://docs.mathjax.org/;
   :group 'org-export-html
-  :package-version '(Org . 

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

[Tim Cross]

In a couple of weeks, I will have some spare time and I am happy to look
at the time related functions in org-mode to see if we can refactor them
to make them a bit clearer and possibly more efficient. I would be
hoping for input from the list as guidance experience has taught me that
date/time stuff can often have some subtle corner cases which are
easily missed.

regards,

Tim

Nicolas Goaziou  writes:

> Hello,
>
> Allen Li  writes:
>
>> Alas, I still can't seem to find the original DST bug.  I'm not sure
>> using UTC solves DST problems.
>>
>> For example, in the timezone America/Los_Angeles,
>>
>> <2017-11-05 01:00:00> -> <2017-11-05 04:00:00> = 4 hours
>> <2017-10-10 01:00:00> -> <2017-10-10 04:00:00> = 3 hours
>> <2017-03-12 01:00:00> -> <2017-03-12 04:00:00> = 2 hour
>>
>> This is what Emacs gives me using the default time zone
>>
>> <2017-11-05 01:00:00> -> <2017-11-05 04:00:00> = 4 hours
>> <2017-10-10 01:00:00> -> <2017-10-10 04:00:00> = 3 hours
>> <2017-03-12 01:00:00> -> <2017-03-12 04:00:00> = 2 hour
>>
>> This is what Emacs gives me using UTC
>>
>> <2017-11-05 01:00:00> -> <2017-11-05 04:00:00> = 3 hours
>> <2017-10-10 01:00:00> -> <2017-10-10 04:00:00> = 3 hours
>> <2017-03-12 01:00:00> -> <2017-03-12 04:00:00> = 3 hours
>>
>> Using UTC seems strictly wrong to me.
>
> You're right. Using UTC doesn't solve any DST bug, despite what
> I initially thought. I think we just need to remove the whole set of
> changes about UTC in `parse-time-string'. We also need to adapt tests in
> test-org-clock since the same time difference could have different
> meanings depending on the time zone. I can do that later, if no one
> objects. WDYT?n
>
> Refactoring time functions in Org is still useful, though.
>
> Regards,


-- 
Tim Cross

Re: [O] Footnotes-per-element?

[Rasmus]

torys.ander...@gmail.com (Tory S. Anderson) writes:

> THanks for this; it may be a workable solution. The trick is, I didn't
> generate the footnotes myself -- I have concatenated a bunch of
> html -> orgmode pandoc outputs. Still an elisp find-and-replace might
> do what I need. I was just hoping for a quick switch to flip for
> localized footnotes.

You could try to #+include them and export via ox-org.

Rasmus

-- 
Need more coffee. . .

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

[Nicolas Goaziou]

Hello,

Allen Li  writes:

> Alas, I still can't seem to find the original DST bug.  I'm not sure
> using UTC solves DST problems.
>
> For example, in the timezone America/Los_Angeles,
>
> <2017-11-05 01:00:00> -> <2017-11-05 04:00:00> = 4 hours
> <2017-10-10 01:00:00> -> <2017-10-10 04:00:00> = 3 hours
> <2017-03-12 01:00:00> -> <2017-03-12 04:00:00> = 2 hour
>
> This is what Emacs gives me using the default time zone
>
> <2017-11-05 01:00:00> -> <2017-11-05 04:00:00> = 4 hours
> <2017-10-10 01:00:00> -> <2017-10-10 04:00:00> = 3 hours
> <2017-03-12 01:00:00> -> <2017-03-12 04:00:00> = 2 hour
>
> This is what Emacs gives me using UTC
>
> <2017-11-05 01:00:00> -> <2017-11-05 04:00:00> = 3 hours
> <2017-10-10 01:00:00> -> <2017-10-10 04:00:00> = 3 hours
> <2017-03-12 01:00:00> -> <2017-03-12 04:00:00> = 3 hours
>
> Using UTC seems strictly wrong to me.

You're right. Using UTC doesn't solve any DST bug, despite what
I initially thought. I think we just need to remove the whole set of
changes about UTC in `parse-time-string'. We also need to adapt tests in
test-org-clock since the same time difference could have different
meanings depending on the time zone. I can do that later, if no one
objects. WDYT?n

Refactoring time functions in Org is still useful, though.

Regards,

-- 
Nicolas Goaziou