date:20180615

Good evening,

A few months ago I migrated my Org-Mode configuration from PDFLaTeX to XeTeX.
It is great using "real fonts" and Unicode symbols, and my Org-Mode
configuration only needed a few changes to use XeTeX. Although I didn't read
any documentation on XeTeX, I know enough about LaTeX to stay out of trouble.
When I got around to choosing my primary fonts though I got a taste of my lack
of Unicode knowledge.

The fontspec let's you set up the three main fonts like this

\setmainfont{DejaVu Serif}
\setsansfont{DejaVu Sans}[Scale=MatchLowercase]
\setmonofont{DejaVu Sans Mono}[Scale=MatchLowercase]

And I figured those would cover at least the emoticon Unicode block. Nope!
Empty boxes appear the first time I want to use a . Sheesh. Never knew how
much work font authors face to cover the code blocks. Now I do. Anyway I am
left scratching my head how to use emoticons in my documents without changing
my three font configurations. And I'm not the only one.

The ucharclass https://github.com/Pomax/ucharclasses packages exists to solve
this topic. It detects the Unicode block for the characters and changes the
font in place. However #1 I couldn't get it working and #2 the package has no
maintainer. After looking at it I don't think I can do it so I looked for
another way to handle this.

This post
https://tex.stackexchange.com/questions/25249/how-do-i-use-a-particular-font-for-a-small-section-of-text-in-my-document
explains how to change the font for a particular region. It works great. I
tested it out for my use cases and it works fine. Here is an example file:

\documentclass[]{article}
\usepackage{fontspec}
\newfontfamily\xxtx{Symbola}
\begin{document}
The domino doesn't exist in my default font.
{\xxtx But it does in here: .}
\end{document}

The ability to use Unicode in Org-Mode and seamlessly export it to PDF via
XeTeX is so nice. And it looks pretty easy to handle different fontx in the
code. So I figured I could write an exporter that extends ox-latex exporter to
do this for me.

The exporter would be basic: it would look at every single character, figure out
if it is in a "special to me" block, and if it is use a different font. My
plan is that simple.

Questions for you:

- What do you think of this?
- What would you do here?
- Would you use it?

My use case is pretty simple, being able to use emoticons and APL characters
and stuff. And I can't be the only one that would use it. I'm reaching out
here though because I'm pretty out of touch in regards to other Org-Mode XeTeX
users.

Regards,

Grant

Re: [O] Proposal: references from code to text.

2018-06-15 Thread John Kitchin

Cool! I was inspired by this to try it with Python doctests. Check out the
result here: http://kitchingroup.cheme.cmu.edu/blog/2018/05/17/
Literate-programming-with-python-doctests/

Note: I thought I had sent this email before, but it appeared as a draft
just now, so I am just sending it again.

John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Thu, May 17, 2018 at 2:33 AM, ZHUO QL (KDr2)  wrote:

