Re: [O] Placement of \makeatletter with \beamer@frametextheight

[Loris Bennett]

Hi Eric,

Eric S Fraga  writes:

> On Wednesday, 28 Nov 2018 at 16:09, Loris Bennett wrote:
>> Hi,
>>
>> I want to specify the size of a graphic in an Beamer presentation
>> generated from my org file.  The following
>>
>>   #+ATTR_LATEX: :height 0.75\textheight
>>
>> works, but
>>
>>   #+ATTR_LATEX: :height 0.75\beamer@frametextheight
>>
>> I get the error
>>
>>   ! Undefined control sequence.
>>   \Gin@@eheight ->0.5\beamer
>>  @frametextheight
>>
>> I assume I need to insert a \makeatletter at the appropriate point.
>> Where would that be?
>
> You might find it easier to create your own variable in the header of
> the LaTeX file and use that directly, as in (untested):
>
> #+latex_header: 
> \makeatletter\let\mytextheight\beamer@frametexheight\makeatother
>
> ...
>
> #+attr_latex: :height 0.75\mytextheight

Thanks, but with that I get

  ! Undefined control sequence.
  \Gin@@eheight ->0.75\mytextheight 

However, the tex file looks OK:

  ...
  \usepackage[sfdefault]{Fira Sans}
  \makeatletter\let\mytextheight\beamer@frametexheight\makeatother
  \definecolor{mFubMainGreen}{HTML}{99CC00}
  ...
  \begin{center}
  \includegraphics[height=0.75\mytextheight]{../../common/resources.png}
  \end{center}
  ...

Any ideas what might still be going wrong?

Cheers,

Loris

--
This signature is currently under construction.

Re: [O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.

[emanuel . charpentier]

TL;DR : your fix works, but I disagree with the absence od
documentation and default. See below :

Le mercredi 28 novembre 2018 à 15:06 +0100, Nicolas Goaziou a écrit :
> Hello,
> 
> Emmanuel Charpentier  writes:
> 
> > Close, but no cigar :
> > 
> > I used the `customize' interface to add it to `org-latex-default-
> > packages-alist' (because the package to load is compiler-
> > dependent),
> 
> This has nothing to do with compiler. You can add it to `org-latex-
> packages-alist'.

AFAICT, polyglossia is to be preferred to babel for use with xelatex or
lualatex. I'll see if this can be accomodated.

> [ Snip... ]

I'll do that.

> See `org-latex-classes' docstring:

> it should be ("AUTO" "babel" t).

OK. That's much clearer. And does what is intended, BTW.

Shouldn't that be default ?(No, I don't (yet) know *how* to do that..).

> >   * If this setup is necessary to get #+langiage: honored fot LaTeX
> > export, this should be done by default (i. e. in org's source
> > code).
> 
> AFAIR, there is no clean way to handle that, so we let users decide
> what
> they want.

Thus introducing a serious problem : exporting to text or ODT works as
described, whereas export to latex needs (undocumented) supplementary
steps.

At the very minimum, this need for further config should be mentioned
in the docs ; preferably, a default should be proposed.

