Release road map - 1.14 and beyond

Release road map - 1.14 and beyond

[John MacFarlane]

There have been a lot of improvements and bug fixes since
the last release (1.13.2).  So it would be good to release the
next version before long.  I wanted to give an opportunity for
discussion of some choice points.

The master branch now contains some breaking API changes:
instead of returning a Pandoc, the readers now returin
Either PandocError Pandoc.  This makes the library safer,
allowing users to handle parsing errors.  Because of this
API change, the version will be 1.14.

There are a number of other things I'd like to fix (or
at least investigate fixing) before the release:

[ ] #2040 - epub stylesheet / --css
[ ] #1995 - popup footnotes
[ ] #1931 - titles inside info elements in docbook
[ ] #1909 - apostrophe in $x$'s being interpreted as open quote
[ ] #1907 - better support for color in latex reader
[ ] #1877 - fix epub reader reference resolution
[ ] #1855 - properly assign mime types
[ ] #1849 - metadata bibliography= implies pandoc-citeproc
[ ] #1844 - render rights with plain writer
[ ] #1834 - strange jpeg crashes - remove bombs in ImageSize parser
[ ] #1820 - disappearing content w malformed div
[ ] #1751, #1670 - support html base tag
[ ] #1735 - exponential performance fro nested brackets
[ ] #1658 - better default for level 4 headers in latex?
[ ] #1609 - remove linear=no from epub cover
[ ] #1606 - make implicit header references case-insensitive?
[ ] #853 - convert docutils citations to regular footnotes?
[ ] #1395 - is there any good alternative to longtable?
[ ] add note to scripting tutorial about 1.14 API differences

In addition to these changes, mb21 has contributed a large
set of changes that add an attributes field to Image, allowing
fine-grained control of image sizing in several output formats
(see the new-image-attributes branch in jgm/pandoc on github).
This is one of the longest-standing requests, and I suspect it
will be a popular feature.  However, this change would require
a change in the underlying Pandoc type (defined in pandoc-types).
Such a change would break many existing filters and custom writers,
so it would be, in some ways, painful.

I think such growing pains are inevitable -- we can't be stuck
with the old types forever.  But it might make sense to (a) wait
for the next release to make these changes, and (b) bundle these
changes with other pandoc-types changes that would make sense.
Perhaps with all those changes we'd want to bump the version to 2.0.
The idea is to minimize the number of releases that will require
upgrades to filters, etc.

Here are some of the other changes to pandoc-types that I think
we'd want to consider:

