From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.text.pandoc/7119 Path: news.gmane.org!not-for-mail From: BP Jonsson Newsgroups: gmane.text.pandoc Subject: Re: syntax for generic spans and divs Date: Sat, 24 Aug 2013 17:47:17 +0200 Message-ID: <5218D585.20702@gmail.com> References: <20130814174642.GA28736@protagoras.phil.berkeley.edu> <520DF300.7030807@gmail.com> <35fe9b44-eb55-4b24-ad68-c958718684e7@googlegroups.com> <569131ac-aae7-4237-9745-133133ce72f5@googlegroups.com> <20130819171309.GI563@dhcp-128-32-252-6.lips.berkeley.edu> Reply-To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1377359239 31618 80.91.229.3 (24 Aug 2013 15:47:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Aug 2013 15:47:19 +0000 (UTC) To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-X-From: pandoc-discuss+bncBCWMVYEK54FRBCNL4OIAKGQEU33XKXI-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Sat Aug 24 17:47:23 2013 Return-path: Envelope-to: gtp-pandoc-discuss@m.gmane.org Original-Received: from mail-bk0-f55.google.com ([209.85.214.55]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VDG3e-0001qP-Jz for gtp-pandoc-discuss@m.gmane.org; Sat, 24 Aug 2013 17:47:22 +0200 Original-Received: by mail-bk0-f55.google.com with SMTP id mz12sf343325bkb.10 for ; Sat, 24 Aug 2013 08:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type:content-transfer-encoding; bh=rtK1tj7A3KMvbNm8zhPILNM0Q4zGCfhT/9TXiTzdfJ8=; b=e1EfWQ7MEUkdFmIRuiAoWUM5pStV8pOWn4j7VM6cOP+8csc4GTc85nrvppJScxMl4W kVGy8zXdGLRYV/Yo+tvKJJabSxNKRb/ClQ7NPCCknTYFMpV8cpkatvzne6bw+0sV/q2Y LWyBs7kYGgvuL/NMxlgVtM83rGFAmeLrQ+nKgg+PODkrZ5VtwnYU38/y/g500EfIrmoC bYy8pebzCUTMPFAHit4shWE4EoObSGAjC/Io1bALT/RgvmGIpxLLGxvkGUZ6sX9ZTQYl HTZ8brE3VyXrJYlnZzErF2KbEdJFOObIekJLRMEOJZQmKkucAuDNVcuoIoszdvIOrtsy LQYA== X-Received: by 10.180.13.145 with SMTP id h17mr57559wic.16.1377359242306; Sat, 24 Aug 2013 08:47:22 -0700 (PDT) X-BeenThere: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-Received: by 10.181.11.200 with SMTP id ek8ls609343wid.10.gmail; Sat, 24 Aug 2013 08:47:21 -0700 (PDT) X-Received: by 10.204.238.194 with SMTP id kt2mr337645bkb.6.1377359241513; Sat, 24 Aug 2013 08:47:21 -0700 (PDT) Original-Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [2a00:1450:4010:c04::235]) by gmr-mx.google.com with ESMTPS id ra8si327527bkb.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Aug 2013 08:47:21 -0700 (PDT) Received-SPF: pass (google.com: domain of melroch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org designates 2a00:1450:4010:c04::235 as permitted sender) client-ip=2a00:1450:4010:c04::235; Original-Received: by mail-lb0-f181.google.com with SMTP id u14so355027lbd.26 for ; Sat, 24 Aug 2013 08:47:21 -0700 (PDT) X-Received: by 10.112.172.137 with SMTP id bc9mr4128779lbc.21.1377359240940; Sat, 24 Aug 2013 08:47:20 -0700 (PDT) Original-Received: from [192.168.1.33] ([178.249.150.103]) by mx.google.com with ESMTPSA id l1sm2085694lbj.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Aug 2013 08:47:19 -0700 (PDT) Original-Sender: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 In-Reply-To: <20130819171309.GI563-0VdLhd/A9Pm0ooXD8Eul3adDtQfY2H3paxvHy9gZ5WyVc3sceRu5cw@public.gmane.org> X-Original-Sender: melroch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of melroch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org designates 2a00:1450:4010:c04::235 as permitted sender) smtp.mail=melroch-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; dkim=pass header.i=@gmail.com Precedence: list Mailing-list: list pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org; contact pandoc-discuss+owners-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-ID: X-Google-Group-Id: 1007024079513 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.text.pandoc:7119 Archived-At: 2013-08-19 19:13, John MacFarlane skrev: > +++ Matthias H=FCning [Aug 19 13 00:14 ]: >> >> >> Am Samstag, 17. August 2013 16:44:19 UTC+2 schrieb David Sanson: >>> >>> >>> So my vote would be---at least at first---for the HTML tag solution for >>> both spans and blocks. If these elements become more central to the >>> behavior of stock pandoc conversions, then one could always add a "nati= ve" >>> syntax later. >>> >> >> I would like to second this. >=20 > I've now implemented parsing of and
tags as > pandoc Span and Div elements in github master. >=20 > This has the GREAT advantage of full compatibility with standard > markdown. People seem to have wildly differing (and sometimes > pretty strong) opinions about all the other options, so I think > for this release I'll content myself with this minimal change, > which gives people the flexibility to do some pretty fancy things > if they want to. It's better than nothing but personally I don't like that at all. The reason I started to use Markdown/Pandoc to begin with is that I find both HTML and TeXish markup extremely ugly and disturbing to read -- I have to render them to see the text as text at all! I actually dislike HTML slightly more because of the *paired* textual tags, so the suggestion (Dirk's?) to have pandoc render a TeXish `\command{text}` into HTML as `text` would be slightly preferable to me -- I even experimented with a text filter doing just that at one point. John, are you averse to in the future supporting more than one syntax each if people's preferences differ too widely, e.g. both a surround marking and a side marking style for divs? After all we already have several syntaxes for tables! (Note: I wrote the following yesterday before seeing John's mail which I'm replying to. Perhaps it can [still] contain something useful. I'm afraid I was my usual verbose self, for which I apologize!) While I agree that the suggested `[text]{.class}` syntax stretches the limits of readability-as-text[^1] but it *does* connect nicely with the existing `[linktext](url)` and `` `code`{.class} `` syntaxes.[^2] It certainly isn't the most pretty or compact syntax imaginable, it is more compact than the corresponding HTML, it does build on existing syntax and it's no *more* ugly than that existing syntax. It's definitely also an advantage if the attribute syntax for headings, code(blocks) spans and divs is the same. That's also one reason why I think that a surround marking style for div blocks would be preferable: it would be closely similar to fenced code blocks, including the way attributes are attached to them, and not to be confused with anything esle like blockquotes; if they can be degraded to mere horizontal rules by just stripping the attributes so much the better! I briefly had the thought that since spans are a form of emphasis maybe they should render as `_emphasized text_{.with attr=3Dibutes}`, so that for the most part one could handle graceful degradation with `s/_\zs{.\{-}}//g`{.vim} or its equivalent, but the question is how emphasis inside spans should then be marked, but since there are two alternative markers for emphasis that should be solveable. Similarly `s/^\s*[_-*]\{4,}\zs\s*{.\{-}}\s*$/`{.vim} should degrade divs if they look like 'horizontal rules with attributes'. One way of getting around `[some]{.long .unsightly attribute=3Dchains}` would be to have a syntax for 'reference attributes' analogous to reference links and similar to footnote syntax for use when one reuses the same cluster of attributes several times in the same document, which is often enough the case! This is a text with [some]{^a} noticeable word and then [another]{^a} equally noticeable word, and a then=20 still a [third]{^a #tertius} with some distinction=20 of its own. {^a}: .long .unsightly attribute=3Dchains Finally one could even *use scripting* if one feels a need to convert markdown with these constructs into markdown with something sightlier! /bpj [^1]: That's why I suggested an alternative `[[class: text]]` or even `{class: text}` syntax in the hope that it would remain more readable-as- text even when left as-is or with the brackets replaced by ordinary parentheses. The best would certainly be if one could run pandoc -t markdown-spans-divs and get 'plain' markdown if one thinks that is sightlier or even pandoc -t markdown+spans_as_em+divs_as_quotes or pandoc -t markdown+spans_as_em+divs_as_rules if one still wants them marked in *some* way. [^2]: In fact I have for a while used a perl program which modifies the pandoc AST via JSON so that a `` `text`{.foo.} `` (note the trailing period!) is converted to a raw inline `text` or `\foo{text}` depending on the desired output format, or a corresponding 'codeblock' \> div/environment, the routine recursively calling itself on the content of `text`. While it has its limitations -- e.g. you can't really use footnotes inside such a block! -- it actually is a general scripting tool: the script is just a wrapper around a module, and you can write your own script and define a subclass with methods so that for any `` `text`{.hook.} `` if your subclass has a method `hook_handler` it is called with an object as argument which contains the text, hook, other classes, id and type (inline/block) of the 'code' element (and in fact the default behavior is handled by an overridable `default_html` or `default_latex` method in the base class.) You then construct the html/latex text -- calling the pandoc wrapper method if necessary -- and then call a method on the element object to eat the brains of the AST hashref containing the code element, converting it to a raw element in place. It seems like this is pretty much the same as John has in mind with python scripting, except that I had to hook into pandoc's code syntax since it was the only element which supported attributes. --=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/5218D585.20702%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.