> 
> >   * One might wish to allow to fully use babel's (and
> > polyglossia's)
> > abilities by specifying a set of possible #+language:s (first
> > call) or switch to another language (further calls down the
> > file...).
> 
> See `org-latex-classes' docstring.

Thanks for the tip ! Now, I begin to understand...

> 
> >   * concerning french: I understand that "frenchb" is obsolete and
> > that one should use "french" instead (better compatibility with
> > ispell and flyspell-babel, among others)...
> 
> I didn't know that. I'll fix it in master.
> 
> >   * I suggest a '(#1# "fontspec" t '(xelatex lualatex)), and
> > possibly
> > an '(#1# "mathspec" t '(xetex luatex)) or '(#1# "unicode-math"
> > t
> > '(xetex luatex))
> > entry(ies) to be added to the default : xetex is more and more
> > used, and luatex is officially the successor to pdftex...
> 
> I use neither xetex or luatex so I cannot comment of this.

I'll try to whip up a proposal.

Sincerely,

--
Emmanuel Charpentier

> However note that default packages should be very limited. It is easy
> enough to add more of them to standard packages.
> 
> Regards,
> 

Re: [O] How to handle an inline multiline noweb reference

[Eric S Fraga]

On Wednesday, 28 Nov 2018 at 15:35, Samuel Wales wrote:
> fyi only: i don't understand the examples or the relevance to pipes.

The output (or more generally the results) of one src block is passed directly 
as input to another using the :post argument.  

See, for instance:

#+begin_src org
  ,#+name: doubleit
  ,#+begin_src octave :results output :var x=[0.1]
  disp(2*x)
  ,#+end_src

  ,#+name: test
  ,#+begin_src octave :post doubleit(x=*this*)
2*3.14
  ,#+end_src

  ,#+results: test
  :  12.560
#+end_src

HTH,
eric

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

Re: [O] Standard Format for Org Outlines?

[David Masterson]

Nicolas Goaziou  writes:

> David Masterson  writes:
>
>> * Header 1
>>
>> * Header 2
>>
>> Position the cursor on '1' and M-return will create a new header with a
>> blank line before and after it, but C-return will create a new header
>> with a blank line before, but not after it.

> I see. I pushed a fix in master branch. Please let me know if it 
> behaves better there.

Good try, but I think you got it backwards.  I pulled down a daily
development snapshot tarball from yesterday (not good with git yet) and
tried it again.  This time, it broke M-return by adding an extra blank
line after the header (ie. two blank lines), but still did not put in a
blank line after the header on C-return.

--
David

Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]

[Carlos Pita]

As a possible fix I implemented this
font-lock-extend-after-change-region-function:

(defun my-org-extend-region (beg end old-len)
  (let ((begin-re "[\t ]*\\(#\\+BEGIN\\|begin{\\)")
(end-re "[\t ]*\\(#\\+END\\|end{\\)"))
(save-excursion
  (goto-char beg)
  (beginning-of-line)
  (if (looking-at end-re)
  (setq beg (or (re-search-backward begin-re nil t) beg))
(when (looking-at begin-re)
  (setq end (or (re-search-forward end-re nil t) end))
  (cons beg end))

It's simple and efficient. The idea is that if you have changed one
endpoint of a #+BEGIN/#+END or \begin{/\end{ block, then you'd better
extend the fontification region up to the other end. This way the
extension only triggers when a BEGIN/END/begin/end match is found in
the current line after a change, making the whole thing quite
lightweight.

Notice that I added the BEGIN/END case because I was having some
issues with org blocks also, although they were less frequent, just
some border cases. This hook made the behavior more robust and
predictable.

Maybe you would like to add this (or something similar or better)
while initializing org mode font lock stuff.

Once this is in place it's trivial to get native fontification of
latex snippets working as explained above, without the need to
disrespect search limits.

So, to sum up:

1. There is a bug and some kind of region extension is in order to
address it. Here I'm proposing one simple solution.

2. Then there is a feature request: add the ability to natively
fontify latex embedded fragments. I've also shown how to do that in a
couple of lines, but obviously some new customization option is also
required.

HIH
--
Carlos


On Wed, Nov 28, 2018 at 3:38 PM Carlos Pita  wrote:
>
> Well, now I do have found a bug ;). It's related to the limit issue I
> mentioned before. Indeed the problem with rehighlighting broken
> environments and highlighting new environments also happens for basic
> latex fontification when org-highlight-latex-and-related is set to
> '(latex), it has nothing to do with my modification in order to call
> org-src-font-lock-fontify-block. It seems that once you break the
> multiline structure (for example, by putting a space between "be" and
> "gin") org mode syntax highlighter is unable to identify it again once
> recomposed. More generally, it's unable to identify environments
> entered after the initial loading of the file into the buffer, being
> them slight "repairments" of previously existing ones or just brand
> new environments. Of course, systematically ignoring the search bound
> is not the right solution. I think some kind of region extension
> function is missing here.

Re: [O] How to handle an inline multiline noweb reference

[Samuel Wales]

fyi only: i don't understand the examples or the relevance to pipes.

On 11/28/18, Eric S Fraga  wrote:
> On Tuesday, 27 Nov 2018 at 19:33, Samuel Wales wrote:
>> this might be the most ridiculous idea you have ever heard, but does
>> babel have a concept similar to stdio pipes?  i've often wanted to
>> just pipe stuff.  dunno if this would help marcin.
>>
>> the only inter-block communication i am aware of are variables and
>> noweb inclusion.
>
> Check out the :post option for src blocks.  May be exactly what you
> want.
> --
> Eric S Fraga via Emacs 27.0.50, Org release_9.1.14-1035-gfeb442
>


-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
.

Re: [O] In LaTeX export, can I control what heading type a headline goes to?

[Diego Zamboni]

Exactly what Ken said. Look at the documentation for org-latex-classes to
see the full description. You can see an example in my Emacs config:
https://github.com/zzamboni/dot-emacs/blob/master/init.org#various-exporters
(look
for the paragraph that starts with "Some customizations for the LaTeX
exporter"). Once that is defined, you can specify the name you used as the
value of "#+latex_class:" at the top of your org file, e.g.:

#+latex_class: book-no-parts

Best,
--Diego


On Wed, Nov 28, 2018 at 8:57 PM Ken Mankoff  wrote:

> Hi Bill,
> On 2018-11-28 at 20:42 +0100, William Denton  wrote:
> > Is there a way, exporting as a book, to make Org skip "part" and make
> > a top-level Org headline turn into a chapter? Is there a built-in way,
> > or do I need to make my own class in org-latex-classes that has the
> > structure I want?
>
> What about customizing org-latex-classes?
>
> It contains:
>
>  ("book" "\\documentclass[11pt]{book}"
>   ("\\part{%s}" . "\\part*{%s}")
>   ("\\chapter{%s}" . "\\chapter*{%s}")
>   ("\\section{%s}" . "\\section*{%s}")
>   ("\\subsection{%s}" . "\\subsection*{%s}")
>   ("\\subsubsection{%s}" . "\\subsubsection*{%s}")))
>
> Seems like modifying that could provide the behavior you're looking for.
>
>   -k.
>
>

Re: [O] In LaTeX export, can I control what heading type a headline goes to?

[Ken Mankoff]

Hi Bill,
On 2018-11-28 at 20:42 +0100, William Denton  wrote:
> Is there a way, exporting as a book, to make Org skip "part" and make
> a top-level Org headline turn into a chapter? Is there a built-in way,
> or do I need to make my own class in org-latex-classes that has the
> structure I want?

What about customizing org-latex-classes?

It contains:

 ("book" "\\documentclass[11pt]{book}"
  ("\\part{%s}" . "\\part*{%s}")
  ("\\chapter{%s}" . "\\chapter*{%s}")
  ("\\section{%s}" . "\\section*{%s}")
  ("\\subsection{%s}" . "\\subsection*{%s}")
  ("\\subsubsection{%s}" . "\\subsubsection*{%s}")))

Seems like modifying that could provide the behavior you're looking for.

  -k.

[O] In LaTeX export, can I control what heading type a headline goes to?

[William Denton]

By default the LaTeX export uses the article class, and headline levels are 
mapped to headings this way:  top level becomes section, second level becomes 
subsection, third level becomes subsubsection.  That's simple and works very 
well.


If the book class is used, then the top level becomes part, the second level 
becomes chapter, the third level becomes section, the fourth level becomes 
subsection, etc.  That works well too, of course, but what if I don't want to 
use "part"?


Is there a way, exporting as a book, to make Org skip "part" and make a 
top-level Org headline turn into a chapter?  Is there a built-in way, or do I 
need to make my own class in org-latex-classes that has the structure I want?


(In LaTeX the problem doesn't arise, of course:  don't use \part{} and just 
start with \chapter{}.)


Bill
--
William Denton :: Toronto, Canada   ---   Listening to Art: 
https://listeningtoart.org/
https://www.miskatonic.org/ ---   GHG.EARTH: http://ghg.earth/
Caveat lector.  ---   STAPLR: http://staplr.org/

Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]

[Carlos Pita]

Well, now I do have found a bug ;). It's related to the limit issue I
mentioned before. Indeed the problem with rehighlighting broken
environments and highlighting new environments also happens for basic
latex fontification when org-highlight-latex-and-related is set to
'(latex), it has nothing to do with my modification in order to call
org-src-font-lock-fontify-block. It seems that once you break the
multiline structure (for example, by putting a space between "be" and
"gin") org mode syntax highlighter is unable to identify it again once
recomposed. More generally, it's unable to identify environments
entered after the initial loading of the file into the buffer, being
them slight "repairments" of previously existing ones or just brand
new environments. Of course, systematically ignoring the search bound
is not the right solution. I think some kind of region extension
function is missing here.

Re: [O] How to handle an inline multiline noweb reference

[Grant Rettke]

On Wed, Nov 28, 2018 at 1:08 AM Eric S Fraga  wrote:
> Check out the :post option for src blocks.  May be exactly what you
> want.

Thanks for sharing that!

Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]

[Carlos Pita]

>  (lambda (start end  args)
>  (org-src-font-lock-fontify-block "latex" start end

Or a safer version:

 (lambda (start end prop face)
   (when (eq face 'org-latex-and-related)
  (org-src-font-lock-fontify-block "latex" start end)

Also note that the advice doesn't avoid the double setting of
(font-lock-multiline t). This is harmless but it's unnecessary
nevertheless. It's just intended as a workaround and to show that it's
pretty simple to extend native fontification to inline snippets.

Re: [O] Bug: org export table.el [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.1/lisp/org/)]

[Ulrich G. Wortmann]

Hi Nicolas,

I know nothing about lisp, but I think I understand enough of the structure
to propose the following changes:

In my testfile, this preserves the current behavior if no #+CAPTION is
present. However, if the  #+CAPTION is not empty, the table will be
exported as float with the proper caption and label. The code needs
probably some cleanup, but I don't understand enough lisp to know what's
save to drop.

Hope this can be merged

Cheers

Uli

--- org-mode/lisp/ox-latex.el   2018-11-28 11:58:15.23423 -0500
+++ org-mode-uliw/ox-latex.el.uliw  2018-11-28 11:57:09.057281230 -0500

@@ -3305,6 +3310,21 @@

 This function assumes TABLE has `table.el' as its `:type'
 property."
