-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change Lua representation, behavior of some types #7718
Comments
That's could be a whole subject on its own!
... Footnotes
|
I created a draft PR for the first two points here: #7719. It's WIP. |
The first two points above have been implemented, which leaves the third.
Let's turn it into a separate issue! Please open one, idealy with a wishlist for features and changes to current objects. Consistent handling of attr is already a really good point. I'm looking to turn all types with Attr into userdata objects that provide better functions, but which behave in a way that ensures backwards compatibility. |
Suggestion for the representation of Table{Head,Foot,Body}:
Suggestions for Row values:
I think it makes sense to treat Row values as sequences, so I'd prefer the breaking change. |
I think I'd be okay with a breaking change here (as long as we telegraph it clearly). |
On the other hand, using |
Maybe I'm approaching this wrong and we should even discourage manual traversal of tables. I like the proposal by @kysko, perhaps we should put the focus on walk methods for tables parts. Modifying rows and cells would become much easier. Pseudo-code: function Table (tbl)
return tbl:walk{
Row = function (row)
if row.classes:contains 'important' then
return row:walk { Cell = modify_important_cell }
end
end
}
end |
Would the traversal idea allow one to modify e.g. the number of cells in a row? |
I believe it would be possible to allow splicing the same way we do for Block and Inline values. |
This does seem like a nice interface. I was struck by |
Having walk methods on all elements would be really nice. I'll give it a go. Treating all Block elements the same would be the simplest approach. Not sure if it's also the best? |
Yes, simplest -- but what about the |
That can be tricky with row/col spans more than 1, even now. When you do this in Haskell, you have the "Annotated Table" (iirc) to help you, whereas in Lua script I have to build a similar "complementary" grid from scratch for such kind of things. So I have my way of coping, I don't want to turn this into an issue, but if e.g. cell deletion/creation is to be made easier, perhaps consider "sharing" the "Annotated Table" with Lua filter users, if that's even possible (or useful). |
Question about the To give an example pandoc.SmallCaps('Hello'):walk{
SmallCaps = function (sc) return pandoc.Emph(sc.content) end,
Str = function (_) return pandoc.Str 'Bye' end
} The above could return either The current work in progress can be found in this branch. |
Using an AnnotatedTable would certainly be nice, but we'd probably support it in a way similar to |
In favor of applying |
OK, I've opened #7732; adding walk to |
The more I think about it, the more I'm changing my mind about how Applying |
One remaining question I have is which objects should get a The |
I definitely think it would be nice to allow
to walk the single element (subtree only), returning an element of the same type, or
to walk the subtree and the element itself, returning a list. |
I've made the changes but didn't get to update the PR yet.
The `walk` method is added to Pandoc objects and to lists created with
`Blocks()` or `Inlines()`. So both of these work
Blocks{element}:walk{}
Inlines{element}:walk{}
as does
div.content:walk{}
The generic `List{element}:walk{}` is not supported yet, but it should
be possible to add it.
Getting a plain `{element}:walk{}` to work is, I believe, impossible due
to the way tables work in Lua.
|
That sounds great! |
As a working example that might help to see how to make table model human readable: It shows a conversion from csv to html (tables). To make result dynamic (filter, pagination) it uses javascript. Adds javascript stuff with A first solution was created on beautifulsoap python library, but with help of @mb21 was able to turn into a lua filter (so all works inside pandoc). But result is pretty cryptic: I will put here for ease reading: working filter:
Notice the part of manipulate This pseudo code is what I would expect to be available:
to turn:
into
Hope this looks like something useful and a clear example on how ease to customize results from this amazing pandoc engine |
I'm in favor of adding proper fields to TableHead, Row, and TableFoot, I have a branch for this in the works. The downside is that we'd loose backwards compatibility. I added code to hslua-2.1 that would allow to keep things backwards compatible, but there are other changes that would be good to get into that release, and it might take a few more weeks before I publish it. |
I think it would be a good change nonetheless. Presently it's pretty mysterious how to modify tables. |
Proposed changes:
Block and Inline lists (
[Block]
/[Inline]
) each get a separate list type. This should improve error messages slightly. It would also allow the addition of type-specific methods, enabling code likedoc.blocks:walk{my-lua-filter}
.The concepts of
Inlines
andBlocks
must be defined in the documentation either way, so having actual Lua types to match seems consistent. ExplicitInlines
andBlocks
constructors could be added, too.Side note: a
pandoc.Inlines
constructor could replace thepandoc.utils.text
function.Remove
.t
/.tag
from MetaValue objects. The current behavior is inconsistent, as MetaString and MetaBool values are pushed as strings and booleans, respectively; they don't have a tag. MetaBlocks and MetaInlines will be treated as[Block]
and[Inline]
values. This change requires the previous point to be implemented, too.Revisit tables. Tables are currently awkward to work with. E.g.,
Caption
values must always be given as{long = ..., short = ...}
, which is inconvenient. It should be possible to just pass Blocks or Inlines in place of a Caption element.The text was updated successfully, but these errors were encountered: