From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.text.pandoc/13566 Path: news.gmane.org!not-for-mail From: Daniel Staal Newsgroups: gmane.text.pandoc Subject: Re: Specifying location of bibliography in document Date: Tue, 01 Sep 2015 15:31:19 -0400 Message-ID: References: <20150829140403.GA47273@MacBook-Air.local> <20150829142113.GA47586@MacBook-Air.local> <55E35446.2000009@web.de> <55E498FA.90500@web.de> <13393D201344655C5B10B6A5@[192.168.1.50]> <55E5E686.10900@web.de> Reply-To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1441135896 21198 80.91.229.3 (1 Sep 2015 19:31:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Sep 2015 19:31:36 +0000 (UTC) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-X-From: pandoc-discuss+bncBCGYLPE23UARBCH2S6XQKGQEETQMYVQ-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Tue Sep 01 21:31:21 2015 Return-path: Envelope-to: gtp-pandoc-discuss@m.gmane.org Original-Received: from mail-pa0-f59.google.com ([209.85.220.59]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZWrH6-00004w-TS for gtp-pandoc-discuss@m.gmane.org; Tue, 01 Sep 2015 21:31:21 +0200 Original-Received: by pacfy2 with SMTP id fy2sf1600986pac.0 for ; Tue, 01 Sep 2015 12:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding:content-disposition :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:sender:list-subscribe:list-unsubscribe; bh=Sw5tpjWQmRBfL2ITe+YJCv9R3QC7kh6v1w9BKO3954o=; b=fjSmhnVAprusG28VZM74DnT/K/YUFT6IKDJAM81F9Y72TraBXbqAch4y6SXSKprH6C eHNp5u3yE4wLYnh8WUoNlDBSDFuAzX6tgl7C6NFAuckCLrkHNl+TW0lBNHHTmE1X4WyB HycgxwX+cNIYiQ3gLvDHUxeZraS3dCTWkGyRyJ7eu4tVBpqPU5vaLTGxuulixE6s0rVu 7xtUy8TivXaWe6MIjNDXRnrXeR0o9WOck612OqtYHrhPEY2E3Iweuxp4CY1a/oCebpdO v/XpBI59QFv3oQpFycizuGgh3xUi51xWE0+zNOrkoAiWAsDZ6D5xvmlcn9XTE6 X-Received: by 10.50.98.99 with SMTP id eh3mr83006igb.0.1441135880556; Tue, 01 Sep 2015 12:31:20 -0700 (PDT) X-BeenThere: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-Received: by 10.51.17.35 with SMTP id gb3ls9041igd.39.gmail; Tue, 01 Sep 2015 12:31:19 -0700 (PDT) X-Received: by 10.66.131.4 with SMTP id oi4mr19116820pab.16.1441135879911; Tue, 01 Sep 2015 12:31:19 -0700 (PDT) Original-Received: from mail.magehandbook.com (173-8-4-45-WashingtonDC.hfc.comcastbusiness.net. [173.8.4.45]) by gmr-mx.google.com with ESMTP id r124si938188ywb.0.2015.09.01.12.31.19 for ; Tue, 01 Sep 2015 12:31:19 -0700 (PDT) Received-SPF: neutral (google.com: 173.8.4.45 is neither permitted nor denied by domain of DStaal-Jdbf3xiKgS8@public.gmane.org) client-ip=173.8.4.45; Original-Received: from [192.168.1.50] (Mac-Pro.magehandbook.com [192.168.1.50]) by mail.magehandbook.com (Postfix) with ESMTP id 3n5JRW31TnzT0 for ; Tue, 1 Sep 2015 15:31:19 -0400 (EDT) In-Reply-To: <55E5E686.10900-S0/GAf8tV78@public.gmane.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-Disposition: inline X-Original-Sender: DStaal-Jdbf3xiKgS8@public.gmane.org X-Original-Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 173.8.4.45 is neither permitted nor denied by domain of DStaal-Jdbf3xiKgS8@public.gmane.org) smtp.mailfrom=DStaal-Jdbf3xiKgS8@public.gmane.org; dmarc=fail (p=NONE dis=NONE) header.from=usa.net Precedence: list Mailing-list: list pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org; contact pandoc-discuss+owners-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-ID: X-Spam-Checked-In-Group: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org X-Google-Group-Id: 1007024079513 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Xref: news.gmane.org gmane.text.pandoc:13566 Archived-At: (Trimmed) --As of September 1, 2015 7:55:18 PM +0200, Pablo Rodr=C3=ADguez is alleged= to=20 have said: > On 08/31/2015 09:29 PM, Daniel Staal wrote: >> --As of August 31, 2015 8:12:10 PM +0200, Pablo Rodr=C3=ADguez is allege= d to >> have said: >>> Sorry, but I gave up trying to explain pandoc (or Markdown) to anyone. = I >>> was writing a manual in Spanish, but I=E2=80=99m afraid Markdown is too >>> complicated to explain to people with no background in text tagging. >>> >>> Probably I=E2=80=99m wrong in expecting that pandoc could replace word >>> proccessing programs for average users. >> >> Probably true. There are Markdown editors that aim for that market, but >> pandoc isn't an editor. It's a converter. The editors give you a nice >> WYSWYG interface, or at least something close, and give easy shortcuts >> to common markup. > > Many thanks for your reply, Daniel. > > The problem with visual editors is that users many not know what they > are actually doing. > > In that case, I think there is no gain in using pandoc. There is some gain - the markup is structurally simpler than many others,= =20 and it's more cross-platform and widely specified. Basically, you get a=20 more compatible and easier to work with file, even if the users don't=20 directly deal with it. >> Except the only actual section divisions we have are divs. Headers >> don't create new sections. (Well, there is an option to make them >> create such, but semantically and under normal use I've often seen >> headers within a section; sub-sections, or just breaking up the flow of >> the text.) They often are placed at the start of new sections, but not >> always. > > It may be my own approach to sections and their titles. Being able to > wrap a section with title and contents into a division is essential to > format chapters (or other sections) such as copyright, dedication, > epigraph and colophon pages as different from other chapters. True, but that's not the only way they are used, just the most common,=20 especially in longer works. >>> Extra paragraphs could be added as explained. And hidding a title shoul= d >>> be an easy task. >> >> Yes, but it'd be confusing, and inconsistent. ;) This 'visible' marker >> (which makes things *more* visible) in one case would now hide the text >> instead. Depending on what the text was, basically. Which will >> eventually surprise someone. >> >> (And note that with the above mentioned option to make headers >> automatically create divs, you could still use your version of the >> markup.) > > My comments don=E2=80=99t make sense now, because the implemented solutio= n > allows to add text both before and after the bibliography. I hadn=E2=80= =99t > thought of that possibility. > > My comment now is to avoid using XML syntax, since it is harder for > newcomers. Yeah, there's was a lot of discussion over the HTML syntax. (It's more=20 HTML than XML, really, even though HTML is basically a subset.) And other= =20 syntaxes... Basically, no one could agree on what a more Markdown-like syntax was, and= =20 since Markdown passes through HTML syntax a temporary solution was to=20 enable reading of the HTML. If someone can come up with a good Markdown=20 syntax for divs and spans I think John's still open to adopting it, but the= =20 current syntax doesn't prevent that and it *was* agreed that divs and spans= =20 were needed. So, to sum up: This works, and if you have a good idea for what the syntax= =20 for a div or a span *should* be, we're all ears. ;) >>> The problem I see with Markdown (and I=E2=80=99m afraid CommonMark does= n=E2=80=99t >>> solve it) is that markup is inconsistent for ordinary people. >>> >>> The simplest rule: paragraphs are formed by consecutive non-empty lines= . >>> Only a blank line builds a new paragraph. Well, and what happens with >>> titles? >> >> I honestly think you're over-thinking this. > > It may be. My fundamental mistake may be be trying to make sense of > Markdown as lightweight markup. > >> Titles aren't paragraphs; they are a single line of text. *Don't* try >> to explain them in terms of paragraphs. Simply say that a titles are a >> single line of text marked up in one of the ways that denotes a title. > > It was only a minor issue. But do you really think that there is a need > to limit titles to a single line? In other words, does this exception > make sense? > > I=E2=80=99m not trying to change it (mainly because of backwards compatib= ility), > but I don=E2=80=99t see any reason to handle titles as block elements in = a > different way from paragraphs (in regard to this rule). Well, first off, they aren't really titles. They are *headings.* (There's= =20 only one title per document, after all...) And part of this is explained= =20 by Markdown's roots as a text-to-html converter; HTML heading elements are= =20 block elements that can't contain other block elements (like paragraphs),= =20 so it was basically assumed. But in general, I can see your point. There's no real reason to assume a= =20 heading is any specific length. Practically, you don't want a heading=20 that's to long because most people won't read it, but that doesn't=20 necessarily mean we should limit it. On the other hand, *most* titles are something that will fit into one easy= =20 line. (And note that Pandoc doesn't limit the length of a line...) One of= =20 the things I like about Pandoc is that it's a 90% solution - it doesn't try= =20 to cover every last possible variation, if that would unnecessarily=20 complicate the markup. Keeping headings to one line makes the markup=20 simple and easy to read, and covers 95+ percent of actual use, so it may=20 not be worth complicating the markup just to cover a few more final percent= =20 of use-cases. If you really need some fancy long multi-line title, you=20 probably will want it laid out and viewed in a specific way for your use,= =20 and there are usually programs specifically designed for that use that you= =20 can do that with. (Even if you are giving up the convertablity and ease of= =20 use of Markdown.) Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- --=20 You received this message because you are subscribed to the Google Groups "= pandoc-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/= pandoc-discuss/FCFE2CE2278E42B31A8E30AE%40%5B192.168.1.50%5D. For more options, visit https://groups.google.com/d/optout.