emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Juan Manuel Macías" <maciaschain@posteo.net>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX)
Date: Sun, 16 Oct 2022 16:33:22 +0000	[thread overview]
Message-ID: <87h703iv8t.fsf_-_@posteo.net> (raw)
In-Reply-To: <tih6ii$lvr$1@ciao.gmane.io> (Max Nikulin's message of "Sun, 16 Oct 2022 22:04:48 +0700")

Max Nikulin writes:

> The following is irrelevant to the recent changes. I have tried
>
> ---- >8 ----
> text
>
> #+begin_verse
>
> a b
> c d
>
> e f
> g h
> #+end_verse
>
> ---- 8< ----
>
> With the fix Ihor committed today I have got
>
> ---- >8 ----
> text
> \begin{verse}
> \vspace*{1em}
> a b\\\empty
> c d\\\empty
> \vspace*{1em}
> e f\\\empty
> g h\\\empty
> \end{verse}
> ---- 8< ----
>
> My expectation was
> ---- >8 ----
> \begin{verse}
> a b\\\empty
> c d
>
> e f\\\empty
> g h
> \end{verse}
> ---- 8< ----
>
> I am surprised that \vspace is added instead of empty line between 
> stanzas. Is there a reason to override LaTeX defaults? If such reason 
> exists would not it better to add
>
>      \parskip=1em plus 0.5em minus 0.25em\relax
>
> before first verse line? Is hard coded rigid vertical space acceptable 
> when high quality output is desired? \vspace before first line looks 
> like a bug. Frankly speaking, nested calls of `replace-regexp-in-string' 
> makes the code hard to read.
>
> P.S. I have not found exact citation, but I noticed a mention: Lamport 
> expected that verse environment would get negative feedback from poets.

First of all, I'm afraid that in my previous post I mixed up two
different issues: the verse block bug and my personal opinions about the
new added constant. I should have separated these topics, sorry.

I answer here what you comment about the verse blocks and later I will
open a different thread for the other issue.

Yes, you're right: that \vspace is the normal behavior of the block when
exporting to LaTeX, and it is certainly not quite correct. In LaTeX,
both the out-of-the-box verse environment and the one provided by the
'verse' package (which, typographically speaking, is the correct way to
represent verses in LaTeX) do not add a \vspace between stanzas. In the
LaTeX input the separation between stanzas is expressed by an (at least)
empty line. In fact, that space can be controlled by the verse package
with the stanzaskip \length. I remember that I commented on this anomaly
here on the list, a long time ago, but I can't find the original
message...

In my init I have redefined the verse block like this, so that there is
a white line between stanzas, not \vspace (I have also added some things
for the verse package, so that the numbering of verses is not broken).
So your example would produce a white line under \begin{verse}, not the
current \vspace, which would be irrelevant to LaTeX. But this is only a
hack:

  (defun org-latex-verse-block (verse-block contents info)
    "Transcode a VERSE-BLOCK element from Org to LaTeX.
      CONTENTS is verse block contents.  INFO is a plist holding
      contextual information."
    (let*
	((lin (org-export-read-attribute :attr_latex verse-block :lines))
	 (latcode (org-export-read-attribute :attr_latex verse-block :latexcode))
	 (cent (org-export-read-attribute :attr_latex verse-block :center))
	 (attr (concat
		(if cent "[\\versewidth]" "")
		(if lin (format "\n\\poemlines{%s}" lin) "")
		(if latcode (format "\n%s" latcode) "")))
	 (versewidth (org-export-read-attribute :attr_latex verse-block :versewidth))
	 (vwidth (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" versewidth) ""))
	 (linreset (if lin "\n\\poemlines{0}" "")))
      (org-latex--wrap-label
       verse-block
       ;; In a verse environment, add a line break to each newline
       ;; character and change each white space at beginning of a line
       ;; into a space of 1 em.  Also change each blank line with
       ;; a vertical space of 1 em.
       (format "%s\\begin{verse}%s\n%s\\end{verse}%s"
	       vwidth
	       attr
	       (replace-regexp-in-string
		"^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
		(replace-regexp-in-string
		 "\\(\\\\\\\\\n\\)+\\([ \t]*\\\\\\\\\\)+" "\n"
		 (replace-regexp-in-string
		  "\\([ \t]*\\\\\\\\\\)?[ \t]*\n" "\\\\\n"
		  (setq contents
			(if lin
			    (replace-regexp-in-string "\\(\n\\)+\\([ \t]*\n\\)+" "\\\\\\\\!\n\n"
						      contents)
			  contents)) nil t) nil t) nil t) linreset)
       info)))


  reply	other threads:[~2022-10-16 16:35 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-15 21:35 [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX Juan Manuel Macías
2022-10-16  3:24 ` Ihor Radchenko
2022-10-16 12:08   ` Juan Manuel Macías
2022-10-16 15:04 ` Max Nikulin
2022-10-16 16:33   ` Juan Manuel Macías [this message]
2022-10-17  8:54     ` Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Ihor Radchenko
2022-10-18  9:39       ` Verse block and separations Juan Manuel Macías
2022-10-17 14:48     ` Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Max Nikulin
2022-10-19 11:08     ` Max Nikulin
2022-10-19 11:24       ` Verse block and separations Juan Manuel Macías
2022-10-16 17:14   ` Line breaks and brackets in LaTeX export (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX) Juan Manuel Macías
2022-10-17  9:04     ` Ihor Radchenko
2022-10-17 11:30       ` Line breaks and brackets in LaTeX export Juan Manuel Macías
2022-10-17 11:47         ` Ihor Radchenko
2022-10-17 12:27           ` Juan Manuel Macías
2022-10-17 15:01         ` Juan Manuel Macías
2022-10-17 16:46           ` Max Nikulin
2022-10-17 18:04             ` Juan Manuel Macías
2022-10-18  4:41               ` Ihor Radchenko
2022-10-18 14:23                 ` Juan Manuel Macías
2022-10-19  3:57                   ` Ihor Radchenko
2022-10-19  5:11                     ` Max Nikulin
2022-10-19 11:16                       ` Juan Manuel Macías
2022-10-19 12:30                         ` Juan Manuel Macías
2022-10-19 17:07                           ` Max Nikulin
2022-10-20 16:55                             ` Juan Manuel Macías
2022-10-21  3:34                               ` Ihor Radchenko
2022-10-21 16:38                                 ` Max Nikulin
2022-10-21 19:32                                   ` Juan Manuel Macías
     [not found]                         ` <ac290c60-3b54-5521-eb16-82e6611dc6e2@gmail.com>
2022-10-20 17:07                           ` Juan Manuel Macías
2022-10-29  2:36                     ` Ihor Radchenko
2022-11-13 17:01                       ` Max Nikulin
2022-10-18  4:39             ` Ihor Radchenko
2022-10-19 17:12               ` Max Nikulin
2022-10-20  5:07                 ` Ihor Radchenko
2022-10-20 17:15                   ` Max Nikulin
2022-10-21  3:41                     ` Ihor Radchenko
2022-10-21 16:32                       ` Max Nikulin
2022-10-22  5:15                         ` Ihor Radchenko
2022-10-22 12:26                           ` Juan Manuel Macías
2022-10-22 15:55                           ` Max Nikulin
2022-11-01  1:51                             ` Ihor Radchenko
2022-11-01 16:07                               ` Max Nikulin
2022-11-02  6:44                                 ` Ihor Radchenko
2022-11-02  6:46                                   ` Ihor Radchenko
2022-11-02 15:27                                     ` Max Nikulin
2022-11-03  6:15                                       ` Ihor Radchenko
2022-11-03 15:00                                         ` Juan Manuel Macías
2022-11-03 15:33                                           ` Max Nikulin
2022-11-03 15:48                                             ` Juan Manuel Macías
2022-11-04  4:23                                             ` Ihor Radchenko
2022-11-04  5:40                                               ` Max Nikulin
2022-11-05  5:30                                                 ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h703iv8t.fsf_-_@posteo.net \
    --to=maciaschain@posteo.net \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).