Re: Bug: Can't set background color of latex fragment
Hi Sébastien,
I originally made my patch because otherwise adding '(:background
"Transparent") to org-format-latex-options always resulted in a white
background (\pagecolor{white} would be forcefully added to the
generated LaTeX). Then I found that dvipng still produced a white
background even without a \pagecolor{...} directive, so I added the
-bg Transparent option. This is unlike dvisvgm, which produces an
opaque background when \pagecolor{...} is present and a transparent
background otherwise.
I didn't realize that dvipng -bg Transparent would completely ignore
the \pagecolor{...} command even if it was present. Perhaps the best
solution that allows the background color to be customized with dvipng
is to remove "-bg Transparent" from the default dvipng command line.
For people who need transparency, perhaps another "dvipng
(transparent)" option can be created, or they can use dvisvgm. This is
useful for HTML export, for example.
That said, I haven't had any issues with Emacs rendering transparent
PNGs (version 27.2 on Linux and macOS). It uses the background color
of whichever face is applied to LaTeX fragments (which seems to be
org-block, along with font-latex-verbatim-face for inline formulae). I
personally find it convenient to customize these faces as needed.
Regards,
Roshan
On Wed, May 19, 2021 at 12:30 AM Sébastien Miquel
wrote:
>
> Hi Roshan,
>
> Roshan Shariff writes:
>
> I can confirm this bug with dvipng --- with the "-bg Transparent"
> option, dvipng ignores the background color from the input tex file,
> whereas without that option it always produces an opaque background.
> There's currently no way to dynamically change command line
> parameters, so I'm not sure how to solve this problem while supporting
> both use cases.
>
>
> I asked about this behaviour on the dvipng mailing list, and the
> maintainer doesn't consider it a bug, see
> https://lists.nongnu.org/archive/html/dvipng/2021-05/msg2.html.
>
> Can you explain the use for a `Transparent` background ? Transparent
> images are poorly supported in emacs, all it does is render it with
> the background color of the default face -- which may not be the
> expected result.
>
> Regards,
>
> --
> Sébastien Miquel
>
>
> On Wed, Apr 7, 2021 at 1:38 PM Sébastien Miquel
> wrote:
>
> To reproduce with `emacs -Q` :
> - Open an org buffer
> - Call ~(setq org-format-latex-options '(:foreground default
> :background "Black" :matchers ("$")))~
> - Call =C-c C-x C-l= (org-latex-preview) on a latex fragment such as
> $abc$
>
> This bug was introduced by the commit 2f9e1569f which adds the option
> `-bg Transparent` to the arguments of `dvipng`. According to its
> manual, this option should be ignored if a background is already set,
> but it doesn't seem to be. Perhaps org should set it differently.
>
> --
> Sébastien Miquel
>
>
>
Re: Invalid duration format error with active timestamp
On Tue 18-May-2021 at 23:23:39 +02, Rainer Hansen wrote: > Hi Garjola, > > I had the same problem. > > I fixed it by downloading manually the last working version of Org from > https://orgmode.org/elpa/, > i.e. https://orgmode.org/elpa/org-20210503.tar > and manually stored the extracted directory into my elpa directory, > /home/garjola/.emacs.d/elpa/ in your case. > > After restarting Emacs Org agenda worked fine again. > > I hope that helps. > > Regards, > Rainer Hi Rainer, Thanks for the tip. I finally got the update via the package manager before having the time to test your solution. And org works great as always! Cheers. G. > > Garjola Dindi writes: > >> On Mon 17-May-2021 at 16:01:25 +02, Nicolas Goaziou >> wrote: >>> Hello, >>> >>> Garjola Dindi writes: >>> I am using the most recent elpa version of org 9.4.5 (9.4.5-93-gbc857b-elpa @ /home/garjola/.emacs.d/elpa/org-20210510/) with emacs master branch. Since updating org yesterday, when I use a timestamp like , | <2021-05-17 Mon 10:00-11:00> ` building the agenda fails with this backtrace: , | Debugger entered--Lisp error: (error "Invalid duration format: | #(\"10:00-11:00\" 0 5 (font...") >>> >>> This was fixed a few days ago. >>> >>> Since Org in ELPA is updated every Monday, you need to update it again >>> (later?) today to get the fix. >>> >> >> Hi, >> >> Thanks for your answer. I've been impatiently refreshing the packages >> since yesterday, but I don't see any new version of org. >> >> I am using >> >> http://orgmode.org/elpa/ >> >> Is this still correct? Just wondering, since I understood that some >> things are changing in org packaging and distribution. >> >> Thanks for your great work! > > > --
Re: new org-contrib and straight.el
Greg Minshall writes: Nick, The recent changes to org-contrib's location/structure have been accounted for on straight's "develop" branch. Once on that branch you can rely on the default recipe: thanks very much. i'll look at switching to the development branch, freezing and thawing. cheers, Greg You're welcome. I've merged the develop branch into the master branch this morning, too. So you should be able to reap that benefit on either branch, but I still recommend using the lockfiles to your advantage.
Re: [PATCH] org-faq.org: Expand "What is the best setup for indenting?"
Maxim, patches to patches... :) i think these are really just typos, rather than any useful substantial comment. - s/is enable (the default) or not:/is enabled (the default) or not:/ - i would suggest separate tables for >= 9.5 and < 9.5. just so the differences between with/without =electric-indent-mode= are easier to spot. - s/C-j anywhere/C-j elsewhere/ (and, iiuc, maybe also the "unadorned" [C-j] table entry should probably be [C-j elsewhere]?) - s/lost formatting/lose formatting/ - s/and, that is/and,/ - s/always indent relatively/always indent relative/ - s/the the element/to the element/ cheers, Greg
Re: new org-contrib and straight.el
Nick, > The recent changes to org-contrib's location/structure have been > accounted for on straight's "develop" branch. Once on that branch you > can rely on the default recipe: thanks very much. i'll look at switching to the development branch, freezing and thawing. cheers, Greg > > #+begin_src emacs-lisp > (straight-use-package 'org-contrib) > #+end_src > > You can see which version of straight you're currently using via `M-x > straight-version`. > If you're on the "master" branch (commit e1390a9 as of this writing), > you can update to the "develop" > branch by adding: > > #+begin_src emacs-lisp > (setq straight-repository-branch "develop") > #+end_src > > prior to straight's bootstrapping snippet in your in init file. > I recommend using the develop branch and utilizing the lockfile system > via > `straight-freeze-versions` and `straight-thaw-versions` to define your > own "stable releases". > > Hope that helps. > If you have any other questions or run into problems feel free to > reach out on our issue tracker: > > https://github.com/raxod502/straight.el/issues/new/choose > > Hope that helps, > > Nick >
Re: Org-capture %K "Link to the currently clocked task" link with id?
Rereading my message, i realized it might not be clear what i mean here. I use (org-id-link-to-org-use-id t) because i like to be able to still follow links after i archive stuff. I want that behavior here so i want the link to an `id:` link instead of a `file:/path/to/file` link. Nate > On May 19, 2021, at 8:26 AM, Nathaniel W Griswold > wrote: > > Looking at the source (org-capture.el), it appears org-capture doesn't allow > you to make a permalink for "Link to the currently clocked task", or %K in > your template. > > `org-capture-fill-template` looks like this: > > ... >(v-K (if (marker-buffer org-clock-marker) > (org-link-make-string > (format "%s::*%s" > (buffer-file-name (marker-buffer org-clock-marker)) > v-k) > v-k) > "")) > ... > > So i guess it's hardcoded to just make a bracket link. > > I guess i can hack something, but can you guys make a nice change to the > source so that i can have a permalink to my clocked in task? Or is there > something i'm missing and i can actually do it already? > > Thank you > > Nate
Re: [POLL] Setting `org-adapt-indentation' to nil by default?
On 16/05/2021 03:51, Bastien wrote: > Maxim Nikulin writes: > >> I think, the something like the following should be added to the >> answer. > > Patch welcome! Either for Worg or etc/ORG-NEWS, if you think we > should add something to the existing explanations. I have tried to express my ideas as patches. Feel free to pick only a part of changes or discard them at all.
[PATCH] etc/ORG-NEWS: Suggest against disabling `electric-indent-mode'
--- etc/ORG-NEWS | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index f49d2c043..8707222e0 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -55,8 +55,11 @@ If you want to automatically indent headlines' metadata, set it to If you want to automatically indent every line to the headline's current indentation, set it to =t=. -Also beware that the behavior of =RET= and =C-j= also depends on the -value of ~electric-indent-mode~. See [[https://orgmode.org/worg/org-faq.html#indentation][this FAQ]] for more details. +Indent added by =RET= and =C-j= also depends on the value of +~electric-indent-mode~. Enabling this mode by default in 9.4 revealed +some bugs caused confusing behavior. If you disabled +~electric-indent-mode~ for this reason, it is time to try it again. +Hopefully problems have been fixed. See [[https://orgmode.org/worg/org-faq.html#indentation][this FAQ]] for more details. *** ~org-speed-commands-user~ is obsolete, use ~org-speed-commands~ -- 2.25.1
[PATCH] org-faq.org: Expand "What is the best setup for indenting?"
--- org-faq.org | 61 ++--- 1 file changed, 44 insertions(+), 17 deletions(-) diff --git a/org-faq.org b/org-faq.org index 9cc193c4..0f8934af 100644 --- a/org-faq.org +++ b/org-faq.org @@ -1029,21 +1029,33 @@ something like this: :CUSTOM_ID: indentation :END: -Indentation is a matter of personal preferences. General indentation -preferences are controlled in Emacs via ~electric-indent-mode~. Org -indentation behavior changes depending on ~org-adapt-indentation~, which -accepts three values: =nil= (no special indentation), =t= (always indent -relatively the the element above) and =headline-data= (only indent the -~PROPERTIES/LOGBOOK~ drawers relatively to the current level). On top -of these two configuration areas, there the difference between =RET= and -=C-j=. - -Here are two tables summarizing the behavior depending on whether -~electric-indent-mode~ is enable (the default) or not: - -With `electric-indent-mode' enabled: - -| org-adapt-indentation => | nil| t | headline-data | +Indentation, both appearance and behavior, is a matter of personal +preferences. You may try if the following adjustments suits better +for you than the defaults. Set ~org-adapt-indentation~ to have +content aligned to headline titles. Disable ~electric-indent-mode~ to +avoid automatic indentation in response to =RET= key. + +In more details, ~org-adapt-indentation~ controls indentation with +regards to previous element. Apparent effect is increased indentation +for content of deeper nested headings. The variable accepts three +values: =nil= (no special indentation), =t= (always indent relatively +the the element above) and =headline-data= (only indent the +~PROPERTIES/LOGBOOK~ drawers relatively to the current level). Value +=t= is suitable for short entries especially if you plan to share your +documents with someone who does not use Emacs. If you just want to +make heading level more prominent then consider adding visual left +margin using =#+STARTUP: indent= as described in the [[https://orgmode.org/manual/Clean-View.html#Clean-View][Clean View]] +section of the manual. The option works without adding extra spaces +to the document text. + +Configured indentation may be applied in response to =RET= or to +=C-j= depending on the state of ~electric-indent-mode~. The following +tables summarizes the difference. Version number is added to column +header if it describes default settings. + +With ~electric-indent-mode~ enabled: + +| org-adapt-indentation => | nil (Org >= 9.5) | t (Org 9.4) | headline-data | |---+++| | RET after a headline | Do not indent | Indent | Do not indent | | C-j after a headline | Do not indent | Do not indent | Do not indent | @@ -1051,9 +1063,9 @@ With `electric-indent-mode' enabled: | C-j anywhere | Do not indent wrt prev | Do not indent wrt previous | Do not indent wrt previous | | Insert PROPERTIES/LOGBOOK | Do not indent | Indent wrt headline | Indent wrt headline| -With `electric-indent-mode' disabled: +With ~electric-indent-mode~ disabled: -| org-adapt-indentation => | nil | t | headline-data | +| org-adapt-indentation => | nil | t | headline-data (Org < 9.4) | |---+-++| | RET after a headline | Do not indent | Do not indent | Do not indent | | C-j after a headline | Do not indent | Indent | Do not indent | @@ -1061,6 +1073,21 @@ With `electric-indent-mode' disabled: | C-j | Indent wrt previous | Indent wrt previous | Indent wrt previous| | Insert PROPERTIES/LOGBOOK | Do not indent | Indent wrt headline | Indent wrt headline| +Do not try to avoid or to ignore indentation of heading body or +properties drawer determined by current state of +~org-adapt-indentation~ and ~electric-indent-mode~ by pressing =C-j= +instead of =RET= (or vice versa). The result is transient and you will +lost formatting when you refile heading or change its level (promote +or demote it). + +You may have noticed recommendation to disable ~electric-indent-mode~ +to restore behavior prior to Org 9.4. In Org 9.5 +~org-adapt-indentation~ default value changed to =nil= and, that is +more important, a number of bugs related to indentation were fixed. +Using =RET= with enabled ~electric-indent-mode~ should be convenient +now. Just customize ~org-adapt-indentation~ variable
Re: [wip-cite-new] Initial implementation of `biblatex' citation processor
Denis Maier writes: > In that case, I'd think that note/bare => footcitecite isn't > a particular good fit. Footcitetext puts the citation in a footnote, > just that it doesn't print a footnote mark in a running text. > (This is useful in cases where the regular footnote mechanism in LaTeX > doesn't work, e.g. in headings or tables. In these cases you' can > place the mark manually with \footnotemark, and later you specify the > text with \footnotetext, or in that case with \footcitetext.) OK, I'll remove it. What about also removing \footcite altogether? We could simply automatically wrap the citation in a inline footnote before exporting the document. No need for a special command. Org already handles footnotes in headings and tables, so there may be no need to footcitetext either… > Regarding: >> | locators | bare | notecite | >> | locators | caps | Pnotecite| >> | locators | bare-caps | Notecite | >> | locators | | pnotecite| > > fnotecite should be added. Under what style/variant combination? >> One problem is there is no "\cite", or "\parencite". I though they would >> make a good fit for the default style, "\cite" being the "bare" variant >> of "\parencite", and "\autocite" could be moved to a "auto" style. I'm >> not sure where to put \cite, then. > > Why not just add a cite/parens style? OK. > \cite could be [cite/bare: ...] This would be confusing. So far, "bare" is a style variant. Your suggestion promotes it exceptionally to a full-fledged style. It hurts my logic. :) Could "\cite" be [cite/parens/bare:...] instead? > Regarding \autocite being the default: > I think one strong argument in favor of this is that people may want > to switch between different citation export processors. So if you > typeset your article with latex you may want to use biblatex. But if > the journal accepts submissions only as docx files you'll have to > switch to a CSL-based citeproc. Here, the default is to wrap the > citation either in a footnote or in parentheses, depending on the > style. > So, to ensure portability of documents across export systems [cite: > @doe] should give similar results with different systems, and I think > \autocite would be the best choice. (By the way, it's also the way > pandoc implements this.) Users can disregard any default style chosen by the processor. If I write: #+cite_export: biblatex whatever text all [cite:...] objects will create \textcite commands, no matter what the processor thinks about it. So, an hypothetical #+cite_export: biblatex foo auto could also turn all [cite:...] into \autocite commands and the document would be portable. The default processor style for citations is to be understood as a fall-back style, not necessarily as "the style associated to [cite:...]". Anyway, I don't have a strong opinion about autocite being the default. If it makes sense and we can put \cite elsewhere, let's use that. Regards,
Re: [wip-cite-new] Initial implementation of `biblatex' citation processor
On Wed, May 19, 2021 at 10:31 AM Denis Maier wrote: > In that case, I'd think that note/bare => footcitecite isn't a > particular good fit. Footcitetext puts the citation in a footnote, just > that it doesn't print a footnote mark in a running text. And, just as a general rule, not all sub-styles are relevant for all styles. > > One problem is there is no "\cite", or "\parencite". I though they would > > make a good fit for the default style, "\cite" being the "bare" variant > > of "\parencite", and "\autocite" could be moved to a "auto" style. I'm > > not sure where to put \cite, then. > > Why not just add a cite/parens style? Probably makes sense. > \cite could be [cite/bare: ...] > > Regarding \autocite being the default: > I think one strong argument in favor of this is that people may want to > switch between different citation export processors. So if you typeset > your article with latex you may want to use biblatex. But if the journal > accepts submissions only as docx files you'll have to switch to a > CSL-based citeproc. Yes, this is the use case I was thinking of when suggesting a lot of this. In fact, it's an approach I'm likely to use myself! > Here, the default is to wrap the citation either in > a footnote or in parentheses, depending on the style. > So, to ensure portability of documents across export systems [cite: > @doe] should give similar results with different systems, and I think > \autocite would be the best choice. (By the way, it's also the way > pandoc implements this.) Bruce
Re: Get list of top-level headings
that is often true, especially with large buffers, but you have to add a bunch of code to go to point-max, and check the level with this. #+BEGIN_SRC emacs-lisp (save-excursion (goto-char (point-max)) (let (components (headings '())) (while (re-search-backward org-complex-heading-regexp nil t) (setq components (org-heading-components)) (when (= (first components) 1) (push (fifth components) headings))) headings)) #+END_SRC This takes about 0.04 ms on a small example. The org-map-entries approach takes 0.6ms on the same example. In a big buffer that might be noticeable! John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Wed, May 19, 2021 at 10:19 AM Jonathan Gregory wrote: > Hi > > On 19 May 2021, John Kitchin wrote: > > > I think this is all you need to get a list of titles of level 1 > > headings as strings > > > > (org-map-entries (lambda () (fifth (org-heading-components))) > > "LEVEL=1") > > > > this also works for me: > > > > #+BEGIN_SRC emacs-lisp > > (org-map-entries (lambda () (org-element-property :title > > (org-element-at-point)) ) "LEVEL=1") > > #+END_SRC > > This is a better approach indeed. No need to create a new list, > although I get faster results using: > > (while (re-search-backward org-complex-heading-regexp nil t) > > > -- > Jonathan > >
Re: [wip-cite-new] Initial implementation of `biblatex' citation processor
Am 19.05.2021 um 15:44 schrieb Nicolas Goaziou: Here is the summary: | Style | Variant | Command | |---+---+--| | author| caps | Citeauthor* | | author| full | citeauthor | | author| caps-full | Citeauthor | | author| | citeauthor | |---+---+--| | locators | bare | notecite | | locators | caps | Pnotecite| | locators | bare-caps | Notecite | | locators | | pnotecite| |---+---+--| | nocite| | nocite | |---+---+--| | note | bare | footcitetext | | note | | footcite | |---+---+--| | smart | caps | Smartcite| | smart | | smartcite| |---+---+--| | super | | supercite| |---+---+--| | text | caps | Textcite | | text | | textcite | |---+---+--| | title | full | citetitle* | | title | | citetitle| |---+---+--| | year | full | citeyear*| | year | | citeyear | |---+---+--| | (default) | caps | Autocite | | (default) | | autocite | "bare" variant means "without parenthesis", I think. Am 19.05.2021 um 15:50 schrieb Bruce D'Arcus: To be more precise/general, it means without enclosing punctuation; parentheses, brackets, etc. Thanks, both. So bare is just the citation without a wrapper. In that case, I'd think that note/bare => footcitecite isn't a particular good fit. Footcitetext puts the citation in a footnote, just that it doesn't print a footnote mark in a running text. (This is useful in cases where the regular footnote mechanism in LaTeX doesn't work, e.g. in headings or tables. In these cases you' can place the mark manually with \footnotemark, and later you specify the text with \footnotetext, or in that case with \footcitetext.) Regarding: > | locators | bare | notecite | > | locators | caps | Pnotecite| > | locators | bare-caps | Notecite | > | locators | | pnotecite| fnotecite should be added. One problem is there is no "\cite", or "\parencite". I though they would make a good fit for the default style, "\cite" being the "bare" variant of "\parencite", and "\autocite" could be moved to a "auto" style. I'm not sure where to put \cite, then. Why not just add a cite/parens style? \cite could be [cite/bare: ...] Regarding \autocite being the default: I think one strong argument in favor of this is that people may want to switch between different citation export processors. So if you typeset your article with latex you may want to use biblatex. But if the journal accepts submissions only as docx files you'll have to switch to a CSL-based citeproc. Here, the default is to wrap the citation either in a footnote or in parentheses, depending on the style. So, to ensure portability of documents across export systems [cite: @doe] should give similar results with different systems, and I think \autocite would be the best choice. (By the way, it's also the way pandoc implements this.) Denis
Re: Get list of top-level headings
Hi On 19 May 2021, John Kitchin wrote: I think this is all you need to get a list of titles of level 1 headings as strings (org-map-entries (lambda () (fifth (org-heading-components))) "LEVEL=1") this also works for me: #+BEGIN_SRC emacs-lisp (org-map-entries (lambda () (org-element-property :title (org-element-at-point)) ) "LEVEL=1") #+END_SRC This is a better approach indeed. No need to create a new list, although I get faster results using: (while (re-search-backward org-complex-heading-regexp nil t) -- Jonathan
Re: Get list of top-level headings
Hello Florian On 19 May 2021, Florian Lindner wrote: Hello, I, an Emacs Lisp newbie, want to get a list of all top-level headings of the current buffer. My approach so far is: (defun test-org-map() (interactive) (setq headings '()) (org-map-entries (lambda () (setq current-header-item (org-element-property : title (org-element-at-point)) (message "Header: %s" current-header-item) (message "Is String: %s" (stringp (org-element-property :title (org-element-at-point (setq headings (append current-header-item headings)) ) "LEVEL=1" ) (dolist (heading headings) (message "Header Item: %s" heading) ) ) This gives the otput: Header: AAA Is String: t Header: BBB Is String: t Header Item: 66 [3 times] Header Item: 65 [3 times] so basically the (org-element-property :title (org-element-at-point) does exactly what I want, but building the list does not what I want. I suppose that comes from a fundamental misunderstanding of how strings work in elisp. I would appreciate a short explanation (or pointers) why this does not work. And of course, I am very open to completely different, likely better, approches to that simply problem! Thanks, Florian The org-map-entries function calls FUNC at each headline, so you have to (1) find the headline/title and (2) add it to your list. One way to do this is with the push macro. --8<---cut here---start->8--- (defun test-org-map () (interactive) (let (headlines) (org-map-entries (lambda () (let* ((element (org-element-at-point)) (headline (org-element-property :title element))) (push headline headlines))) "LEVEL=1") (print (nreverse headlines --8<---cut here---end--->8--- Or by searching the buffer: --8<---cut here---start->8--- (defun test-org-map () (interactive) (let (headlines) (save-excursion (goto-char (point-max)) (while (re-search-backward org-complex-heading-regexp nil t) (let ((headline (match-string-no-properties 4))) (when (= (org-current-level) 1) (push headline headlines (print headlines --8<---cut here---end--->8--- BTW you're missing a closing parenthesis in: (setq current-header-item (org-element-property :title (org-element-at-point))) Maybe that's why you're getting errors. -- Jonathan
Re: [wip-cite-new] Initial implementation of `biblatex' citation processor
Hello, Denis Maier writes: > \cite is the most basic cite command: > > In a author-year style: > \cite => Doe 2020 > \textcite => Doe (2020) > \parencite=> (Doe 2020) > \autocite => \parencite > > In note-based styles (e.g verbose): > > \cite => Doe, Title > \footcite => [fn:: Doe, Title] > \parencite=> (Doe, Title) > \autocite => \footcite > >> >>> Also, footcite should be there. >> Footcite is already there under the "note"/"fn" style. > > Good! (I was just a bit confused because biblatex has \footcite and > \notecite. Here is the summary: | Style | Variant | Command | |---+---+--| | author| caps | Citeauthor* | | author| full | citeauthor | | author| caps-full | Citeauthor | | author| | citeauthor | |---+---+--| | locators | bare | notecite | | locators | caps | Pnotecite| | locators | bare-caps | Notecite | | locators | | pnotecite| |---+---+--| | nocite| | nocite | |---+---+--| | note | bare | footcitetext | | note | | footcite | |---+---+--| | smart | caps | Smartcite| | smart | | smartcite| |---+---+--| | super | | supercite| |---+---+--| | text | caps | Textcite | | text | | textcite | |---+---+--| | title | full | citetitle* | | title | | citetitle| |---+---+--| | year | full | citeyear*| | year | | citeyear | |---+---+--| | (default) | caps | Autocite | | (default) | | autocite | "bare" variant means "without parenthesis", I think. One problem is there is no "\cite", or "\parencite". I though they would make a good fit for the default style, "\cite" being the "bare" variant of "\parencite", and "\autocite" could be moved to a "auto" style. I'm not sure where to put \cite, then. Suggestions to change the table above are welcome. Regards, -- Nicolas Goaziou
Re: Get list of top-level headings
I think this is all you need to get a list of titles of level 1 headings as strings (org-map-entries (lambda () (fifth (org-heading-components))) "LEVEL=1") this also works for me: #+BEGIN_SRC emacs-lisp (org-map-entries (lambda () (org-element-property :title (org-element-at-point)) ) "LEVEL=1") #+END_SRC John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Wed, May 19, 2021 at 3:51 AM Florian Lindner wrote: > Hello, > > I, an Emacs Lisp newbie, want to get a list of all top-level headings of > the current buffer. My approach so far is: > > (defun test-org-map() > (interactive) > (setq headings '()) > (org-map-entries (lambda () > (setq current-header-item (org-element-property > :title (org-element-at-point)) > (message "Header: %s" current-header-item) > (message "Is String: %s" (stringp > (org-element-property :title (org-element-at-point > (setq headings (append current-header-item headings)) > ) >"LEVEL=1" >) > (dolist (heading headings) > (message "Header Item: %s" heading) > ) > ) > > This gives the otput: > > Header: AAA > Is String: t > Header: BBB > Is String: t > Header Item: 66 [3 times] > Header Item: 65 [3 times] > > so basically the (org-element-property :title (org-element-at-point) does > exactly what I want, but building the list does not what I want. I suppose > that comes from a fundamental misunderstanding of how strings work in elisp. > > I would appreciate a short explanation (or pointers) why this does not > work. And of course, I am very open to completely different, likely better, > approches to that simply problem! > > Thanks, > Florian >
Re: [wip-cite-new] Initial implementation of `biblatex' citation processor
On Wed, May 19, 2021 at 9:45 AM Nicolas Goaziou wrote: > "bare" variant means "without parenthesis", I think. To be more precise/general, it means without enclosing punctuation; parentheses, brackets, etc. Bruce
Org-capture %K "Link to the currently clocked task" link with id?
Looking at the source (org-capture.el), it appears org-capture doesn't allow you to make a permalink for "Link to the currently clocked task", or %K in your template. `org-capture-fill-template` looks like this: ... (v-K (if (marker-buffer org-clock-marker) (org-link-make-string (format "%s::*%s" (buffer-file-name (marker-buffer org-clock-marker)) v-k) v-k) "")) ... So i guess it's hardcoded to just make a bracket link. I guess i can hack something, but can you guys make a nice change to the source so that i can have a permalink to my clocked in task? Or is there something i'm missing and i can actually do it already? Thank you Nate
Re: [wip-cite-new] Initial implementation of `biblatex' citation processor
Hi, Am 18.05.2021 um 17:13 schrieb Nicolas Goaziou: Hello, In a rebased "wip-cite-new" branch, I made an modest attempt to write a `biblatex' citation processor, in the file "oc-biblatex.el" Just in case anyone else stumbles over this: You'll have the add (require 'oc-biblatex) to the cite-init.el file. - author(a), including caps(c), full(f) and caps-full(f) variants, - locators(l), including bare(b), caps(c) bare-caps(bc) variants, - nocite(n), - note(fn), including bare(b) variant, - smart(sm), including caps(c) variant, - super(s), - text(t), including caps(c) variant, - title(ti), including full(f) variant, - year(y), including full(f) variant, - default style, including caps(c) variant. What's the intended meaning of these "bare" variants? I was a bit confused by [cite/note/bare...] going to \footcitetext What's the intention here? Denis
Release 9.4.6 (bugfix)
Hi all, Org 9.4.6, a bugfix release, is out, avaiable in Org ELPA and as a standalone archive. Hopefully this will be the last one before we release 9.5. As always, thanks a lot to the contributors! See https://orgmode.org/worg/org-contribute.html on how to start contributing. -- Bastien
Re: [wip-cite-new] Initial implementation of `biblatex' citation processor
Am 19.05.2021 um 12:43 schrieb Bruce D'Arcus: On Wed, May 19, 2021 at 6:05 AM Denis Maier wrote: Is there a way to get a simple \cite? Hmm ... "cite/cite"? What does "cite" do that "autocite" doesn't? \cite is the most basic cite command: In a author-year style: \cite => Doe 2020 \textcite => Doe (2020) \parencite => (Doe 2020) \autocite => \parencite In note-based styles (e.g verbose): \cite => Doe, Title \footcite => [fn:: Doe, Title] \parencite => (Doe, Title) \autocite => \footcite Also, footcite should be there. Footcite is already there under the "note"/"fn" style. Good! (I was just a bit confused because biblatex has \footcite and \notecite. Denis
Re: [wip-cite-new] Initial implementation of `biblatex' citation processor
On Wed, May 19, 2021 at 6:05 AM Denis Maier wrote: > Is there a way to get a simple \cite? Hmm ... "cite/cite"? What does "cite" do that "autocite" doesn't? > Also, footcite should be there. Footcite is already there under the "note"/"fn" style. Bruce
Re: [wip-cite-new] Initial implementation of `biblatex' citation processor
Am 18.05.2021 um 17:13 schrieb Nicolas Goaziou: Hello, In a rebased "wip-cite-new" branch, I made an modest attempt to write a `biblatex' citation processor, in the file "oc-biblatex.el As Bruces has already written, this doesn't look modest at all. [...] - author(a), including caps(c), full(f) and caps-full(f) variants, - locators(l), including bare(b), caps(c) bare-caps(bc) variants, - nocite(n), - note(fn), including bare(b) variant, - smart(sm), including caps(c) variant, - super(s), - text(t), including caps(c) variant, - title(ti), including full(f) variant, - year(y), including full(f) variant, - default style, including caps(c) variant. Is there a way to get a simple \cite? Also, footcite should be there. The default style creates "autocite" commands. [...] I don't use biblatex, but I'm not convinced by the default autocite command. Wouldn't parencite be more predictable? Also, adding #+cite_export biblatex ... auto to trigger autocite by default seems easy enough. I think autocite is a reasonable default. Parencite would be a bad fit for the verbose styles. And in author-year styles autocite is equivalent to parencite anyway. Denis
Re: Cross referencing in Emacs Org mode
Hi, The question, then, is not if you can have cross-references (as you say, they work fine), but if they will work with subtree export. I believe not (but others may have to correct me). Links/refs to parts of the document outside the exported subtree *will* be broken. The exporter does not consider other sections of the document and will not try to resolve how the refs *should* have looked. If you use custom IDs or dedicated Org targets like <> for the label and links like [[label1]] for the refs, you *can* manage how broken links should be handled. `C-h v org-export-with-broken-links' for details. Yours, Christian Partha Pratim Ghosh writes: > Dear All, > > Is it possible to have cross reference in LaTeX export for Org > mode. To be specific: I have a org file segmented into sections, say as > follows: > > *** example of Org file, excluding the headers** > > * Section 1 > contains some text, a label [label:label1] and some citation > [cite:cite1] > > * Section 2 > contains some text, a label [label:label2] and a reference to label1 > as [ref:label1], and a reference to a label in Section 3, [ref:label3] > > * Section 3 > contains some text, and label [label:label3] > > \printbibliography > > > > I did not include the headers where the bibliography files are properly > added. When I export the full buffer with C-c C-e l o everything runs > fine. However, whenever I go to Section 2, say and try to export using > C-c C-e C-s l o (for subtree export only), the bibliography does not > appear, and the reference to label1 or label3 does not appear. > > Is it possible to have the labels properly referenced as well as the > bibliography printed when subtrees are only exported to pdf? > > With my regards and all the very best wishes, > > partha
Re: [PATCH] Link handling for qutebrowser org-mac-link.el
Aimé Bertrand writes: > you know what, I wanna do my part: > > https://sr.ht/~aimebertrand/org-mac-link/ Thanks! I updated the org-contrib repository. -- Bastien
Re: [PATCH] Async session eval (2nd attempt)
Hi Jack, Jack Kamm writes: >> Please feel free to commit this patch in master so that more people >> can test it, we can test and fix oddities while preparing for 9.5. > > OK, I have incorporated the minor fixes from Kyle's review and pushed to > master. Thanks a lot! -- Bastien
Re: Cross referencing in Emacs Org mode
On Wednesday, 19 May 2021 at 00:25, Partha Pratim Ghosh wrote: > Is it possible to have cross reference in LaTeX export for Org > mode. To be specific: I have a org file segmented into sections, say as > follows: Check out the "Internal Links" section of the org manual. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-534-g8f03cd
Get list of top-level headings
Hello, I, an Emacs Lisp newbie, want to get a list of all top-level headings of the current buffer. My approach so far is: (defun test-org-map() (interactive) (setq headings '()) (org-map-entries (lambda () (setq current-header-item (org-element-property :title (org-element-at-point)) (message "Header: %s" current-header-item) (message "Is String: %s" (stringp (org-element-property :title (org-element-at-point (setq headings (append current-header-item headings)) ) "LEVEL=1" ) (dolist (heading headings) (message "Header Item: %s" heading) ) ) This gives the otput: Header: AAA Is String: t Header: BBB Is String: t Header Item: 66 [3 times] Header Item: 65 [3 times] so basically the (org-element-property :title (org-element-at-point) does exactly what I want, but building the list does not what I want. I suppose that comes from a fundamental misunderstanding of how strings work in elisp. I would appreciate a short explanation (or pointers) why this does not work. And of course, I am very open to completely different, likely better, approches to that simply problem! Thanks, Florian
Re: Bug: Can't set background color of latex fragment
Hi Roshan,
Roshan Shariff writes:
I can confirm this bug with dvipng --- with the "-bg Transparent"
option, dvipng ignores the background color from the input tex file,
whereas without that option it always produces an opaque background.
There's currently no way to dynamically change command line
parameters, so I'm not sure how to solve this problem while supporting
both use cases.
I asked about this behaviour on the dvipng mailing list, and the
maintainer doesn't consider it a bug, see
https://lists.nongnu.org/archive/html/dvipng/2021-05/msg2.html.
Can you explain the use for a `Transparent` background ? Transparent
images are poorly supported in emacs, all it does is render it with
the background color of the default face -- which may not be the
expected result.
Regards,
--
Sébastien Miquel
On Wed, Apr 7, 2021 at 1:38 PM Sébastien Miquel
wrote:
To reproduce with `emacs -Q` :
- Open an org buffer
- Call ~(setq org-format-latex-options '(:foreground default
:background "Black" :matchers ("$")))~
- Call =C-c C-x C-l= (org-latex-preview) on a latex fragment such as
$abc$
This bug was introduced by the commit 2f9e1569f which adds the option
`-bg Transparent` to the arguments of `dvipng`. According to its
manual, this option should be ignored if a background is already set,
but it doesn't seem to be. Perhaps org should set it differently.
--
Sébastien Miquel