+  (let* ((caption (org-latex--caption/label-string table info))
+(attr (org-export-read-attribute :attr_latex table))
+;; Determine alignment string.
+(alignment (org-latex--align-string table info))
+;; Determine environment for the table: longtable, tabular...
+(table-env (or (plist-get attr :environment)
+   (plist-get info :latex-default-table-environment)))
+;; If table is a float, determine environment: table, table*
+;; or sidewaystable.
+(placement
+ (or (plist-get attr :placement)
+ (format "[%s]" (plist-get info
:latex-default-figure-position
+(centerp (if (plist-member attr :center) (plist-get attr :center)
+   (plist-get info :latex-tables-centered)))
+(caption-above-p (org-latex--caption-above-p table info)))
   (require 'table)
   ;; Ensure "*org-export-table*" buffer is empty.
   (with-current-buffer (get-buffer-create "*org-export-table*")
@@ -3332,7 +3352,16 @@
   (let ((centerp (if (plist-member attr :center) (plist-get attr
:center)
   (plist-get info :latex-tables-centered
(if (not centerp) output
- (format "\\begin{center}\n%s\n\\end{center}" output))
+ (if (string= "" caption)
+ (format (concat "\\begin{center}\n"
+ "%s\n"
+ "\\end{center}\n") output)
+   (format (concat "\\begin{table}\n"
+   caption
+   "\\centering\n"
+   "%s\n"
+   "\\end{table}\n") output))
+ ))

 (defun org-latex--math-table (table info)
   "Return appropriate LaTeX code for a matrix.


On Mon, 26 Nov 2018 at 16:02 Nicolas Goaziou  wrote:

> Hello,
>
> "Ulrich G. Wortmann"  writes:
>
> > I had a quick look at table.el
> >
> > It exports only a tabular command, not a table. Is there a way to make
> org
> > wrap the
> >
> > \begin{tabular}
> > \end{tabular}
> >
> > into a regular
> >
> > \begin{table}
> > \end{table}
> >
> > This would be perfectly correct latex, and keep the export mechanism,
> > neatly separated
>
> You may want to look at `org-latex--table.el-table' and see what can be
> done.
>
> Regards,
>
> --
> Nicolas Goaziou
>
-- 

Ulrich Wortmann 416 978 7084

Associate Chair Undergraduate Affairs

Department of Earth Sciences

University of Toronto
22 Russel St., Toronto, ON, Canada, M5S 3B1

Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]

[Carlos Pita]

> all fontification is lost for the entire environment and never reapplied

The problem is with the limit argument passed by the font locking
framework to org-do-latex-and-related .

Once you natively fontified the environment this limit arg became non
nil and it's in general not enough to match the entire latex
environment. I assume this is because of the way native fontification
annotates the code which makes the framework think it would be enough
to look up to some limit. But this is not true anymore when you have
this hybrid syntax that forces to refontify the entire fragment in a
temporary buffer.

So in order to get native fontification working for inline latex you need to:

1. Ignore the limit argument.
2. Replace the calls to font-lock-prepend-text-property and
add-text-properties by a single call to
org-src-font-lock-fontify-block
3. Also this makes most sense if org-highlight-latex-and-related is
set to '(latex).

Maybe an option could be added that did something like 1, 2 and 3
above, in case the user prefers native fontification for inline latex.

In any case, here is an advice that will do the trick:

(advice-add 'org-do-latex-and-related
:around (lambda (f limit)
  (cl-letf
  (((symbol-function 'font-lock-prepend-text-property)
(lambda (start end  args)
  (org-src-font-lock-fontify-block "latex"
start end
(funcall f nil

Regards
---
Carlos

Re: [O] Placement of \makeatletter with \beamer@frametextheight

[Eric S Fraga]

On Wednesday, 28 Nov 2018 at 16:09, Loris Bennett wrote:
> Hi,
>
> I want to specify the size of a graphic in an Beamer presentation
> generated from my org file.  The following
>
>   #+ATTR_LATEX: :height 0.75\textheight
>
> works, but
>
>   #+ATTR_LATEX: :height 0.75\beamer@frametextheight
>
> I get the error
>
>   ! Undefined control sequence.
>   \Gin@@eheight ->0.5\beamer 
>  @frametextheight
>
> I assume I need to insert a \makeatletter at the appropriate point.
> Where would that be?

You might find it easier to create your own variable in the header of the LaTeX 
file and use that directly, as in (untested):

#+latex_header: \makeatletter\let\mytextheight\beamer@frametexheight\makeatother

...

#+attr_latex: :height 0.75\mytextheight

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

Re: [O] Solar orbit statistics and your agenda

[Eric S Fraga]

On Tuesday, 27 Nov 2018 at 23:08, Alan E. Davis wrote:
> Eric:
>
> I was able to access the API docs (requiring, with my Firefox, to
> accept a security exception.)
>
> https://aa.usno.navy.mil/data/docs/api.php

Very useful.  Thanks.  With wget, I had to add --no-check-certificate to get 
anywhere.  Now just need to write some code to interpret the JSON output!

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

[O] Placement of \makeatletter with \beamer@frametextheight

[Loris Bennett]

Hi,

I want to specify the size of a graphic in an Beamer presentation
generated from my org file.  The following

  #+ATTR_LATEX: :height 0.75\textheight

works, but

  #+ATTR_LATEX: :height 0.75\beamer@frametextheight

I get the error

  ! Undefined control sequence.
  \Gin@@eheight ->0.5\beamer 
 @frametextheight

I assume I need to insert a \makeatletter at the appropriate point.
Where would that be?

Cheers,

Loris

-- 
This signature is currently under construction.

Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]

[Carlos Pita]

Hi Nicolas, thank you for your detailed answer!

To be honest I was wrapping my head around this until late tonight when it
all suddenly made sense and I more or less concluded the same you explained
about the role of each block and was going to say that you could indeed
dismiss this request.

Nevertheless there is one area I still believe that could be improved which
is native fontification of inline code. I almost got it by advicing
org-do-latex-and-related so that it does the equivalent of:

(org-src-font-lock-fontify-block "latex"
 (+ offset (match-beginning 0))
 (match-end 0))
;; (font-lock-prepend-text-property
;;  (+ offset (match-beginning 0)) (match-end 0)
;;  'face 'org-latex-and-related)

That correctly fontifies latex if org-highlight-latex-and-related includes
'latex. The problem is that once you break the beginning of the
environment, say by adding a space so that "\begin" -> "\be gin" or
whatever, all fontification is lost for the entire environment and never
reapplied, no matter whether it became valid latex again afterwards or not.
The next statement in org-do-latex-and-related is:

(add-text-properties (+ offset (match-beginning 0)) (match-end 0)
  '(font-lock-multiline t)))

But this doesn't seem to help keeping font locking in sync. I will dig
deeper into emacs font locking mechanism until I get this working but,
since I'm no expert, maybe you can point in the right direction and spare
me some time.

A missing feature is still not a bug, i.e., feature requests are not bug
> reports.
>

I understand this, I just followed the instructions in the manual and
thought org-submit-bug-request was intended for everything feedback
related, so sorry if I should have written directly to the list or maybe
removed the Bug: prefix in the header.

Regards
--
Carlos

Re: [O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.

[Nicolas Goaziou]

Hello,

Emmanuel Charpentier  writes:

> Close, but no cigar :
>
> I used the `customize' interface to add it to `org-latex-default-
> packages-alist' (because the package to load is compiler-dependent),

This has nothing to do with compiler. You can add it to 
`org-latex-packages-alist'.

> which becomes:
>
> (("AUTO" "inputenc" t
>   ("pdflatex"))
>  ("T1" "fontenc" t
>   ("pdflatex"))
>  (#1="" "graphicx" t nil)
>  (#1# "grffile" t nil)
>  (#1# "longtable" nil nil)
>  (#1# "wrapfig" nil nil)
>  (#1# "rotating" nil nil)
>  ("normalem" "ulem" t nil)
>  (#1# "amsmath" t nil)
>  (#1# "textcomp" t nil)
>  (#1# "amssymb" t nil)
>  (#1# "capt-of" nil nil)
>  (#1# "hyperref" nil nil)
>  (#1# "babel" t
>   ("pdflatex"))
>  (#1# "polyglossia" t
>   ("xelatex" "lualatex")))
>
> I then retried an example (similar to the first one, but another
> machine...) (see enclosed files).
>
>   * The latex file does indeed contain "\usepackage{babel}" at the end
> of preamble
>
>   * But the language is never set.
>
>   * Therefore, no "frenchizing" happens...
>
> This is due to the fact that, in order to get what I mean, the babel
> loading should be "\usepackage[frenchb]{babel}", i. e. take the value
> corresponding to whatever #+language: implies ("frenchb" for "fr",
> etc...). I do not know how to do that.

See `org-latex-classes' docstring: it should be ("AUTO" "babel" t).

>   * If this setup is necessary to get #+langiage: honored fot LaTeX
> export, this should be done by default (i. e. in org's source
> code).

AFAIR, there is no clean way to handle that, so we let users decide what
they want.

>   * One might wish to allow to fully use babel's (and polyglossia's)
> abilities by specifying a set of possible #+language:s (first
> call) or switch to another language (further calls down the
> file...).

See `org-latex-classes' docstring.

>   * concerning french: I understand that "frenchb" is obsolete and
> that one should use "french" instead (better compatibility with
> ispell and flyspell-babel, among others)...

I didn't know that. I'll fix it in master.

>   * I suggest a '(#1# "fontspec" t '(xelatex lualatex)), and possibly
> an '(#1# "mathspec" t '(xetex luatex)) or '(#1# "unicode-math" t
> '(xetex luatex))
> entry(ies) to be added to the default : xetex is more and more
> used, and luatex is officially the successor to pdftex...

I use neither xetex or luatex so I cannot comment of this.

However note that default packages should be very limited. It is easy
enough to add more of them to standard packages.

Regards,

-- 
Nicolas Goaziou

Re: [O] Possible bug in org-mode (MELPA version as of 1018-11-25) : #+language: is not (fully) honored.

[Emmanuel Charpentier]

Le mercredi 28 novembre 2018 à 00:40 +0100, Nicolas Goaziou a écrit :

> emanuel.charpent...@gmail.com writes:
>

> > Le mardi 27 novembre 2018 à 21:26 +0100, Nicolas Goaziou a écrit :
> >
> > [ Snip... ]
> >

> > > What happens if you remove "org-ref.el" reference?

> >
> > Same thing.
> >
> > Even after uninstalling org-ref and its dependencies.
> >
> > Sorry...

>
> OK. I got it. This has nothing to do with LANGUAGE keyword.
>
> Babel is not a default package, per `org-latex-default-packages-
> alist.
> You need to add it to `org-latex-packages-alist'.


Close, but no cigar :

I used the `customize' interface to add it to `org-latex-default-
packages-alist' (because the package to load is compiler-dependent),
which becomes:

(("AUTO" "inputenc" t
  ("pdflatex"))
 ("T1" "fontenc" t
  ("pdflatex"))
 (#1="" "graphicx" t nil)
 (#1# "grffile" t nil)
 (#1# "longtable" nil nil)
 (#1# "wrapfig" nil nil)
 (#1# "rotating" nil nil)
 ("normalem" "ulem" t nil)
 (#1# "amsmath" t nil)
 (#1# "textcomp" t nil)
 (#1# "amssymb" t nil)
 (#1# "capt-of" nil nil)
 (#1# "hyperref" nil nil)
 (#1# "babel" t
  ("pdflatex"))
 (#1# "polyglossia" t
  ("xelatex" "lualatex")))

I then retried an example (similar to the first one, but another
machine...) (see enclosed files).

  * The latex file does indeed contain "\usepackage{babel}" at the end
of preamble

  * But the language is never set.

  * Therefore, no "frenchizing" happens...

This is due to the fact that, in order to get what I mean, the babel
loading should be "\usepackage[frenchb]{babel}", i. e. take the value
corresponding to whatever #+language: implies ("frenchb" for "fr",
etc...). I do not know how to do that.

Is there a documented way to do that, or should I dive in ox-latex
source ?

A couple of remarks :
  * If this setup is necessary to get #+langiage: honored fot LaTeX
export, this should be done by default (i. e. in org's source
code).

  * One might wish to allow to fully use babel's (and polyglossia's)
abilities by specifying a set of possible #+language:s (first
call) or switch to another language (further calls down the
file...).

  * concerning french: I understand that "frenchb" is obsolete and
that one should use "french" instead (better compatibility with
ispell and flyspell-babel, among others)...

  * I suggest a '(#1# "fontspec" t '(xelatex lualatex)), and possibly
an '(#1# "mathspec" t '(xetex luatex)) or '(#1# "unicode-math" t
'(xetex luatex))
entry(ies) to be added to the default : xetex is more and more
used, and luatex is officially the successor to pdftex...

HTH,

--
Emmanuel Charpentier


Le mer. 28 nov. 2018 à 00:40, Nicolas Goaziou  a
écrit :

> emanuel.charpent...@gmail.com writes:
>
> > Le mardi 27 novembre 2018 à 21:26 +0100, Nicolas Goaziou a écrit :
> >
> > [ Snip... ]
> >
> >> What happens if you remove "org-ref.el" reference?
> >
> > Same thing.
> >
> > Even after uninstalling org-ref and its dependencies.
> >
> > Sorry...
>
> OK. I got it. This has nothing to do with LANGUAGE keyword.
>
> Babel is not a default package, per `org-latex-default-packages-alist.
> You need to add it to `org-latex-packages-alist'.
>
>


TstFrench.org
Description: Binary data
% Created 2018-11-28 mer. 11:48
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\usepackage{babel}
\author{Emmanuel Charpentier}
\date{Novembre 2018}
\title{Test de l'option \texttt{\#+language:}}
\hypersetup{
 pdfauthor={Emmanuel Charpentier},
 pdftitle={Test de l'option \texttt{\#+language:}},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 27.0.50 (Org mode 9.1.14)}, 
 pdflang={French}}
\begin{document}

\maketitle
\tableofcontents


\section{Pique.}
\label{sec:orgf5d6a52}

Baratin.

\section{Et pique\ldots{}}
\label{sec:orge68ddf8}

Autre baratin.

\section{Et colégram!}
\label{sec:orgf4c826b}

Troisième baratin.
\end{document}

TstFrench.pdf
Description: Adobe PDF document

Re: [O] Bug: Add option to fontify latex blocks [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]

[Nicolas Goaziou]

Hello,

Carlos Pita  writes:

> The behavior of
>
>(P) previews,
>(E) C-c ' editing and
>(F) native fontification
>
> is very inconsistent for latex:
>
> 1. $xxx$ and $$xxx$$ no (F) no (E) but (P)

I guess (E) could be added, we already do this for inline source code,
but no one bothered implementing it.

> 2. \begin{xxx}...\end{xxx} no (F) but (E) and (P)

This is consistent with 1., with the (E) feature.

> 3. #+BEGIN_EXPORT latex and #+LATEX  no (P) but (E) and (F)

This is something entirely different. #+BEGIN_EXPORT latex ...
#+END_EXPORT latex, in Org lingo, is not LaTeX #code, but raw text for
an export back-end called "latex". There is no guarantee export back-end
"latex" correspond to real LaTeX code.

You cannot expect the same behavior for apples and oranges, can you?

> The lack of features for $$...$$ is more questionable. And you can do
> \begin{displaymath}, which is exactly the same, and get (E).

A missing feature is still not a bug, i.e., feature requests are not bug
reports.

> Anyway, if there were an option for long code fragments to be
> correctly folded, fontified, edited and previewed I would pay the
> price of the "#+BEGIN_EXPORT latex" extra typing.

I'm not sure what you mean by "folded". You can see fontification and
you can edit #+begin_export latex blocks with .

There are not fontified in the Org buffer, but Org only fontifies source
blocks.

> The only problem is
> that previews are not working there. So why not activate previews
> inside export environments of latex type to get the full combo?

There may not be something to preview in the first place. More
precisely, they shouldn't contain something that can be previewed. For
that, you can use environments, e.g.
\begin{something}...\end{something}.

Regards,

-- 
Nicolas Goaziou

Re: [O] Feature request - Decouple org's keybindings from their functions

[Ihor Radchenko]

> Decoupling is not a good idea. Because it will let user define too much
> keybindings. And User can define keybinding in Emacs easily. Emacs is
> powerful for customization.

I disagree. It is against emacs philosophy.
It is one of the key features of emacs that users can redefine
keybindings if they need to (but do not have to do it).
I do not like loosing this feature without a strong reason. 

> And user need convention for Org default keybindings so that when Org
> users communications can know what he did. For example, when I said [C-c
> C-c] in Org, Every Org users know it.

You can as well say `M-x org-ctrl-c-ctrl-c` and be understood.

Best,
Ihor


stardiviner  writes:

> Decoupling is not a good idea. Because it will let user define too much
> keybindings. And User can define keybinding in Emacs easily. Emacs is
> powerful for customization.
>
> And user need convention for Org default keybindings so that when Org
> users communications can know what he did. For example, when I said [C-c
> C-c] in Org, Every Org users know it.
>
> --
> [ 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
>



signature.asc
Description: PGP signature

[O] [Need Help] I need help, someone can help me debug on this?

[stardiviner]

Check out my previous email. (Because I lost the screenshot image file...)

-- 
[ 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 - Decouple org's keybindings from their functions

[stardiviner]

Decoupling is not a good idea. Because it will let user define too much
keybindings. And User can define keybinding in Emacs easily. Emacs is
powerful for customization.

And user need convention for Org default keybindings so that when Org
users communications can know what he did. For example, when I said [C-c
C-c] in Org, Every Org users know it.

--
[ 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