> Thanks, that works perfectly. I made a simple summary of this thread on my
> site: http://kdr2.com/tech/emacs/1805-approach-org-ref-code-to-text.html
>
>
> Greetings.
>
> ZHUO QL (KDr2, http://kdr2.com)
>
>
>
> On Thursday, May 17, 2018, 11:11:39 AM GMT+8, John Kitchin <
> jkitc...@andrew.cmu.edu> wrote:
>
>
> I believe you can do that with the Library of Babel (
> https://orgmode.org/worg/org-contrib/babel/library-of-babel.html)
>
> John
>
> ---
> Professor John Kitchin
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>

Re: [O] org creates bibtex fontification buffers without setting dialect, causes error

Hello,

Adam Porter  writes:

> It seems easy enough to fix: Org should call bibtex-set-dialect in its
> BibTeX fontification buffer.

Do you want to propose a patch?

Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] ob-shell initialize header arguments for other shell names too

Hello,

stardiviner  writes:

> From 4519624de8543205533b89e05d14e308d891f45b Mon Sep 17 00:00:00 2001
> From: stardiviner 
> Date: Mon, 4 Jun 2018 12:02:55 +0800
> Subject: [PATCH] ob-shell.el: Initialize header arguments for other shell
>  names too
>
> * lisp/ob-shell.el (org-babel-shell-initialize) initialize
>   org-babel-default-header-args: for shell names.

Applied. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Proposal: references from code to text.

On Wed, May 16, 2018 at 9:25 AM, John Kitchin  wrote:
> #+NAME: DOC-OF-ADD
> We use the function add to calculate the sum of two numbers.
>
> #+NAME: add-options
> - one
> - two
> - three
> - and of course "optional things"
>
>
> We use a block like this to get the contents of an org-element by name as a
> string, and possibly transform it some how, e.g. in this case I escape
> quotes. I guess you could also use an exporter to convert it to what ever
> form you want. You might bury this block at the end in an appendix so it
> isn't in the middle of your document like this.
>
> #+name: get-string
> #+BEGIN_SRC emacs-lisp :var name="add-options"
> (let ((el (org-element-map (org-element-parse-buffer)
> org-element-all-elements
> (lambda (el)
>   (when (string= (org-element-property :name el) name)
> el))
> nil t)))
>   (let ((s (buffer-substring (org-element-property :contents-begin el)
>  (org-element-property :contents-end el
> (replace-regexp-in-string "\\\"" "\"" s)))
> #+END_SRC
>
>
> Now, we can use those elements in a src-block like this.
>
> #+NAME: ADD
> #+BEGIN_SRC emacs-lisp -n -r :noweb yes :tangle test.el
> (defun add (x y)
>   "One line description of adding X and Y.
>   <> ;; code to code
>   <>"
>   ;; [[id:BAD97113-3561-4A4A-BA07-0CD5BF6BA35F][There is a reason we only
> support two args]] code to text
>   (+ x y) (ref:add)
>   ;; it appears the coderef needs to be on it's own line, otherwise you get
> a org-link-search: No match for coderef: add when you click on the link.
>   )
> #+END_SRC

This thread is great. Got me thinking about "true" one-time
documentation definitions in the file itself. The blog post laid it
all out very nicely.

It got me wondering if I (or anybody) would like something like this
style of use where you write your documentation in-line of the
document using a macro that might look like this:

Add a macro that you could use in the documentation like this both to
define the string and include it in the export

"The document adding function is pretty important to the doc function Add. .

#+MACRO: add-string (eval (add-string "$1" "$2")

Add a file buffer-local variable of key/value pairs for strings named 'strings'.

Add helper functions with the same names here "get-string, add-string"
to use it (pseudo code follows)

#+name: add-string
#+begin_src emacs-lisp :var key="default" :var value="default
;; if the key doesn't exist in the hashmap then add it and return the value
;; otherwise just return the value so it doesn't stomp on the existing value
#+end_src

Add would return the string, and that would get inserted in the export.

Get-string would just get they key's value from the hashmap

#+name: get-string
#+begin_src emacs-lisp :var key="default"
;; if the key exists then return its value
;; otherwise return "UNDEFINED"
#+end_src

To use that documentation in the source block it would work the same as above

It would be easy to add prettification to cut down on the "noise" of
the syntax to use the macro and do the literate call, too that people
might like.

This is all pseudo code but I think it is in the same spirit of this
thread. Do you?

[O] [SOLVED, really] (was: export to odt, eqnarray and align are not supported)

>>> "Eric" == Eric S Fraga  writes:

   > On Friday, 15 Jun 2018 at 10:52, Uwe Brauer wrote:
   >> Both a set to nil, but even if I try dvipng via 
   >> 
   >> #+OPTIONS: tex:dvipng
   >> 
   >> Or   #+OPTIONS: tex:imagemagick

   > Data point:

   > Both work for me.  The dvipng output looks better, however.  The mathml
   > doesn't work (for me) for the second case with the align environment.

   >> The math, even equations are inserted verbatim, that is really odd.
   >> The minibuffer tells me that the png are generated and indeed there are,
   >> but they are not inserted in the odt file using as  org-export-dispatch
   >> and then chosing odt.

   > Strange.  Cannot help.  Sorry.

Ok I found the culprit, I debugged ox-odt.el
it is the following function 


(defun org-odt-format-headline-default-function
 (let* ((style (format "OrgPriority-%s" priority))
 ^ this is the problem.

The new code has 

  (let* ((style (format "OrgPriority-%c" priority))

And this solves the eqnarray problem. Good, uff relived. Now I can go
home ;-)


smime.p7s
Description: S/MIME cryptographic signature

Re: [O] Issues with org-babel-detangle and :comments noweb

On Mon, May 28, 2018 at 12:32 PM, Frederick Giasson  wrote:
> Hi Everybody,
>
> I am trying to have noweb references working with org-babel-detangle. Let's
> use this example:
>
> ```
> #+NAME: a
> #+BEGIN_SRC clojure
>
> (def a "a")
>
> #+END_SRC
>
> #+NAME: b
> #+BEGIN_SRC clojure
>
> (def a "b")
>
> #+END_SRC
>
> #+NAME: c
> #+BEGIN_SRC clojure
>
> (def a "c")
>
> #+END_SRC
>
> #+NAME: a
> #+BEGIN_SRC clojure
>
> (def a "a")
>
> #+END_SRC
>
>
> #+NAME: test
> #+BEGIN_SRC clojure :tangle test.clj :mkdirp yes :noweb yes :padline yes
> :results silent :comments noweb
>
> <>
> <>
> <>
>
> #+END_SRC
>
> ```
>
>
> Once tangled, the test.clj file looks like:
>
> ```
> ;; [[file:test.org::test][test]]
> ;; [[file:test.org::a][a]]
>
> (def a "a")
>
> ;; a ends here
> ;; [[file:test.org::a][a]]
>
> (def a "a")
>
> ;; a ends here
> ;; [[file:test.org::b][b]]
>
> (def a "b")
>
> ;; b ends here
> ;; [[file:test.org::c][c]]
>
> (def a "c")
>
> ;; c ends here
> ;; test ends here
> ```
>
> If I perform org-babel-tangle-jump-to-org  everything works fine, I jump to
> the block codes.
>
> However if I perform org-babel-detangle, when I get the message "Not in
> tangle code". The problem appears to be that the references are "embedded"
> in the tangled block code. If I move the "test ends here" above, then it
> works, but then when the tangled block code get detangled, I loose the noweb
> references.
>
> Any idea if there is a work around for that? I would like to use
> org-babel-tangle-jump-to-org and org-babel-detangle while being about to
> change the order of the code within the block codes in the tangled file.

Hi Fred,

I took your example and changed the language but that doesn't affect
the example.

All of the examples include what is the minimum amount necessary.

Here is my version of the org file

=

#+NAME: a
#+BEGIN_SRC clojure
(def a "a")
#+END_SRC
#+NAME: b
#+BEGIN_SRC clojure
(def b "b")
#+END_SRC
#+NAME: c
#+BEGIN_SRC clojure
(def c "c")
#+END_SRC
#+NAME: test
#+BEGIN_SRC emacs-lisp :tangle test.el
⟪a⟫
⟪b⟫
⟪c⟫
#+END_SRC

=

Here is the generated code

;; [[file:~/tmp/frederick.org::test][test]]
;; [[file:~/tmp/frederick.org::a][a]]
(def a "a")
;; a ends here
;; [[file:~/tmp/frederick.org::b][b]]
(def b "b")
;; b ends here
;; [[file:~/tmp/frederick.org::c][c]]
(def c "c")
;; c ends here
;; test ends here


=

If I go the the tangled code

;; [[file:~/tmp/frederick.org::c][c]]
(def c "c") <--- and put the cursor here
;; c ends here
;; test ends here

And call org-babel-tangle-jump-to-org

#+NAME: c
#+BEGIN_SRC clojure
(def c "c") <--- then the cursor jumps here
#+END_SRC

=

If I go the the tangled code

;; [[file:~/tmp/frederick.org::test][test]] <--- and put the cursor here
;; [[file:~/tmp/frederick.org::a][a]]
(def a "a")
;; a ends here

And call org-babel-tangle-jump-to-org

#+NAME: test
#+BEGIN_SRC emacs-lisp :tangle test.el <--- then the cursor jumps here
<>
<>
<>
#+END_SRC

=

It seems like Org "knows what to do here".

Here is my question:

If I take the tangled code and change the source block so the order is
reverse and the content of c has changed

;; [[file:~/tmp/frederick.org::test][test]]
;; [[file:~/tmp/frederick.org::c][c]]
(def c "CADILLAC")
;; c ends here
;; [[file:~/tmp/frederick.org::b][b]]
(def b "b")
;; b ends here
;; [[file:~/tmp/frederick.org::a][a]]
(def a "a")
;; a ends here
;; test ends here

And I detangle that file:

Then do you want the code in the source file to look like this?

#+NAME: c
#+BEGIN_SRC clojure
(def c "Cadillac")
#+END_SRC

#+NAME: test
#+BEGIN_SRC emacs-lisp :tangle test.el
⟪c⟫
⟪b⟫
⟪a⟫
#+END_SRC

=

Does the jumping to org working the same here for you as for me?

Is the detangling behavior example I wrote what you are thinking of?

I am asking because I want to know if I understand correctly or not.

Re: [O] How to enable truncate-lines in orgmode by default?

Hello,

ST  writes:

> I would like to enable truncate-lines in orgmode by default - how can I
> do that?

By default, Org enables truncate-lines.

See also `org-startup-truncated'.

Regards,

-- 
Nicolas Goaziou

Re: [O] org-metaup destructive when region active?

Hello,

Adam Porter  writes:

> I noticed that using org-metaup when a region is active seems to behave
> in an unintuitive and potentially dangerous way.  I would expect that it
> would behave similarly to org-refile when a region is active, but it
> doesn't.
>
> Looking at the code, I see that it does this:
>
> ┌
> │ (let* ((a (min (region-beginning) (region-end)))
> │(b (1- (max (region-beginning) (region-end
> │(c (save-excursion (goto-char a)
> │   (move-beginning-of-line 0)))
> │(d (save-excursion (goto-char a)
> │   (move-end-of-line 0) (point
> │   (transpose-regions a b c d)
> │   (goto-char c))
> └
>
> It was difficult for me to understand what that would do, and the
> docstring of transpose-regions didn't help.  So I did a small
> experiment, defining that code as a command and calling it in this
> buffer (where the region is marked with brackets):
>
> ┌
> │ abcd
> │ [efgh
> │ hijk]
> │ lmno
> └
>
> The result was this:
>
> ┌
> │ efgh
> │ hij
> │ abcdk
> │ lmno
> └

This is now fixed. Thank you.

> Now for an example with Org headings, before:
>
> ┌
> │ * A
> │ ** A1
> │ ** A2
> │ [* B
> │ ** B1
> │ ** B2]
> │ * C
> │ ** C1
> │ ** C2
> └
>
> After:
>
> ┌
> │ * A
> │ ** A1
> │ * B
> │ ** B1
> │ ** B
> │ ** A22
> │ * C
> │ ** C1
> │ ** C2

This is partly fixed, i.e., there is no more "2" left over.

> Ideally it would act on all headings in the region, but given the
> complexity of doing that correctly, would it be a good first step to
> simply do nothing when org-metaup is called and a region is active?  It
> would at least avoid corrupting data.  I think that's a non-trivial
> risk, because when I noticed this behavior, it was in a partially
> collapsed outline, and some of the headings in the region (and their
> entry content) seemed to vanish altogether; I only recovered them with
> undo.

I have no strong opinion on the subject. However, I agree this feature,
i.e., `org-metaup' (or `org-metadown') on a region can be removed
altogether, since this is but a glorified kill'n'yank process.

Nevertheless, I'm Cc'ing Bastien for his opinion, as he introduced the
feature in the first place.

I didn't write tests for the function because its specifications are not
completely defined yet.

Regards,

-- 
Nicolas Goaziou

Re: [O] General advice beyond Org

On Wed, Jun 6, 2018 at 3:58 AM, Marco  wrote:
> I started as post-doc almost 10 years ago,

Thanks for your share Marco.

Re: [O] Org mode in combination with emacs follow-mode is terrible

2018-06-15 Thread Gerald Wildgruber



I tried profiling my use of org-mode in conjunction with follow-mode; I
did the following:

1. M-x profiler-start
2. I enabled follow-mode in my buffer
3. I did some editing
4. M-x profiler-report
5. M-x profiler-stop

here's the result:

Collapsed, the report looks like that:

+ command-execute8789  47%
+ follow-post-command-hook   7755  41%
+ ...1976  10%
+ redisplay_internal (C function) 104   0%
+ yas--post-command-handler40   0%
+ timer-event-handler  20   0%
  tooltip-hide  7   0%


And somewhat expanded:

- command-execute8789  47%
 - call-interactively8789  47%
  - byte-code8174  43%
   - read-extended-command   8174  43%
- completing-read8174  43%
 - # 8174  43%
  - apply8174  43%
   - helm--completing-read-default   8174  43%
- helm-completing-read-sync-default-handler   8174  43%
 - helm-completing-read-default-18174  43%
  - helm-comp-read   8174  43%
   - helm8165  43%
- apply  8165  43%
 - helm  8165  43%
  - apply8165  43%
   - helm-internal   8165  43%
- helm-read-pattern-maybe8150  43%
 + read-from-minibuffer  8079  43%
 + helm-update 43   0%
- # 9   0%
 + helm-cleanup 9   0%
+ helm-display-buffer   6   0%
   + helm-make-source   9   0%
  + funcall-interactively 615   3%
- follow-post-command-hook   7755  41%
 - follow-adjust-window  7755  41%
  - follow-windows-start-end 7732  41%
   - follow-calc-win-end 7732  41%
+ pos-visible-in-window-p  25   0%
+ posn-at-x-y   7   0%
+ window-inside-pixel-edges 3   0%
  + follow-all-followers4   0%
follow-avoid-tail-recenter  3   0%

If I understand correctly "follow-calc-win-end" would be the function
that uses most of cpu time.

I can't say how "normal" the other 47% under "command-execute" are,
which mainly seems to be helm-related ("helm-update").

Can anyone give an advice on possible optimizations with this situation?


Gerald.


On Mi, Jun 13 2018, Joost Kremers  wrote:

> Actually, I would suspect it's more of a problem for follow-mode than
> org-mode, because follow-mode needs to keep the different windows in sync.
> For this, it adds a function to `post-command-hook', which means it's run
> after every key press.
>
> It's not inconceivable that `follow-mode' does something that is extra
> time-consuming in an Org buffer. To find out what that might be, you could
> try the Elisp profiler that comes with Emacs. See the section "Profiling"
> in the Elisp manual for details.
>
> Once you've found out which function(s) consume so much time, it might be
> possible to ask in here or on emacs-devel what exactly is causing the
> problem and whether there's a way around it.


--
Dr. Gerald Wildgruber
Institut für Philosophie, Literatur-, Wissenschafts- und Technikgeschichte
Literaturwissenschaft mit Schwerpunkt Literatur und Wissenschaft
Technische Universität Berlin
Straße des 17. Juni 135
D-10623 Berlin
http://www.philosophie.tu-berlin.de/menue/home/
T. +49 (0)30 314 25924
F. +49 (0)30 314 23107
wildgru...@tu-berlin.de
-
Sent with mu4e

Re: [O] New org-count-words function

On Tue, Jun 12, 2018 at 2:58 PM, Adam Porter  wrote:
> I think it's an improvement over the functions I've seen that do this.
> Hope someone finds it useful.

Thank you that is very nice.

Got me thinking that it would be fun to write some code that would
report file statistics by element.

[O] How to enable truncate-lines in orgmode by default?

2018-06-15 Thread ST

Hello,

I would like to enable truncate-lines in orgmode by default - how can I
do that?

Here is what I tried to put in my config, but it doesn't seem to help:

(add-hook 'org-mode-hook 
  (lambda ()
(setq truncate-lines t)))

Thank you!

[O] [SOLVED] (was: orgtbl in latex files: array with \hline)

>>> "Uwe" == Uwe Brauer  writes:

   > Hi

   > I would like to generate the following array environment with orgtbl.

   > \begin{equation*}
   > % BEGIN RECEIVE ORGTBL laplace
   > \begin{array}{|c|c|}
   >  f(x) & \mathcal{L} \left\{ f(x) \right\} =F(s) \\ \hline
   > \end{array}
   > % END RECEIVE ORGTBL laplace
   > \begin{comment}

   > #+ORGTBL: SEND laplace orgtbl-to-latex :latex-default-table-mode math 
:environment array
   > | f(x)| \mathcal{L} \left\{ f(x) \right\} =F(s)
|

   > \end{comment}
   > \end{equation*}


   > How can I achieve {|c|c|} and \hline when translating the table to
   > latex?

I think I asked something similar a while ago and the correct answer
seems to be:


\begin{equation}
  \label{eq:myarray:1}
\begin{array}{l|l|}
% BEGIN RECEIVE ORGTBL test
17 & 8\\ \hline
% END RECEIVE ORGTBL test
\end{array}
\end{equation}

\begin{comment}
#+ORGTBL: SEND test orgtbl-to-latex  :lend " \\hline" :environment array 
:splice t
| 17 | 8 |
\end{comment}



smime.p7s
Description: S/MIME cryptographic signature

Re: [O] Org mode in combination with emacs follow-mode is terrible

2018-06-15 Thread Gerald Wildgruber



Thanks Joost,

that's interesting! I never used the profiler but I will try and see how
far I get with it and then come back here.

Gerald.

On Mi, Jun 13 2018, Joost Kremers  wrote:

> On Wed, Jun 13 2018, Eric S Fraga wrote:
>> On Wednesday, 13 Jun 2018 at 09:53, Gerald Wildgruber wrote:
>>> Switching to text-mode, with 5 windows and follow-mode still being
>>> active reduces lag significantly.
>>>
>>> So there must be an issue specifically with the combination of org-mode
>>> and follow-mode!
>>
>> I don't think there's an issue per se in the sense of bugs.  Org does
>> much more processing of the text than does text mode so if you have 60k
>> worth of text to process each time you type something, it's probably not
>> surprising that there is a lag.
>
> Actually, I would suspect it's more of a problem for follow-mode than
> org-mode, because follow-mode needs to keep the different windows in sync.
> For this, it adds a function to `post-command-hook', which means it's run
> after every key press.
>
> It's not inconceivable that `follow-mode' does something that is extra
> time-consuming in an Org buffer. To find out what that might be, you could
> try the Elisp profiler that comes with Emacs. See the section "Profiling"
> in the Elisp manual for details.
>
> Once you've found out which function(s) consume so much time, it might be
> possible to ask in here or on emacs-devel what exactly is causing the
> problem and whether there's a way around it.


--
Dr. Gerald Wildgruber
Institut für Philosophie, Literatur-, Wissenschafts- und Technikgeschichte
Literaturwissenschaft mit Schwerpunkt Literatur und Wissenschaft
Technische Universität Berlin
Straße des 17. Juni 135
D-10623 Berlin
http://www.philosophie.tu-berlin.de/menue/home/
T. +49 (0)30 314 25924
F. +49 (0)30 314 23107
wildgru...@tu-berlin.de
-
Sent with mu4e

Re: [O] Org mode in combination with emacs follow-mode is terrible

2018-06-15 Thread Gerald Wildgruber

Thanks again; I'm always using the latest git checkout of emacs
(v.27, see my first posting).

On Mi, Jun 13 2018, Eric S Fraga  wrote:

> I don't think there's an issue per se in the sense of bugs.  Org does
> much more processing of the text than does text mode so if you have 60k
> worth of text to process each time you type something, it's probably not
> surprising that there is a lag.  60k is a lot of text and I assume there
> are many headings etc.?

Yes, indeed, there are! Actually does this mean that emacs or org-mode
has to take into consideration every single bit of text in the visible
part buffer of the buffer, whenever I press a key? what needs to be
calculated by simple entering of text?

Gerald

--
Dr. Gerald Wildgruber
Institut für Philosophie, Literatur-, Wissenschafts- und Technikgeschichte
Literaturwissenschaft mit Schwerpunkt Literatur und Wissenschaft
Technische Universität Berlin
Straße des 17. Juni 135
D-10623 Berlin
http://www.philosophie.tu-berlin.de/menue/home/
T. +49 (0)30 314 25924
F. +49 (0)30 314 23107
wildgru...@tu-berlin.de
-
Sent with mu4e

Re: [O] Fix org-meta-return for checkbox lists

2018-06-15 Thread Kaushal Modi

On Fri, Jun 15, 2018 at 10:10 AM Nicolas Goaziou 
wrote:

>
> The problem is that your initial suggestion make it impossible, common
> or not.
>

I agree. That was a mistake. I overlooked the case where one would want to
have mix of checkbox and unordered items.


> As it is, it is symmetric with M-RET and M-S-RET on headlines. E.g., in
> the following document
>
>   * TODO Stuff|
>
> where "|" is point, M-RET results in
>
>   * TODO Stuff
>   *
>
> i.e., no TODO added. I find it straightforward.
>

OK. So no one way is right :) So it makes sense to keep it as it is.
-- 

Kaushal Modi

Re: [O] Fix org-meta-return for checkbox lists

Hello,

Kaushal Modi  writes:

> Is it that common to have mix of checkboxes and unordered lists items?

The problem is that your initial suggestion make it impossible, common
or not.

> I would think that this behavior of org-meta-return is more consistent:
>
> - If you are on a "* foo" line, M-RET creates "* " on the next line.
> - If you are on a "1. foo" line, M-RET creates "2. " on the next line.
> - If you are on a "- foo" line, M-RET creates "- " on the next line.
> - *But* if you are on a "- [ ] foo" line, M-RET still creates "- " instead
> of "- [ ] " on the next line?
>
> Shouldn't M-RET and M-S-RET behavior be switched for checkbox lists?

As it is, it is symmetric with M-RET and M-S-RET on headlines. E.g., in
the following document

  * TODO Stuff|

where "|" is point, M-RET results in

  * TODO Stuff
  * 

i.e., no TODO added. I find it straightforward.

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] Use Emacs' default value of "bidi-paragraph-direction" in orgmode

Hello,

ST  writes:

> Please leave the Emacs' default value of "bidi-paragraph-direction"
> which is "nil" in orgmode as well. Right now orgmode seems to force
> "left-to-right", thus blocking "right-to-left". With "nil" it is
> dynamic, which means both directions work well out-of-the box.
>
> Right now I'm forced to add this to my config:
>
> (add-hook 'org-mode-hook 
>   (lambda ()
> (setq bidi-paragraph-direction nil)))
>
> It took me a lot of time to figure out, which makes the first Org steps
> for RTL-newbies quite frustrating...

It may not be as obvious as you think. See

for details.

Regards,

-- 
Nicolas Goaziou

Re: [O] Fix org-meta-return for checkbox lists

2018-06-15 Thread Kaushal Modi

Hello Nicolas, Brent,

On Fri, Jun 15, 2018 at 9:53 AM Bernt Hansen  wrote:

> I agree.  I use lists with mixed checkboxes and no checkboxes and do not
> want to enforce checkboxes on every list item.
>

OK, I can understand if the behavior is kept as it is.

Is it that common to have mix of checkboxes and unordered lists items?

I would think that this behavior of org-meta-return is more consistent:

- If you are on a "* foo" line, M-RET creates "* " on the next line.
- If you are on a "1. foo" line, M-RET creates "2. " on the next line.
- If you are on a "- foo" line, M-RET creates "- " on the next line.
- *But* if you are on a "- [ ] foo" line, M-RET still creates "- " instead
of "- [ ] " on the next line?

Shouldn't M-RET and M-S-RET behavior be switched for checkbox lists?
-- 

Kaushal Modi

Re: [O] Fix org-meta-return for checkbox lists

2018-06-15 Thread Bernt Hansen

Nicolas Goaziou  writes:

> Kaushal Modi  writes:
>
>> Currently if you do M-RET in a checkbox list item, the next item does not
>> become a checkbox automatically. This patch fixes that.
>>
>> I have been using this fix locally for few months. But never got to
>> submitting it as I need to yet write a test for it.
>>
>> Does that patch look good (apart from missing tests). Should I format it
>> w.r.t to next? or master?
>
> IMO, there is nothing to fix. Inserting a checkbox in every item is not
> mandatory.
>
> Furthermore, currently, M-RET inserts a regular item and M-S-RET inserts
> it with a checkbox. With your patch, both M-RET and M-S-RET do the same
> thing, which is sub-optimal.
>
> My vote is to keep the current behaviour.

I agree.  I use lists with mixed checkboxes and no checkboxes and do not
want to enforce checkboxes on every list item.

Thanks,
Bernt

[O] [equations: conversions] (was: [Sort of Solved:culprit])








   > Ok I found the culprit: it is the org version. I am using master git
   > from July of last year, because

I did some further testing this git version converts \[ \]

But not equations eqnarray etc.



The strange thing when I use the version shipped by the package system 
which is org-20171116, a date posterior to July 2017, then equations are
converted. However I thought the package system does not ship the latest
master but a stable release. So I am a bit confused.


Anybody know about the issue of exporting eqautions and eqnarray and
recent changes in the filters?

[O] Use Emacs' default value of "bidi-paragraph-direction" in orgmode

2018-06-15 Thread ST

Hello,

Please leave the Emacs' default value of "bidi-paragraph-direction"
which is "nil" in orgmode as well. Right now orgmode seems to force
"left-to-right", thus blocking "right-to-left". With "nil" it is
dynamic, which means both directions work well out-of-the box.

Right now I'm forced to add this to my config:

(add-hook 'org-mode-hook 
  (lambda ()
(setq bidi-paragraph-direction nil)))

It took me a lot of time to figure out, which makes the first Org steps
for RTL-newbies quite frustrating...

Please, let me know if you decide to fix this in the upcoming versions.

Thank you!

[O] [Sort of Solved:culprit] (was: export to odt, eqnarray and align are not supported)

>>> "Eric" == Eric S Fraga  writes:

   > On Friday, 15 Jun 2018 at 10:52, Uwe Brauer wrote:
   >> Both a set to nil, but even if I try dvipng via 
   >> 
   >> #+OPTIONS: tex:dvipng
   >> 
   >> Or   #+OPTIONS: tex:imagemagick

   > Data point:

   > Both work for me.  The dvipng output looks better, however.  The mathml
   > doesn't work (for me) for the second case with the align environment.

   >> The math, even equations are inserted verbatim, that is really odd.
   >> The minibuffer tells me that the png are generated and indeed there are,
   >> but they are not inserted in the odt file using as  org-export-dispatch
   >> and then chosing odt.

   > Strange.  Cannot help.  Sorry.

Ok I found the culprit: it is the org version. I am using master git
from July of last year, because

1. It contains Nick's cool hide very wide columns in tables

2. But it does not contain the new template system, which breaks
   backwards compatibility. :'(

However when converting to odt with dvipng, inline symbols are correctly
generated but not equations or eqnarryas etc. That must be a bug in this
particular master version, sigh

I thinks as soon as possible I have to acquaint myself with the new
template system and convert the bunch of templates I have to the new system.

However right now I still with the version and will use vanilla org for
the conversion. 

smime.p7s
Description: S/MIME cryptographic signature

Re: [O] export to odt, eqnarray and align are not supported

>>> "Eric" == Eric S Fraga  writes:

   > On Friday, 15 Jun 2018 at 10:52, Uwe Brauer wrote:
   >> Both a set to nil, but even if I try dvipng via 
   >> 
   >> #+OPTIONS: tex:dvipng
   >> 
   >> Or   #+OPTIONS: tex:imagemagick

   > Data point:

   > Both work for me.  The dvipng output looks better, however.  The mathml
   > doesn't work (for me) for the second case with the align environment.

Thanks, I got meanwhile the mathml to work, but the result is not
appealing.

   >> The math, even equations are inserted verbatim, that is really odd.
   >> The minibuffer tells me that the png are generated and indeed there are,
   >> but they are not inserted in the odt file using as  org-export-dispatch
   >> and then chosing odt.

   > Strange.  Cannot help.  Sorry.

Ok I started emacs -q and then it worked. 

So it must be something in my setting. Sigh. I have to debug this which
can take a while, anybody an idea which variable I set incorrectly?


smime.p7s
Description: S/MIME cryptographic signature

Re: [O] export to odt, eqnarray and align are not supported

2018-06-15 Thread Eric S Fraga

On Friday, 15 Jun 2018 at 10:52, Uwe Brauer wrote:
> Both a set to nil, but even if I try dvipng via 
>
>#+OPTIONS: tex:dvipng
>
> Or   #+OPTIONS: tex:imagemagick

Data point:

Both work for me.  The dvipng output looks better, however.  The mathml
doesn't work (for me) for the second case with the align environment.

> The math, even equations are inserted verbatim, that is really odd.
> The minibuffer tells me that the png are generated and indeed there are,
> but they are not inserted in the odt file using as  org-export-dispatch
> and then chosing odt.

Strange.  Cannot help.  Sorry.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.11-620-ga548e4


signature.asc
Description: PGP signature

Re: [O] org creates bibtex fontification buffers without setting dialect, causes error

2018-06-15 Thread Eric S Fraga

On Thursday, 14 Jun 2018 at 21:34, Adam Porter wrote:

[...]

> It seems easy enough to fix: Org should call bibtex-set-dialect in its
> BibTeX fontification buffer. But why has no one else has noticed this
> problem?  It seems like this should happen to every Org user who has a
> BibTeX source block in an open Org buffer.

I have had this problem for a very long time now but have never been
able to diagnose it.  I don't have the requisite Emacs skills for
this. :-(

It would indeed be nice for this to be fixed!  And thanks for your
diagnosis.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.13-753-g2ec5d3

signature.asc
Description: PGP signature

Re: [O] export to odt, eqnarray and align are not supported

>>> "Uwe" == Uwe Brauer  writes:

   > Hi 

   > Maybe there is something odd in my configuration, but I cannot export
   > the following minimal example to odt, with the equation correctly
   > translated, and I don't know how to debug it.

Sigh

(describe-variable 'org-latex-to-mathml-jar-file)
(describe-variable 'org-latex-to-mathml-convert-command)

Both a set to nil, but even if I try dvipng via 

   #+OPTIONS: tex:dvipng

Or   #+OPTIONS: tex:imagemagick

The math, even equations are inserted verbatim, that is really odd.
The minibuffer tells me that the png are generated and indeed there are,
but they are not inserted in the odt file using as  org-export-dispatch
and then chosing odt.

This is all very odd.

smime.p7s
Description: S/MIME cryptographic signature

[O] export to odt, eqnarray and align are not supported