Re: Removing horizontal space in latex fragments
Not really worried about which alternative is chosen. I was just exhibiting my inner compulsive nature... ;-) -- Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-544-gd215c3
Re: Removing horizontal space in latex fragments
Thanks for the reply Eric. The thing I like about the newlines is that the generated tex files are slightly easier to read. However, this is really minor. I've created 2 separate patches: one keeping the newlines and the other without. I'm happy to defer to you or anyone else in regard to which is preferable. On Thu, Dec 5, 2019 at 2:24 PM Fraga, Eric wrote: > On Thursday, 5 Dec 2019 at 11:03, Matt Huszagh wrote: > > Is anyone else interested in this modification? Should I submit it as a > > patch? > > I think so. And I am not sure all those \n's are necessary. Without > them, you can probably also remove many of the %s. > -- > Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-544-gd215c3 > remove-newlines.patch Description: Binary data keep-newlines.patch Description: Binary data
Re: android phone computer and orgmode
One thing I forgot to mention in the previous thread (apologies if it was already mentioned, I didn't see it) is you could try git-annex. The android version does rely on termux as its runtime, but interacting with it is through a local web server, so if use of termux for initial setup is an option for you, it should be usable ongoing without having to interact with termux directly through the console. I haven't personally used it, but I was researching it for a personal project (different goal) at one point. git-annex itself is an extension that allows for large files to be versioned with git while not necessarily physically present on a device and is very general, but git annex assistant is implemented on top of it and acts as a decentralized sync client. If you're happy with Dropbox I'm not sure it would add anything for you, but i meant to mention it alongside Syncthing earlier. I look forward to hearing more about what you decide on. Personally I'm very, very excited that orgzly is getting native git support. Alex On 12/3/19 2:03 PM, Jude DaShiell wrote: > Since I use a command line on the computer I got orgsly and dropbox > working on the phone. > If I can get rclone working on the computer with dropbox I'll have > synchronizing capability. > Other applications on archlinux and slint either don't work or aren't > accessible for screen reader users like me. > > More later when I figure it out. > > > -- > >
Incompatible changes regarding link
Hello, I just noticed that the recent updates regarding the bracket link escaping syntax seem to have an issue. Does anybody happen to know how to put a pair of [] around a link without using "zero width space" or something similar? For example, [[[https://somewhere-to-url][My Link]]] does not succeed in exporting to HTML showing "Unable to resolve link: "[https://somewhere-to-url"";. [[https://somewhere-to-url][[My Link]]] is not properly exported; the closing bracket "]" is not included in the exported link. Thank you! Best regards, Kiwon
Re: org-custom-id-goto?
John Kitchin writes: > If you like ivy, you might find this helpful: Also see counsel-org-goto and counsel-org-goto-all, which provide similar capability. > Fraga, Eric writes: > >> On Wednesday, 4 Dec 2019 at 10:26, Matt Price wrote: >>> Is there a quasi-equivalent of ~org-id-goto~ or >>> ~org-babel-goto-named-src-block~ which will jump to a header in the >>> current buffer? >> >> If by header you mean headline or heading, I don't think there is >> anything exactly how you might want it but you should maybe look at >> "org-goto" and "org-occur" (or both in combination). > > > -- > Professor John Kitchin > Doherty Hall A207F > Department of Chemical Engineering > Carnegie Mellon University > Pittsburgh, PA 15213 > 412-268-7803 > @johnkitchin > http://kitchingroup.cheme.cmu.edu > > --
Included global properties not inherited: bug or feature?
Greetings.
It seems that when a file with global properties is included, the global
properties are not inherited. Is this a bug or a feature?
Consider the two files inlined below:
# -- file 'included.org' ---
#+property: MY_INCLUDED_PROPERTY some included value
# --
# -- file which includes ---
#+include: included.org :only-contents nil
#+property: MY_INLINE_PROPERTY some inline value
src_elisp[:exports results :results raw]{(org-entry-get nil
"MY_INCLUDED_PROPERTY" t)} nil
src_elisp[:exports results :results raw]{(org-entry-get nil
"MY_INLINE_PROPERTY" t)} some inline value
# --
As you can see from the results of evaluation of elisp blocks, the
included global property is not available in the including file. Note
that the documentation for #include states that there is a special
property :only-contents for including only contents, not properties. To
play it safe, I have set this property to 'nil' above.
https://orgmode.org/manual/Include-files.html
Based on this documentation, I was expecting global properties to be
available by default in including files.
I find current behaviour inconvenient, because I want to set common
global properties for a large number of files, and I can not currently
do this via an included file.
What is the verdict?
I am running
Org mode version 9.3 (release_9.3-34-g2eee3c)
GNU Emacs 26.2
Jarmo
Re: Bug: Org 9.3 table columnwidth directive not working [9.3 (release_9.3 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
On Thu 05 Dec 2019, Kyle Meyer wrote: > Pankaj Jangid writes: > >> C-c TAB is working but earlier the behaviour was to apply >> directive by default on next electric formatting. Has the behaviour >> changed in 9.3? > > 9.2, I believe, more specifically 6d6a30d4c (org-table: Implement shrunk > columns, 2017-06-27). The relevant NEWS entry, added in 6e5598dc3 > (Document new column display, 2017-08-19), is > > *** =align= STARTUP value no longer narrow table columns > > Columns narrowing (or shrinking) is now dynamic. See [[*Dynamically > narrow table columns]] for details. In particular, it is decoupled from > aligning. > > If you need to automatically shrink columns upon opening an Org > document, use =shrink= value instead, or in addition to align: > > #+BEGIN_EXAMPLE > ,#+STARTUP: align shrink > #+END_EXAMPLE > > Quickly digging, here are some related threads on the mailing list: > > https://lists.gnu.org/archive/html/emacs-orgmode/2017-07/msg00214.html > https://lists.gnu.org/archive/html/emacs-orgmode/2017-09/msg00217.html This is still a regression. The old behaviour allowed display of fixed width columns, even if that is wider than the content of cells in that column. This is useful for display of several related tables with aligned column dividers. How do I get the old behaviour back, rather than the new breakage ? AndyM
How-to use a source block output as code for another source block?
Hello,
Yesterday I asked this question on IRC and the community kindly
answered. I was also asked to send an email to the mailing list
explaining my use case. Thus this email.
So, in the scope of my current project at work I need to see if Neo4J would
be a valid alternative to PostgreSQL to store our data. Were hoping to
have better flexibility and better performance on some requests.
In order to document the steps of my exploration I decided to use
org-mode which I discovered a couple of weeks ago (I use it mainly to
keep a diary of my work days).
The first step in my investigation is to migrate the data from Postgres
to Neo4j via CSV files. Since our schema contains quite a bit of tables
and relations I decided to generate corresponding SQL COPY ... TO ...
requests by first putting variable data in a array, second generating
requests with a python source bloc and then feed it to a SQL bloc. Here
is the result:
#+tblname: rels-data
| computer | id | house | house_id | EQUIPS |
computer |
| house | id | block | block_id | IN |
house |
| block | id | city | city_id | IN | block |
| city | id | country | country_id | IN | city |
| city | id | city_group | city_group_id | BELONGS_TO |
city |
#+name: import-rels
#+begin_src python :var rels=rels-data :results value verbatim
res = ["""COPY (
SELECT '{0}' || {1} as ":START_ID", '{2}' || {3} as ":END_ID", '{4}'
as ":TYPE"
FROM "{5}"
) TO '/data/rels_{0}_{2}.csv' WITH CSV HEADER;""".format(*row) for row
in rels]
return "\n".join(res)
#+end_src
#+name: export-data
#+header: :engine postgresql
#+header: :dbhost localhost
#+header: :dbuser mrwho
#+header: :database whatever
#+header: :noweb no-export
#+begin_src sql
<>
#+end_src
All the magic is in the use of noweb[1] feature.
If you have any questions or remarks don't hesitate.
Regards,
[1] https://orgmode.org/manual/noweb.html
Issues with nested begin..end blocks in inline math environments
I'm experiencing incorrect and seemingly inconsistent behavior when nesting
`\begin` `\end` environments inside `\(\)` or `$$`. For example, the
following is valid latex code:
```
\(\begin{aligned}
b_n &= \frac{1}{\pi} \int_{0}^{\pi} x \sin{\left(nx\right)}dx \\
b_0 &= 0 \\
\int_{0}^{\pi} udv &= \left[uv\right]_{0}^{\pi}
- \int_{0}^{\pi} vdu \\
dv &= \sin{\left(nx\right)}dx \\
v(x) &= \int \sin{\left(nx\right)}dx \\
&= -\frac{\cos{\left(nx\right)}}{n} \\
\left[uv\right]_{0}^{\pi} &=
-\left[\frac{x\cos{\left(nx\right)}}{n}\right]_{0}^{\pi} \\
&= \left\{\begin{alignedat}{2}
\frac{\pi}{n}&, && \quad \text{$n$ odd} \\
-\frac{\pi}{n}&, && \quad \text{$n$ positive even} \\
\end{alignedat}\right. \\
\int_{0}^{\pi} vdu &=
\int_{0}^{\pi} -\frac{\cos{\left(nx\right)}}{n} dx \\
&= -\frac{1}{n^2} \left.\sin{\left(nx\right)}\right|_{0}^{\pi} \\
&= 0 \\
b_{n\in \mathbb{Z}^+} &= \left\{\begin{alignedat}{2}
\frac{1}{n}&, && \quad \text{$n$ odd} \\
-\frac{1}{n}&, && \quad \text{$n$ positive even} \\
\end{alignedat}\right. \\
\end{aligned}\)
```
But this confuses org which is generating images for the `\begin{aligned}`
at the top and the `\text` macros, but nothing else. Iterations on this
sometimes work fine, however. For example,
```
\(\begin{aligned}
b_{n\in \mathbb{Z}^+} &= \left\{\begin{alignedat}{2}
\frac{1}{n}&, && \quad \text{$n$ odd} \\
-\frac{1}{n}&, && \quad \text{$n$ positive even} \\
\end{alignedat}\right. \\
\end{aligned}\)
```
typesets correctly. Has anyone else had trouble with the latex fragment
regex's?
Re: Incompatible changes regarding link
Hello, Kiwon Um writes: > I just noticed that the recent updates regarding the bracket link escaping > syntax seem to have an issue. > > Does anybody happen to know how to put a pair of [] around a link without > using "zero width space" or something similar? > For example, > [[[https://somewhere-to-url][My Link]]] does not succeed in exporting to HTML > showing "Unable to resolve link: "[https://somewhere-to-url"";. I don't see any issue here. The "zero width space" is exactly for that situation. But, honestly, the fact that it worked differently in the past is the real issue. The current interpretation is correct. > [[https://somewhere-to-url][[My Link]]] is not properly exported; the > closing bracket "]" is not included in the exported link. This looks like a different problem. If you want to include the brackets, you need to escape them, as explained in the ORG-NEWS document, or in the manual: [[https://somewhere-to-url][\[My Link\]]] Regards, -- Nicolas Goaziou
Re: Bug: Org 9.3 table columnwidth directive not working [9.3 (release_9.3 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
Hello, Andy Moreton writes: > This is still a regression. > > The old behaviour allowed display of fixed width columns, even if that > is wider than the content of cells in that column. This is useful for > display of several related tables with aligned column dividers. > > How do I get the old behaviour back, rather than the new breakage ? I will try to ignore the sarcasm, or whatever you may call it, from your answer. AFAICT, you still can have cells wider than their contents, e.g., try `C-c TAB` on the table below. | <30> | | foo | Regards, -- Nicolas Goaziou
Re: Included global properties not inherited: bug or feature?
Hello, Jarmo Hurri writes: > I find current behaviour inconvenient, because I want to set common > global properties for a large number of files, and I can not currently > do this via an included file. What happens if you use SETUPFILE instead? Regards, -- Nicolas Goaziou
Re: Incompatible changes regarding link
Hello, Thank you for the reply. On Fri, Dec 6, 2019 at 9:33 PM Nicolas Goaziou wrote: > Kiwon Um writes: > > > I just noticed that the recent updates regarding the bracket link escaping > > syntax seem to have an issue. > > > > Does anybody happen to know how to put a pair of [] around a link without > > using "zero width space" or something similar? > > For example, > > [[[https://somewhere-to-url][My Link]]] does not succeed in exporting to > > HTML showing "Unable to resolve link: "[https://somewhere-to-url"";. > > I don't see any issue here. The "zero width space" is exactly for that > situation. > But, honestly, the fact that it worked differently in the past is the > real issue. The current interpretation is correct. I didn't know what the issue in the past interpretation was, but I am just not sure whether it's a good idea to enforce that we must use such a special character, which we cannot directly see from the editor. > > [[https://somewhere-to-url][[My Link]]] is not properly exported; the > > closing bracket "]" is not included in the exported link. > > This looks like a different problem. If you want to include the > brackets, you need to escape them, as explained in the ORG-NEWS > document, or in the manual: > > [[https://somewhere-to-url][\[My Link\]]] Unfortunately, this doesn't work either. [[https://www.youtube.com/][\[You Tube\]]] is exported as https://www.youtube.com/";>\[You Tube\] Regards, Kiwon
Re: Incompatible changes regarding link
Kiwon Um writes: > I didn't know what the issue in the past interpretation was, but I am > just not sure whether it's a good idea to enforce that we must use > such a special character, which we cannot directly see from the > editor. This is because you are using an ambiguous construct. There are things you cannot do in Org (e.g., starting a line with "|" and expect it to be something else than a table), yet, Org provides a syntax to work around the problem. I agree this is not perfect. >> > [[https://somewhere-to-url][[My Link]]] is not properly exported; the >> > closing bracket "]" is not included in the exported link. >> >> This looks like a different problem. If you want to include the >> brackets, you need to escape them, as explained in the ORG-NEWS >> document, or in the manual: >> >> [[https://somewhere-to-url][\[My Link\]]] > > Unfortunately, this doesn't work either. > [[https://www.youtube.com/][\[You Tube\]]] is exported as href="https://www.youtube.com/";>\[You Tube\] Indeed! I forgot about that: the escaping mechanism is for the link part. For the description part, you have to use a zero width space, too. Note that `org-insert-link' (C-c C-l) does that automatically. IIRC, square brackets were forbidden in descriptions (and changed into curly brackets automatically) before that change.
Re: Incompatible changes regarding link
On Fri, Dec 6, 2019 at 10:10 PM Nicolas Goaziou wrote: > > Kiwon Um writes: > > > I didn't know what the issue in the past interpretation was, but I am > > just not sure whether it's a good idea to enforce that we must use > > such a special character, which we cannot directly see from the > > editor. > > This is because you are using an ambiguous construct. There are things > you cannot do in Org (e.g., starting a line with "|" and expect it to be > something else than a table), yet, Org provides a syntax to work around > the problem. I agree this is not perfect. I understand Org-mode has its syntax. I am not saying Org-mode should be able to do everything we want. As you already agreed, I'm just not sure whether it's the best. In my opinion, one of the great advantages of Org-mode is that we can do a lot of things with plain texts, and here I am just little bit unhappy with using hidden characters to escape something, particularly in a plane text file. > > Unfortunately, this doesn't work either. > > [[https://www.youtube.com/][\[You Tube\]]] is exported as > href="https://www.youtube.com/";>\[You Tube\] > > Indeed! I forgot about that: the escaping mechanism is for the link > part. For the description part, you have to use a zero width space, too. > Note that `org-insert-link' (C-c C-l) does that automatically. > > IIRC, square brackets were forbidden in descriptions (and changed into > curly brackets automatically) before that change. Right, that seems to be the only option for now. I may use zero width spaces or other parentheses around links. Thank you for your time again. Best, Kiwon
Re: Included global properties not inherited: bug or feature?
Nicolas Goaziou writes:
>> I find current behaviour inconvenient, because I want to set common
>> global properties for a large number of files, and I can not currently
>> do this via an included file.
>
> What happens if you use SETUPFILE instead?
It works perfectly.
Please find attached a patch that mentions this behaviour in the
include-part of Org manual. Ok?
Jarmo
>From 00701e1732fcf71180dc02f72117b44bccf5eb2d Mon Sep 17 00:00:00 2001
From: Jarmo Hurri
Date: Sat, 7 Dec 2019 08:19:05 +0200
Subject: [PATCH] org-manual.org: Document global properties not being
inherited when including files
* doc/org-manual.org: Note that when an org-file is included, even
with `:only-contents` set to `nil`, global properties set with lines
beginning `#+PROPERTY:` will not be inherited in the file that
includes. Point the user to use `#+SETUPFILE:` for this purpose.
---
doc/org-manual.org | 5 +
1 file changed, 5 insertions(+)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 35f6013ce..a0aedf825 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -11770,6 +11770,11 @@ with the custom ID =theory=, you can use
: #+INCLUDE: "./paper.org::#theory" :only-contents t
+Note that even when =:only-contents= has value ~nil~, properties set
+in the included file by lines beginning with =#+PROPERTY:= will not be
+inherited in the file that includes. To achieve such inheritance, use
+=#+SETUPFILE:= instead (see [[Summary of In-Buffer Settings]]).
+
The following command allows navigating to the included document:
- {{{kbd(C-c ')}}} (~org-edit~special~) ::
--
2.21.0
PATCH: Display point of code block point when confirming evaluation
Greetings. Please find attached a patch that adds the point of the source code block to the message shown to user when confirming the evaluation of the block. In large org-files, I have often trouble figuring out which code block Org is confirming me to evaluate when exporting. This is especially true when I have set 'cache: yes'. When something changes in code, these blocks need to be re-evaluated during export, but the '#results:' of these blocks are not changed. Therefore, on the next export I will be asked again, unless I find the block and evaluate it by hand myself. This patch adds the 'start' element of source block info at the end of the confirmation message. Jarmo >From aaa68af8a7710ffe2c61fc45edf2ff377438cd32 Mon Sep 17 00:00:00 2001 From: Jarmo Hurri Date: Sat, 7 Dec 2019 09:14:34 +0200 Subject: [PATCH] ob-core.el: Display block point during evaluation confirmation * lisp/ob-core.el (org-babel-confirm-evaluate): Display code block point when querying confirmation of evaluation. This addresses the problem of finding the block currently evaluated. --- lisp/ob-core.el | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index f877ff51b..7ba9894e6 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -277,7 +277,8 @@ environment, to override this check." (let* ((evalp (org-babel-check-confirm-evaluate info)) (lang (nth 0 info)) (name (nth 4 info)) - (name-string (if name (format " (%s) " name) " "))) + (name-string (if name (format " (%s) " name) " ")) + (start (nth 5 info))) (pcase evalp (`nil nil) (`t t) @@ -285,11 +286,11 @@ environment, to override this check." (and (not (bound-and-true-p org-babel-confirm-evaluate-answer-no)) (yes-or-no-p - (format "Evaluate this %s code block%son your system? " - lang name-string))) + (format "Evaluate this %s code block%son your system (point %d)? " + lang name-string start))) (progn - (message "Evaluation of this %s code block%sis aborted." - lang name-string) + (message "Evaluation of this %s code block%sis aborted (point %d)." + lang name-string start) nil))) (x (error "Unexpected value `%s' from `org-babel-check-confirm-evaluate'" x) -- 2.21.0
