From: Ethan Ligon <firstname.lastname@example.org> To: email@example.com Subject: Re: [PATCH] Problem with html export of description list items Date: Thu, 7 Apr 2011 21:52:51 +0000 (UTC) [thread overview] Message-ID: <loom.20110407T234130firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> Nic- Nicolas Goaziou <n.goaziou <at> gmail.com> writes: > > Ethan Ligon <ligon <at> are.berkeley.edu> writes: > >> > >> I've just stumbled across what I regard as a bug in the html export of > >> description list items. > >> > >> The problem has to do with whether the specification of a description > >> list includes a trailing space or not; i.e., whether "- Item ::" is > >> treated the same way as "- Item :: ". LaTeX export treats these as > >> identical. Html export gets confused about what the description list > >> item is, and winds up generating a "???" for the description. > > LaTeX exporter doesn't treats these as identical. What happens is that > in your example, the first item is correct and the list is thus set as > a description list. As such, LaTeX exporter tries hard to fill > description terms for every item in the list. If you exchange the first > and second items in your example, the list will be exported as > a standard itemize list in LaTeX. <snip> > Your patch allows items like: > > - term ::description > > which are not valid for a description list. Thanks for correcting my misunderstanding of the latex-export behavior. But I still think this behavior is undesirable. The org manual says that a description item takes the form '- term :: ', and thus seems to require a space after the double colon. I suppose it's this that you're relying on in claiming that "- term ::description" is invalid. I agree that "- term ::description" is ugly, but the use-case that is giving me problems is something like - term :: 1. A list 2. Providing 3. The description The html export code currently allows "- term ::[ \t]+", so the above breaks unless there's a space or a tab following the "::". My issue would be addressed if we could just slightly expand the set of allowable white space following, so that we'd have "::[ \t\n]+". Does that seem reasonable? Thanks, -Ethan
next prev parent reply other threads:[~2011-04-07 21:53 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-04-06 0:07 [Bug] " Ethan Ligon 2011-04-06 0:38 ` [PATCH] " Ethan Ligon 2011-04-07 12:51 ` Nicolas Goaziou 2011-04-07 21:52 ` Ethan Ligon [this message] 2011-04-08 11:53 ` Nicolas Goaziou 2011-04-08 17:46 ` [PATCH] Fix for html & docbook " Ethan Ligon 2011-04-09 3:19 ` [PATCH] Problem with html " Ethan Ligon
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=loom.20110407T234130firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] Problem with html export of description list items' \ /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
Code repositories for project(s) associated with this 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).