Displaying reference key or prefix for publications

[inukshuk]

Displaying reference key or prefix for publications

[inukshuk]

We could add the key to each reference as a data attribute then you could add a little JavaScript to extract it from there. Or, the nicer approach would be for us to use a little HTML template into which the reference is rendered; we could then expose via the configuration to give you full control. Something like:

reference_template: <abbr>#{key}</abbr>#{reference}

We simply run each generated reference through that template using string interpolation. What do you think?

(looping in @ashinkarov since he's working on scholar at the moment as well)

Providing a method to specify HTML template is good. I would suggest that having an ordered list based on type would be good too. That is, prefixed with a string.

[inukshuk]

I just added a first implementation. Now the question is what values we expose to the template. So far it is reference and key; we could add the type.

What about more custom requirements? We could add the current index in the list. For more control we'd need a kind of callback function that receives the entry and can return a hash. The only question is whether or not this is already too complex for the regular user and the more advanced users could just extend the tag anyway.

I would think most users will either use the key or some form of an ordered list with a string prefix. Do you have an example up on how to use what you checked in?

Advanced users would probably just extend the tag.

[inukshuk]

You can see an example here: https://github.com/inukshuk/jekyll-scholar/blob/master/features/bibtex.feature#L94

Basically you can configure the bibliography_template and in there you currently have access to %{reference} %{index} and %{key} – and I forgot to add %{type}

[inukshuk]

I also added a configuration option for reference_tagname so that you can configure what the reference will be rendered into (defaults to a span).

Thanks.

I think we should work out a method to cleanly interface scholar with extras. Extras does break because of the new additions to scholar. Perhaps having an -extras or some clean interface after which I can pick up the commands from there to do my extras parsing ... ?

[ashinkarov]

@hdpatel, is there a reason why do you keep extras in a separate repository? I mean extras are great, but you don't add that much of a functionality there, so it seems to me that your stuff can be added directly into jekyll-scholar with some configuration parameters. In that case whoever changes one thing will have to take into account another...

[inukshuk]

Which changes broke the API there? The reference_tag should continue to work like before and the bibliography_tag was newly added.

[inukshuk]

@ashinkarov in the beginning there were a few things in extras which were too specific to add them to scholar directly, that's why we decided to go for two separate repositories if I remember correctly.

Scholar has become more flexible in the meantime so we might be able to add most (or all?) functionality directly. @hdpatel will know that better than I do : )

@ashinkarov: Two main reasons: 1) I just started it as a separate project to not bother @inukshuk much with my inexperienced abilities in ruby. Looking at the code you'll see that I am truly inexperienced. 2) scholar was not as flexible as it is now. Thanks to @inukshuk, it has evolved significantly in the short period of time.

@inukshuk: My problem is that I had customizations for bibliography with my own bibliography_bytype that allowed for parameters after it. For example:

%{ bibliography_bytype articles, Journals %}

I believe combining the features of scholar such as custom bibs using "-f" and queries "--query" will kill extras =)

[ashinkarov]

Right, so both of you guys are saying that there is nothing but historical reasons. It seems that it's time to join the efforts and join extras into scholar. It's just my opinion from the outside, and I might not know something. However, it would be easier for the users to install and configure one thing instead of two, and for the developers who might be not aware that the other thing exists. Just my twopence :)

[inukshuk]

Yes we changed the argument format completely for the 1.0.0 release to make it easier to maintain. I started jekyll scholar but there are a number of people who use it more than I do myself, so I'm not always in the best position to judge what should or shouldn't be added. Basically, I think every tag, converter etc. should be added that has at least some potential appeal to everyone (this typically means it should be at least somewhat configurable). To make maintenance easier it should come with a test case, too. Other than that I really don't have a strong opinion.

I know that the query-support was a big step, so if we can implement the extras features directly in scholar all the better. @hdpatel you're not bothering me at all – it's actually the other way around, I think it's much easier if we can share the maintenance efforts.

@ashinkarov you beat me to it. I fully agree with you there.

@inukshuk, @ashinkarov: I'm in agreement. We should integrate extras features into scholar. How should we proceed with that? FYI: I won't have time to really work on the code until after 3 weeks (exams and such).

[inukshuk]

@hdpatel I think the best way forward would be to open an issue for each feature that's currently in extras. This way we can look at each one and see whether or not it is now covered by existing parameters; if it isn't we can move them over or implement them differently – whatever makes more sense.