Re: caption width in LateX export

[Juan Manuel Macías]

Hi Seb

Seb writes:

> When exporting to LaTeX, is there a mechanism to make the figure
> captions as wide as the figure?  In pure LaTeX, this can be easily
> accomplished by placing the figure inside a minipage environment.
> Using a special block, as in:
>
> \begin{minipage}{0.7\textwidth}
>
> #+CAPTION: looong caption.
> [[file_path]]
>
> \end{minipage}
>
> fails, as it seems impossible to pass arguments to the special block.
> Any tips welcome.

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

Best regards,

Juan Manuel 

tab at beginning of line does not indent any more

[Mandar Mitra]

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. 

Thanks,
Mandar.

caption width in LateX export

[Seb]

Hello,

When exporting to LaTeX, is there a mechanism to make the figure
captions as wide as the figure?  In pure LaTeX, this can be easily
accomplished by placing the figure inside a minipage environment.
Using a special block, as in:

\begin{minipage}{0.7\textwidth}
#+CAPTION: looong caption.
[[file_path]]
\end{minipage}

fails, as it seems impossible to pass arguments to the special block.
Any tips welcome.


--
Seb

bug#52587: 29.0.50; Wrong block header/footer background in Org

[Kévin Le Gouguec]

Protesilaos Stavrou  writes:

> On 2021-12-26, 22:04 +0100, Rudolf Adamkovič  wrote:
>
>>> - Create a file with demo content, such as ~/test-org-block.org
>>> - Execute 'emacs -Q' on the command-line.
>>> - M-x load-theme RET modus-operandi
>>> - C-x C-f test-org-block.org RET
>
> Gotcha!  I can reproduce that.  It is not a theme issue.  I checked the
> Org code a bit.  There is a function in org-compat.el called
> 'org--set-faces-extend' and in org.el we see it being used in the
> (define-derived-mode org-mode ... part.
>
> In other words, M-x org-mode wants those faces to have ':extend t'.

Only when org-fontify-whole-block-delimiter-line is set (which it is, by
default, I think).

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

[Nicolas Goaziou]

Hello,

Thanks.

Jonas Bernoulli  writes:

> +#+begin_example
> +- Key: C-n (do-something) ::
> +  This command does something.
> +
> +- User Option: do-something-somehow ::
> +  This option controls how exactly ~do-something~ does its thing.
> +#+end_example
> +
> +#+texinfo: @noindent
> +becomes
> +
> +#+begin_example
> +@table @asis
> +@item @kbd{C-c C-c} (@code{do-something})
> +@kindex C-c C-c
> +@findex do-something
> +This command does something.
> +@end table

There's a mismatch between the keys.

> +Key items don't have to specify the respective command in parenthesis
> +as done above; that part is optional.

Simply put:

Command in parenthesis, as done above, is optional.

> +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.

I think the functions responsible for generating the Texinfo code should
handle this without relying on the macro. 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?


> +(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)

> +  (while (setq item (pop contents))

nitpick: Use dolist.

> +(pcase-let ((`(,cmd . ,args) (org-texinfo--match-definition 
> item)))
> +  (cond
> +   (cmd
> +(when items
> +  (org-texinfo--split-plain-list plain-list (nreverse items))
> +  (setq items nil))
> +(org-texinfo--split-definition plain-list item cmd args))
> +   (t
> +(when args
> +  (org-texinfo--massage-key-item plain-list item args))
> +(push item items)
> +  (unless (org-element-contents plain-list)
> +(org-element-extract-element plain-list)
> +info)
> +  tree)
> +
> +(defun org-texinfo--match-definition (item)
> +  "Return a cons-cell if ITEM specifies a Texinfo definition command.
> +The car is the command and the cdr is its arguments."
> +  (let ((tag (car-safe (org-element-property :tag item
> +(and tag
> + (stringp tag)
> + (string-match org-texinfo--definition-command-regexp tag)
> + (pcase-let*
> + ((cmd (car (rassoc (match-string-no-properties 1 tag)
> + org-texinfo--definition-command-alist)))
> +  (`(,cmd ,category)
> +   (and cmd (save-match-data (split-string cmd " "
> +  (args (match-string-no-properties 2 tag)))
> +   (cons cmd (if category (concat category " " args) args))
> +
> +(defun org-texinfo--split-definition (plain-list item cmd args)
> +  "Insert a definition command before list PLAIN-LIST.
> +Replace list item ITEM with a special-block that inherits the
> +contents of ITEM and whose type and Texinfo attributes are
> +specified by CMD and ARGS."
> +  (let ((contents (org-element-contents item)))
> +(org-element-insert-before
> + (apply #'org-element-create 'special-block
> +(list :type cmd
> +  :attr_texinfo (list (format ":options %s" args))
> +  :post-blank (if contents 1 0))
> +(mapc #'org-element-extract-element contents))
> + plain-list))
> +  (org-element-extract-element item))
> +
> +(defun org-texinfo--split-plain-list (plain-list items)
> +  "Insert a new plain list before the plain list PLAIN-LIST.
> +Remove ITEMS from PLAIN-LIST and use them as the contents of the
> +new plain list."
> +  (org-element-insert-before
> +   (apply #'org-element-create 'plain-list
> +  (list :type 'descriptive :post-blank 1)
> +  (mapc #'org-element-extract-element items))
> +   plain-list))
> +
> +(defun org-texinfo--massage-key-item (plain-list item args)
> +  "In PLAIN-LIST modify ITEM based on ARGS.
> +Reformat ITEM'

bug#52587: 29.0.50; Wrong block header/footer background in Org

[Protesilaos Stavrou]

On 2021-12-26, 22:04 +0100, Rudolf Adamkovič  wrote:

> Protesilaos Stavrou  writes:
>
>> Do you get the same results?
>
> Oh, I do!  That said, if I reverse last two steps, I do not:
>
>> - Create a file with demo content, such as ~/test-org-block.org
>> - Execute 'emacs -Q' on the command-line.
>> - M-x load-theme RET modus-operandi
>> - C-x C-f test-org-block.org RET

Gotcha!  I can reproduce that.  It is not a theme issue.  I checked the
Org code a bit.  There is a function in org-compat.el called
'org--set-faces-extend' and in org.el we see it being used in the
(define-derived-mode org-mode ... part.

In other words, M-x org-mode wants those faces to have ':extend t'.

I must investigate this further, though my first impression is that we
need to notify the Org folks about it.

-- 
Protesilaos Stavrou
https://protesilaos.com

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

[Nicolas Goaziou]

Hello,

Thanks. Some comments follow.

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.

>  *** 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.

> +  (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 "+".

Anyhow, relying on mixed bullets is not great…

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] ox-icalendar.el: customizable vevent summary prefix

[Nicolas Goaziou]

Hello,

Thanks. Some comments follow.

Mikhail Skorzhinskii  writes:

> * lisp/ox-icalendar.el (org-icalendar-scheduled-summary-prepend):
> configurable prefix for the scheduled headlines

"New variable" is enough.

> * lisp/ox-icalendar.el (org-icalendar-deadline-summary-prepend):
> configurable prefix for the headlines with a deadline

Ditto.

> +(defcustom org-icalendar-scheduled-summary-prepend "S: "
> +  "String used for prepending summary in exported scheduled
> headlines."
> +  :group 'org-export-icalendar
> +  :type 'string)
> +
> +
> +(defcustom org-icalendar-deadline-summary-prepend "DL: "
> +  "String used for prepending summary in exported deadlines."
> +  :group 'org-export-icalendar
> +  :type 'string)
> +

Could you add missing :safe and :package-version keywords?

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] ox-icalendar.el: create alarm at event time

[Nicolas Goaziou]

Hello,

Mikhail Skorzhinskii  writes:

> * lisp/ox-icalendar.el (org-icalendar-force-alarm): option to set alarm
> even if alarm time is set to zero.
> * lisp/ox-icalendar.el (org-icalendar--valarm): create VALARM at the
> event start if the alarm time is set to zero and
> `org-icalendar-force-alarm' is set to true.

Thanks. Some comments follow.

> +(defcustom org-icalendar-force-alarm nil
> +  "Non-nil means alarm will be created even if is set to zero.
> +
> +This overrides default behaviour where zero means no alarm. With
 ^^^
You need two spaces after full stop.

> +this set to non-nil and alarm set to zero, alarm will be created
> +and will fire at the event start."
> +  :group 'org-export-icalendar
> +  :type 'bool)

`boolean' is the valid type.

You also need to add :package-version '(Org . "9.6") and :safe #'booleanp.
> +    (if org-icalendar-force-alarm
> +    (if alarm-time
> +    alarm-time
> +  org-icalendar-alarm-time)
> +  (if (zerop alarm-time)
> +  org-icalendar-alarm-time
> +    alarm-time))

I suggest to refactor the above into something like:

(cond
 ((> alarm-time 0) alarm-time)
 ((and (= 0 alarm-time) org-icalendar-force-alarm) alarm-time)
 (t org-icalendar-alarm-time))

Could you send an updated patch?

Regards,
-- 
Nicolas Goaziou

[PATCH] ob-maxima.el: Fix execution on MS Windows

[Nikolay Kudryavtsev]

Hello.

I've been playing around with Maxima from time to time.

Ob-maxima currently does not work on Windows due to it using single 
quotes in the Maxima invocation and those not being supported by Windows 
CMD.


After some testing I've found an invocation that seems to work fine on 
both Windows and Linux. I don't think this patch can cause any real 
issue, since the string in those quotes is just the temp file path.
From b0206d14df8947c831e56eef21fbd38ca88c1fd5 Mon Sep 17 00:00:00 2001
From: Nikolay Kudryavtsev 
Date: Sun, 26 Dec 2021 22:47:19 +0300
Subject: [PATCH] ob-maxima.el: Fix execution on MS Windows

* ob-maxima.el (org-babel-execute:maxima): Change command line
invocation to a one that should work everywhere.
---
 lisp/ob-maxima.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ob-maxima.el b/lisp/ob-maxima.el
index 7b49bb07a..512712221 100644
--- a/lisp/ob-maxima.el
+++ b/lisp/ob-maxima.el
@@ -77,7 +77,7 @@ This function is called by `org-babel-execute-src-block'."
(result
 (let* ((cmdline (or (cdr (assq :cmdline params)) ""))
(in-file (org-babel-temp-file "maxima-" ".max"))
-   (cmd (format "%s --very-quiet -r 'batchload(%S)$' %s"
+   (cmd (format "%s --very-quiet -r \"batchload(\\\"%S\\\")\"$ %s"
 org-babel-maxima-command in-file cmdline)))
   (with-temp-file in-file (insert (org-babel-maxima-expand body 
params)))
   (message cmd)
-- 
2.34.1.windows.1

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

[Rudolf Adamkovič]

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).

Rudy
-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't. That's logic.'"
-- Lewis Carroll, Through the Looking Glass

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

Re: [PATCH] org-element--current-element: Fix #+BEGIN$ parsed as special block

[Nicolas Goaziou]

Hello,

Ihor Radchenko  writes:

> Nicolas,
> Let me know if I miss something about special block parsing.

LGTM! Thanks.

Regards,
-- 
Nicolas Goaziou

bug#52778: 29.0.50; refill-mode issues in org-mode

[Kyle Meyer]

Ihor Radchenko writes:

> Eli Zaretskii  writes:
>
>>> You are right. I do not actively watch Emacs bug tracker and I had no
>>> information about Rudolf's previous reports today.
>>
>> Did you look at them now?  I meant bugs 52771 and 52772.
>
> Yes. One is fixed already.

Thanks for fixing 52772.  I've marked it as done.  (One way to do that
is appending -done to the bug number in the debbugs address:
<52772-d...@debbugs.gnu.org>.)

> The other one should probably be forwarded to
> Org ML. However, I am not sure what is the right way to redirect
> messages from Emacs bug tracker to Org ML. Usually, Kyle takes care
> about this part.

Before replying to a message, you can reassign it the "org-mode" package
by sending a message to cont...@debbugs.gnu.org.  Here's an example:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38592;msg=10

However, looking at , it's already been
assigned to the org-mode package, so the reply I've sent should go to
Org's mailing list.

bug#52771: 29.0.50; org-fill-paragraph does not work for several plain lists

[Kyle Meyer]

Rudolf Adamkovič writes:

> Reproduction steps:
>
> 1. start "emacs -Q"
> 2. type "C-x C-f" and "test.org" and RET
> 3. type the following:
>
> - one
>  two
>
> - three
>  four
>
> 4. mark all with "C-x h"
> 5. type "M-q" to fill
>
> Actual:
>
> - one
>  two
>
> - three four
>
> Expected:
>
> - one two
>
> - three four

I can trigger the same behavior on my end.  I haven't stepped through
any code or searched the mailing list for related discussion, but it
looks like a bug to me.

(Unlike the initial post, this message should be forwarded to Org's
mailing list, and I've marked it as a confirmed bug for Org's
.)

Re: [BUG] 9.5.1 cannot export specific table [9.5 (9.5-g0a86ad @ /gnu/store/qhqhlclxnqsxazs88wrmqz2vi5abcgm0-emacs-org-9.5/share/emacs/site-lisp/org-9.5/)]

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  writes:

> I tried 9.5.2, but the error is still there:
>
> org-ascii-table-cell: Wrong type argument: wholenump, -2

Oops. That commit was only on main. Not on "stable" bugfix branch.

I just cherry-picked the commit to bugfix. Sorry for the confusion.

Best,
Ihor

Re: [BUG] 9.5.1 cannot export specific table [9.5 (9.5-g0a86ad @ /gnu/store/qhqhlclxnqsxazs88wrmqz2vi5abcgm0-emacs-org-9.5/share/emacs/site-lisp/org-9.5/)]

[Dr. Arne Babenhauserheide]

"Dr. Arne Babenhauserheide"  writes:

> Ihor Radchenko  writes:
>> "Dr. Arne Babenhauserheide"  writes:
>>> In org 9.5.1 I get problems exporting a table. Trying to export
>>> https://hg.sr.ht/~arnebab/draketo/browse/politik/gnu-linux-desktop-share.org
>>> as ascii or running the embedded gnuplot source block fails with
>>> wholenump error.
>>> ...
>>> Debugger entered--Lisp error: (wrong-type-argument wholenump -2)
>>>   make-string(-2 32)
>>>   org-ascii-table-cell((table-cell (:begin 14...
>>
>> Thanks for reporting!
>>
>> It should have been fixed after 895e0baad. Can you update Org an try
>> again?
>
> I can update org once the new version is in Guix.

I tried 9.5.2, but the error is still there:

org-ascii-table-cell: Wrong type argument: wholenump, -2

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

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

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

Best,
Ihor

Re: "Orgdown", the new name for the syntax of Org-mode

[Jean-Christophe Helary]

> On Nov 29, 2021, at 8:24, Jean-Christophe Helary  
> wrote:
> 
> 
> 
>> On Nov 29, 2021, at 7:57, Tom Gillespie  wrote:
>> 
>> PS Another brainstormed name: Orgsyn?
> 
> Org Agnostic Syntax Modules → OrgASM

I understand that the issue is quite moot now (and I'm sorry for my silly 
proposal), but I just found out about "CommonMark" and I thought that if org 
syntax *had* to borrow from a markdown-esque name, then CommonOrg would 
perfectly fit the endeavor.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

[PATCH] org-element--current-element: Fix #+BEGIN$ parsed as special block

[Ihor Radchenko]

Robert Nikander  writes:

> Hitting TAB on the BEGIN line does nothing. But if I add a blank line before 
> it, then hitting TAB hides and shows the block. Is that a bug? Or am I doing 
> it wrong? Seems like it should work without the blank line.
>
> * Test
> Some text
>
> #+BEGIN 
> Hide this
> #+END
>
> M-x org-version => 9.5.1.

This last case is actually a bug. As Tomas pointed, Org blocks have
slightly different syntax: either #+begin_something or #+begin:
typeofblock. The fact that you can fold the #+BEGIN..#+END in your
second case should not happen.

The fix is attached.

Nicolas,
Let me know if I miss something about special block parsing.

Best,
Ihor

>From 289afdb9672eadaea119ebb2b0deecff4db3aa89 Mon Sep 17 00:00:00 2001
Message-Id: <289afdb9672eadaea119ebb2b0deecff4db3aa89.1640530104.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Sun, 26 Dec 2021 22:45:36 +0800
Subject: [PATCH] org-element--current-element: Fix #+BEGIN$ parsed as special
 block

* lisp/org-element.el (org-element--current-element): Use
`org-element-dynamic-block-open-re' to match blocks.

Reported in https://list.orgmode.org/ycay4s3iadegs...@tuxteam.de/T/#t
---
 lisp/org-element.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index eac39d429..ce251da38 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -4266,7 +4266,7 @@ (defun org-element--current-element (limit &optional granularity mode structure
 	((looking-at "CALL:")
 		 (beginning-of-line)
 		 (org-element-babel-call-parser limit affiliated))
-	((looking-at "BEGIN:? ")
+	((looking-at org-element-dynamic-block-open-re)
 		 (beginning-of-line)
 		 (org-element-dynamic-block-parser limit affiliated))
 	((looking-at "\\S-+:")
-- 
2.32.0

Re: [PATCH] org-agenda.el: customise outline path in echo area

[Ihor Radchenko]

"Mikhail Skorzhinskiy"  writes:

> Should I resubmit the patch in this thread? I agree with your change.

Yes. Just reply to my message with the new version of the patch.

Best,
Ihor

Re: [PATCH] org-refile.el: show refile targets with doc. title

[Ihor Radchenko]

Mikhail Skorzhinskii  writes:

> * lisp/org-refile.el (org-refile-use-outline-path): add an option
> 'title

This is an interesting idea. However, your patch may break things quite
badly. Look at `org-refile-get-location'. It expects a very specific
format for the refile targets and treats 'file/'full-file-path values
specially.

Can you add tests for your new value of org-refile-use-outline-path and
make sure that they do not fail after applying your patch?

Best,
Ihor

Re: [PATCH] org-agenda.el: customise outline path in echo area

[Mikhail Skorzhinskiy]

Glad to hear that.

Should I resubmit the patch in this thread? I agree with your change.

Thanks, Mikhail

-- 
  Mikhail Skorzhinskiy
  mskorzhins...@eml.cc

On Sun, Dec 26, 2021, at 16:44, Ihor Radchenko wrote:
> Mikhail Skorzhinskii  writes:
>
> Thanks for the patch! The addition looks reasonable to me.
>
>> +    (title (when (and file-or-title (string= file-or-title
>> 'title))
>> ...
>> +  (and file-or-title bfn (concat (if (and (string= file-or-
>> title 'title) title)
>
> (string= file-or-title 'title) will match FILE-OR-TITLE values "title"
> and 'title. I am not sure if it is what you intended to achieve.
> Probably, a simple (eq file-or-title 'title) would be sufficient.
>
> Best,
> Ihor

Re: [PATCH] org-agenda.el: customise outline path in echo area

[Ihor Radchenko]

Mikhail Skorzhinskii  writes:

Thanks for the patch! The addition looks reasonable to me.

> +    (title (when (and file-or-title (string= file-or-title
> 'title))
> ...
> +  (and file-or-title bfn (concat (if (and (string= file-or-
> title 'title) title)

(string= file-or-title 'title) will match FILE-OR-TITLE values "title"
and 'title. I am not sure if it is what you intended to achieve.
Probably, a simple (eq file-or-title 'title) would be sufficient.

Best,
Ihor

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

[Ihor Radchenko]

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')?

Thanks for reminding about `org-babel-load-languages'.
Note that `org-babel-execute-src-block' (called by
org-babel-execute-buffer) does not really use it. It just checks for
(intern (concat "org-babel-execute:" lang)).

Maybe we just should not throw an error when lang is not in
`org-babel-load-languages'? Or maybe we can check for this in
`org-babel-confirm-evaluate'.

Best,
Ihor

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

[Max Nikulin]

On 24/12/2021 05:00, Rudolf Adamkovič wrote:

Ihor Radchenko writes:


So, Org cannot distinguish between language backends that are simply
not loaded and the ones that do not define org-babel-execute:lang.


Oh, if we have this architectural limitation in place, then Org cannot
help the user, and every user will have "explain" to Org that executing
BibTeX makes no sense.  I guess we can then close this bug then!


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

bug#52587: 29.0.50; Wrong block header/footer background in Org

[Protesilaos Stavrou]

On 2021-12-26, 11:22 +0100, Rudolf Adamkovič  wrote:

> Protesilaos Stavrou  writes:
>
>> [ I will sync with emacs.git as soon as I publish the next tagged
>>   version (2.0.0).  It is a big one and the change log will take some
>>   time to prepare...  Maybe this week. ]
>
> I noticed "Update modus-themes to version 2.0.0" in the Git log.  Yet, I
> compiled Emacs today (2021-12-26), and the gray area extends
> edge-to-edge while modus-themes-org-blocks equals nil.  Perhaps I
> misunderstood your intention?

No, you did not misunderstand my intention.  Maybe something else is
going on, as I am getting the expected results.  Check the attached
screenshot.

Steps to reproduce the screenshot:

- Create a file with demo content, such as ~/test-org-block.org:

* Testing

This is a test

#+begin_src emacs-lisp
(message "Hello world")
#+end_src

* Test

- Execute 'emacs -Q' on the command-line.
- C-x C-f test-org-block.org RET
- M-x load-theme RET modus-operandi

Do you get the same results?

-- 
Protesilaos Stavrou
https://protesilaos.com

bug#52587: 29.0.50; Wrong block header/footer background in Org

[General discussions about Org-mode.]

Protesilaos Stavrou  writes:

> [ I will sync with emacs.git as soon as I publish the next tagged
>   version (2.0.0).  It is a big one and the change log will take some
>   time to prepare...  Maybe this week. ]

I noticed "Update modus-themes to version 2.0.0" in the Git log.  Yet, I
compiled Emacs today (2021-12-26), and the gray area extends
edge-to-edge while modus-themes-org-blocks equals nil.  Perhaps I
misunderstood your intention?

Rudy
-- 
"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: text after sub headings?

[Juan Manuel Macías]

Max Nikulin writes:

> It is not necessary complex layout. It is a decoration similar to
> pictures in fiction books. Unlike figures such additions are not 
> strictly important to understand material. In printed form it is like
> figures however. Insets are appropriate in particular places, but 
> tolerate some shift due to paging.

Generally, any scenario where graphic and textual content must be
distributed and managed is already complex layout. Although there are
several levels of complexity, and in many cases visual control is
necessary. In any case, TeX is not intended for (stricto sensu) layout
but for typesetting, which is where DTP programs often fail. This does
not mean that highly complex pages cannot be achieved in TeX, but the
strong point of TeX is the automation of processes and repeated
structures, while the strong point of DTP programs is visual layout
design, more focused on magazines, newspapers, posters, etc. There are
"intermediate places", and in TeX there are still unresolved issues. For
example: the possibility of working with independent text flows (for
example, create two parallel TeX processes: one for even pages and
another for odd pages) or grid typesetting (in LaTeX it is almost impossible
and in ConTeXt some advances have been made) although I am very critical
of the grid composition, which has become a plague lately.

Anyway, in order not to get too off the topic, here are a couple of
examples that I made (one of them with flowfram), exporting an inline
task to LaTeX through an ad hoc filter:

https://i.imgur.com/8ERXNWp.png

https://i.imgur.com/mpFRL9h.png

(code attached)

Best regards,

Juan Manuel 



tests.org
Description: Lotus Organizer