emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Bruce D'Arcus" <bdarcus@gmail.com>
To: "Bruce D'Arcus" <bdarcus@gmail.com>,
	Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [wip-cite-new] New natbib processor
Date: Sun, 9 May 2021 18:01:44 -0400	[thread overview]
Message-ID: <CAF-FPGN=qf7g-sf4C=uR6F9siq1ArpdMjZCzDdXuKxszMf7LHQ@mail.gmail.com> (raw)
In-Reply-To: <878s4nzmcd.fsf@nicolasgoaziou.fr>

On Sun, May 9, 2021 at 4:25 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Hello,
>
> "Bruce D'Arcus" <bdarcus@gmail.com> writes:
>
> > To bottom line it, seems the decision comes down to something like
> > these three choices:
> >
> > 1. no change; keep sub-styles as they are ATM
> > 2. change sub-styles to a simple string. So [cite/text/caps+full:...],
> > where sub-style is the string "caps+full"; short cut would be
> > something like [cite:/t/c+f:...]
> > 3. remove sub-styles entirely; just have things like
> > [cite/text+caps-full:...], where the style is "text+caps-full"; or
> > with shortcuts [cite/t+c-f:...]
> >
> > Any of them seem reasonable to me.
> >
> > Maybe 2 is the best balance of flexibility and simplicity?
>
> But there are two 2 ;)

The nice thing about a wiki is one can always edit one's mistakes!

But I did correct the quoted text above, so I meant the first "2".

See below however ...

...

> Sub-styles buy us nicer switching between processors, indeed. But they
> come at a price, too. In particular, we need to re-define inheritance
> between styles defined in `org-cite-export-processor', "cite_export"
> keyword and the citation object. As I wrote earlier in this thread,
> there are multiple ways to deal with it, so a clear design is in order.
>
> Plain styles already exist. Sub-styles requires more work. Does the
> benefit outweigh it? If so, what do you suggest for the inheritance
> problem?

I guess the question is really about the logic in this function?

(defun org-cite-natbib--style-to-command (style)
  "Return command name to use according to STYLE string."
  (let ((base
         (if (org-cite-natbib--has-substyle-p style "caps")
             "Cite"
           "cite"))
        (alt
         (and (org-cite-natbib--has-substyle-p style "alt")
              "al"))
        (main (pcase (org-cite-natbib--main-style style)
                ((or "text" "t") "t")
                ((or "author" "a") "author")
                ((or "year" "y") "year")
                (_ "p")))
        (star
         (and (org-cite-natbib--has-substyle-p style "full")
              "*")))
    (concat "\\" base alt main star)))

My read of the natbib docs is this should work correctly, except for
the 'year' style, for which 'full' and 'caps' do not apply because
there are no authors output in those styles.

Indeed, if you do something like \Citeyear you will get an error from LaTeX.

So I think you need a conditional that ignores those for that style.

But otherwise, I think this should be fine.

The example you raised in the first post in this thread was the following:

> Also it introduces ambiguities in style inheritance.
> For example, if I add
>
>  #+cite_export: natbib plainnat text

So the default style is "text."

> would
>
>  [cite//alt/caps:...]
>
> mean
>
>  [cite/text/alt/caps:...]   (i.e., \Citealt{...})
>
> or really
>
>  [cite//alt/caps:]          (i.e., \Citealp{...})
>
> ?

First, I am thinking "bare" would be more clear than "alt", at least
if we're shooting for names that are clear outside the content of a
particular output format. WDYT?

On the more important output question, do not those two natbib
commands generate the same final output in the end?

As in, this ambiguity is in natbib itself?

That aside, I think just logically the first makes more sense, because
nowhere does the style or sub-styles specify the "citep" style.
Indeed, that style doesn't exist in the current list. This is what the
code currently produces.

Am I missing something there?

Bruce


  reply	other threads:[~2021-05-09 22:04 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-05 14:53 [wip-cite-new] New natbib processor Nicolas Goaziou
2021-05-05 15:20 ` Bruce D'Arcus
2021-05-05 15:32   ` Bastien
2021-05-06 12:29   ` Nicolas Goaziou
2021-05-06 12:56     ` Bruce D'Arcus
2021-05-05 18:08 ` Bruce D'Arcus
2021-05-05 21:25   ` Bruce D'Arcus
2021-05-05 21:40     ` Bruce D'Arcus
2021-05-05 22:32     ` Bruce D'Arcus
2021-05-06  7:36     ` Denis Maier
2021-05-06 10:06       ` Bruce D'Arcus
2021-05-06 11:22         ` Bruce D'Arcus
2021-05-06 12:05     ` Nicolas Goaziou
2021-05-06 13:09       ` Bruce D'Arcus
2021-05-06 14:12         ` Nicolas Goaziou
2021-05-06 14:23           ` Bruce D'Arcus
2021-05-06 16:20             ` Nicolas Goaziou
2021-05-06 16:59               ` Bruce D'Arcus
2021-05-06  8:47 ` Bruce D'Arcus
2021-05-06 12:11   ` Nicolas Goaziou
2021-05-06 12:37     ` Bruce D'Arcus
2021-05-07 11:37       ` Bruce D'Arcus
2021-05-08 13:51         ` Bruce D'Arcus
2021-05-09  8:57           ` Nicolas Goaziou
2021-05-09 13:49             ` Bruce D'Arcus
2021-05-09 20:25               ` Nicolas Goaziou
2021-05-09 22:01                 ` Bruce D'Arcus [this message]
2021-05-10 17:07                   ` Bruce D'Arcus
2021-05-10 20:22                     ` Nicolas Goaziou
2021-05-10 20:52                       ` Bruce D'Arcus
2021-05-15 21:29                   ` Nicolas Goaziou
2021-05-15 21:54                     ` Bruce D'Arcus
2021-05-16  9:47                       ` Nicolas Goaziou
2021-05-11 12:13 ` Eric S Fraga

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAF-FPGN=qf7g-sf4C=uR6F9siq1ArpdMjZCzDdXuKxszMf7LHQ@mail.gmail.com' \
    --to=bdarcus@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).