BBT schomd methods signature change

[retorquere]

Hi Karl,

I'm going to release a change to BBT somewhere today or tomorrow which changes the schomd calls you use. Instead of calling schomd.bibliographybbl(keys), you will have to call scomd.bibliography(keys, {format: 'bbl'}). I've looked at your scheme code, but my lisp-fu is shamefully weak, so I can't submit a pull request for you.

[KarlHegbloom]

Ok. It won't affect it very much. That's easy to change. I actually wanted
to do the same thing but thought it might break other people's code in
other editor plugins.

Please look at my propachi-texmacs repository and at the bootstrap.js
there. I am loading a citeproc.js that sets the feature to wrap URL and
DOI. It also must have the bbl output format, and is incompatible with BBT
because they both monkey patch or load a new citeproc.js. The citeproc.js
that I'm loading is in my fork of it there on github.

I wonder if that wrap url and doi feature can be enabled via a monkey patch
that does not reload the entire citeproc?

On Tue, Jun 21, 2016, 03:34 retorquere [email protected] wrote:

Hi Karl,

I'm going to release a change to BBT somewhere today or tomorrow which
changes the schomd calls you use. Instead of calling
schomd.bibliographybbl(keys), you will have to call scomd.bibliography(keys,
format: 'bbl'). I've looked at your scheme code, but my lisp-fu is
shamefully weak, so I can't submit a pull request for you.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#3, or mute
the thread
https://github.com/notifications/unsubscribe/AACslot3p69L65_LisnCuK1N4qmANXzmks5qN7AqgaJpZM4I6iKZ
.

[retorquere]

I was just looking how to enable that. Super annoying how badly documented this stuff is.

[KarlHegbloom]

I was committing to the wrong branch on my propachi-texmacs. I just changed
default to master so now you can see it. I'll fix branch names later... or
will add one to track upstream propachi-upper by Frank Bennet. It probably
won't ever change much, so no worries, not many changes to track.

On Tue, Jun 21, 2016, 08:30 retorquere [email protected] wrote:

I was just looking how to enable that. Super annoying how badly documented
this stuff is.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACslqYY5NB6_Sf8VDDjkwKvB1Ax_xDvks5qN_VugaJpZM4I6iKZ
.

[retorquere]

I can enable the setting, no monkey-patching required, but the URL is offered to the @url method pre-escaped. Still need a way around that.

[retorquere]

Doesn't look like there is a way around that. I could try to undo the escaping, but that's going to get ugly fast. Monkey-patching it is, I suppose.

[retorquere]

And no monkey-patching, because this is deeply nested if statements... I've managed to get something to work by maintaining global state, but it's not pretty. at. all.

[KarlHegbloom]

Don't worry about the escaping. It seems to work fine somehow. I never knew
about it, and it just works.

On Tue, Jun 21, 2016, 09:08 retorquere [email protected] wrote:

And no monkey-patching, because this is deeply nested if statements...
I've manager to get something to work by maintaining global state, but it's
not pretty. at. all.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACslixk_9KsgWICxobwbjTeaMwQJ0Loks5qN_5tgaJpZM4I6iKZ
.

[retorquere]

Not for markdown it doesn't.

[KarlHegbloom]

Hmmm. Let's look inside citeproc to see what it's doing and find out why.

On Tue, Jun 21, 2016, 09:39 retorquere [email protected] wrote:

Not for markdown it doesn't.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACslmDFT3AZxpNBm7xCYbrkJ3mdm5GHks5qOAWigaJpZM4I6iKZ
.

[KarlHegbloom]

My train is here in a few minutes... errands today, and writing
transcripts and a court document. But I can give this some time within the
next few days.

It occurs to me that I need to check and be sure that clicking links in PDF
generated by this works as expected. I recall visiting doi.org that way,
so am sure I tested it. Will double check later.

On Tue, Jun 21, 2016, 09:40 Karl Hegbloom [email protected] wrote:

