Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

I'm trying to build a description-list-with-header-line by using a macro. In the non-MWE, the macro adds additional value like index entries and margin notes, but here I have the simplest case possible.

\documentclass{article}
\newcommand{\pni}[1]{\item{#1} The name of the rose\par\noindent}
\newcommand{\dbs}[1]{\item{#1} The name of the rose\\}
\begin{document}
\begin{description}
\dbs{abc def}
A book that isn't about roses.

Another paragraph
\pni{abc def}
A book that isn't about roses, either.

Another paragraph
\pni{abc def}%
A book that isn't about roses, either.

Another paragraph\end{description}
\end{document}

The first line of the description item consists of a key and title; the rest is descriptive text in paragraphs.

Now, it seems to me to be semantically better to use \par\noindent to get ready for the first paragraph of text, because this will obey 'other definitions' of paragraph-ness, as opposed to \\, which is simply a line break. But as you can see, \par\noindent introduces a spurious space at the start of the new paragraph.

enter image description here

I know I can suppress this by adding a % to my call, but I'd prefer to do this inside the macro. How?


In the light of the answers so far (with thanks and apologies to @DavidCarlisle and @egreg), here's a second MWE that more accurately reflects my case. I'm using enumitem with memoir, which I now see makes my original MWE a bit oversimplified. Here goes:

\documentclass{memoir}
\usepackage{tgpagella}
\usepackage{xparse}
\usepackage{enumitem}
\newlist{mfields}{description}{1}
\setlist[mfields]{%
    font=\bfseries\scshape,leftmargin=!,labelwidth=3.5em,
    labelsep=0.5em,itemindent=0pt,listparindent=\parindent}
\DeclareDocumentCommand{\mfield}{m m}{%
    \item[#1]#2\par}
\DeclareDocumentCommand{\xfield}{m m}{%
    \item[#1]#2\par\noindent\ignorespaces}
\begin{document}
\begin{mfields}
\mfield{abcdef}{The Name of The Rose}
A book that isn't about roses.

Another paragraph goes here etc.

\xfield{ghijkl}{The Island of the Day Before}
A book that isn't about roses, either.

Another paragraph goes here etc.

\xfield{mnopqr}{The Island of the Day Before}

A book that isn't about roses, either.

Another paragraph goes here etc.
\end{mfields}
\end{document}
share|improve this question
add comment

2 Answers

up vote 15 down vote accepted

It's a primitive feature of TeX's line breaking algorithm that glue (including glue from white space) is discarded at the beginning of the line. But \noindent starts the paragraph already so the following space token produces glue that is not discarded (as it doesn't follow a linebreak.

It would seem that you The name of the rose should be part of the list label (optional argument to \item) rather than forcing a break after it.


As noted in comments, \par\noindent has the bad effect of generating a spurious empty paragraph if a blank line follows the command, and \par\noindent\ignorespaces doesn't fix that. However in this context you have 0pt indentation anyway so a simpler definition is

\newcommand{\pni}[1]{\item{#1} The name of the rose\par}

space tokens and blank likes will be ignored after the \par and the paragraph will start with 0 width indentation.

Or if \listparindent isn't 0

\newcommand{\pni}[1]{\item{#1} The name of the rose\par\bgroup\parindent\z@\everypar{\egroup}}
share|improve this answer
    
Thanks, David, that's an interesting idea, but I think I'll go with @egreg's for now. The 'real-life' case is much more complex –  Brent.Longborough Mar 11 '13 at 22:47
3  
@Brent.Longborough the main disadvantage of using \par\noindent and why LaTeX never uses that when suppressing indentation in lists or after a section head is that it means that your text has to come immediately after your command. If you put a blank line before A book that then the \par\noindent will cause a spurious all white paragraph then you will get a paragraph and indented text. If you used the list code or \@afterheading then a blank line could be safely used in this context, just as it can after a \subsection or \item[...] –  David Carlisle Mar 11 '13 at 22:56
    
Aha! OK, I'll research 'how lists work' and report back. I appreciate the 'empty paragraph' problem. But I may still have to go with q&d for now... –  Brent.Longborough Mar 11 '13 at 22:59
    
@Brent.Longborough I updated answer with a suggestion to address the empty paragraphs. –  David Carlisle Mar 12 '13 at 15:01
    
I'm sorry, but in my more complex case, that doesn't work, as \listparindent isn't zero, so the first para is indented. ing everyone's effort so far... –  Brent.Longborough Mar 12 '13 at 15:45
show 2 more comments

Whenever you use \noindent (or \indent) at the end of a macro with arguments, it's good rule to add \ignorespaces: the space you see is due to the end of line after \pni{abc def}.

So

\newcommand{\pni}[1]{\item{#1} The name of the rose\par\noindent\ignorespaces}

is the answer.

Why doesn't it happen with \\? Because this macro has a * variant (and an optional argument, which whould sufficient by itself) and the look up for the * eats spaces. In this case it wouldn't make a difference anyway, because the space is at the start of a line.


Regarding the new example, if what you want is that the two \xfield items give the same result, that is, in the second one the blank line is ignored, you can define a \ignorespacesandpars command to be used in place of \ignorespaces.

\makeatletter
\newcommand{\ignorespacesandpars}{%
  \@ifnextchar\par{\@ignorespacesandpars}{}}
\long\def\@ignorespacesandpars#1{\noindent\ignorespacesandpars}
\makeatother

Spaces are eaten up by \@ifnextchar, while \par token will case the macro to call again itself after having get rid of \par.

share|improve this answer
2  
'tis true that \\ eats the space tokens because it looks for [ but even if you stop it doing that eg use {\\} the white space still does not get into the output as glue is discarded, so I think we're both right:-) –  David Carlisle Mar 11 '13 at 22:50
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.