[O] problem with export of #+BEGIN_src latex :results latex replace :exports results :eval t
Hi
The following org file is exported correctly to latex.
,
|
| * Test of the bibliography
|
|
| \begin{equation}
| \label{eq:testbib:1}
| \int f dx =0
| \end{equation}
|
| see
| citep:tao08:_global
|
|
| bibliographystyle:unsrt
| bibliography:/home/oub/texmf/bibtex/bib/bibgraf.bib
`
However I sometimes prefer
,
| * Test of the bibliography
| #+BEGIN_src latex :results latex replace :exports results :eval t
|
| \begin{equation}
| \label{eq:testbib:1}
| \int f dx =0
| \end{equation}
|
| see
| citep:tao08:_global
|
| #+END_src
| bibliographystyle:unsrt
| bibliography:/home/oub/texmf/bibtex/bib/bibgraf.bib
|
`
Because this way the fortification for \begin{equation} is the same as
in my latex buffer (with auctex).
However, in this case the exportation to latex is only partially
successful.
citep:tao08:_global
Is *not* expanded.
Can this problem solved?
Regards
Uwe Brauer
[O] [Bug?] org-20181210 seems to break Column View
I've been using Column View for quite some time without any issues. After today's update, C-c C-c on the BEGIN line of the dynamic block #+BEGIN: columnview :hlines 1 :id local :maxlevel 3 [...] #+END: draws the table close to the very beginning of a buffer, starting at the 11th char, cells determined by forumlas are left empty, the dynamic block is emptied as well (so e.g. a TBLFM statement is gone). I'm quite sure it happened in recent hours, as I perform Column View refresh several times a day. signature.asc Description: PGP signature
Re: [O] Org-Publish of a PDF ??
Richard Lawrence writes: > David Masterson writes: >> When I publish my project, I find that my org files are first generated >> into tex and pdf files in directory1 and then the tex/pdf files are >> copied to directory2. What I would like is for the tex/pdf files to be >> directly generated in directory2 with no "extras" in directory1. > I think you might be thinking about this the wrong way around. I may be > wrong about this, as I'm not a heavy user of the publishing framework, > but here's my two cents. > > As far as I understand it, the publishing framework is basically > designed around the idea of copying finished products to a desired > location (a directory, either locally or on a webserver). It's built as > a layer on top of Org's exporters, not as a way to make those exporters > behave differently. If you want to control the *build* process for the > PDF, as opposed to just where it finally ends up, you probably want to > set options for the latex exporter, not the publishing framework. > > In particular, you might want something like: > > #+EXPORT_FILE_NAME: builddir/file.tex > > in the Org files you're exporting, where builddir is somewhere outside > of your directory1. (I'm *pretty* sure that will work, but I haven't > tested it.) Hmm. That's a possibility. Then, I assume, that, after EXPORT_FILE_NAME is made, the PDF file will be made in the same location. I'll have a look at the exporter options more. I wonder if there is an EXPORT_DIR..? -- David
Re: [O] Bug: protocol capture without url corrupts org-stored-links [9.1.14 (9.1.14-1059-gadec50-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181211/)]
On Wed, Dec 12, 2018 at 9:59 AM Nicolas Goaziou wrote: > > Could you give more context about the bug you're encountering? What does > mean "function correctly if a URL was not provided"? What is the use > case? What result did you expect, besides not encountering an error > message? The issue occurs when org protocol capture is invoked without a url param, e.g. emacsclient 'org-protocol://capture?url=percent-encoded-url&body=some-text' vs emacsclient 'org-protocol://capture?body=some-text' By "function correctly", I mean make the latter not break org-insert-link by not corrupting the value of org-stored-links. The use case is capturing some text without an associated URL. The result I expect is the latter not breaking org-insert-link. Note that invoking the latter otherwise behaves correctly/as expected. It starts the capture process with the provided body text/initial contents. The only thing that breaks is org-insert-link when the user calls org-insert-link later. > There are multiple ways to solve this. In particular, if a URL is not > provided, it seems natural to store nil instead, as > `org-protocol-capture' currently does. If we do not support missing URL, > then it should raise an error instead of letting it slip into > `org-insert-link'. If we do, then `org-insert-link' should handle it > gracefully. Except storing nil is not supported by org-insert-link, breaking it until the savvy user manually fixes org-stored-links. I don't see what meaning storing and inserting a nil link could have. We could change org-insert-link to fix or ignore the invalid value in org-stored-links, but why not stop inserting the invalid value into org-stored-links in the first place? > > So, again, more context could help understanding what is the best > solution. > > Regards, > > -- > Nicolas Goaziou
Re: [O] Bug: Special property ITEM without stars [9.1.14]
On Wed, Dec 12, 2018 at 10:00 AM Nicolas Goaziou wrote: > > This is not satisfying, actually. If every item has a single asterisk, > you miss hierarchy between headlines in the same tree. I don't know what you mean. Hierarchy is not displayed normally in agenda view anyway, I don't know why displaying it in agenda column view via the ITEM property is desirable? > > You can use `org-columns-modify-value-for-display-function' to remove > the asterisks, if needed. Is there a recommended way to set this only for agenda views? I tried setting it via the custom settings in org-agenda-custom-commands but that doesn't work. > > Regards, > > -- > Nicolas Goaziou
Re: [O] CSV batch agenda
On 2018-12-12, at 15:23, Nicolas Goaziou wrote: > Hello, > > Marcin Borkowski writes: > >> I'm playing around with `org-batch-agenda-csv'. My question is, what is >> "String with extra planning info"? > > No idea. The manual is pretty vague, indeed. Well, maybe I'll try to edebug this one day, or just read the source... >> Also, what is "numerical priority" and how is it computed? I could find >> any reference in the manual. Again, a quick experiment suggests >> a number between 1000 and 2000, converging to 2000 as the item gets more >> and more overdue. Do I guess it right? > > See `org-get-priority-function'. Hm, it's nil in my Emacs... But grepping the source revealed `org-get-priority'. I'll look into this, thanks! Best, -- Marcin Borkowski http://mbork.pl
Re: [O] [PATCH] ox.el: Define subtitle macro
> master branch is meant to be released... at some point. For the record, > I cannot do it myself. +1 It would be great to have Org 9.2 released!
Re: [O] meaning for _ (and perhaps ^) temporalily changed
On Mon, Dec 10, 2018 at 5:34 AM Rudolf Sykora wrote:
>
> Dear list,
>
> is there a way to *temporalily* disable the default interpretation
> of _ as a subscript?
>
> I use filenames which include _ , while I have
> many other places where I want the default behaviour
> (I don't want to rewrite these with explicit {} and changing
> org-use-sub-superscripts variable to {}).
If you set this in your Emacs config:
(setq org-export-with-sub-superscripts '{})
The subscripts and superscripts will be parsed only when the
to-be-subscripted/superscripted is enclosed in _{..} and ^{..}
respectively.
If you don't want to set this option globally,add this to the top of
your Org file:
#+options: ^:{}
>From Org manual (org) Export Settings:
‘^’
Toggle TeX-like syntax for sub- and superscripts. If you write
‘^:{}’, ‘a_{b}’ is interpreted, but the simple ‘a_b’ is left as it
is (‘org-export-with-sub-superscripts’).
Re: [O] Org-Publish of a PDF ??
Hi David, David Masterson writes: > When I publish my project, I find that my org files are first generated > into tex and pdf files in directory1 and then the tex/pdf files are > copied to directory2. What I would like is for the tex/pdf files to be > directly generated in directory2 with no "extras" in directory1. I think you might be thinking about this the wrong way around. I may be wrong about this, as I'm not a heavy user of the publishing framework, but here's my two cents. As far as I understand it, the publishing framework is basically designed around the idea of copying finished products to a desired location (a directory, either locally or on a webserver). It's built as a layer on top of Org's exporters, not as a way to make those exporters behave differently. If you want to control the *build* process for the PDF, as opposed to just where it finally ends up, you probably want to set options for the latex exporter, not the publishing framework. In particular, you might want something like: #+EXPORT_FILE_NAME: builddir/file.tex in the Org files you're exporting, where builddir is somewhere outside of your directory1. (I'm *pretty* sure that will work, but I haven't tested it.) Hope that helps! -- Best, Richard
Re: [O] Noweb blocks duplicate during Org export if part of #+include
On Sat, Dec 8, 2018 at 4:42 AM Nicolas Goaziou wrote: > Now, onto the second case. When evaluating Babel code, the whole initial > buffer is taken as reference. It allows, for example, to define source > blocks in a dedicated section, and export another one that calls them. > When the INCLUDE keyword is expanded, there are two ":noweb-ref > some_snippet". Even if they are outside the exported subtree, they are > still concatenated and used as a replacement for "<". > > In a nutshell, that can be surprising, but this is to be expected. Thank you for the detailed answer. As I don't know how to "fix" this, I will just remember to not use Noweb in subtrees that I plan to #+include.
Re: [O] Bug: Special property ITEM without stars [9.1.14]
Hello, Allen Li writes: > On Thu, Dec 6, 2018 at 6:35 AM Nicolas Goaziou wrote: >> We could ignore the level when displaying ITEM in agenda column view. As >> a consequence, every item would start with a single star, which is >> shorter and still not confusing. > > Sounds good to me. This is not satisfying, actually. If every item has a single asterisk, you miss hierarchy between headlines in the same tree. You can use `org-columns-modify-value-for-display-function' to remove the asterisks, if needed. Regards, -- Nicolas Goaziou
Re: [O] Bug: protocol capture without url corrupts org-stored-links [9.1.14 (9.1.14-1059-gadec50-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181211/)]
Hello, Allen Li writes: > I didn't realize that org-protocol-capture is documented for URLs, > since the concept of capturing through org-protocol is useful for > non-web browser contexts. > > Anyway, I'm not interested in updating the documentation for > org-protocol-capture at the moment, but even if org-protocol-capture > is documented to need a URL, it seems wrong for it to corrupt > org-stored-links but otherwise function correctly if a URL was not > provided. Could you give more context about the bug you're encountering? What does mean "function correctly if a URL was not provided"? What is the use case? What result did you expect, besides not encountering an error message? There are multiple ways to solve this. In particular, if a URL is not provided, it seems natural to store nil instead, as `org-protocol-capture' currently does. If we do not support missing URL, then it should raise an error instead of letting it slip into `org-insert-link'. If we do, then `org-insert-link' should handle it gracefully. So, again, more context could help understanding what is the best solution. Regards, -- Nicolas Goaziou
Re: [O] CSV batch agenda
Hello, Marcin Borkowski writes: > I'm playing around with `org-batch-agenda-csv'. My question is, what is > "String with extra planning info"? No idea. The manual is pretty vague, indeed. > Also, what is "numerical priority" and how is it computed? I could find > any reference in the manual. Again, a quick experiment suggests > a number between 1000 and 2000, converging to 2000 as the item gets more > and more overdue. Do I guess it right? See `org-get-priority-function'. Regards, -- Nicolas Goaziou
Re: [O] Bug: org-map-entries narrowing smaller than entry [9.1.14 (9.1.14-1049-g04641c-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)]
Hello, Allen Li writes: > I think this issue is medium/low priority and difficult to resolve. I > have worked around it for my use case. However, I still think it is > an issue since it's an edge case that users of org-map-entries will > need to take into account. This is not specific to `org-map-entries' and many parts of the code already deal with it. I don't think there is anything to fix in a general fashion, though. Regards, -- Nicolas Goaziou