Hmmm. Let's look inside citeproc to see what it's doing and find out why.

On Tue, Jun 21, 2016, 09:39 retorquere [email protected] wrote:

Not for markdown it doesn't.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACslmDFT3AZxpNBm7xCYbrkJ3mdm5GHks5qOAWigaJpZM4I6iKZ
.

[retorquere]

I've looked at citeproc, but that's some dense and tangled code... currently, the processor spits out a literal text "http://doi.org/" (which it generates itself, it isn't in the reference), and then calls "@DOI/true" with the pre-escaped DOI (which is no good to me, because for markdown the label must be escaped, but the URL must not be). If I just let that pass, I get something like http://doi.org/[10.1128/genomeA.00323\-13](http://dx.doi.org/10.1128/genomeA.00323-13).

Here and following lines is how I currently handle it, but it's not pretty.

[KarlHegbloom]

It looks fine to me. Deep Magic, but elegant enough.

On Tue, Jun 21, 2016, 09:51 retorquere [email protected] wrote:

I've looked at citeproc, but that's some dense and tangled code...
currently, the processor spits out a literal text "http://doi.org/"
(which it generates itself, it isn't in the reference), and then calls
"@DOI/true" with the pre-escaped DOI (which is no good to me, because for
markdown the label must be escaped, but the URL must not be). If I just let
that pass, I get something like
http://doi.org/[10.1128/genomeA.00323\-13](http://dx.doi.org/10.1128/genomeA.00323-13).

Here
https://github.com/retorquere/zotero-better-bibtex/blob/2a2e7d418f2f699a9a5a94528408b623cc4e4e43/chrome/content/zotero-better-bibtex/schomd.coffee#L16
and following lines is how I currently handle it, but it's not pretty.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACsloHrkZpA-6ZM84cUprBwzcHxuzP1ks5qOAh-gaJpZM4I6iKZ
.

[KarlHegbloom]

Did you see what I did to make url's appear on their own line in footnotes
and bibliographies? And for href's inside running text to make the link
appear as a footnote...

On Tue, Jun 21, 2016, 09:54 Karl Hegbloom [email protected] wrote:

It looks fine to me. Deep Magic, but elegant enough.

On Tue, Jun 21, 2016, 09:51 retorquere [email protected] wrote:

I've looked at citeproc, but that's some dense and tangled code...
currently, the processor spits out a literal text "http://doi.org/"
(which it generates itself, it isn't in the reference), and then calls
"@DOI/true" with the pre-escaped DOI (which is no good to me, because for
markdown the label must be escaped, but the URL must not be). If I just let
that pass, I get something like
http://doi.org/[10.1128/genomeA.00323\-13](http://dx.doi.org/10.1128/genomeA.00323-13).

Here
https://github.com/retorquere/zotero-better-bibtex/blob/2a2e7d418f2f699a9a5a94528408b623cc4e4e43/chrome/content/zotero-better-bibtex/schomd.coffee#L16
and following lines is how I currently handle it, but it's not pretty.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACsloHrkZpA-6ZM84cUprBwzcHxuzP1ks5qOAh-gaJpZM4I6iKZ
.

[retorquere]

It relies on two assumptions which I really feel I should not be counting on:

• this code will only ever run synchronously, and no two states will ever be active at the same time (not a particularly safe assumption given where Zotero is moving), and
• the user will never enter that DOI url by hand, because I'm blindly chucking it.

not happy with that at all, but the fact I need to enable a development option gives me hope there's still opportunity to change this behavior.

[retorquere]

No, I didn't see that, where can I find those?

[KarlHegbloom]

Then we should think about how it ought to work and offer up a patch. Since
it's of by default it's probably safe to do that.

On Tue, Jun 21, 2016, 09:58 retorquere [email protected] wrote:

It relies on two assumptions which I really feel I should not be counting
on:

• this code will only ever run synchronously, and no two states will
  ever be active at the same time (not a particularly safe assumption given
  where Zotero is moving), and
• the user will never enter that DOI url by hand, because I'm blindly
  chucking it.

not happy with that at all, but the fact I need to enable a development
option gives me hope there's still opportunity to change this behavior.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACslr-59C94KEyYbZELBhNJ7w2DDUMwks5qOAoOgaJpZM4I6iKZ
.

[KarlHegbloom]

https://github.com/KarlHegbloom/zotero-texmacs-integration/blob/master/progs/zotero.scm#L1922

https://github.com/KarlHegbloom/zotero-texmacs-integration/blob/master/progs/zotero.scm#L2095

On Tue, Jun 21, 2016, 10:00 Karl Hegbloom [email protected] wrote:

Then we should think about how it ought to work and offer up a patch.
Since it's of by default it's probably safe to do that.

On Tue, Jun 21, 2016, 09:58 retorquere [email protected] wrote:

It relies on two assumptions which I really feel I should not be counting
on:

• this code will only ever run synchronously, and no two states will
  ever be active at the same time (not a particularly safe assumption given
  where Zotero is moving), and
• the user will never enter that DOI url by hand, because I'm blindly
  chucking it.

not happy with that at all, but the fact I need to enable a development
option gives me hope there's still opportunity to change this behavior.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACslr-59C94KEyYbZELBhNJ7w2DDUMwks5qOAoOgaJpZM4I6iKZ
.

[retorquere]

How it ought to work seems rather straightforward to me: @url and @doi should simply be offered the non-ecaped text (which is easy to escape using text_escape), and no doi prefix should be injected, when wrap_url_and_doi is true. But I've looked at the citeproc-js code that does these things, and I have no idea how it hangs together an awful lot of state and dynamic code lives there. I wouldn't know where to begin finding out even just in what order they're called - the doi prefix is escaped after the @doi function is called, for example, but the prefix appears before the results of @doi.

[rmzelle]

@fbennett, could you chime in? I'm hoping to use https://github.com/retorquere/zotero-citations to cite items from my Zotero library in markdown files in the Atom text editor. One issue is that Emiliano (@retorquere), the author of "zotero-citations", is having a hard time formatting DOIs correctly in markdown because he doesn't seem to have access to the raw unescaped DOI string. See also https://github.com/retorquere/zotero-citations/issues/27

(edit: @fbennett, looks like @retorquere already made some progress: https://github.com/retorquere/zotero-citations/issues/27#issuecomment-227528121)

[KarlHegbloom]

Some styles format the doi as "doi:nnnnn", while others use http://doi.org
as the prefix text. That part is not sent through @DOI/true, only the doi
number is.

On Tue, Jun 21, 2016, 11:55 Rintze M. Zelle [email protected]
wrote:

@fbennett https://github.com/fbennett, could you chime in? I'm hoping
to use https://github.com/retorquere/zotero-citations to cite items from
my Zotero library in markdown files in the Atom text editor. One issue is
that Emiliano (@retorquere https://github.com/retorquere), the author
of "zotero-citations", is having a hard time formatting DOIs correctly in
markdown because he doesn't seem to have access to the raw unescaped DOI
string. See also retorquere/zotero-citations#27
https://github.com/retorquere/zotero-citations/issues/27

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACslgRxnBfUXcvUPuvl5MSu6qIOK4JGks5qOCWSgaJpZM4I6iKZ
.

[fbennett]

@rmzelle Ping me if don't hear back during the weekend. Full-up with work this week.

[rmzelle]

I think we're good here, Frank. Sorry for the noise.

Rintze

On Tuesday, June 21, 2016, Frank Bennett [email protected] wrote:

@rmzelle https://github.com/rmzelle Ping me if don't hear back during
the weekend. Full-up with work this week.

[retorquere]

@KarlHegbloom the citations call has also changed (back), although I've aimed to keep the bbl behavior as you had it. For HTML/MD, it expects citation clusters as usual, after the BBL changes it would only give back the clusters that could be fully resolved. I've reverted that for HTML/MD; the idea is that the input and output array are of equal length, and that you can tell (part of) a cluster could not be converted to a citation because the equivalent position in the output array is null. The BBL changes filtered those out; I assume that's desirable for your bbl connection (although I don't really understand how), so I've made it so that for the bbl format specifically, it scrubs the array of null values before returning it.

[KarlHegbloom]

You can change it also. I'm not using it anymore. I'm only using the
OpenOffice integration wire protocol.

On Sun, Jun 26, 2016, 08:54 retorquere [email protected] wrote:

@KarlHegbloom https://github.com/KarlHegbloom the citations call has
also changed (back), although I've aimed to keep the bbl behavior as you
had it. For HTML/MD, it expects citation clusters as usual, after the BBL
changes it would only give back the clusters that could be fully resolved.
I've reverted that for HTML/MD; the idea is that the input and output array
are of equal length, and that you can tell (part of) a cluster could not be
converted to a citation because the equivalent position in the output array
is null. The BBL changes filtered those out; I assume that's desirable for
your bbl connection (although I don't really understand how), so I've made
it so that for the bbl format specifically, it scrubs the array of null
values before returning it.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACslozzKb6cfD31BBWg877WfRVrHQI2ks5qPpKTgaJpZM4I6iKZ
.

[retorquere]

So is the entire bbl/html stuff deprecated? If so, I'd rather remove it.

[KarlHegbloom]

Unless you want it for implementation of a drop in for bibtex later.

On Sun, Jun 26, 2016, 11:00 retorquere [email protected] wrote:

So is the entire bbl/html stuff deprecated? If so, I'd rather remove it.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACsluDNjGCpVgkmEAzIELbVJeM7gZ8Hks5qPrBBgaJpZM4I6iKZ
.

[retorquere]

It's not in my plans. What was the html version for? Can I remove both?

[retorquere]

This is what the reversal would look like: retorquere/zotero-better-bibtex@3ef1338 . No issue for you then?

[KarlHegbloom]

I used the html output for comparison testing.

On Sun, Jun 26, 2016, 13:53 retorquere [email protected] wrote:

This is what the reversal would look like:
retorquere/zotero-better-bibtex@3ef1338
retorquere/zotero-better-bibtex@3ef1338
. No issue for you then?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACslrIp9RFZCi-lwHmlQWgf6z1Ua5-_ks5qPtiagaJpZM4I6iKZ
.

[retorquere]

used, as in past tense?

[KarlHegbloom]

Yes. I have not been using it in a while. At first, I was planning to use
BBT for the TeXmacs to Zotero interface, because I thought the OpenOffice
protocol would be too difficult to do. But it turned out to not be very
difficult after all. It does a lot of the work for me, reducing the amount
of duplication of logic that I'd otherwise have to do. I like the way it
sort of takes control of the editor to fix up the fields that change when I
add a citation, for example. It also automatically maintains the
bibliography. The code at my end that does it is very simple and reused for
the citation fields as well as the bibliography.

I was using schomd for the bbl output method, but then wanted to enable the
URL and DOI wrappers... and then learned that in order to do that I had to
monkey-patch the citeproc. I then decided to go ahead and monkey patch the
integration.js as well, so that the zotero-texmacs-integration no longer
requires a patched copy of Juris-M or Zotero. (In order to make it use the
bbl outputFormat.) But then I ran into the incompatibility with BBT, since
it turns out that you are monkey patching the citeproc.js as well! So in
order to have it all working, I had to put the bbl outputFormat into the
"propachi-texmacs" that I created which drops in a new citeproc.js with the
features enabled that I need, as well as with the bbl outputFormat. It also
monkey patches the integration.js to turn on the bbl outputFormat.

The side effect is that it can not be enabled at the same time as BBT.

On Sun, Jun 26, 2016 at 2:30 PM retorquere [email protected] wrote:

used, as in past tense?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACslt3aOXSJgaB6FGUVvNDbP1zXp83fks5qPuF-gaJpZM4I6iKZ
.

[retorquere]

I don't follow anymore. There's only one place I monkey-patch Zotero's citeproc, and that's to add the markdown format, does that get in your way? I do otherwise load a separate citeproc, but that's in a different namespace, so that shouldn't bother anyone.

I don't like the idea that BBT can't be enabled at the same time as... well, anything else. So:

1. What should I change to accommodate your work?
2. Can the changes I've made to remove bbl support be merged into master without damage to you?

Still not entirely certain what working with the wire protocol does in the context of your texmacs work, but I agree it is to be preferred over my changes. I just don't understand how it works.

[KarlHegbloom]

I did not realize that your citeproc is being loaded into a separate
namespace. As long as that's the case then it shouldn't matter. It must
have been something else cause the problem then... probably having to do
with order of loading of extensions? Your adding of the markdown
outputFormat does not interfere in any way.

Order of loading is what I assumed was the problem to begin with, and then
I looked around in BBT and realized you're loading a citeproc. I assumed
that you are doing what propachi-* does, overriding the one that ships with
Juris-M / Zotero. I didn't know you load it into a separate namespace. So
the outputFormats defined in schomd are part of the normal citeproc
namespace... what's the other citeproc for?

Because I'm now loading a new citeproc via my "propachi-texmacs", and
because I couldn't get things to work right until I disabled BBT, so I had
to add the bbl outputFormat to the citeproc that I'm loading, removing the
bbl support from your program is not going to interfere with mine. In fact,
it eliminates a maintain-in-two-places problem. Perhaps I can get the bbl
format into upstream citeproc someday, but first, it's probably best if I
have full control of it until it's well settled and tested.

Using the Juris-M / Zotero "integration.js" wire-protocol provides me with
a number of advantages:

https://www.zotero.org/support/dev/client_coding/libreoffice_plugin_wire_protocol

The main thing is that it drives the editor, not the other way around. That
offloads the logic behind checking for which fields need to be updated,
etc. So I set up a connection to it, then send an "integration command",
which sets it into motion, causing it to call back to the editor via the
defined functions. The editor doesn't have to know anything about the CSL
processor at all. It only needs to be able to send a list of fields in
document order, to get and set the field code and field text, the document
configuration data, the bibliography formatting options (single or double
space, hanging indent, etc.), and how to put an error dialog up when
something goes wrong. If I used another interface or ran the citeproc
myself, I'd have to handle all of that logic myself using the citeproc API
instead. The "integration.js" does that for me, integrating Zotero's
database with citeproc and a way to drive the editor automatically.

I wonder if the similar thing could be done for the markdown, for something
like Emacs, with an Emacs Lisp program? Would that matter? Or does the
final format of the citation not really happen until after the document is
processed... so maintaining them WYSIWYG doesn't matter with markdown,
right, in terms of "Ibid." forms, etc.?

By the way, what does "schomd" mean? I get "cayw" as "cite as you write",
but not "schomd".

Can you take a look at my "propachi-texmacs" package and see what might
cause the problem, and try and load both it and BBT into the same Firefox,
and see if you can see what's causing the problem? You have more experience
with this than I have.

On Mon, Jun 27, 2016 at 12:31 AM retorquere [email protected]
wrote:

I don't follow anymore. There's only one place I monkey-patch Zotero's
citeproc, and that's to add the markdown format, does that get in your way?
I do otherwise load a separate citeproc, but that's in a different
namespace, so that shouldn't bother anyone.

I don't like the idea that BBT can't be enabled at the same time as...
well, anything else. So:

1. What should I change to accommodate your work?
2. Can the changes I've made to remove bbl support be merged into
   master without damage to you?

Still not entirely certain what working with the wire protocol does in the
context of your texmacs work, but I agree it is to be preferred over my
changes. I just don't understand how it works.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACslvq-HYueHnNDnUpxkEzdKWmWevZrks5qP25VgaJpZM4I6iKZ
.

[KarlHegbloom]

Someday when I have more time for it... I'd like to see if I can get that
drop-in replacement for bibtex to work right for biblatex styles that have
in-text citations other than author-year or numbered; like for Indigobook,
or others like that. I don't know much about it yet, and can't take the
time for it until I get some other higher priority things out of the way...
I don't really use LaTeX right now... I helped typeset a book for a
professor once, so I know a little about it, but not as much as I'd
eventually like to know. I've got some books on it that I've not had time
to read. When we did that, he wanted a categorized bibliography, so I made
one. I ran that program that generates a bibtex program, then hand-edited
it, using things gleaned from several sources to cobble together what it
finally became.

I want to support that kind of categorized bibliography in the TeXmacs
plugin. In order to do that, I will need to extend the integration.js. I'll
start by monkey-patching, to figure it out and develop it to a stable form,
then later, try and create a patch to submit to them. Citeproc already has
the features necessary, with it's include, exclude, quash thing. I just
need to make the zbibliography field data contain that information somehow,
and pass it to the integration, and have it do the right thing with it...
then have multiple zbibliography fields in the document. I think I'm going
to want the ability to create tables of authorities for statutes,
constitutions, rules separate from ones for books and law journal articles,
and separate from ones for caselaw citations. It may also require extending
the CSL stylesheet.

For conversion of TeXmacs documents written using bibtex that have bibtex
data embedded in them, I'd like to be able to send that data to Juris-M /
Zotero and have it add entries. I think that your bibtex translators
probably will figure into that. That's not for today though. I've got too
much to do right now to even think about it.

On Mon, Jun 27, 2016 at 12:31 PM Karl Hegbloom [email protected]
wrote:

I did not realize that your citeproc is being loaded into a separate
namespace. As long as that's the case then it shouldn't matter. It must
have been something else cause the problem then... probably having to do
with order of loading of extensions? Your adding of the markdown
outputFormat does not interfere in any way.

Order of loading is what I assumed was the problem to begin with, and then
I looked around in BBT and realized you're loading a citeproc. I assumed
that you are doing what propachi-* does, overriding the one that ships with
Juris-M / Zotero. I didn't know you load it into a separate namespace. So
the outputFormats defined in schomd are part of the normal citeproc
namespace... what's the other citeproc for?

Because I'm now loading a new citeproc via my "propachi-texmacs", and
because I couldn't get things to work right until I disabled BBT, so I had
to add the bbl outputFormat to the citeproc that I'm loading, removing the
bbl support from your program is not going to interfere with mine. In fact,
it eliminates a maintain-in-two-places problem. Perhaps I can get the bbl
format into upstream citeproc someday, but first, it's probably best if I
have full control of it until it's well settled and tested.

Using the Juris-M / Zotero "integration.js" wire-protocol provides me with
a number of advantages:

https://www.zotero.org/support/dev/client_coding/libreoffice_plugin_wire_protocol

The main thing is that it drives the editor, not the other way around.
That offloads the logic behind checking for which fields need to be
updated, etc. So I set up a connection to it, then send an "integration
command", which sets it into motion, causing it to call back to the editor
via the defined functions. The editor doesn't have to know anything about
the CSL processor at all. It only needs to be able to send a list of fields
in document order, to get and set the field code and field text, the
document configuration data, the bibliography formatting options (single or
double space, hanging indent, etc.), and how to put an error dialog up when
something goes wrong. If I used another interface or ran the citeproc
myself, I'd have to handle all of that logic myself using the citeproc API
instead. The "integration.js" does that for me, integrating Zotero's
database with citeproc and a way to drive the editor automatically.

I wonder if the similar thing could be done for the markdown, for
something like Emacs, with an Emacs Lisp program? Would that matter? Or
does the final format of the citation not really happen until after the
document is processed... so maintaining them WYSIWYG doesn't matter with
markdown, right, in terms of "Ibid." forms, etc.?

By the way, what does "schomd" mean? I get "cayw" as "cite as you write",
but not "schomd".

Can you take a look at my "propachi-texmacs" package and see what might
cause the problem, and try and load both it and BBT into the same Firefox,
and see if you can see what's causing the problem? You have more experience
with this than I have.

On Mon, Jun 27, 2016 at 12:31 AM retorquere [email protected]
wrote:

I don't follow anymore. There's only one place I monkey-patch Zotero's
citeproc, and that's to add the markdown format, does that get in your way?
I do otherwise load a separate citeproc, but that's in a different
namespace, so that shouldn't bother anyone.

I don't like the idea that BBT can't be enabled at the same time as...
well, anything else. So:

1. What should I change to accommodate your work?
2. Can the changes I've made to remove bbl support be merged into
   master without damage to you?

Still not entirely certain what working with the wire protocol does in
the context of your texmacs work, but I agree it is to be preferred over my
changes. I just don't understand how it works.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AACslvq-HYueHnNDnUpxkEzdKWmWevZrks5qP25VgaJpZM4I6iKZ
.

[retorquere]

So the outputFormats defined in schomd are part of the normal citeproc namespace...

Correct

what's the other citeproc for?

Frank Bennet fixed a slew of problems in citeproc in functionality I needed in BBT, mostly to do with name and date parsing, nothing to do with bibliography or citation generation. Zotero updates citeproc only very occasionally, and I needed those fixes immediately, so I loaded a private copy. This may not be needed anymore -- perhaps Zotero has updated in the interim.

Using the Juris-M / Zotero "integration.js" wire-protocol provides me with a number of advantages:

The main thing is that it drives the editor, not the other way around.

I see. That may be interesting for atom-zotero-citations, where I can in principle drive the editor, but CAYW picking is meant to be a general easy-entry option for quick integration. atom-zotero-citations was more a proof-of-concept for the schomd work. It's not something I actively work on.

I wonder if the similar thing could be done for the markdown, for something like Emacs, with an Emacs Lisp program? Would that matter? Or does the final format of the citation not really happen until after the document is processed... so maintaining them WYSIWYG doesn't matter with markdown, right, in terms of "Ibid." forms, etc.?

That depends on the way you want it to work. Pandoc-markdown does all the processing in the final production step. atom-zotero-citations aims to do everything in pure markdown, so there the markdown itself is changed to insert the citations and the bibliography. In that case, the similar approach should work, but I doubt if I will ever get around to learning lisp. Certainly not with the ferflixten 5.0 around the corner, for which I'm still undecided whether I should go through the effort. The promisification is a pain in the ass, and much of BBT will need to be rewritten from scratch.

By the way, what does "schomd" mean? I get "cayw" as "cite as you write", but not "schomd".

Scholarly Markdown.

Can you take a look at my "propachi-texmacs" package and see what might cause the problem, and try and load both it and BBT into the same Firefox, and see if you can see what's causing the problem? You have more experience with this than I have.

What problem precisely? I've loaded your package, and BBT doesn't seem to mind.

Someday when I have more time for it... I'd like to see if I can get that drop-in replacement for bibtex to work right

I'm a little more pessimistic than I was a while ago. Not only have I found very little good information on what a drop-in replacement might need to do, the citeproc formats interface is not well documented. It has the feel it was custom-written for html and rtf.

My own pet project is going to be a reference quality checker. There's a lot of implicit knowledge on what fields should be present in the CSL styles, and incomplete references came very close to costing me my honors at graduation.