Re: Debugging at least 2 regressions in org-mode master breaking ox-hugo
Kyle Meyer writes: > I'll plan to bring that commit into master tomorrow. We can > reevaluate/rework the change if needed when Bastien is back in action. Done with 3c31941139ed6de14aebee950141dabbd7c0b468.
Re: wip-cite status question and feedback
On Sat, Apr 25, 2020 at 4:03 PM Nicolas Goaziou wrote: ... > > My understanding, though, is that org "cite" would default to your > > last example I quote above (in natibib, citep); that there's no need > > for a dedicated "cite/paren" command, either reserved or not. > > Not necessarily. "cite" means default value, whatever that is. It could, > for example, mean: "cite/text" for every citation, if that is what you > use the most. In that case, "cite/paren" is necessary, to override it > locally. It could also be, e.g., "cite/footnote", then both "cite/text" > and "cite/paren" could be of some use. That was suggested by Richard > Lawrence in this thread, if my memory serves me right. > > Does that make sense? I think so. I'll defer to Richard on this, since he was making this point. ... > > Given how common that is (In natbib, it and citep are the two core > > commands), is there any downside to reserving that? > > As I wrote, we can reserve "cite/text" already. > > Could we find something shorter for such a common need? Well, I didn't > find any syntax compelling enough—I don't like special casing. For > example, having both "citeX" and "cite/XXX", as suggested by Denis > Maier, is a bit convoluted, IMO. E.g., having both "citet" and > "cite/text" would just add confusion to the system, IMO. > > Besides, "cite/text" is not that difficult to type. Moreover, you would > probably use a tool to insert the citation anyway. > > This is not an irrevocable decision, of course. I merely suggested and > implemented one syntax, but I'm still open to suggestions. I support this decision, for all the reasons you mention; no problem at all. > > And then I guess the "suppress-author" variant would be something like > > "cite/year" or "cite/suppress-author"? > > The syntax still includes the "suppress-author" mechanism: > [cite:-@doe20]. Oh right; good. > It could be redundant with "cite/suppress-author", indeed. We can keep > it nonetheless. We can also decide to remove the "-@key" special syntax. > Or, we could also consider this idea to be an interesting one, and > extend it, with, e.g., [cite:!@doe20], which could be a shortcut for > [cite/text:@doe20]. > > Special cases… Everything's possible. You tell me. I vote to keep the "-". On your last suggestion (the "!" citet shortcut), how valuable it would be would really depend on the UX; how commonly, per your point above, one would be using a tool to insert this citation command. Bruce
Re: wip-cite status question and feedback
Hello,
"Bruce D'Arcus" writes:
> On Sat, Apr 25, 2020 at 12:20 PM Nicolas Goaziou
> wrote:
>
[...]
>>
>> [cite/text: ...]
>> [cite/paren: ...]
>>
> So in this approach, we have a single core "cite" command, and
> everything else is a namespaced extension?
Indeed.
> My understanding, though, is that org "cite" would default to your
> last example I quote above (in natibib, citep); that there's no need
> for a dedicated "cite/paren" command, either reserved or not.
Not necessarily. "cite" means default value, whatever that is. It could,
for example, mean: "cite/text" for every citation, if that is what you
use the most. In that case, "cite/paren" is necessary, to override it
locally. It could also be, e.g., "cite/footnote", then both "cite/text"
and "cite/paren" could be of some use. That was suggested by Richard
Lawrence in this thread, if my memory serves me right.
Does that make sense?
> So by default, the "cite" command might yield something like this on
> output (of course, depending on processor)?
>
> - to natbib/latex = "\citep{doe18}"
>
> For final HTML output (say using citeproc-el/org), something like:
>
> - author-date = "(Doe, 2018)"
> - number = "[3]"
> - note = "2" (represented as a footnote or endnote, of course)
>
> ... etc.
>
> And then we need a mechanism to do the textual variant (natbib citet);
> "cite/text" makes sense to me.
I assume this would be the more common configuration, indeed.
> Given how common that is (In natbib, it and citep are the two core
> commands), is there any downside to reserving that?
As I wrote, we can reserve "cite/text" already.
Could we find something shorter for such a common need? Well, I didn't
find any syntax compelling enough—I don't like special casing. For
example, having both "citeX" and "cite/XXX", as suggested by Denis
Maier, is a bit convoluted, IMO. E.g., having both "citet" and
"cite/text" would just add confusion to the system, IMO.
Besides, "cite/text" is not that difficult to type. Moreover, you would
probably use a tool to insert the citation anyway.
This is not an irrevocable decision, of course. I merely suggested and
implemented one syntax, but I'm still open to suggestions.
> And then I guess the "suppress-author" variant would be something like
> "cite/year" or "cite/suppress-author"?
The syntax still includes the "suppress-author" mechanism:
[cite:-@doe20].
It could be redundant with "cite/suppress-author", indeed. We can keep
it nonetheless. We can also decide to remove the "-@key" special syntax.
Or, we could also consider this idea to be an interesting one, and
extend it, with, e.g., [cite:!@doe20], which could be a shortcut for
[cite/text:@doe20].
Special cases… Everything's possible. You tell me.
Regards,
--
Nicolas Goaziou
Re: wip-cite status question and feedback
First, thanks for your work on this Nicolas; really awesome to see the progress!
I'm just going to address your syntax/cite command question.
I don't have concerns about the other details, and I think others are
better positioned to comment on those ...
On Sat, Apr 25, 2020 at 12:20 PM Nicolas Goaziou wrote:
...
> I assume [cite:...] is the default citation style, defined at the
> citation processor's level. Styled citations override locally the
> default style. Again, a processor not handling a given style is expected
> to fallback to default style.
>
> As a consequence, there is no special syntax for "author-in-text" style.
> But we can suggest one for back-end processors. We might want to stick
> to the most complete one, BibLaTeX, IIUC, and /require/ processors to
> support, at least:
>
> [cite/text: ...]
> [cite/paren: ...]
>
> With this bare minimum, we ensure documents are somehow portable between
> processors, and, therefore, export back-ends.
...
So in this approach, we have a single core "cite" command, and
everything else is a namespaced extension?
My understanding, though, is that org "cite" would default to your
last example I quote above (in natibib, citep); that there's no need
for a dedicated "cite/paren" command, either reserved or not.
So by default, the "cite" command might yield something like this on
output (of course, depending on processor)?
- to natbib/latex = "\citep{doe18}"
For final HTML output (say using citeproc-el/org), something like:
- author-date = "(Doe, 2018)"
- number = "[3]"
- note = "2" (represented as a footnote or endnote, of course)
... etc.
And then we need a mechanism to do the textual variant (natbib citet);
"cite/text" makes sense to me.
Given how common that is (In natbib, it and citep are the two core
commands), is there any downside to reserving that?
And then I guess the "suppress-author" variant would be something like
"cite/year" or "cite/suppress-author"?
Bruce
Re: wip-cite status question and feedback
Hello, I cannot answer all open questions as the thread would spread too thin. So, I'll try to subsume where Org is at the moment, and what need to be decided. First things first, I pushed a new branch, "wip-cite-new" in the repository, with an modified implementation of citation syntax, hopefully taking into consideration remarks made so far. I didn't squash "wip-cite" because citeproc-org library suggests to use it, and I didn't want to break it. Instead of formally describing the syntax, here are a few boring examples: [cite:@key] [cite:-@key] [cite:pre @key post] [cite:pre @key post; pre -@key2 post] [cite: common prefix; pre @key post; pre @key2 post; common suffix] There is a limitation for prefixes and suffixes: they cannot contain semicolons or closing square brackets. I'm not sure it is worth implementing some character escape mechanism, tho. Now with styles: [cite/style: ...] [cite/style/substyle: ...] [cite/mycitationprocessor/fullcite: ...] [cite/foot/text: ...] [cite/style/substyle/subsubstyle/OMG: ...] The forward slash separator gives us local citation style and a name space. There's no limit on the depth of sub-styles. However style strings are limited to alphanumeric characters only. I also removed short citations: Lorem ipsum @doe09 dolor sit amet They look nice, but I realized this was the same mistake as allowing [1] to be a footnote reference. False positives are way too common. This could generate frustration upon export. I assume [cite:...] is the default citation style, defined at the citation processor's level. Styled citations override locally the default style. Again, a processor not handling a given style is expected to fallback to default style. As a consequence, there is no special syntax for "author-in-text" style. But we can suggest one for back-end processors. We might want to stick to the most complete one, BibLaTeX, IIUC, and /require/ processors to support, at least: [cite/text: ...] [cite/paren: ...] With this bare minimum, we ensure documents are somehow portable between processors, and, therefore, export back-ends. Again, this is only a proposal, feedback is welcome. Hopefully we can move onto the next step: how should we interface citation processors and Org? First, I think we agreed on the BIBLIOGRAPHY keyword, with the following syntax: #+BIBLIOGRAPHY: file #+BIBLIOGRAPHY: "file" There can be multiple BIBLIOGRAPHY keywords in a document (and equivalent node properties). Also, I think Org should support a global variable, e.g., `org-citation-default-bibliography'. I also think we defined a keyword to insert a bibliography: #+PRINT_BIBLIOGRAPHY: ... options ... (may be specific to citation processors) I expect the processors to provide Org with a maximum two different actions: manage and export. For example, AFAIK, Org Ref manages and exports, citeproc-org/citeproc-el only exports, and a default processor might realistically limit export to LaTeX and derived and management to a default fontification of citations. - Management :: As suggested by John Kitchin, we want something like `org-link-parameters'. However, I don't think it makes much sense to let different citation processors handle different citations in the same buffer. Instead we can provide one global function for each of these features: - completion - fontification (possibly special keymaps, help-echo, etc) - following - am I missing something? Citation processors may operate on the bibliography file, but that's out of the scope of Org. For example, we could introduce the variable `org-citation-follow-function', which contains a function called with two arguments: the key of the citation to follow, and the list of bibliography files active in the buffer. Each citation processor could set this function. By default, it would probably be (defun org-citation-follow-default ( _) (message "Please activate a citation processor to follow citations") nil) - Export :: In this case, we may want to allow multiple processors for various export back-ends. I thought about declaring active processors in a document with a keyword, e.g., #+CITATION_PROCESSOR: org-ref :default-style foo :back-ends (latex) #+CITATION_PROCESSOR: citeproc :default-style bar and with a global variable, e.g., `org-citation-export-default' which could be, e.g., '((default :defaut-style "authoryear" :back-ends (latex))) but could become, with appropriate libraries '((org-ref :defaut-style "authoryear" :back-ends (latex)) (citeproc-org :default-style "style-file.csl" :back-ends nil)) where more specialized back-ends are used first. Note that `latex' would mean `latex' and derived back-ends, e.g., `beamer'. Well, that's all for now. Again, I am not a citation specialist, so I need feedback. Let's keep the ball rolling! Regards, -- Nicolas Goaziou
[SOLVED] Re: org-set-tags function will overwrite original tags when use it pragmatically
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nicolas Goaziou writes: > Hello, > > stardiviner writes: > >> I use function ~org-set-tags~ pragmatically like this: > > [...] > >> But I found a problem, it will overwrite original tags. It's not appending >> method. > > Well, it is expected according to its docstring, isn't it? > >> I hope this function can be improve to suitable for this purpose. What about >> and >> optional argument of this function to decide overwrite or append >> method? > > I think > > (org-set-tags (cons "LOG" (org-get-tags nil t))) > > is enough. No need to add arguments. This is great, thanks, Nicolas. - -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3 -BEGIN PGP SIGNATURE- iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6kSo4UHG51bWJjaGls ZEBnbWFpbC5jb20ACgkQG13xyVromsP1rwgAg+zG8LIWq8W87pCLFqS6BHH+y4Zy zHMGpYUmIIfsLXrhDWyJCaEnABNICq7zTZV1Qa3UNt7vR5kapp7GuBzdFefcVjjx +QPG19YUDRD2Xr6U6MrJxXrvLBXcawsemZ+5eAJTC9oD6P38iCXvDO0r7rtBXYvd /OBiKw+Oih7Vlr0wqTAbBO2MKicPQmb8lhRQQlbUoy8SFN80dA3ih1bRsMfP2NX8 1knKruhi007WK2KVdAv90wa5m+FPHW2fLliz07QHv5b84YUOgK8I7UnRXr0wdwww IjmuWcF6iyOpysE5tHeGXZwugz0vgxDAayfHKsXwKuGVEczv2GGRzA62bQ== =QRtm -END PGP SIGNATURE-
org-thtml - static html site in pure org + Emacs
Hi, I have created this standalone framework for building static HTML sites using Emacs and org-mode https://github.com/juanjosegarciaripoll/org-thtml/ The github repository has a sample mini-site, but you may want to see a more mature one at my homepage https://juanjose.garciaripoll.com It only requires emacs. The example requires a recent version of org-mode. The stock one seems to have a problem resolving file: links in files that have been #+include'd. Cheers, -- Juan José García Ripoll http://juanjose.garciaripoll.com http://quinfog.hbar.es
Re: how to get an org-link to open a program in eshell
Many thanks Kyle for your reply,
In fact I have succeeded to open directly some programs with eshell
thanks to org-links like the following one:
[[eshell:program_name]]
If I put these org-links into an org file and if I have bookmarked this
file.
Nevertheless, I do not find that this solution is very elegant. In
my bookmark file I have this part of code:
#1=(#("eshell-launcher" 0 15
(bmkp-full-record #1#))
(buffer-name . "*dashboard*")
(visits . 2)
(time 24213 34946 832780 22000)
(created 24213 34859 529449 8000)
(position . 0)
(function . eshell)
(handler . bmkp-jump-function))
and it works correctly: via the bookmark in my dashboard, I can open
eshell . But I have not succeed to write a code in this bookmark file to
get a program that is opened directly via eshell, hence org-links in an
org file. All that I wrote in this bookmark file failed. Any suggestion
is welcome, even if it is not a serious problem to open an org file
first. It is just an elegance issue.
Best wishes, and again, thanks,
Jo.
--
Joseph
Re: org-set-tags function will overwrite original tags when use it pragmatically
Hello, stardiviner writes: > I use function ~org-set-tags~ pragmatically like this: [...] > But I found a problem, it will overwrite original tags. It's not appending > method. Well, it is expected according to its docstring, isn't it? > I hope this function can be improve to suitable for this purpose. What about > and > optional argument of this function to decide overwrite or append > method? I think (org-set-tags (cons "LOG" (org-get-tags nil t))) is enough. No need to add arguments. Regards, -- Nicolas Goaziou
org-set-tags function will overwrite original tags when use it pragmatically
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I use function ~org-set-tags~ pragmatically like this:
#+begin_src emacs-lisp
(defun my/org-add-note--auto-add-tag ()
"Auto add tag 'NOTE' when add note log."
(org-back-to-heading)
(org-set-tags '("LOG")))
(advice-add 'org-add-note :after #'my/org-add-note--auto-add-tag)
#+end_src
But I found a problem, it will overwrite original tags. It's not appending
method.
I hope this function can be improve to suitable for this purpose. What about and
optional argument of this function to decide overwrite or append method?
Thanks in advance.
- --
[ stardiviner ]
I try to make every word tell the meaning what I want to express.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
-BEGIN PGP SIGNATURE-
iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl6j5ygUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsM1lwgArs5bGY3res7ejZM1kaOVLGtMMpdK
4uMIlJAgf6F9Kn2c4owImC88we6/IPK0TVOMISKBY30ZCIiFq2OMMhuwAOTXICmT
kx8New5B1k8XuFFxNYH2QxxNR1taYXQrfXyBHtXGjAXtPkY0hscXGt4FIsZY71Tj
2zGPxtb47WY6KIapuqqi6KEyG5DgABgsFvF6mpjYmDe0tsC6POjQA3FkfdsxhQzX
sBbVJHD8bvrVcROGlyTc8xXjUTwRXz2WlAB38rDebq/QqFbPcrVixxonHwp7h2eM
bzSvg0oombEUQp/+j+kU23Y96p7kTTaFl9VE0Ynb2hNSjbGRU9BlafhwLg==
=3MMP
-END PGP SIGNATURE-