[ ] adding Attr field to Image (mb21's change)
[ ] adding Attr field to Link
[ ] alternatively:  radical restructuring of the types so that
    everything has an Attr field (this would have advantages of
    uniformity, at the cost of making the structures more awkward to
    work with and pattern match on, and of course this change would require
    massive changes to the pandoc code base)
[ ] changing String to Text everywhere (this would require extensive
    but easy changes throughout the pandoc code base)
[ ] hand-written ToJSON and FromJSON instances, instead of deriving
    generic ones, to make it easier to keep the JSON format stable
    even when the Pandoc type changes
[ ] an Anchor element (might be unnecessary if everything had Attr)
[ ] a Figure block element, capable of containing multiple images
    (this would eliminate some hackery we currently do with a "fig:"
    prefix in image titles)
[ ] a LineBlock block element (#1623, currently we just use a paragraph with
    lots of line breaks, which isn't ideal)
[ ] a PageBreak block element
[ ] replace Strikeout with Deleted; add an Inserted element
[ ] add a SoftBreak element, to give the option of preserving line
    breaks from the source (see #1701)
[ ] allow colspans in Table element (this would require figuring out
    how to do colspans in our markdown table formats)

At this point, I'm most hoping for feedback on whether it makes sense
to release 1.14 without the Image attribute changes, and save those
for a future release where they might be bundled with some of these
other improvements in the Pandoc type.

John

Re: Release road map - 1.14 and beyond

[Joseph Reagle]

On 04/03/2015 01:05 PM, John MacFarlane wrote:
> There are a number of other things I'd like to fix (or
> at least investigate fixing) before the release:

How about reveal.js 3.0.0 ?

Re: Release road map - 1.14 and beyond

[Matthew Pickering]

 I have tagged all the issues John indicated on github.
https://github.com/jgm/pandoc/milestones/1.14

On the other issues I have several comments.

(1) I support adding an attribute field to all elements but I would
prefer it if the attribute type was left open and as much code written
as possible which was ambivalent to the type of the attribute.

For example, I would prefer.. data AElement a = AElement a Inline
rather than the monomorphic version.

(1a) If this were to happen I would also prefer a more principled Attr
type than we currently have.

(2) String to text will be very very painful as most of the parsing
code will have to be rewritten as it relies on Text.Parsec.Char at
least indirectly.

(3) With regard to other AST elements, I am in favour of adding many
semantically distinct elements as desired. I see no harm at all in
having a very rich document model which none of the readers fully
implement. This would also help keep the API more stable across
releases.



On Fri, Apr 3, 2015 at 6:28 PM, Joseph Reagle <joseph.2011-T1oY19WcHSwdnm+yROfE0A@public.gmane.org> wrote:
> On 04/03/2015 01:05 PM, John MacFarlane wrote:
>> There are a number of other things I'd like to fix (or
>> at least investigate fixing) before the release:
>
> How about reveal.js 3.0.0 ?
>
> --
> 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 email 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/551ECDD2.5050606%40reagle.org.
> For more options, visit https://groups.google.com/d/optout.

Re: Release road map - 1.14 and beyond

[John MacFarlane]

+++ Matthew Pickering [Apr 03 15 20:40 ]:
>(2) String to text will be very very painful as most of the parsing
>code will have to be rewritten as it relies on Text.Parsec.Char at
>least indirectly.

One can always use Text.Parsec.Char parsers, then use Text.pack to pack
the resulting Strings into Texts.  To improve efficiency, we might
add some customized parsers that operate directly on Text input (like
Data.Attoparsec.Text.takeWhile), and use them where it helps.  I don't see
a big issue here; I think the changes to the parsers would be fairly
straightforward.  Just tedious.

Re: Release road map - 1.14 and beyond

[Nick Yakimov]

[-- Attachment #1.1: Type: text/plain, Size: 5638 bytes --]

Something I realized just now on the topic of attributes. I think I'd like 
to have tables have attributes as well. But that's not far removed from 
wanting *everything* to have attributes (at least all block-level elements 
and links). This would be a major change, but it will make AST more robust 
and (hopefully) allow for less changes in the future.

пятница, 3 апреля 2015 г., 20:05:45 UTC+3 пользователь John MacFarlane 
написал:
>
> There have been a lot of improvements and bug fixes since 
> the last release (1.13.2).  So it would be good to release the 
> next version before long.  I wanted to give an opportunity for 
> discussion of some choice points. 
>
> The master branch now contains some breaking API changes: 
> instead of returning a Pandoc, the readers now returin 
> Either PandocError Pandoc.  This makes the library safer, 
> allowing users to handle parsing errors.  Because of this 
> API change, the version will be 1.14. 
>
> There are a number of other things I'd like to fix (or 
> at least investigate fixing) before the release: 
>
> [ ] #2040 - epub stylesheet / --css 
> [ ] #1995 - popup footnotes 
> [ ] #1931 - titles inside info elements in docbook 
> [ ] #1909 - apostrophe in $x$'s being interpreted as open quote 
> [ ] #1907 - better support for color in latex reader 
> [ ] #1877 - fix epub reader reference resolution 
> [ ] #1855 - properly assign mime types 
> [ ] #1849 - metadata bibliography= implies pandoc-citeproc 
> [ ] #1844 - render rights with plain writer 
> [ ] #1834 - strange jpeg crashes - remove bombs in ImageSize parser 
> [ ] #1820 - disappearing content w malformed div 
> [ ] #1751, #1670 - support html base tag 
> [ ] #1735 - exponential performance fro nested brackets 
> [ ] #1658 - better default for level 4 headers in latex? 
> [ ] #1609 - remove linear=no from epub cover 
> [ ] #1606 - make implicit header references case-insensitive? 
> [ ] #853 - convert docutils citations to regular footnotes? 
> [ ] #1395 - is there any good alternative to longtable? 
> [ ] add note to scripting tutorial about 1.14 API differences 
>
> In addition to these changes, mb21 has contributed a large 
> set of changes that add an attributes field to Image, allowing 
> fine-grained control of image sizing in several output formats 
> (see the new-image-attributes branch in jgm/pandoc on github). 
> This is one of the longest-standing requests, and I suspect it 
> will be a popular feature.  However, this change would require 
> a change in the underlying Pandoc type (defined in pandoc-types). 
> Such a change would break many existing filters and custom writers, 
> so it would be, in some ways, painful. 
>
> I think such growing pains are inevitable -- we can't be stuck 
> with the old types forever.  But it might make sense to (a) wait 
> for the next release to make these changes, and (b) bundle these 
> changes with other pandoc-types changes that would make sense. 
> Perhaps with all those changes we'd want to bump the version to 2.0. 
> The idea is to minimize the number of releases that will require 
> upgrades to filters, etc. 
>
> Here are some of the other changes to pandoc-types that I think 
> we'd want to consider: 
>
> [ ] adding Attr field to Image (mb21's change) 
> [ ] adding Attr field to Link 
> [ ] alternatively:  radical restructuring of the types so that 
>     everything has an Attr field (this would have advantages of 
>     uniformity, at the cost of making the structures more awkward to 
>     work with and pattern match on, and of course this change would 
> require 
>     massive changes to the pandoc code base) 
> [ ] changing String to Text everywhere (this would require extensive 
>     but easy changes throughout the pandoc code base) 
> [ ] hand-written ToJSON and FromJSON instances, instead of deriving 
>     generic ones, to make it easier to keep the JSON format stable 
>     even when the Pandoc type changes 
> [ ] an Anchor element (might be unnecessary if everything had Attr) 
> [ ] a Figure block element, capable of containing multiple images 
>     (this would eliminate some hackery we currently do with a "fig:" 
>     prefix in image titles) 
> [ ] a LineBlock block element (#1623, currently we just use a paragraph 
> with 
>     lots of line breaks, which isn't ideal) 
> [ ] a PageBreak block element 
> [ ] replace Strikeout with Deleted; add an Inserted element 
> [ ] add a SoftBreak element, to give the option of preserving line 
>     breaks from the source (see #1701) 
> [ ] allow colspans in Table element (this would require figuring out 
>     how to do colspans in our markdown table formats) 
>
> At this point, I'm most hoping for feedback on whether it makes sense 
> to release 1.14 without the Image attribute changes, and save those 
> for a future release where they might be bundled with some of these 
> other improvements in the Pandoc type. 
>
> John 
>
>

-- 
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 email 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/affa2598-d059-4285-bf64-e4b94a393e12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 6423 bytes --]

Re: Release road map - 1.14 and beyond

[Andrew Dunning]

[-- Attachment #1.1: Type: text/plain, Size: 1558 bytes --]



On Friday, April 3, 2015 at 3:40:05 PM UTC-4, Matthew Pickering wrote:
>
>
> (3) With regard to other AST elements, I am in favour of adding many 
> semantically distinct elements as desired. I see no harm at all in 
> having a very rich document model which none of the readers fully 
> implement. This would also help keep the API more stable across 
> releases. 


It would be wonderful if this could be done without seriously sacrificing 
interoperability. The TEI guidelines serve as both the pinnacle of semantic 
document structuring and a warning of what can go wrong. There are many 
things in there that would be useful to have in Pandoc, especially for 
representing primary source materials. For instance, I was surprised the 
other day to find how difficult it is to reliably indicate the page numbers 
from a printed volume in making an ebook version. It could be useful to 
have Pandoc support for something like TEI Simple (see 
<https://github.com/TEIC/TEI-Simple>).

-- 
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 email 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/657d0ad0-c97a-40bb-b50e-c4676de65e89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 2136 bytes --]

Re: Release road map - 1.14 and beyond

[John MacFarlane]

+++ Andrew Dunning [Apr 06 15 19:15 ]:

>For instance, I was surprised the
>other day to find how difficult it is to reliably indicate the page numbers
>from a printed volume in making an ebook version.

I think using custom spans is an excellent way to do this in a pandoc
markdown context.

    Hello <span x-page="44" />world

Filters can then be created to treat these spans in any way you like in
the final output.  (Or, if you're targeting EPUB, you can just use CSS.)

If that's too much typing, you can always create an ad hoc method and
use filters to create spans.  E.g.

    Hello
    p44
    world

could be converted to

    Hello <span x-page="44" />world

Re: Release road map - 1.14 and beyond

[daniel]

On 2015-04-06 23:26, John MacFarlane wrote:
> +++ Andrew Dunning [Apr 06 15 19:15 ]:
> 
>> For instance, I was surprised the
>> other day to find how difficult it is to reliably indicate the page 
>> numbers
>> from a printed volume in making an ebook version.
> 
> I think using custom spans is an excellent way to do this in a pandoc
> markdown context.
> 
>    Hello <span x-page="44" />world
> 
> Filters can then be created to treat these spans in any way you like in
> the final output.  (Or, if you're targeting EPUB, you can just use 
> CSS.)
> 
> If that's too much typing, you can always create an ad hoc method and
> use filters to create spans.  E.g.
> 
>    Hello
>    p44
>    world
> 
> could be converted to
> 
>    Hello <span x-page="44" />world

... With the one issue being that the actual page number in an ebook is 
dependent on the reader and font used to read the ebook...

If there's a better, more semantic way to indicate 'we are going to 
reference to here' that could be included in some future version, it 
might be a good idea.  (Assuming references to headers and such don't 
already cover the use cases.)

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.
---------------------------------------------------------------

Re: Release road map - 1.14 and beyond

[mb21]

[-- Attachment #1.1: Type: text/plain, Size: 7133 bytes --]

I'm back from some extended travel, so I would have some time to work on 
this again. Particularly adding the Attr field to Link. Should this be done 
on the new-image-attributes branch as well?

I've looked at the new branch: with most of the changes I was on the fence 
when I implemented them (whether the `textFl` etc. functions in ImageSize 
were really a good idea, or whether writerDpi should be an int of 
float—personally I'm still not sure about that one). So thank you John for 
taking a good look, merging and cleaning things up.

So I'm in favour of a 1.14 release with image and link attributes, plus 
maybe the proposed changes listed below:

> [ ] changing String to Text everywhere (this would require extensive 
>     but easy changes throughout the pandoc code base) 
> [ ] a Figure block element, capable of containing multiple images 
>     (this would eliminate some hackery we currently do with a "fig:" 
>     prefix in image titles) 
> [ ] hand-written ToJSON and FromJSON instances, instead of deriving 
>     generic ones, to make it easier to keep the JSON format stable 
>     even when the Pandoc type changes 

Yes, I've been thinking of hand-written ToJSON as well, as the current JSON 
format really doesn't seem too friendly to filter writers. Plus, as you 
said, future changes should break fever filters.

If we are to stay true to Markdown's origins in mirroring HTML's document 
model, an Anchor element seems like a bad idea. For a 1.14 release (or 
2.0), adding Attr to Image, Link, Table and BlockQuote should do —then you 
can reference all elements you usually want to link to. Implementing ids 
and classes in the writers would suffice for the start, wouldn't it?

Ultimately, I'm in favour of a somewhat rolling release (like most software 
is trending towards): it's better to have little now than nothing later.



On Friday, April 3, 2015 at 7:05:45 PM UTC+2, John MacFarlane wrote:
>
> There have been a lot of improvements and bug fixes since 
> the last release (1.13.2).  So it would be good to release the 
> next version before long.  I wanted to give an opportunity for 
> discussion of some choice points. 
>
> The master branch now contains some breaking API changes: 
> instead of returning a Pandoc, the readers now returin 
> Either PandocError Pandoc.  This makes the library safer, 
> allowing users to handle parsing errors.  Because of this 
> API change, the version will be 1.14. 
>
> There are a number of other things I'd like to fix (or 
> at least investigate fixing) before the release: 
>
> [ ] #2040 - epub stylesheet / --css 
> [ ] #1995 - popup footnotes 
> [ ] #1931 - titles inside info elements in docbook 
> [ ] #1909 - apostrophe in $x$'s being interpreted as open quote 
> [ ] #1907 - better support for color in latex reader 
> [ ] #1877 - fix epub reader reference resolution 
> [ ] #1855 - properly assign mime types 
> [ ] #1849 - metadata bibliography= implies pandoc-citeproc 
> [ ] #1844 - render rights with plain writer 
> [ ] #1834 - strange jpeg crashes - remove bombs in ImageSize parser 
> [ ] #1820 - disappearing content w malformed div 
> [ ] #1751, #1670 - support html base tag 
> [ ] #1735 - exponential performance fro nested brackets 
> [ ] #1658 - better default for level 4 headers in latex? 
> [ ] #1609 - remove linear=no from epub cover 
> [ ] #1606 - make implicit header references case-insensitive? 
> [ ] #853 - convert docutils citations to regular footnotes? 
> [ ] #1395 - is there any good alternative to longtable? 
> [ ] add note to scripting tutorial about 1.14 API differences 
>
> In addition to these changes, mb21 has contributed a large 
> set of changes that add an attributes field to Image, allowing 
> fine-grained control of image sizing in several output formats 
> (see the new-image-attributes branch in jgm/pandoc on github). 
> This is one of the longest-standing requests, and I suspect it 
> will be a popular feature.  However, this change would require 
> a change in the underlying Pandoc type (defined in pandoc-types). 
> Such a change would break many existing filters and custom writers, 
> so it would be, in some ways, painful. 
>
> I think such growing pains are inevitable -- we can't be stuck 
> with the old types forever.  But it might make sense to (a) wait 
> for the next release to make these changes, and (b) bundle these 
> changes with other pandoc-types changes that would make sense. 
> Perhaps with all those changes we'd want to bump the version to 2.0. 
> The idea is to minimize the number of releases that will require 
> upgrades to filters, etc. 
>
> Here are some of the other changes to pandoc-types that I think 
> we'd want to consider: 
>
> [ ] adding Attr field to Image (mb21's change) 
> [ ] adding Attr field to Link 
> [ ] alternatively:  radical restructuring of the types so that 
>     everything has an Attr field (this would have advantages of 
>     uniformity, at the cost of making the structures more awkward to 
>     work with and pattern match on, and of course this change would 
> require 
>     massive changes to the pandoc code base) 
> [ ] changing String to Text everywhere (this would require extensive 
>     but easy changes throughout the pandoc code base) 
> [ ] hand-written ToJSON and FromJSON instances, instead of deriving 
>     generic ones, to make it easier to keep the JSON format stable 
>     even when the Pandoc type changes 
> [ ] an Anchor element (might be unnecessary if everything had Attr) 
> [ ] a Figure block element, capable of containing multiple images 
>     (this would eliminate some hackery we currently do with a "fig:" 
>     prefix in image titles) 
> [ ] a LineBlock block element (#1623, currently we just use a paragraph 
> with 
>     lots of line breaks, which isn't ideal) 
> [ ] a PageBreak block element 
> [ ] replace Strikeout with Deleted; add an Inserted element 
> [ ] add a SoftBreak element, to give the option of preserving line 
>     breaks from the source (see #1701) 
> [ ] allow colspans in Table element (this would require figuring out 
>     how to do colspans in our markdown table formats) 
>
> At this point, I'm most hoping for feedback on whether it makes sense 
> to release 1.14 without the Image attribute changes, and save those 
> for a future release where they might be bundled with some of these 
> other improvements in the Pandoc type. 
>
> John 
>
>

-- 
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 email 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/2e314761-d731-4104-9e68-fbbd87bb901b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 8232 bytes --]

Re: Release road map - 1.14 and beyond

[insanemole]

[-- Attachment #1.1: Type: text/plain, Size: 3307 bytes --]

I can say nothing about this particular update, put I'll use the 
opportunity to mention some more general thought about the ideas:

I think it would be great to have more options for extensions. The origin 
of Pandoc may lie in the Markdown world, but it would be great if some day 
a Docx reader and an Odt writer could keep much more of their shared 
structure if they work together, without having to make the core types too 
bloated. Adding Attrs, however, might not be the best approach. We have 
such a great type system, so we should use it. One way to go might be to 
turn *Inline *and *Block *into GADTs similar to to this:

data Inline where
  -- ...
  Emph :: (EmphasisData d) => d -> [Inlines] -> Emph d [Inline]
  -- ...

class (Typeable d) => EmphasisData d where
  -- empty

(I just choose *Emph *as it was not mentioned before. Maybe one day someone 
wants to differentiate between smallcaps, italics, and underlined or 
something.)
Now a reader can add as much bonus information as it wants, and a writer 
can use it, if it supports it. Downsides: a lot of (not very involved) 
rewriting would be necessary and some process would have to control which 
extensions should be canonical.
It might even be a good idea to transport a heterogenous list of 
*EmphasisData*, but that would be even more complicated for the poor writer 
that has to make sense of that later. If you don't like *Typeable* and want 
to make pattern matching possible, there would of course be the option to 
just make *EmphasisData *a simple data type instead. I was just going for 
maximum extensibility here.

Another layer of complexity: It would be great if a writer could tell a 
reader about its capabilities, so the reader can adapt to it. That should 
be a simple extension to their type classes. Maybe they could get a stack 
of *TypeRef*'s each for every extendable *Inline*/*Block *constructor, plus 
some simple lookup functions. There are type classes for readers and 
writers, right? Yet another step: make *Inline *and *Block *type classes 
too, with their current constructors as instances. Gigantic rewriting, but 
maximum extensibility...

I think it might be possible to implement something like this parallel to 
the current system with relatively easy fallback converters. It's just... 
daunting. Is it worth the effort? That depends on the long term goals I 
suppose.

Oh, and concerning

[ ] replace Strikeout with Deleted; add an Inserted element 
>

I'd say these are completely orthogonal features semantically. So the 
additions might make sense, but I don't see the point in removing 
*Strikeout*.


Of course these are just the 2.5 cents of someone at the edge of the system 
looking through the tinted glass... ;-)

-- 
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 email 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/9a296b69-010d-4f7e-bced-11c40ecbabf2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 7479 bytes --]

Re: Release road map - 1.14 and beyond

[John MacFarlane]

I'm planning to release 1.14 soon -- today I hope!
I'm not going to include image and link attributes in this
release, but maybe next major release.

+++ mb21 [May 24 15 05:59 ]:
>I'm back from some extended travel, so I would have some time to work on
>this again. Particularly adding the Attr field to Link. Should this be done
>on the new-image-attributes branch as well?
>
>I've looked at the new branch: with most of the changes I was on the fence
>when I implemented them (whether the `textFl` etc. functions in ImageSize
>were really a good idea, or whether writerDpi should be an int of
>float—personally I'm still not sure about that one). So thank you John for
>taking a good look, merging and cleaning things up.
>
>So I'm in favour of a 1.14 release with image and link attributes, plus
>maybe the proposed changes listed below:
>
>> [ ] changing String to Text everywhere (this would require extensive
>>     but easy changes throughout the pandoc code base)
>> [ ] a Figure block element, capable of containing multiple images
>>     (this would eliminate some hackery we currently do with a "fig:"
>>     prefix in image titles)
>> [ ] hand-written ToJSON and FromJSON instances, instead of deriving
>>     generic ones, to make it easier to keep the JSON format stable
>>     even when the Pandoc type changes
>
>Yes, I've been thinking of hand-written ToJSON as well, as the current JSON
>format really doesn't seem too friendly to filter writers. Plus, as you
>said, future changes should break fever filters.
>
>If we are to stay true to Markdown's origins in mirroring HTML's document
>model, an Anchor element seems like a bad idea. For a 1.14 release (or
>2.0), adding Attr to Image, Link, Table and BlockQuote should do —then you
>can reference all elements you usually want to link to. Implementing ids
>and classes in the writers would suffice for the start, wouldn't it?
>
>Ultimately, I'm in favour of a somewhat rolling release (like most software
>is trending towards): it's better to have little now than nothing later.
>
>
>
>On Friday, April 3, 2015 at 7:05:45 PM UTC+2, John MacFarlane wrote:
>>
>> There have been a lot of improvements and bug fixes since
>> the last release (1.13.2).  So it would be good to release the
>> next version before long.  I wanted to give an opportunity for
>> discussion of some choice points.
>>
>> The master branch now contains some breaking API changes:
>> instead of returning a Pandoc, the readers now returin
>> Either PandocError Pandoc.  This makes the library safer,
>> allowing users to handle parsing errors.  Because of this
>> API change, the version will be 1.14.
>>
>> There are a number of other things I'd like to fix (or
>> at least investigate fixing) before the release:
>>
>> [ ] #2040 - epub stylesheet / --css
>> [ ] #1995 - popup footnotes
>> [ ] #1931 - titles inside info elements in docbook
>> [ ] #1909 - apostrophe in $x$'s being interpreted as open quote
>> [ ] #1907 - better support for color in latex reader
>> [ ] #1877 - fix epub reader reference resolution
>> [ ] #1855 - properly assign mime types
>> [ ] #1849 - metadata bibliography= implies pandoc-citeproc
>> [ ] #1844 - render rights with plain writer
>> [ ] #1834 - strange jpeg crashes - remove bombs in ImageSize parser
>> [ ] #1820 - disappearing content w malformed div
>> [ ] #1751, #1670 - support html base tag
>> [ ] #1735 - exponential performance fro nested brackets
>> [ ] #1658 - better default for level 4 headers in latex?
>> [ ] #1609 - remove linear=no from epub cover
>> [ ] #1606 - make implicit header references case-insensitive?
>> [ ] #853 - convert docutils citations to regular footnotes?
>> [ ] #1395 - is there any good alternative to longtable?
>> [ ] add note to scripting tutorial about 1.14 API differences
>>
>> In addition to these changes, mb21 has contributed a large
>> set of changes that add an attributes field to Image, allowing
>> fine-grained control of image sizing in several output formats
>> (see the new-image-attributes branch in jgm/pandoc on github).
>> This is one of the longest-standing requests, and I suspect it
>> will be a popular feature.  However, this change would require
>> a change in the underlying Pandoc type (defined in pandoc-types).
>> Such a change would break many existing filters and custom writers,
>> so it would be, in some ways, painful.
>>
>> I think such growing pains are inevitable -- we can't be stuck
>> with the old types forever.  But it might make sense to (a) wait
>> for the next release to make these changes, and (b) bundle these
>> changes with other pandoc-types changes that would make sense.
>> Perhaps with all those changes we'd want to bump the version to 2.0.
>> The idea is to minimize the number of releases that will require
>> upgrades to filters, etc.
>>
>> Here are some of the other changes to pandoc-types that I think
>> we'd want to consider:
>>
>> [ ] adding Attr field to Image (mb21's change)
>> [ ] adding Attr field to Link
>> [ ] alternatively:  radical restructuring of the types so that
>>     everything has an Attr field (this would have advantages of
>>     uniformity, at the cost of making the structures more awkward to
>>     work with and pattern match on, and of course this change would
>> require
>>     massive changes to the pandoc code base)
>> [ ] changing String to Text everywhere (this would require extensive
>>     but easy changes throughout the pandoc code base)
>> [ ] hand-written ToJSON and FromJSON instances, instead of deriving
>>     generic ones, to make it easier to keep the JSON format stable
>>     even when the Pandoc type changes
>> [ ] an Anchor element (might be unnecessary if everything had Attr)
>> [ ] a Figure block element, capable of containing multiple images
>>     (this would eliminate some hackery we currently do with a "fig:"
>>     prefix in image titles)
>> [ ] a LineBlock block element (#1623, currently we just use a paragraph
>> with
>>     lots of line breaks, which isn't ideal)
>> [ ] a PageBreak block element
>> [ ] replace Strikeout with Deleted; add an Inserted element
>> [ ] add a SoftBreak element, to give the option of preserving line
>>     breaks from the source (see #1701)
>> [ ] allow colspans in Table element (this would require figuring out
>>     how to do colspans in our markdown table formats)
>>
>> At this point, I'm most hoping for feedback on whether it makes sense
>> to release 1.14 without the Image attribute changes, and save those
>> for a future release where they might be bundled with some of these
>> other improvements in the Pandoc type.
>>
>> John
>>
>>
>
>-- 
>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 email 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/2e314761-d731-4104-9e68-fbbd87bb901b%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
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 email 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/20150527223700.GB53167%40localhost.hsd1.ca.comcast.net.
For more options, visit https://groups.google.com/d/optout.

Re: Release road map - 1.14 and beyond

[Tim St. Clair]

[-- Attachment #1.1: Type: text/plain, Size: 5988 bytes --]

I'm still all for the radical restructuring proposed, since I've already 
been using hacks in markdown to do a [ ... ]( ... ){ ... } format for *both* 
links and images. Implementing for links and images would get me by, and if 
that alone is in the next release, I'm happy. A ballpark on when it might 
drop would be nice :)

In my case I've been using a new tag handler - 
?[command](action){atrribute-map} - to handle actions like performing 
oembeds or importing external markdown files. It's pretty complex and 
switches on *command* to determine what to do, so it's kinda far off the 
ideal path for markdown, and means nothing at all to other text formats, 
ans doing it in filters is kinda hokey. Having the ability to drop 
attributes onto any object I like would mean I could then use javascript 
when the page renders to do these sorts of actions.

On Saturday, 4 April 2015 04:05:45 UTC+11, John MacFarlane wrote:
>
> There have been a lot of improvements and bug fixes since 
> the last release (1.13.2).  So it would be good to release the 
> next version before long.  I wanted to give an opportunity for 
> discussion of some choice points. 
>
> The master branch now contains some breaking API changes: 
> instead of returning a Pandoc, the readers now returin 
> Either PandocError Pandoc.  This makes the library safer, 
> allowing users to handle parsing errors.  Because of this 
> API change, the version will be 1.14. 
>
> There are a number of other things I'd like to fix (or 
> at least investigate fixing) before the release: 
>
> [ ] #2040 - epub stylesheet / --css 
> [ ] #1995 - popup footnotes 
> [ ] #1931 - titles inside info elements in docbook 
> [ ] #1909 - apostrophe in $x$'s being interpreted as open quote 
> [ ] #1907 - better support for color in latex reader 
> [ ] #1877 - fix epub reader reference resolution 
> [ ] #1855 - properly assign mime types 
> [ ] #1849 - metadata bibliography= implies pandoc-citeproc 
> [ ] #1844 - render rights with plain writer 
> [ ] #1834 - strange jpeg crashes - remove bombs in ImageSize parser 
> [ ] #1820 - disappearing content w malformed div 
> [ ] #1751, #1670 - support html base tag 
> [ ] #1735 - exponential performance fro nested brackets 
> [ ] #1658 - better default for level 4 headers in latex? 
> [ ] #1609 - remove linear=no from epub cover 
> [ ] #1606 - make implicit header references case-insensitive? 
> [ ] #853 - convert docutils citations to regular footnotes? 
> [ ] #1395 - is there any good alternative to longtable? 
> [ ] add note to scripting tutorial about 1.14 API differences 
>
> In addition to these changes, mb21 has contributed a large 
> set of changes that add an attributes field to Image, allowing 
> fine-grained control of image sizing in several output formats 
> (see the new-image-attributes branch in jgm/pandoc on github). 
> This is one of the longest-standing requests, and I suspect it 
> will be a popular feature.  However, this change would require 
> a change in the underlying Pandoc type (defined in pandoc-types). 
> Such a change would break many existing filters and custom writers, 
> so it would be, in some ways, painful. 
>
> I think such growing pains are inevitable -- we can't be stuck 
> with the old types forever.  But it might make sense to (a) wait 
> for the next release to make these changes, and (b) bundle these 
> changes with other pandoc-types changes that would make sense. 
> Perhaps with all those changes we'd want to bump the version to 2.0. 
> The idea is to minimize the number of releases that will require 
> upgrades to filters, etc. 
>
> Here are some of the other changes to pandoc-types that I think 
> we'd want to consider: 
>
> [ ] adding Attr field to Image (mb21's change) 
> [ ] adding Attr field to Link 
> [ ] alternatively:  radical restructuring of the types so that 
>     everything has an Attr field (this would have advantages of 
>     uniformity, at the cost of making the structures more awkward to 
>     work with and pattern match on, and of course this change would 
> require 
>     massive changes to the pandoc code base) 
> [ ] changing String to Text everywhere (this would require extensive 
>     but easy changes throughout the pandoc code base) 
> [ ] hand-written ToJSON and FromJSON instances, instead of deriving 
>     generic ones, to make it easier to keep the JSON format stable 
>     even when the Pandoc type changes 
> [ ] an Anchor element (might be unnecessary if everything had Attr) 
> [ ] a Figure block element, capable of containing multiple images 
>     (this would eliminate some hackery we currently do with a "fig:" 
>     prefix in image titles) 
> [ ] a LineBlock block element (#1623, currently we just use a paragraph 
> with 
>     lots of line breaks, which isn't ideal) 
> [ ] a PageBreak block element 
> [ ] replace Strikeout with Deleted; add an Inserted element 
> [ ] add a SoftBreak element, to give the option of preserving line 
>     breaks from the source (see #1701) 
> [ ] allow colspans in Table element (this would require figuring out 
>     how to do colspans in our markdown table formats) 
>
> At this point, I'm most hoping for feedback on whether it makes sense 
> to release 1.14 without the Image attribute changes, and save those 
> for a future release where they might be bundled with some of these 
> other improvements in the Pandoc type. 
>
> John 
>
>

-- 
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 email 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/c3454404-6373-4148-a53a-030229e99db5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 6984 bytes --]

Re: Release road map - 1.14 and beyond

[mb21]

[-- Attachment #1.1: Type: text/plain, Size: 723 bytes --]

I was thinking of adding Attr to Link on the new-image-attributes branch, 
but I'll have to merge in master I guess. Do you prefer to merge or rebase?

-- 
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 email 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/c31c10c5-1292-4501-8b95-cd2056fda9c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 1139 bytes --]

Re: Release road map - 1.14 and beyond

[mb21]

[-- Attachment #1.1: Type: text/plain, Size: 932 bytes --]

Okay, I rebased from master and implemented the link attributes: 
https://github.com/mb21/pandoc/tree/new-image-attributes

Still not quite sure where we're going with this... I don't think we need 
Attr on every element (it's not worth the effort just for consistency), but 
at least on Table and Math, so we can reference tables and equations in 
documents?

-- 
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 email 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/7c361579-6858-4b3d-a24d-814ac2c9a7cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 1380 bytes --]

Re: Release road map - 1.14 and beyond

[Nikolay Yakimov]

[-- Attachment #1: Type: text/plain, Size: 2550 bytes --]

Personally, I’d be quite happy with Image, Table and Math. Maybe BlockQuote
could be useful in some cases as well. Not convinced lists or paragraphs
are worth it, although having an id on individual DefinitionList items
could be handy (but that’s another can of worms, I suppose). Plain,
HorizontalRule and Null obviously don’t make much sense in this context.

That said, having “freeform” attributes on any block element (not limited
to just id and class) opens a whole new avenue of fun with filters, so I
reckon it’s not just about “consistency”, but also “extendability”.
​

вс, 26 июля 2015 г. в 21:22, mb21 <mauro.bieg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:

> Okay, I rebased from master and implemented the link attributes:
> https://github.com/mb21/pandoc/tree/new-image-attributes
>
> Still not quite sure where we're going with this... I don't think we need
> Attr on every element (it's not worth the effort just for consistency), but
> at least on Table and Math, so we can reference tables and equations in
> documents?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "pandoc-discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/pandoc-discuss/650Exs1sCrE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email 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/7c361579-6858-4b3d-a24d-814ac2c9a7cc%40googlegroups.com
> <https://groups.google.com/d/msgid/pandoc-discuss/7c361579-6858-4b3d-a24d-814ac2c9a7cc%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 email 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/CA%2BhqrpWPvSgwKjwUphBv9-hKrxxhpbLk66Wg8STB%3DXkAREo-7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: Type: text/html, Size: 7541 bytes --]

Re: Release road map - 1.14 and beyond

[Pablo Rodríguez]

On 07/26/2015 08:37 PM, Nikolay Yakimov wrote:
> [...]
> That said, having “freeform” attributes on any block element (not
> limited to just |id| and |class|) opens a whole new avenue of fun with
> filters, so I reckon it’s not just about “consistency”, but also
> “extendability”.

It is really a pity that we don’t have attributes for all elements. But
at least, to make it easier, could we have special syntax for generic
division and spans.

We have been discussing this for more than five years
(https://github.com/jgm/pandoc/issues/168).

Sorry, but is it so difficult to implement a special syntax for generic
division and span elements?

If this is not so hard to implement, could it be included in the next
release?

Many thanks for your help,


Pablo


> вс, 26 июля 2015 г. в 21:22, mb21:
> 
>     Okay, I rebased from master and implemented the link attributes:
>     https://github.com/mb21/pandoc/tree/new-image-attributes
> 
>     Still not quite sure where we're going with this... I don't think we
>     need Attr on every element (it's not worth the effort just for
>     consistency), but at least on Table and Math, so we can reference
>     tables and equations in documents?
> 

-- 
http://www.ousia.tk

-- 
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 email 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/55B52D51.8010309%40web.de.
For more options, visit https://groups.google.com/d/optout.

Re: Release road map - 1.14 and beyond

[John MacFarlane]

+++ Pablo Rodríguez [Jul 26 15 20:56 ]:
>On 07/26/2015 08:37 PM, Nikolay Yakimov wrote:
>> [...]
>> That said, having “freeform” attributes on any block element (not
>> limited to just |id| and |class|) opens a whole new avenue of fun with
>> filters, so I reckon it’s not just about “consistency”, but also
>> “extendability”.
>
>It is really a pity that we don’t have attributes for all elements. But
>at least, to make it easier, could we have special syntax for generic
>division and spans.
>
>We have been discussing this for more than five years
>(https://github.com/jgm/pandoc/issues/168).
>
>Sorry, but is it so difficult to implement a special syntax for generic
>division and span elements?
>
>If this is not so hard to implement, could it be included in the next
>release?

No, it's not hard to implement.  What's hard is figuring out
the right syntax, because once you implement a syntax
extension, it's very hard to change later.

-- 
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 email 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/20150727162402.GC27705%40protagoras.berkeley.edu.
For more options, visit https://groups.google.com/d/optout.

Re: Release road map - 1.14 and beyond

[BP Jonsson]

Den 2015-07-27 18:24, John MacFarlane skrev:
> +++ Pablo Rodríguez [Jul 26 15 20:56 ]:
>> On 07/26/2015 08:37 PM, Nikolay Yakimov wrote:
>>> [...]
>>> That said, having “freeform” attributes on any block element (not
>>> limited to just |id| and |class|) opens a whole new avenue of
>>> fun with
>>> filters, so I reckon it’s not just about “consistency”, but also
>>> “extendability”.
>>
>> It is really a pity that we don’t have attributes for all
>> elements. But
>> at least, to make it easier, could we have special syntax for
>> generic
>> division and spans.
>>
>> We have been discussing this for more than five years
>> (https://github.com/jgm/pandoc/issues/168).
>>
>> Sorry, but is it so difficult to implement a special syntax for
>> generic
>> division and span elements?
>>
>> If this is not so hard to implement, could it be included in the
>> next
>> release?
>
> No, it's not hard to implement.  What's hard is figuring out
> the right syntax, because once you implement a syntax
> extension, it's very hard to change later.
>

What's happening in the CommonMark discussions with regard to 
this? Is there any consensus in sight?  Would it help if someone 
put together an overview of what has been suggested there to serve 
as a basis for discussion here? (I don't have time ATM but may 
well do it later this year).

However I guess that at least

     [<text>]{<attributes>}

for spans would be rather 'natural' for Pandoc in the light of 
what we got already.[^1]  Would you (jgm) be adverse to 
implementing that without implementing a div syntax at the same 
time?  At least to my mind the HTML-like div syntax is not half as 
annoying as the HTML-like span syntax.

/bpj

[^1]: It just hit me that this is only true if reference links 
with custom attributes isn't considered in the future, but I think 
that reference links should have their attributes if any along 
with their definition only. If not `[<link-id>][]{<attributes>}` 
could disambiguate at need. Truth to say I'm not so keen on 
shortcut reference links since my texts often contain phonetic 
transcriptions in angle brackets, and I'm not keen on having to 
backslash-escape them.  There have been clashes.



-- 
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 email 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/55B6774B.6090909%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Release road map - 1.14 and beyond

[BP Jonsson]

Den 2015-07-26 20:22, mb21 skrev:
> Okay, I rebased from master and implemented the link attributes:
> https://github.com/mb21/pandoc/tree/new-image-attributes
>
> Still not quite sure where we're going with this... I don't think we need
> Attr on every element (it's not worth the effort just for consistency), but
> at least on Table and Math, so we can reference tables and equations in
> documents?
>

The readme on that branch says:

> The `width` and `height` attributes on images are treated specially. When
> used without a unit, the unit is assumed to be pixels. However, any of
> the following unit identifiers can be used: `px`, `cm`, `in`, `inch` and
> `%`. There must not be any spaces between the number and the unit.

Why not `mm` as well?  After all millimeters is the 'proper' unit 
to use for such things in the metric world.

/bpj

Re: Release road map - 1.14 and beyond

[mb21]

[-- Attachment #1.1: Type: text/plain, Size: 1724 bytes --]

@BP Josson, added millimeters on my branch as well now: 
https://github.com/mb21/pandoc/tree/new-image-attributes (although I 
personally prefer writing 6cm to 60mm ;)

On Monday, July 27, 2015 at 8:31:48 PM UTC+2, BP Jonsson wrote:
>
> Den 2015-07-26 20:22, mb21 skrev: 
> > Okay, I rebased from master and implemented the link attributes: 
> > https://github.com/mb21/pandoc/tree/new-image-attributes 
> > 
> > Still not quite sure where we're going with this... I don't think we 
> need 
> > Attr on every element (it's not worth the effort just for consistency), 
> but 
> > at least on Table and Math, so we can reference tables and equations in 
> > documents? 
> > 
>
> The readme on that branch says: 
>
> > The `width` and `height` attributes on images are treated specially. 
> When 
> > used without a unit, the unit is assumed to be pixels. However, any of 
> > the following unit identifiers can be used: `px`, `cm`, `in`, `inch` and 
> > `%`. There must not be any spaces between the number and the unit. 
>
> Why not `mm` as well?  After all millimeters is the 'proper' unit 
> to use for such things in the metric world. 
>
> /bpj 
>
>

-- 
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 email 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/4663f0c6-7e25-41ac-bb1e-b174639ea010%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 2892 bytes --]

Re: Release road map - 1.14 and beyond

[Tim St. Clair]

[-- Attachment #1.1: Type: text/plain, Size: 2078 bytes --]

then if that's the case, what about vw and vh? These are formats used by 
html that are a width and height relative to the browser viewport. I've 
used them. I think once you set an arbitrary restriction in place, an 
exception for it immediately comes up.

On Tuesday, 28 July 2015 06:04:05 UTC+10, mb21 wrote:
>
> @BP Josson, added millimeters on my branch as well now: 
> https://github.com/mb21/pandoc/tree/new-image-attributes (although I 
> personally prefer writing 6cm to 60mm ;)
>
> On Monday, July 27, 2015 at 8:31:48 PM UTC+2, BP Jonsson wrote:
>>
>> Den 2015-07-26 20:22, mb21 skrev: 
>> > Okay, I rebased from master and implemented the link attributes: 
>> > https://github.com/mb21/pandoc/tree/new-image-attributes 
>> > 
>> > Still not quite sure where we're going with this... I don't think we 
>> need 
>> > Attr on every element (it's not worth the effort just for consistency), 
>> but 
>> > at least on Table and Math, so we can reference tables and equations in 
>> > documents? 
>> > 
>>
>> The readme on that branch says: 
>>
>> > The `width` and `height` attributes on images are treated specially. 
>> When 
>> > used without a unit, the unit is assumed to be pixels. However, any of 
>> > the following unit identifiers can be used: `px`, `cm`, `in`, `inch` 
>> and 
>> > `%`. There must not be any spaces between the number and the unit. 
>>
>> Why not `mm` as well?  After all millimeters is the 'proper' unit 
>> to use for such things in the metric world. 
>>
>> /bpj 
>>
>>

-- 
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 email 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/134301db-83b8-4a95-a550-8cf46eb10f0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 3884 bytes --]

Re: Release road map - 1.14 and beyond

[BP Jonsson]

Den 2015-07-27 23:28, Tim St. Clair skrev:
> then if that's the case, what about vw and vh? These are formats used by
> html that are a width and height relative to the browser viewport. I've
> used them. I think once you set an arbitrary restriction in place, an
> exception for it immediately comes up.

Probably a case can be made for supporting, at least as in passing 
through, all units which CSS and LaTeX support.

CSS: em, ex, ch, rem, vw, vh, vmin, vmax, %, cm, mm, in, px, pt, pc

LaTeX: pt, mm, cm, in, ex, em, bp, pc, dd, cc, sp

Note: a CSS "pt" is the same thing as a LaTeX "bp". Perhaps the 
HTML reader could replace "pt" with "bp" and the HTML writer 
replace "bp" with "pt"?

The alphabetical list of all the unique abbreviations (thus 
ignoring the ambiguity of "pt") is:

%
bp
cc
ch
cm
dd
em
ex
in
mm
pc
pt
px
rem
sp
vh
vmax
vmin
vw

/bpj

>
> On Tuesday, 28 July 2015 06:04:05 UTC+10, mb21 wrote:
>>
>> @BP Josson, added millimeters on my branch as well now:
>> https://github.com/mb21/pandoc/tree/new-image-attributes (although I
>> personally prefer writing 6cm to 60mm ;)
>>
>> On Monday, July 27, 2015 at 8:31:48 PM UTC+2, BP Jonsson wrote:
>>>
>>> Den 2015-07-26 20:22, mb21 skrev:
>>>> Okay, I rebased from master and implemented the link attributes:
>>>> https://github.com/mb21/pandoc/tree/new-image-attributes
>>>>
>>>> Still not quite sure where we're going with this... I don't think we
>>> need
>>>> Attr on every element (it's not worth the effort just for consistency),
>>> but
>>>> at least on Table and Math, so we can reference tables and equations in
>>>> documents?
>>>>
>>>
>>> The readme on that branch says:
>>>
>>>> The `width` and `height` attributes on images are treated specially.
>>> When
>>>> used without a unit, the unit is assumed to be pixels. However, any of
>>>> the following unit identifiers can be used: `px`, `cm`, `in`, `inch`
>>> and
>>>> `%`. There must not be any spaces between the number and the unit.
>>>
>>> Why not `mm` as well?  After all millimeters is the 'proper' unit
>>> to use for such things in the metric world.
>>>
>>> /bpj
>>>
>>>
>

Re: Release road map - 1.14 and beyond

[BP Jonsson]

I should add that the "bp" abbreviation has the virtue of being 
unambiguous.  For what its worth I've been using _bp_ wherever 
possible in LaTeX for the last decade at least.

Den 2015-07-27 23:56, BP Jonsson skrev:
> Note: a CSS "pt" is the same thing as a LaTeX "bp". Perhaps the
> HTML reader could replace "pt" with "bp" and the HTML writer
> replace "bp" with "pt"?
>
> The alphabetical list of all the unique abbreviations (thus
> ignoring the ambiguity of "pt") is:
>
> %
> bp
> cc
> ch
> cm
> dd
> em
> ex
> in
> mm
> pc
> pt
> px
> rem
> sp
> vh
> vmax
> vmin
> vw
>
> /bpj
>
>>
>> On Tuesday, 28 July 2015 06:04:05 UTC+10, mb21 wrote:
>>>
>>> @BP Josson, added millimeters on my branch as well now:
>>> https://github.com/mb21/pandoc/tree/new-image-attributes
>>> (although I
>>> personally prefer writing 6cm to 60mm ;)
>>>
>>> On Monday, July 27, 2015 at 8:31:48 PM UTC+2, BP Jonsson wrote:
>>>>
>>>> Den 2015-07-26 20:22, mb21 skrev:
>>>>> Okay, I rebased from master and implemented the link attributes:
>>>>> https://github.com/mb21/pandoc/tree/new-image-attributes
>>>>>
>>>>> Still not quite sure where we're going with this... I don't
>>>>> think we
>>>> need
>>>>> Attr on every element (it's not worth the effort just for
>>>>> consistency),
>>>> but
>>>>> at least on Table and Math, so we can reference tables and
>>>>> equations in
>>>>> documents?
>>>>>
>>>>
>>>> The readme on that branch says:
>>>>
>>>>> The `width` and `height` attributes on images are treated
>>>>> specially.
>>>> When
>>>>> used without a unit, the unit is assumed to be pixels.
>>>>> However, any of
>>>>> the following unit identifiers can be used: `px`, `cm`, `in`,
>>>>> `inch`
>>>> and
>>>>> `%`. There must not be any spaces between the number and the
>>>>> unit.
>>>>
>>>> Why not `mm` as well?  After all millimeters is the 'proper' unit
>>>> to use for such things in the metric world.
>>>>
>>>> /bpj
>>>>
>>>>
>>
>

Re: Release road map - 1.14 and beyond

[mb21]

[-- Attachment #1.1: Type: text/plain, Size: 3520 bytes --]

Note that this discussion has already taken place 
at https://github.com/jgm/pandoc/issues/261 (over the course of a couple of 
years). Adding millimeter as a synonym for 0.1 centimeter was easy, but if 
you want to use vw and vh, just write ![](image.png){ style=50vw } or maybe 
better ![](image.png){ width=50% } which, depending on your CSS, has mostly 
the same effect. Finally, I'd rather stick to those units most people 
understand, If you really need an image that's 1 point wide (really?), you 
can still write 0.01389 inch.


On Monday, July 27, 2015 at 11:56:49 PM UTC+2, BP Jonsson wrote:
>
> Den 2015-07-27 23:28, Tim St. Clair skrev: 
> > then if that's the case, what about vw and vh? These are formats used by 
> > html that are a width and height relative to the browser viewport. I've 
> > used them. I think once you set an arbitrary restriction in place, an 
> > exception for it immediately comes up. 
>
> Probably a case can be made for supporting, at least as in passing 
> through, all units which CSS and LaTeX support. 
>
> CSS: em, ex, ch, rem, vw, vh, vmin, vmax, %, cm, mm, in, px, pt, pc 
>
> LaTeX: pt, mm, cm, in, ex, em, bp, pc, dd, cc, sp 
>
> Note: a CSS "pt" is the same thing as a LaTeX "bp". Perhaps the 
> HTML reader could replace "pt" with "bp" and the HTML writer 
> replace "bp" with "pt"? 
>
> The alphabetical list of all the unique abbreviations (thus 
> ignoring the ambiguity of "pt") is: 
>
> % 
> bp 
> cc 
> ch 
> cm 
> dd 
> em 
> ex 
> in 
> mm 
> pc 
> pt 
> px 
> rem 
> sp 
> vh 
> vmax 
> vmin 
> vw 
>
> /bpj 
>
> > 
> > On Tuesday, 28 July 2015 06:04:05 UTC+10, mb21 wrote: 
> >> 
> >> @BP Josson, added millimeters on my branch as well now: 
> >> https://github.com/mb21/pandoc/tree/new-image-attributes (although I 
> >> personally prefer writing 6cm to 60mm ;) 
> >> 
> >> On Monday, July 27, 2015 at 8:31:48 PM UTC+2, BP Jonsson wrote: 
> >>> 
> >>> Den 2015-07-26 20:22, mb21 skrev: 
> >>>> Okay, I rebased from master and implemented the link attributes: 
> >>>> https://github.com/mb21/pandoc/tree/new-image-attributes 
> >>>> 
> >>>> Still not quite sure where we're going with this... I don't think we 
> >>> need 
> >>>> Attr on every element (it's not worth the effort just for 
> consistency), 
> >>> but 
> >>>> at least on Table and Math, so we can reference tables and equations 
> in 
> >>>> documents? 
> >>>> 
> >>> 
> >>> The readme on that branch says: 
> >>> 
> >>>> The `width` and `height` attributes on images are treated specially. 
> >>> When 
> >>>> used without a unit, the unit is assumed to be pixels. However, any 
> of 
> >>>> the following unit identifiers can be used: `px`, `cm`, `in`, `inch` 
> >>> and 
> >>>> `%`. There must not be any spaces between the number and the unit. 
> >>> 
> >>> Why not `mm` as well?  After all millimeters is the 'proper' unit 
> >>> to use for such things in the metric world. 
> >>> 
> >>> /bpj 
> >>> 
> >>> 
> > 
>
>

-- 
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 email 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/ac3237e2-c984-4360-a3f2-4c1ff883ff4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 5741 bytes --]

Re: Release road map - 1.14 and beyond

[mb21]

[-- Attachment #1.1: Type: text/plain, Size: 692 bytes --]

@jgm so, should I make a pull request or continue adding Attrs to more 
elements on the new-image-attributes branch? :P

-- 
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 email 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/408eafa7-541e-4fb4-ade8-93cc0597c095%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 1103 bytes --]

Re: Release road map - 1.14 and beyond

[John MacFarlane]

+++ mb21 [Jul 30 15 09:42 ]:
>   @jgm so, should I make a pull request or continue adding Attrs to more
>   elements on the new-image-attributes branch? :P

Not sure.  It feels wrong somehow to keep adding Attr to more and
more elements.  I'm comfortable with what you've done with
Image, because that's a very common request and you've made
appropriate changes to the writers.  Beyond that I'm not
sure.

Re: Release road map - 1.14 and beyond

[mb21]

[-- Attachment #1.1: Type: text/plain, Size: 2808 bytes --]

Great, yeah I would like to see the image attributes shipped with the next 
major release. I made a pull request: 
https://github.com/jgm/pandoc/pull/2351

However, I also see the argument of: if we're already making breaking 
changes, we might do a bunch of them, so whatever we can agree on to do 
now, we probably should.

It feels wrong somehow to keep adding Attr to more and more elements.


I know what you mean, but maybe it's just because Attr is kind of a hacky 
type in itself (a three-tuple and not even newtype). But is there a better 
alternative to adding Attr to more things? i.e. what would be ideal?

Maybe Attr should ultimately be a GADT with record syntax (GADTs are a 
GHC-extension that effectively provide subtyping, see 
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-extensions.html#gadt). 
Something like:

    data Attr where
      GeneralAttr :: { uid    :: String              -- unique identifier
                     , cls    :: [String]            -- classes
                     , others :: [(String, String)]  -- key-value pairs for 
filters etc
                     } -> Attr
      ImageAttr   :: { uid    :: String
                     , cls    :: [String]
                     , width  :: Dimension
                     , height :: Dimension
                     , figure :: Bool
                     , others :: [(String, String)]
                     } -> Attr
      CodeAttr    :: { uid    :: String
                     , cls    :: [String]
                     , lang   :: String
                     , others :: [(String, String)]
                     } -> Attr
      HeaderAttr  :: { uid    :: String
                     , cls    :: [String]
                     , numbered :: Bool
                     , others :: [(String, String)]
                     } -> Attr
      deriving (Show)


    nullAttr :: Attr
    nullAttr = GeneralAttr "" [] []


    -- sample functions


    getUid :: Attr -> String
    getUid attr = uid attr


    getClass :: Attr -> [String]
    getClass = cls


But even so, we would still have to add Attr to a few more elements (mainly 
to get ids to reference and classes to customize/specialize elements)... or 
is there a better way?

-- 
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 email 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/c0450ce6-34ad-4f31-b142-62f6fc49bf29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 18010 bytes --]

Re: Release road map - 1.14 and beyond

[Pablo Rodríguez]

On 08/07/2015 03:54 PM, mb21 wrote:
> [...]
>    data Attrwhere
>      GeneralAttr::{uid    ::String             --unique identifier
>                   ,cls    ::[String]           --classes
>                   ,others ::[(String,String)] --key-value pairs
>                   }->Attr

Only a simple request: would it be possible to add language to general
attributes?

In multilingual documents, language is a basic attribute and I think it
should be handled as an special one (such as identifiers and classes).


Pablo
-- 
http://www.ousia.tk

Re: Release road map - 1.14 and beyond

[mb21]

[-- Attachment #1.1: Type: text/plain, Size: 4411 bytes --]

Has anyone thought about this some more?

@jgm mentioned recently somewhere 
<https://github.com/jgm/pandoc/issues/895#issuecomment-148197399> that we 
should at least convert Attr from a type to a newtype. That means changing 
`(ident, cls, kvs)` to `Attr ident cls kvs` in lots and lots of places, or 
is there an unorthodox way around this? (Also, if I were to do this, I'd 
probably put it in a separate commit that's after the image/link attributes 
in the history if that's okay... in the same pull request though?)

About going even further and defining Attr as a GADT (see my previous 
message below), it's probably a tradeoff away from the flexibility of the 
list of string tuples (which permits arbitrary key value pairs without 
breaking the API for anyone) towards using Haskell's type system even more 
and embedding the semantics of the attributes directly in the types. I'd 
certainly prefer GADTs from a theoretical point of view, but seeing how 
hard it is to change pandoc-types I'm not so sure anymore (though future 
changes to, say, the image attribute would only affect users that make use 
of the ImageAttr constructor, thus being much more limited in scope). Finally, 
if we were to stick with dumb key value pairs, should we at least make it a 
HashMap?

Basically, the question still is: what would be the optimal approach of 
handling attributes? So we can get it as right as possible this time.


On Friday, August 7, 2015 at 3:54:41 PM UTC+2, mb21 wrote:
>
> Great, yeah I would like to see the image attributes shipped with the next 
> major release. I made a pull request: 
> https://github.com/jgm/pandoc/pull/2351
>
> However, I also see the argument of: if we're already making breaking 
> changes, we might do a bunch of them, so whatever we can agree on to do 
> now, we probably should.
>
> It feels wrong somehow to keep adding Attr to more and more elements.
>
>
> I know what you mean, but maybe it's just because Attr is kind of a hacky 
> type in itself (a three-tuple and not even newtype). But is there a better 
> alternative to adding Attr to more things? i.e. what would be ideal?
>
> Maybe Attr should ultimately be a GADT with record syntax (GADTs are a 
> GHC-extension that effectively provide subtyping, see 
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-extensions.html#gadt). 
> Something like:
>
>     data Attr where
>       GeneralAttr :: { uid    :: String              -- unique identifier
>                      , cls    :: [String]            -- classes
>                      , others :: [(String, String)]  -- key-value pairs 
> for filters etc
>                      } -> Attr
>       ImageAttr   :: { uid    :: String
>                      , cls    :: [String]
>                      , width  :: Dimension
>                      , height :: Dimension
>                      , figure :: Bool
>                      , others :: [(String, String)]
>                      } -> Attr
>       CodeAttr    :: { uid    :: String
>                      , cls    :: [String]
>                      , lang   :: String
>                      , others :: [(String, String)]
>                      } -> Attr
>       HeaderAttr  :: { uid    :: String
>                      , cls    :: [String]
>                      , numbered :: Bool
>                      , others :: [(String, String)]
>                      } -> Attr
>       deriving (Show)
>
>
>     nullAttr :: Attr
>     nullAttr = GeneralAttr "" [] []
>
>
>     -- sample functions
>
>
>     getUid :: Attr -> String
>     getUid attr = uid attr
>
>
>     getClass :: Attr -> [String]
>     getClass = cls
>
>
> But even so, we would still have to add Attr to a few more elements 
> (mainly to get ids to reference and classes to customize/specialize 
> elements)... or is there a better way?
>
>

-- 
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 email 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/32e7774a-9532-497b-baa5-4d8730ddfb7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 14262 bytes --]

Re: Release road map - 1.14 and beyond

[Nick Yakimov]

[-- Attachment #1.1: Type: text/plain, Size: 2165 bytes --]

What about making key-value part of `Attr` into something like `MetaValue`?

E.g., from the top of my head,

```haskell
data Attr = Attr { attrId      :: String
                 , attrClasses :: [String]
                 , attrKVs     :: [(String, AttrValue)]
                 }
                 deriving (...)
```

`AttrValue` could be a simple type with several constructors, or maybe an 
existential type (something like `Data.Dynamic`? sorry, I'm not good enough 
with Haskell to determine if that would be viable)

I also still maintain that basically everything (all `Block`s and 
`Inline`s) could have `Attr` attached. From generality point of view, this 
is sound (somewhat). Implementation can be a horrific nightmare though. 
Pattern synonyms might alleviate some pains. One case where this 
immediately seems useful is matching source lines to output (something I've 
been thinking about lately) -- reader could store auxiliary line numbers in 
this "universal Attr".

One option for generalising `Attr`, that seems somewhat reasonable, is 
defining wrappers for `Block` and `Inline`, e.g. with another type ctor:

```haskell
data Block =
        ...
        | BlockAttr Attr Block
        ...
```

Or maybe with a type like

```haskell
data AttrWrapper = BlockAttr Attr Block | InlineAttr Attr Inline
```

First option would probably require fewer changes to readers/writers, but 
somehow seems less "correct".

Again, pattern synonyms can alleviate some of the pains here.

P.S. This all is not as well thought-through as I'd like to, so treat this 
as a stream of consciousness.

-- 
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 email 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/7e68bb74-ba2c-4d4f-92c7-ec4c60dfea09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 3056 bytes --]

Re: Release road map - 1.14 and beyond

[Nikolay Yakimov]

[-- Attachment #1: Type: text/plain, Size: 2267 bytes --]

Sorry, too much time spent on GitHub. A pretty-formatted version of my
previous message:


What about making key-value part of Attr into something like MetaValue?
E.g., from the top of my head,

data Attr = Attr { attrId      :: String
                 , attrClasses :: [String]
                 , attrKVs     :: [(String, AttrValue)]
                 }
                 deriving (...)

AttrValue could be a simple type with several constructors, or maybe an
existential type (something like Data.Dynamic? sorry, I’m not good enough
with Haskell to determine if that would be viable)

I also still maintain that basically everything (all Blocks and Inlines)
could have Attr attached. From generality point of view, this is sound
(somewhat). Implementation can be a horrific nightmare though. Pattern
synonyms might alleviate some pains. One case where this immediately seems
useful is matching source lines to output (something I’ve been thinking
about lately) — reader could store auxiliary line numbers in this
“universal Attr”.

One option for generalising Attr, that seems somewhat reasonable, is
defining wrappers for Block and Inline, e.g. with another type ctor:

data Block =
        ...
        | BlockAttr Attr Block
        ...

Or maybe with a type like

data AttrWrapper = BlockAttr Attr Block | InlineAttr Attr Inline

First option would probably require fewer changes to readers/writers, but
somehow seems less “correct”.

Again, pattern synonyms can alleviate some of the pains here.

P.S. This all is not as well thought-through as I’d like to, so treat this
as a stream of consciousness.
​

-- 
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 email 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/CA%2BhqrpX-6SPW3cnKv09zf9B06NQHkaM8UPag5Jt%3D5xtBGzJp7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: Type: text/html, Size: 15653 bytes --]

Re: Release road map - 1.14 and beyond

[mb21]

[-- Attachment #1.1: Type: text/plain, Size: 3055 bytes --]

Thanks for the input Nick. I've been thinking about something like [(String, 
AttrValue)] as well,  but that still leaves a lot unchecked by the type 
system. It would be nice if you could look up in Definition.hs that for 
example whenever there is a key "width" its value must be a "Dimension". 
Maybe we can make the GADT approach work by providing functions in 
Builder.hs that take Strings. The type signature of those functions 
wouldn't need to change again (e.g. setKV :: String -> String -> Attr -> 
Attr) while we could continue adding type-safe fields to attributes when a 
new feature in pandoc requires to do so.


On Friday, October 30, 2015 at 7:07:29 PM UTC+1, Nick Yakimov wrote:
>
> Sorry, too much time spent on GitHub. A pretty-formatted version of my 
> previous message:
>
>
> What about making key-value part of Attr into something like MetaValue?
> E.g., from the top of my head,
>
> data Attr = Attr { attrId      :: String
>                  , attrClasses :: [String]
>                  , attrKVs     :: [(String, AttrValue)]
>                  }
>                  deriving (...)
>
> AttrValue could be a simple type with several constructors, or maybe an 
> existential type (something like Data.Dynamic? sorry, I’m not good enough 
> with Haskell to determine if that would be viable)
>
> I also still maintain that basically everything (all Blocks and Inlines) 
> could have Attr attached. From generality point of view, this is sound 
> (somewhat). Implementation can be a horrific nightmare though. Pattern 
> synonyms might alleviate some pains. One case where this immediately seems 
> useful is matching source lines to output (something I’ve been thinking 
> about lately) — reader could store auxiliary line numbers in this 
> “universal Attr”.
>
> One option for generalising Attr, that seems somewhat reasonable, is 
> defining wrappers for Block and Inline, e.g. with another type ctor:
>
> data Block =
>         ...
>         | BlockAttr Attr Block
>         ...
>
> Or maybe with a type like
>
> data AttrWrapper = BlockAttr Attr Block | InlineAttr Attr Inline
>
> First option would probably require fewer changes to readers/writers, but 
> somehow seems less “correct”.
>
> Again, pattern synonyms can alleviate some of the pains here.
>
> P.S. This all is not as well thought-through as I’d like to, so treat this 
> as a stream of consciousness.
> ​
>

-- 
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 email 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/6a384350-9b66-419e-84b5-0e95cabe0b00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 15952 bytes --]