Re: caption width in LateX export

2021-12-27 Thread Juan Manuel Macías
Sebastian P. Luque writes:

> This is great, and very interesting to learn about the BIND keyword.
>
> Thank you,

You're welcome. Of course, if you use the filter very often, it is not
necessary to include it in a document or use the bind keyword. It
would be enough to add the function to your init and the line:

(add-to-list 'org-export-filter-final-output-functions #'caption-auto-width)

In a case like this, however, I would prefer to use the other function
in Lua within LuaTeX, since two commands could be defined: one to enable
the automatic caption width and one to disable it, throughout the
document. E.g.:

#+begin_src latex
  \usepackage{luacode}

  \begin{luacode*}
function caption_width ( text )
  text = string.gsub ( text, "(\\includegraphics.+)", "\\sbox0{%1}")
  text = string.gsub ( text, "(\\caption.+)", 
"\\begin{minipage}{\\wd0}\\usebox0%1\\end{minipage}")
  return text
end
  \end{luacode*}

\newcommand\CaptionAutoWidthOn{\directlua{luatexbase.add_to_callback
  ( "process_input_buffer" , caption_width , "caption_width" )}}

\newcommand\CaptionAutoWidthOff{\directlua{luatexbase.remove_from_callback
  ( "process_input_buffer" , "caption_width" )}}
#+end_src

\CaptionAutoWidthOn

#+CAPTION: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec 
hendrerit tempor tellus 
#+ATTR_LaTeX: :width .3\linewidth
[[img.jpg]]

\CaptionAutoWidthOff

#+CAPTION: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec 
hendrerit tempor tellus
#+ATTR_LaTeX: :width .1\linewidth
[[img.jpg]]



Re: caption width in LateX export

2021-12-27 Thread Sebastian P . Luque
On Mon, 27 Dec 2021 13:28:08 +,
Juan Manuel Macías  wrote:

> Sebastian P. Luque writes:
>> Thank you, Juan.  Unfortunately, there is a price for this solution
>> as it is now impossible to name and refer to this segment as usual:

> I see. Have you tried the option with LuaTeX that I put in my other
> message? You can compile with LuaTeX also using latexmk:

> (setq org-latex-pdf-process '("latexmk -lualatex -e
> '$lualatex=q/lualatex %%O -shell-escape %%S/' %f"))

I haven't tried this yet, but it's great to know latexmk can use LuaTex.


> In any case, since this is a simple substitution, you can use also a
> function in Elisp as a final output filter[1]:

> #+BIND: org-export-filter-final-output-functions (caption-auto-width)
> #+begin_src emacs-lisp :exports results :results none

>   (defun caption-auto-width (text backend info) (when
> (org-export-derived-backend-p backend 'latex) (with-temp-buffer
> (insert text) (save-excursion (goto-char (point-min)) (while
> (re-search-forward "\\(includegraphics.+\\)" nil t) (replace-match
> "sbox0{\\1}" t nil))) (save-excursion (goto-char (point-min))
> (while (re-search-forward "\\(caption.+\\)" nil t) (replace-match
> "begin{minipage}{wd0}usebox0\\1end{minipage}" t nil)))
> (setq text (buffer-string) #+end_src

> Vid. [[fig:1]]

> #+NAME: fig:1 #+CAPTION: Lorem ipsum dolor sit amet, consectetuer
> adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere
> tellus

> #+ATTR_LaTeX: :width .3\linewidth [[my-image.jpg]]

> [1] You need to set this variable as non-nil, in order to use bind
> keywords: (setq org-export-allow-bind-keywords t)

> Hope this works,

This is great, and very interesting to learn about the BIND keyword.

Thank you,
-- 
Seb




Re: [PATCH 2/2] ox-texinfo: Define definition commands using description lists

2021-12-27 Thread Jonas Bernoulli
Nicolas Goaziou  writes:

> There's a mismatch between the keys.

Fixed.

> Simply put:
>
> Command in parenthesis, as done above, is optional.

Done.

>> +Regardless of which approach you use, you must define the =kbd= macro
>> +(see [[*Macro Replacement]]), which you can then use anywhere in the Org
>> +file:
>> +
>> +#+begin_example
>> +,#+macro: kbd (eval (let ((case-fold-search nil) (regexp (regexp-opt 
>> '("SPC" "RET" "LFD" "TAB" "BS" "ESC" "DELETE" "SHIFT" "Ctrl" "Meta" "Alt" 
>> "Cmd" "Super" "UP" "LEFT" "RIGHT" "DOWN") 'words))) (format 
>> "@@texinfo:@kbd{@@%s@@texinfo:}@@" (replace-regexp-in-string regexp 
>> "@@texinfo:@key{@@\\&@@texinfo:}@@" $1 t
>>  #+end_example
>
> Ouch. I don't think we should expect users to define this in order to
> use the feature being implemented. IOW, it should work out of the box.

Luckily that's already how it works; I just chose to not document the
fallback (done that now).  If the macro is not available, then @code{}
is used instead.

> I think the functions responsible for generating the Texinfo code should
> handle this without relying on the macro.

I tried but could not get it to work that way.  Whatever I tried
ox-texinfo insisted on breaking it by adding quotes.

I didn't go as far as to try injecting export-snippet elements into the
tree because without using org-macro-replace-all it seemed painful to do
that.  But on second thought...

Would it be okay to represent e.g. "C-c SPC" as:

   (export-snippet
(:back-end "texinfo" :value "@kbd{C-c @key{SPC}}" :post-blank 0 :parent #2))

instead of the more painful to construct:

   (export-snippet
(:back-end "texinfo" :value "@kbd{" :begin 317 :end 334 :post-blank 0 
:parent #2))
   #("C-c " 0 4
 (:parent #2))
   (export-snippet
(:back-end "texinfo" :value "@key{" :begin 338 :end 355 :post-blank 0 
:parent #2))
   #("SPC" 0 3
 (:parent #2))
   (export-snippet
(:back-end "texinfo" :value "}" :begin 358 :end 371 :post-blank 0 :parent 
#2))
   (export-snippet
(:back-end "texinfo" :value "}" :begin 371 :end 384 :post-blank 0 :parent 
#2))

> Of course, if that part is
> factored out, the macro might, in turn, make use of it.

>> +(defconst org-texinfo--definition-command-regexp
>> +  (format "\\`%s: \\(.+\\)"
>> +  (regexp-opt
>> +   (delq nil (mapcar #'cdr org-texinfo--definition-command-alist))
>> +   1))
>
> What is 1 meaning here? Do you mean t?

Yes. Done.

>> +(defun org-texinfo--separate-definitions (tree _backend info)
>> +  "Split up descriptive lists that contain Texinfo definition
>> commands."
>
> You need to document the arguments.
>> +  (org-element-map tree 'plain-list
>> +(lambda (plain-list)
>> +  (when (eq (org-element-property :type plain-list) 'descriptive)
>> +(let ((contents (org-element-contents plain-list))
>> +  item items)
>
> Nitpick: (items nil)

Done.

>> +  (while (setq item (pop contents))
>
> nitpick: Use dolist.

Err, that's what I would usually do.  Not sure why not here.

Done.

>> +(if (string-match " +(\\([^()]+\\)) *\\'" args)
>
> Could you use `rx' here?

Done.

(Not a fan personally.  IMO rx is less readable than a plain old
regexp, though that's probably just because I never took the time
to retrain myself.)

>> +(setq key (substring args 0 (match-beginning 0))
>> +  cmd (match-string 1 args))
>> +  (setq key args))
>> +(org-element-put-property
>> + item :tag
>> + (nconc (if (assoc "kbd" org-macro-templates)
>> +(let ((templates org-macro-templates))
>> +  (with-temp-buffer
>> +(insert (format "{{{kbd(%s)}}}" key))
>
> Here, there could be a function building the key chord, and you could
> wrap the result into a raw string (see `org-export-raw-string').

I think that is one of the things I tried that ox-texinfo insisted on
quoting anyway.  I might misremember, so I will have another look.
Above I suggested using an `export-snippet' element (instead of `raw');
to me that seems appropriate too.

 Cheers,
 Jonas



Re: [PATCH 1/2] ox-texinfo: Turn a description list item with "+" bullet into @itemx

2021-12-27 Thread Jonas Bernoulli
Nicolas Goaziou  writes:

> Hello,
>
> Thanks. Some comments follow.

Thanks for the review!

> Jonas Bernoulli  writes:
>
>> +In description lists the used bullet is significant when exporting to
>> +Texinfo; when in doubt, then use =-=.  An item that uses =+= instead
>> +becomes a new entry in the first column of the table.  The above
>> +output can also be produced with:
>>  
>>  #+begin_example
>> -#+ATTR_TEXINFO: :enum A
>> -1. Alpha
>> -2. Bravo
>> -3. Charlie
>> +,#+attr_texinfo: :table-type vtable :indic asis
>> +- foo ::
>> ++ bar ::
>> +  This is the common text for foo and bar.
>>  #+end_example
>
> The above is fragile, because pressing  on an item will
> "repair" the bullets. Therefore, you cannot support mixed bullets in the
> same list.

The alternative also isn't great (see below).

I vaguely remember having run into this feature before when using Org to
record a pros and cons list.  As a maintainer I don't like this question
but; could this feature be made optional?  (Of course one could use tags
to indicate whether an item is a pro or cons, but for such a simple use-
case that seems more work than necessary and less immediately obvious.)

>>  *** Tables in Texinfo export
>> diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
>> index b0125894a..35862357d 100644
>> --- a/lisp/ox-texinfo.el
>> +++ b/lisp/ox-texinfo.el
>> @@ -418,6 +418,11 @@ (defun org-texinfo--filter-section-blank-lines 
>> (headline _backend _info)
>>"Filter controlling number of blank lines after a section."
>>(replace-regexp-in-string "\n\\(?:\n[ \t]*\\)*\\'" "\n\n" headline))
>>  
>> +(defun org-texinfo--filter-parse-tree (tree backend info)
>> +  "Normalize headlines and items."
>> +  (org-texinfo--normalize-headlines tree backend info)
>> +  (org-texinfo--normalize-items tree info))
>
> Could you expound the docstring? Arguments are missing, and "normalize"
> is vague.

This bothered me a bit too when writing it but at the same time
it seemed like overkill to replicate the docstrings of the called
functions.  How do you feel about using a hook instead?

(defvar org-texinfo--filter-parse-tree-functions
  '(org-texinfo--normalize-headlines
org-texinfo--normalize-items)
  "List of functions the `texinfo' back-end applies to the parsed tree.
Each filter is called with three arguments: the parse tree, as
returned by `org-element-parse-buffer', the back-end, as
a symbol, and the communication channel, as a plist.  It must
return the modified parse tree to transcode.")

Do you prefer to add the hook functions as done above or should each one
be added individually using add-hook?

>> +  (org-element-map tree 'plain-list
>> +(lambda (plain-list)
>> +  (when (eq (org-element-property :type plain-list) 'descriptive)
>> +(let ((contents (org-element-contents plain-list)))
>> +  (while (setq item (pop contents))
>> +(let ((next-item (car contents)))
>> +  (when (and next-item
>> + (equal (org-element-property :bullet next-item) "+ 
>> "))
>
> The above will fail if `org-list-two-spaces-after-bullet-regexp' is
> non-nil. You should compare the trimmed bullet with "+".

Done.  Is this okay?:

  (when (and next-item
 (string-prefix-p
  "+"
  (org-element-property :bullet next-item)))

Or should the line-breaks go elsewhere?

> Anyhow, relying on mixed bullets is not great…

The alternative isn't great either.

For example:

- Key: C-c C-w (forge-browse-TYPE) ::
+ Key: C-c C-w (forge-browse-dwim) ::
+ Key: N b I (forge-browse-issues) ::
+ Key: N b P (forge-browse-pullreqs) ::
+ Key: N b t (forge-browse-topic) ::
+ Key: N b i (forge-browse-issue) ::
+ Key: N b p (forge-browse-pullreq) ::

  These commands visit the topic, issue(s), pull-request(s), post,
  branch, commit, or remote at point in a browser. ...

vs.

- Key: C-c C-w (forge-browse-TYPE), C-c C-w (forge-browse-dwim), N b I 
(forge-browse-issues), N b P (forge-browse-pullreqs), N b t 
(forge-browse-topic), N b i (forge-browse-issue), N b p (forge-browse-pullreq) 
::

  These commands visit the topic, issue(s), pull-request(s), post,
  branch, commit, or remote at point in a browser. ...

I am sure I am gonna make mistakes when using the latter approach.

 Cheers,
 Jonas



Re: caption width in LateX export

2021-12-27 Thread Juan Manuel Macías
Sebastian P. Luque writes:

> Thank you, Juan.  Unfortunately, there is a price for this solution as
> it is now impossible to name and refer to this segment as usual:

I see. Have you tried the option with LuaTeX that I put in my other
message? You can compile with LuaTeX also using latexmk:

(setq org-latex-pdf-process
  '("latexmk -lualatex -e '$lualatex=q/lualatex %%O -shell-escape %%S/' 
%f"))

In any case, since this is a simple substitution, you can use also a
function in Elisp as a final output filter[1]:

#+BIND: org-export-filter-final-output-functions (caption-auto-width)
#+begin_src emacs-lisp :exports results :results none
  (defun caption-auto-width (text backend info)
(when (org-export-derived-backend-p backend 'latex)
  (with-temp-buffer
(insert text)
(save-excursion
  (goto-char (point-min))
  (while (re-search-forward "\\(includegraphics.+\\)" nil t)
(replace-match "sbox0{\\1}" t nil)))
(save-excursion
  (goto-char (point-min))
  (while (re-search-forward "\\(caption.+\\)" nil t)
(replace-match 
"begin{minipage}{wd0}usebox0\\1end{minipage}" t nil)))
(setq text (buffer-string)
#+end_src

Vid. [[fig:1]] 

#+NAME: fig:1
#+CAPTION: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec 
hendrerit tempor tellus. Donec pretium posuere tellus
#+ATTR_LaTeX: :width .3\linewidth
[[my-image.jpg]]

[1] You need to set this variable as non-nil, in order to use bind
keywords: (setq org-export-allow-bind-keywords t)

Hope this works,

Best regards,

Juan Manuel 



Re: tab at beginning of line does not indent any more

2021-12-27 Thread Jose A. Ortega Ruiz
On Mon, Dec 27 2021, Mandar Mitra wrote:

> I have org 20210929 installed. 
>
> With emacs -Q and (package-initialize) evaluted in the *scratch*
> buffer, I see the following change in behaviour:
>
> * ABCD
> 
>
>
>
> I'm fairly sure that, before the last upgrade, I used to get 
>
> * ABCD
>   
>
>
> Have other users observed this? Are you bothered by it? Is this a bug
> or a feature? Note I'm running with emacs -Q for the above, but I get
> the same behaviour with org-cycle-emulate-tab set to t or white. The
> information I found on the net seems to pertain to much older
> versions.

i was surprised by this (new?) behaviour too.  in my case, i "fixed" it
with

  (setq org-adapt-indentation t)

if memory serves, i found about this variable in the info manual.

hope this helps,
jao
-- 
In this world, there are only two tragedies.  One is not getting
what one wants, and the other is getting it. - Oscar Wilde




Re: caption width in LateX export

2021-12-27 Thread Sebastian P . Luque
On Mon, 27 Dec 2021 07:41:59 +,
Juan Manuel Macías  wrote:

[...]

> If you use the caption package (https://www.ctan.org/pkg/caption), you
> can indicate in each figure the width of the caption. In this case,
> you would have to introduce the code using raw latex via the
> `:caption' property:

> #+LaTeX_Header: \usepackage{caption}

> #+ATTR_LaTeX: :caption \captionsetup{width=.3\linewidth}\caption{Lorem
> ipsum dolor sit amet, consectetuer adipiscing elit} #+ATTR_LaTeX:
> :width .3\linewidth [[file_path]]

Thank you, Juan.  Unfortunately, there is a price for this solution as
it is now impossible to name and refer to this segment as usual:

#+LATEX_HEADER: \usepackage{caption}

See [[fig1]].

#+NAME: fig1
#+ATTR_LATEX: :caption \captionsetup{width=0.5\textwidth}\caption{Lorem ipsum 
dolor sit amet, consectetuer adipiscing elit}
[[file_path]]

leads to this (I compile with latexmk):

Latexmk: Summary of warnings from last run of *latex:
  Latex failed to resolve 1 reference(s)


-- 
Seb




Re: test-org/auto-repeat-maybe depends on locale

2021-12-27 Thread Axel Kielhorn



> Am 26.12.2021 um 16:03 schrieb Ihor Radchenko :
> 
> Axel Kielhorn  writes:
> 
>> I have just installed Org mode 9.5 and get a few failing tests:
>> 
>> Which LANG = de_DE.UTF-8 I get:
>> 
>> But which LANG = C I get:
> 
> I am unable to reproduce both the failures on my side

Neither can I with current org.
Somehow it got fixed, whatever it was.


Greetings
Axel




bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

2021-12-27 Thread General discussions about Org-mode.
Max Nikulin  writes:

> Let's consider the following example:
>
>  >8 
> Test
>
> #+begin_src elisp
>(message "Test")
> #+end_src
>  8< -
>
> emacs -Q -L ~/src/org-mode/lisp/ --eval "(custom-set-variables 
> '(org-babel-load-languages '((emacs-lisp . nil" babel-exec.org
>
> Do you agree that "No org-babel-execute function for elisp!" is a 
> reasonable reaction to `org-babel-execute-buffer`?

The user did ask Org to load "emacs-lisp" but to never execute it.
Thus, I would expect Org to do just that.  What do you think?

-- 
"Logic is a science of the necessary laws of thought, without which no
employment of the understanding and the reason takes place." -- Immanuel
Kant, 1785

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia





Re: tab at beginning of line does not indent any more

2021-12-27 Thread Mandar Mitra
On Mon, Dec 27 2021, Jose A. Ortega Ruiz wrote:
> On Mon, Dec 27 2021, Mandar Mitra wrote:
> i was surprised by this (new?) behaviour too.  in my case, i "fixed" it
> with
> 
>   (setq org-adapt-indentation t)
> 
> if memory serves, i found about this variable in the info manual.
> 
> hope this helps,

Yes, this fixed the problem for me too, thanks very much!

In hindsight, seems to me that this may have been intended for people who write 
LaTeX (or other documents) using org-mode.



Re: Report error in scheme evaluation

2021-12-27 Thread Felipe Lema
I just realized I was un-CCed out of the thread

Here's the updated patch with the requested changes (actually single one)

Lemme know if I'm missing anything else.

Felipediff --git a/lisp/org/ob-scheme.el b/lisp/org/ob-scheme.el
index f4836b23fe..8720bd099e 100644
--- a/lisp/org/ob-scheme.el
+++ b/lisp/org/ob-scheme.el
@@ -39,6 +39,7 @@
 
 ;;; Code:
 (require 'ob)
+(require 'subr-x)
 (require 'geiser nil t)
 (require 'geiser-impl nil t)
 (defvar geiser-repl--repl) ; Defined in geiser-repl.el
@@ -58,6 +59,7 @@ geiser-repl-window-allow-split
 (declare-function geiser-repl-exit "ext:geiser-repl" ( arg))
 (declare-function geiser-eval--retort-output "ext:geiser-eval" (ret))
 (declare-function geiser-eval--retort-result-str "ext:geiser-eval" (ret prefix))
+(declare-function geiser-eval--retort-error "ext:geiser-eval" (ret))
 
 (defcustom org-babel-scheme-null-to 'hline
   "Replace `null' and empty lists in scheme tables with this before returning."
@@ -180,8 +182,20 @@ org-babel-scheme-execute-with-geiser
 	  (setq result (if output
 			   (or (geiser-eval--retort-output ret)
    "Geiser Interpreter produced no output")
-			 (geiser-eval--retort-result-str ret "")
-	  (when (not repl)
+			 (geiser-eval--retort-result-str ret "")))
+  (when-let* ((err (geiser-eval--retort-error ret)))
+;; there was an error, report it!
+(org-babel-eval-error-notify
+ -1 ;; filler value, anything non-zero should do
+ (geiser-eval--retort-output ret))
+(save-excursion
+  (when (get-buffer org-babel-error-buffer-name)
+(with-current-buffer org-babel-error-buffer-name
+  (unless (derived-mode-p 'compilation-mode)
+(compilation-mode))
+  ;; Compilation-mode enforces read-only, but Babel expects the buffer modifiable.
+  (setq buffer-read-only nil)))
+  (when (not repl)
 	(save-current-buffer (set-buffer repl-buffer)
  (geiser-repl-exit))
 	(set-process-query-on-exit-flag (get-buffer-process repl-buffer) nil)


Re: caption width in LateX export

2021-12-27 Thread Juan Manuel Macías
P.S.: I have come up with another possibility, more automatic, on the
LaTeX side, if you compile with LuaTeX. This thread
(https://tex.stackexchange.com/questions/202046/width-of-the-caption-of-a-figure),
where someone proposes to use a \savebox for concrete images, gave me
the idea. We can automate that through a simple function in Lua, and add
it to the `process_input_buffer' callback, in order to the caption
*always* has the width of each image:

You can put this in your Org document:

#+NAME: luacode
#+begin_src latex :exports none
\usepackage{luacode}

\begin{luacode*}
  function caption_width ( text )
  text = string.gsub ( text, "(\\includegraphics.+)", "\\sbox0{%1}")
  text = string.gsub ( text, "(\\caption{.+})", 
"\\begin{minipage}{\\wd0}\\usebox0%1\\end{minipage}")
  return text
  end
\end{luacode*}

\newcommand\CaptionAutoWidth{\directlua{luatexbase.add_to_callback
( "process_input_buffer" , caption_width , "caption_width" )}}

\AtBeginDocument{\CaptionAutoWidth}
#+end_src

#+begin_src latex :noweb yes :results raw
,#+LaTeX_HEADER: <>
#+end_src

And then:

#+CAPTION: Lorem ipsum dolor sit amet, consectetuer adipiscing elit
#+ATTR_LaTeX: :width .3\linewidth
[[img]]

Best regards,

Juan Manuel 

Juan Manuel Macías writes:

> If you use the caption package (https://www.ctan.org/pkg/caption), you
> can indicate in each figure the width of the caption. In this case, you
> would have to introduce the code using raw latex via the `:caption'
> property:
>
> #+LaTeX_Header: \usepackage{caption}
>
> #+ATTR_LaTeX: :caption \captionsetup{width=.3\linewidth}\caption{Lorem ipsum 
> dolor sit amet, consectetuer adipiscing elit}
> #+ATTR_LaTeX: :width .3\linewidth
> [[file_path]]



bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks

2021-12-27 Thread Max Nikulin
I am sorry that I sent previous message to emacs-orgmode list only, not 
to debbugs.


On 27/12/2021 02:51, Rudolf Adamkovič wrote:

Max Nikulin writes:


Rudolf, do have support BibTeX as babel language loaded to Org (by
customization of `org-babel-load-languages' or by explicit `require')?


I have it listed in org-babel-do-load-languages as (bibtex . nil).


Let's consider the following example:

 >8 
Test

#+begin_src elisp
  (message "Test")
#+end_src
 8< -

emacs -Q -L ~/src/org-mode/lisp/ --eval "(custom-set-variables 
'(org-babel-load-languages '((emacs-lisp . nil" babel-exec.org


Do you agree that "No org-babel-execute function for elisp!" is a 
reasonable reaction to `org-babel-execute-buffer`?