[O] [FEATURE] exporting with write partially to solve big Org file slowing exporting

[stardiviner]

When I export a big Org file which is a big reference has about 36285
lines to epub format through package "ox-epub". I found it write to HTML
is very slow.

Is there any solution to solve this?

I guess this could be Org exporter problem. If Org exporter can write
partly to file one by one. it will be better.

If you have any other idea, please tell me. Thanks.

Regards.

--
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

[O] time range, timestamps // was: docstring typoes in org-read-date-force-compatible-dates

[Van L]

> Kyle Meyer wrote:
> 
> In the future, please send
> generated patches with git format-patch so that they include a commit
> message (see 
> for instructions).

Thanks Kyle. Noted.

I am muddling my way through

 [info:org#Creating timestamps]
 [info:org#The date/time prompt]

and see that org-evaluate-time-range does nothing for

<2019-01-04 Fri 11:00-12:15>

which was created using the “11am+2:15” style from

— quote
   You can specify a time range by giving start and end times or by
giving a start time and a duration (in HH:MM format).  Use one or two
dash(es) as the separator in the former case and use ’+’ as the
separator in the latter case, e.g.:

 11am-1:15pm⇒ 11:00-13:15
 11am--1:15pm   ⇒ same as above
 11am+2:15  ⇒ same as above

   Parallel to the minibuffer prompt, a calendar is popped up(2).  When
you exit the date prompt,
— quote ends

exporting that to ASCII in a buffer transforms the time range to

<2019-01-04 Fri 11:00>–<2019-01-04 Fri 12:15>

Now, that formatting put back in the Org buffer does work for 
org-evaluate-time-range, as follows:

<2019-01-04 Fri 12:34>-<2019-01-04 Fri 12:35> 00:01

;; Using the C-u C-c C-y

Re: [O] docstring typoes in org-read-date-force-compatible-dates

[Kyle Meyer]

Van L  writes:

> Hello,
>
> I found and fixed the following typoes.
>
> diff --git a/lisp/org.el b/lisp/org.el

Thank you.  I've applied your changes.  In the future, please send
generated patches with git format-patch so that they include a commit
message (see 
for instructions).

-- 
Kyle

[O] docstring typoes in org-read-date-force-compatible-dates

[Van L]

Hello,

I found and fixed the following typoes.

diff --git a/lisp/org.el b/lisp/org.el
index 5dd5c024d..755c190cf 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3329,7 +3329,7 @@ Depending on the system Emacs is running on, certain 
dates cannot
 be represented with the type used internally to represent time.
 Dates between 1970-1-1 and 2038-1-1 can always be represented
 correctly.  Some systems allow for earlier dates, some for later,
-some for both.  One way to find out it to insert any date into an
+some for both.  One way to find out is to insert any date into an
 Org buffer, putting the cursor on the year and hitting S-up and
 S-down to test the range.
 
@@ -3337,7 +3337,7 @@ When this variable is set to t, the date/time prompt will 
not let
 you specify dates outside the 1970-2037 range, so it is certain that
 these dates will work in whatever version of Emacs you are
 running, and also that you can move a file from one Emacs implementation
-to another.  WHenever Org is forcing the year for you, it will display
+to another.  Whenever Org is forcing the year for you, it will display
 a message and beep.
 
 When this variable is nil, Org will check if the date is

[O] Change in order of tag collation from #+filetags plus heading tags [Regression 9.1 -> 9.2]

[Kaushal Modi]

Hello,

I have noticed a minor regression in the order in which Org collects the
"ALLTAGS" tags at point.

Here is a simple Org file to reproduce that issue:

=
#+filetags: a

* Level 1
:b:
** Level 2
:c:
*** Level 3
:d:

=

With point anywhere under ~* Level 3~ heading, evaluate:

M-: (org-entry-get (point) "ALLTAGS")


In Org 9.1.x, the order of tags returned was ":a:b:c:d:".
But in Org 9.2, the order becomes ":b:c:a:d:".

So, earlier (Org 9.1.x) the order was:
1. tags from filetags
2. tags from parent headings in order
3. current heading tags

In Org 9.2, the order is:
1. *tags from parent headings in order*
2. *tags from filetags*
3. current heading tags

Is this switch of order expected?


--
Kaushal Modi

[O] Fix C-u C-c C-q (align all tags in visible buffer)

[Kaushal Modi]

Hello,

This minor bug had been bothering me for a while and I eventually got to
looking into the source code for it.

As of current master, C-u C-c C-q doesn't work as in the doc-string i.e.
"When optional argument ALL is non-nil, align all tags in the visible part
of the buffer.".

Here's an example Org buffer:

=
* Foo :abc:
** Bar :def:
=

- With point on Foo heading, C-u C-c C-q aligns only :def: tag (tags from
*next* heading onwards).
- So when point is on Bar, no tags get aligned.

Though I remember that C-u C-c C-q worked quite some time back.

A commit in Apr 28, 2018 broke that behavior in
https://code.orgmode.org/bzg/org-mode/commit/1615261cdc5da6dbe50176d7958c775d6d54411e#diff-f9a90d66b3053f60bd4e8d63f214273067d0d28L14288
.

While I don't understand that entire commit, this simple fix brings back
the true C-u C-c C-q behavior:

diff --git a/lisp/org.el b/lisp/org.el
index db3c11b5f..b8daa3bfc 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -14203,8 +14203,10 @@ visible part of the buffer."
 (org--align-tags-here (funcall get-indent-column))
   (save-excursion
 (if all
+(progn
+  (goto-char (point-min))
   (while (re-search-forward org-tag-line-re nil t)
-  (org--align-tags-here (funcall get-indent-column)))
+(org--align-tags-here (funcall get-indent-column
   (org-back-to-heading t)
   (org--align-tags-here (funcall get-indent-column)))


If this looks good, I can commit this to maint and master.

Thanks.


--
Kaushal Modi

Re: [O] Bug: C-u M-x org-footnote-action sort deletes footnotes used in #+include:’d files [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.3/lisp/org/)]

[Arne Babenhauserheide]

> Arne Babenhauserheide  writes:
> 
> > In my setup, it deletes footnote [fn:2].
> >
> > Damn, I missed one important part in the ECM: Set
> >
> >   org-footnote-section
> >
> > to nil. Does it still leave them untouched?
> 
> I still cannot reproduce it.

Then I’ll need to test this in org 9.

Does it at least move footnote [fn:1] out from the Footnotes section?
If not, then the call org-footnote-action does not actually work.

> > It does not reference between included files, but references from
> > included files to the main file actually work.
> 
> I'm positively sure this cannot be. Indeed "ox.el" has a comment about
> it:
> 
> ;; Append ID to all footnote references and definitions, so they
> ;; become file specific and cannot collide with footnotes in other
> ;; included files.

I’m sure that this works, because I’m creating a PDF via ox-latex using those 
footnotes.

Here’s the source with a full autotools setup: 
https://bitbucket.org/ArneBab/1w6/src/default/Hauptdokument/ews30/

Main file: 
https://bitbucket.org/ArneBab/1w6/src/cd0a985945e46389d2690b759869706df572e65f/Hauptdokument/ews30/ews.org

You can test this with the latest release: 
https://www.1w6.org/releases/ews30eb1.tar.gz

Build it with


./configure; make distcheck


I hope that org 9 does not break this.

Best wishes,
Arne

Re: [O] Exporting description list without description

[Yasushi SHOJI]

Hi,

On Thu, Jan 3, 2019, 22:40 Eric S Fraga  wrote:

> yes, and I get the same as you do, but that whitespace difference should
> make no difference in the PDF result?  I guess it may make a difference
> for other export targets.
>

Yes.  I know some backends don't care.  I just couldn't find a reason why
and where in the element.el or ox.el.   if this isn't intended, should this
be fixed, perhaps?

Thanks,
-- 
  yashi

>

[O] Bug: Inconsistent usage of org-capture-get [9.2 (release_9.2 @ /Users/xristos/code/elisp/third-party/org-mode/lisp/)]

[xristos]

At some point, the optional argument LOCAL was added to org-capture-get:

(org-capture-get PROP  LOCAL)

"When LOCAL is set, use the local variable ‘org-capture-current-plist’,
this is necessary after initialization of the capture process,
to avoid conflicts with other active capture processes."

A lot of the org-capture-get calls in org-capture.el do not set LOCAL
and suffer from aforementioned conflicts. The calls inside function org-capture
are exempt from this, but the calls inside org-capture-finalize that do not
set LOCAL are obviously erroneous. There are more org-capture-get calls in
other functions that have to be reviewed.

Emacs  : GNU Emacs 25.3.2 (x86_64-apple-darwin17.4.0, Carbon Version 158 AppKit 
1561.2)
 of 2018-02-19
Package: Org mode version 9.2 (release_9.2 @ 
/Users/xristos/code/elisp/third-party/org-mode/lisp/)

Re: [O] Bug: Latex preview fg color w/tikz (known problem, fix suggested) [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.90/lisp/org/)]

[Carlos Pita]

Hi Nicolas,

I've improved the commit message to better fit org mode conventions
and also added a note to ORG-NEWS about the new feature. Let me know
if there still is something I should change or feel free to amend it
to your liking.

One question for future patches: is it ok to add a link to the mailing
list thread where the issue was discussed in the commit message?

Regards
--
Carlos.
From bc210a028bb755aa8ca0eaef1605efaab735fde4 Mon Sep 17 00:00:00 2001
From: memeplex 
Date: Wed, 2 Jan 2019 19:05:26 -0300
Subject: [PATCH] Use xcolor for all latex preview converters

* lisp/org.el: remove :use-xcolor option and make dvipng use xcolor
  since usage of CLI fg and bg color args is incompatible with docs
  that themselves use xcolor (e.g. through tikz).
* etc/ORG-NEWS: add incompatible change note.
---
 etc/ORG-NEWS |  9 
 lisp/org.el  | 63 
 2 files changed, 28 insertions(+), 44 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index b988559..c1e426c 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -39,6 +39,15 @@ arguments no longer imply a "file" result is expected.
 
 See [[git:3367ac9457]] for details.
 
+*** All LaTeX preview backends use now xcolor
+
+The dvipng backend was previously relying on fg and bg parameters to
+be passed to the CLI. This didn't work when xcolor was directly or
+indirectly used in the document (e.g. tkiz is a user of xcolor). Since
+every other backend was already using xcolor to set fg and bg, the CLI
+alternative was removed and there is no more a :use-xcolor options
+since now it's implicitly always true.
+
 ** New features
 *** Add a dispatcher command to insert dynamic blocks
 
diff --git a/lisp/org.el b/lisp/org.el
index 0e541cd..2e63a65 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3813,12 +3813,11 @@ All available processes and theirs documents can be found in
  :image-output-type "png"
  :image-size-adjust (1.0 . 1.0)
  :latex-compiler ("latex -interaction nonstopmode -output-directory %o %f")
- :image-converter ("dvipng -fg %F -bg %B -D %D -T tight -o %O %f"))
+ :image-converter ("dvipng -D %D -T tight -o %O %f"))
 (dvisvgm
  :programs ("latex" "dvisvgm")
  :description "dvi > svg"
  :message "you need to install the programs: latex and dvisvgm."
- :use-xcolor t
  :image-input-type "dvi"
  :image-output-type "svg"
  :image-size-adjust (1.7 . 1.5)
@@ -3828,7 +3827,6 @@ All available processes and theirs documents can be found in
  :programs ("latex" "convert")
  :description "pdf > png"
  :message "you need to install the programs: latex and imagemagick."
- :use-xcolor t
  :image-input-type "pdf"
  :image-output-type "png"
  :image-size-adjust (1.0 . 1.0)
@@ -3848,11 +3846,6 @@ PROPERTIES accepts the following attributes:
   :messagestring, message it when required programs cannot be found.
   :image-input-type   string, input file type of image converter (e.g., \"dvi\").
   :image-output-type  string, output file type of image converter (e.g., \"png\").
-  :use-xcolor boolean, when non-nil, LaTeX \"xcolor\" macro is used to
-  deal with background and foreground color of image.
-  Otherwise, dvipng style background and foreground color
-  format are generated.  You may then refer to them in
-  command options with \"%F\" and \"%B\".
   :image-size-adjust  cons of numbers, the car element is used to adjust LaTeX
   image size showed in buffer and the cdr element is for
   HTML file.  This option is only useful for process
@@ -3884,8 +3877,6 @@ Place-holders used by `:image-converter' and `:latex-compiler':
 
 Place-holders only used by `:image-converter':
 
-  %Fforeground of image
-  %Bbackground of image
   %Ddpi, which is used to adjust image size by some processing commands.
   %Sthe image size scale ratio, which is used to adjust image size by some
 processing commands."
@@ -18339,7 +18330,6 @@ a HTML file."
 	  (cdr (assq processing-type org-preview-latex-process-alist)))
 	 (programs (plist-get processing-info :programs))
 	 (error-message (or (plist-get processing-info :message) ""))
-	 (use-xcolor (plist-get processing-info :use-xcolor))
 	 (image-input-type (plist-get processing-info :image-input-type))
 	 (image-output-type (plist-get processing-info :image-output-type))
 	 (post-clean (or (plist-get processing-info :post-clean)
@@ -18370,36 +18360,23 @@ a HTML file."
 	 (resize-mini-windows nil)) ;Fix Emacs flicker when creating image.
 (dolist (program programs)
   (org-check-external-command program error-message))
-(if use-xcolor
-	(progn (if (eq fg 'default)
-		   (setq fg (org-latex-color :foreground))
-		 (setq fg (org-latex-color-format fg)))
-	   (if (eq bg 'default)
-		   (setq bg (org-latex-color :background))
-		 (setq bg 

Re: [O] [Patch] [Feature request] Add option to natively fontify latex snippets and environment

[Carlos Pita]

I've improved the commit message to better align org mode conventions
and also added a note to ORG-NEWS about the new feature.
From 19d1d83901d3cc959b0cef5d2832da307e01 Mon Sep 17 00:00:00 2001
From: memeplex 
Date: Wed, 2 Jan 2019 19:43:21 -0300
Subject: [PATCH] Add option to natively fontify LaTeX snippets and
 environments

* lisp/org.el: add a 'native value to org-highlight-latex-and-related
  that allows to use tex native font locking by means of
  org-src-font-lock-fontify-block.
* etc/ORG-NEWS: add note about new feature.
---
 etc/ORG-NEWS |  5 +
 lisp/org.el  | 24 +++-
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index c1e426c..51d6a07 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -99,6 +99,11 @@ system than the main Org document.  For example:
 *** New cell movement functions in tables
 ~S-~, ~S-~, ~S-~, and ~S-~ now move cells in
 the corresponding direction by swapping with the adjacent cell.
+*** New option to natively fontify LaTeX snippets and environments
+A 'native option was added to org-highlight-latex-and-related. It
+matches the same structures than 'latex but it calls
+org-src-font-lock-fontify-block instead, thus bringing about full
+LaTeX font locking.
 
 ** New functions
 *** ~org-dynamic-block-insert-dblock~
diff --git a/lisp/org.el b/lisp/org.el
index 2e63a65..3c9a5dc 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4138,6 +4138,7 @@ org-level-* faces."
   "Non-nil means highlight LaTeX related syntax in the buffer.
 When non nil, the value should be a list containing any of the
 following symbols:
+  `native'   Highlight LaTeX snippets and environments natively.
   `latex'Highlight LaTeX snippets and environments.
   `script'   Highlight subscript and superscript.
   `entities' Highlight entities."
@@ -4147,6 +4148,7 @@ following symbols:
   :type '(choice
 	  (const :tag "No highlighting" nil)
 	  (set :greedy t :tag "Highlight"
+	   (const :tag "LaTeX snippets and environments (native)" native)
 	   (const :tag "LaTeX snippets and environments" latex)
 	   (const :tag "Subscript and superscript" script)
 	   (const :tag "Entities" entities
@@ -6093,7 +6095,8 @@ Result depends on variable `org-highlight-latex-and-related'."
 		(list org-match-substring-with-braces-regexp))
 	   (org-use-sub-superscripts (list org-match-substring-regexp
 	(re-latex
-	 (when (memq 'latex org-highlight-latex-and-related)
+	 (when (or (memq 'latex org-highlight-latex-and-related)
+		   (memq 'native org-highlight-latex-and-related))
 	   (let ((matchers (plist-get org-format-latex-options :matchers)))
 	 (delq nil
 		   (mapcar (lambda (x)
@@ -6117,17 +6120,20 @@ highlighting was done, nil otherwise."
   (while (re-search-forward org-latex-and-related-regexp
 nil t) ;; on purpose, we ignore LIMIT
 	(unless (cl-some (lambda (f) (memq f '(org-code org-verbatim underline
-		   org-special-keyword)))
+			org-special-keyword)))
 			 (save-excursion
 			   (goto-char (1+ (match-beginning 0)))
 			   (face-at-point nil t)))
-	  (let ((offset (if (memq (char-after (1+ (match-beginning 0)))
-  '(?_ ?^))
-			1
-			  0)))
-	(font-lock-prepend-text-property
-	 (+ offset (match-beginning 0)) (match-end 0)
-	 'face 'org-latex-and-related)
+	  (let* ((offset (if (memq (char-after (1+ (match-beginning 0)))
+   '(?_ ?^))
+			 1
+			   0))
+		 (start (+ offset (match-beginning 0)))
+		 (end (match-end 0)))
+	(if (memq 'native org-highlight-latex-and-related)
+		(org-src-font-lock-fontify-block "latex" start end)
+	  (font-lock-prepend-text-property start end
+	   'face 'org-latex-and-related))
 	(add-text-properties (+ offset (match-beginning 0)) (match-end 0)
  '(font-lock-multiline t)))
 	  (throw 'found t)))
-- 
2.20.1

Re: [O] Bug: links are not highlighted anymore with Org Mode 9.2

[Daniel Borchmann]

ghItlhpu' Daniel Borchmann :
> I get (in the *scratch* buffer):
>
> (facep nil) → [face unspecified unspecified unspecified unspecified 
> unspecified unspecified unspecified unspecified unspecified unspecified 
> unspecified ...]

Seems this an issue with my configuration, not Emacs itself, as stock
Emacs (started with emacs -Q) returns nil for (facep nil), as you
mentioned.  Indeed, somehow something defined ‘nil’ as a face for me,
causing the above issues.

So no bug in Org Mode, sorry for the noise :)

  Daniel

-- 
Daniel Borchmann
GPG (Mail)0849 473E 6BF0 B504 DF0B  D640 455E 3610 01FF 778F


signature.asc
Description: PGP signature

Re: [O] Bug: links are not highlighted anymore with Org Mode 9.2

[Daniel Borchmann]

ghItlhpu' Nicolas Goaziou :
>> The reason for this seems to be that
>> ‘org-activate-links’ uses the following code to determine which face to
>> use:
>>
>> --8<---cut here---start->8---
>> (pcase (org-link-get-parameter type :face)
>>   ((and (pred functionp) face) (funcall face path))
>>   ((and (pred facep) face) face)
>>   ((and (pred consp) face) face) ;anonymous
>>   (_ 'org-link))
>> --8<---cut here---end--->8---
>>
>> However, ‘nil’ is a valid face,
>
> No, it isn't: (facep nil) => nil

Interesting!

I get (in the *scratch* buffer):

(facep nil) → [face unspecified unspecified unspecified unspecified 
unspecified unspecified unspecified unspecified unspecified unspecified 
unspecified ...]

M-x emacs-version returns

GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars) 
of 2018-12-26, modified by Debian

So this is more likely an issue of Emacs itself?  Maybe it has been
fixed in a later version?

Thanks!

  Daniel

-- 
Daniel Borchmann
GPG (Mail)0849 473E 6BF0 B504 DF0B  D640 455E 3610 01FF 778F


signature.asc
Description: PGP signature

Re: [O] Bug: C-u M-x org-footnote-action sort deletes footnotes used in #+include:’d files [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.3/lisp/org/)]

[Nicolas Goaziou]

Hello,

Arne Babenhauserheide  writes:

> In my setup, it deletes footnote [fn:2].
>
> Damn, I missed one important part in the ECM: Set
>
>   org-footnote-section
>
> to nil. Does it still leave them untouched?

I still cannot reproduce it.

> It does not reference between included files, but references from
> included files to the main file actually work.

I'm positively sure this cannot be. Indeed "ox.el" has a comment about
it:

;; Append ID to all footnote references and definitions, so they
;; become file specific and cannot collide with footnotes in other
;; included files.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: links are not highlighted anymore with Org Mode 9.2

[Nicolas Goaziou]

Hello,

Daniel Borchmann  writes:

> links in Org Mode 9.2 are not highlighted anymore if no :face keyword is
> given in ‘org-link-parameters’.

I cannot reproduce this.

> The reason for this seems to be that
> ‘org-activate-links’ uses the following code to determine which face to
> use:
>
> --8<---cut here---start->8---
> (pcase (org-link-get-parameter type :face)
>   ((and (pred functionp) face) (funcall face path))
>   ((and (pred facep) face) face)
>   ((and (pred consp) face) face) ;anonymous
>   (_ 'org-link))
> --8<---cut here---end--->8---
>
> However, ‘nil’ is a valid face,

No, it isn't: (facep nil) => nil

> and thus this form returns ‘nil’ instead of the default ‘org-link’
> face if no :face keyword is given.

I don't think the analysis is correct, per above.

Regards,

-- 
Nicolas Goaziou

Re: [O] Exporting description list without description

[Eric S Fraga]

On Thursday,  3 Jan 2019 at 19:24, Yasushi SHOJI wrote:
> Hi,
>
> On Wed, Jan 2, 2019 at 11:52 PM Eric S Fraga  wrote:
>> What export target?  I don't see any difference when exporting to LaTeX.
>
> Even Latex backed does it differently.  Note the space between one and two.

yes, and I get the same as you do, but that whitespace difference should
make no difference in the PDF result?  I guess it may make a difference
for other export targets.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.14-1035-gfeb442

[O] Bug: links are not highlighted anymore with Org Mode 9.2

[Daniel Borchmann]

Hey,

links in Org Mode 9.2 are not highlighted anymore if no :face keyword is
given in ‘org-link-parameters’.  The reason for this seems to be that
‘org-activate-links’ uses the following code to determine which face to
use:

--8<---cut here---start->8---
(pcase (org-link-get-parameter type :face)
  ((and (pred functionp) face) (funcall face path))
  ((and (pred facep) face) face)
  ((and (pred consp) face) face) ;anonymous
  (_ 'org-link))
--8<---cut here---end--->8---

However, ‘nil’ is a valid face, and thus this form returns ‘nil’ instead
of the default ‘org-link’ face if no :face keyword is given.

Best,

  Daniel

PS: Thanks a ton for Org Mode, I literally couldn’t live without it! :)

-- 
Daniel Borchmann
GPG (Mail)0849 473E 6BF0 B504 DF0B  D640 455E 3610 01FF 778F


signature.asc
Description: PGP signature

[O] [SOLVED] How about Org Mode invalid link handling strategy for exporting?

[stardiviner]

I have not found that option. Thanks.

I checked the org-manual.org now, it's mentioned.

-- 
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  

Re: [O] [Feature Request] Add an dispatcher command (keybinding) for inserting dynamic blocks

[stardiviner]

Nicolas Goaziou  writes:

> Hello,
>
> stardiviner  writes:
>
>> As always, add patch as attachment.
>
> Thank you! I applied your patch, with minor tweaks.
>
> Regards,

Thanks Nicolas.

I will continue contribute in Org Mode.


-- 
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  

Re: [O] Org-drill edit feature request

[stardiviner]

John Kitchin  writes:

> My experience with this is that you have to get the word by some means
> (e.g. it is a property, or it is selected some how) and then send it to
> a platform specific speech program. It is easy on a mac as there is a
> command line tool called "say". So, something like this
>
> (shell-command "say \"Hello\")
>
> will say the word Hello out loud. I guess there are windows and linux
> equivalents.
>

Indeed have similar command under Linux. The trouble is how to get the
word every time org-drill change word when in recite single word mode.

-- 
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  

Re: [O] Bug: Latex preview fg color w/tikz (known problem, fix suggested) [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.90/lisp/org/)]

[Nicolas Goaziou]

Hello,

Carlos Pita  writes:

> Here is a patch. It removes quite a few LOC.

Thank you.

> Every other previewer has :use-xcolor t. I assume it's safe to simply
> ignore :use-xcolor if it's there except that some user has configured
> a converter that for some reason requires the color command line args,
> in which case he will get an error (because of the color placeholders
> left untouched in the command line template).

Could you also add an entry in ORG-NEWS, in Incompatible Changes section?

> From 9beda785e60c791bc6524b996b60e9db00f858b7 Mon Sep 17 00:00:00 2001
> From: memeplex 
> Date: Wed, 2 Jan 2019 19:05:26 -0300
> Subject: [PATCH] Use xcolor for all latex preview converters

You need to expound a bit the commit message. Please have a look at
other such messages for examples.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Secondary smart quotes are exported as apostrophes. [9.1.14 (9.1.14-1-g4931fc-elpa @ /home/coleman/.emacs.d/elpa/org-9.1.14/)]

[Nicolas Goaziou]

Hello,

Coleman Gariety  writes:

> Also, it occurs to me that one can make use of single quotation marks as
> primary quotes when mentioning a word without using it. Moreover, when
> italics and double quotation marks are also present, the use of single
> quotations as primary is necessary.
>
> For example:
>
> 'GNU' is an acronym for the phrase "GNU's Not Unix!" but GNU is an
> operating system and *not* an acronym.

When you need that level of precision, smart quotes are not for you.
"Smart" quotes are a dumb way to automate some basic typographic rules.
Clearly, this is not what you are after.

You can use entities directly to obtain the desired result, e.g. \rsquo,
\lsquo...

> Is it feasible to add an option to treat single quotation marks as primary
> pairs on export?

I think you are mixing up the level of quotation and the glyph used. You
can export "..." as single quotes by setting
`org-export-smart-quotes-alist' accordingly.


Regards,

-- 
Nicolas Goaziou

Re: [O] Exporting description list without description

[Yasushi SHOJI]

Hi,

On Wed, Jan 2, 2019 at 11:52 PM Eric S Fraga  wrote:
> What export target?  I don't see any difference when exporting to LaTeX.

Even Latex backed does it differently.  Note the space between one and two.
Here are both outputs:

\begin{description}
\item[{one}]

\item[{two}]
\end{description}

vs

\begin{description}
\item[{one}] This is 1
\item[{two}] This is 2
\end{description}

Does it happen on your env.? or is it just me?
-- 
yashi