On Thu, 2023-03-09 at 12:22 +, Ihor Radchenko wrote:
>
> im-in-options and im-out-options, according to
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html
> ,
> are options passed to ImageMagick.
>
> However, for example, (shell-quote-argument "-enhance -strip") will
>
Hi
I have
The following setting in my custom file
'(org-ref-formatted-citation-formats
'(
("org"
("misc" . "${author}, /${title}/ *${howpublished}* ${url} (${year}).")
("article" . "${author}, /${title}/, ${journal}, *${volume}(${number})*,
${pages} (${year}). ${doi}")
Yep, I had seen that whitespace is the issue in my initial email, but I
had not noticed that tabs are used. So here's a third attempt, sorry
for the hiccups.
Whitespace should be consistent now. :) And yes, attachments are much
better, but I wasn't sure about the policy here and I have not setup
> We have org-edit-prep:lang functions that do initial setup in individual
> languages. However, they will be applied both when you call
> `org-babel-do-in-edit-buffer' and in C-c '.
I have no problem with these being called in both cases. However, as
functions they would be "extensible" only by
On 10/03/2023 19:08, Ihor Radchenko wrote:
Do I understand correctly that you propose the following:
If we have
[previous object ][object to be removed ]
change it to
[previous object ]
Yes, you do.
I expected some complications due to newline characters (not line break
markup
赵一宇 writes:
> +org-realign-table-maybe-h function definition is at the end.
>
> Instead of using save-excursion macro, it saves current point to a var,
> and restore the point after execute org-table-align.
> That would cause point move visually. Although the (point) value not changed,
>
Daniel Kraus writes:
> attached is a bigger patch that fixes the result output of ob-clojure.
> The commit message contains examples what's currently wrong
> and what's fixed.
> This is a breaking change though.
> So if someone before relied on the fact that, e.g. cider, returns
> the result of
On 10/03/2023 18:48, Ihor Radchenko wrote:
Tim Ruffing writes:
* org-agenda.el (org-prepare-agenda): Don't reset
`org-todo-keywords-for-agenda' when org-agenda-multi.
Unfortunately, it does not apply.
- @@ lines are wrapped by mail user agent
- tabs are converted to spaces
Attached with TINYCHECK.
Unfortunately I don't have the time to write a test right now because
I'll be traveling from tomorrow on. (You'd to wait for at least 6
weeks..)
Here's a sketch for a test case:
* Show an agenda with that has org-agenda-multi
* In the agenda buffer, assert that
Max Nikulin writes:
>> Plain strings always have :post-blank nil.
>> So do line breaks.
>
> If preceding object is string than trailing spaces should be taken into
> account instead of :post-blank. If footnote reference or similar object
> has more :post-blank spaces than replace it by string
Daniel Kraus writes:
> If I could freely choose if a :var declaration in one source block
> should create a global variable for all other blocks in this session,
> I would say making it only available in the defining source block
> is more natural (i.e. use let instead of def).
You can always
Tim Ruffing writes:
> * org-agenda.el (org-prepare-agenda): Don't reset
> `org-todo-keywords-for-agenda' when org-agenda-multi.
>
> Fixes a bug with TODO keywords that came to light in org-modern,
> see https://github.com/minad/org-modern/issues/26.
>
> This is very similar to
Rudolf Adamkovič writes:
> - e.g. "FILE" from Project.el
> - e.g. "*EGLOT (PROJECT/(MODE)) events*" from Eglot
> - e.g. "magit-diff(FILE1 -- FILE2): PROJECT" from Magit
>
> All "normal looking" (spacing-wise), unlike e.g. "*Org Src FILE[ MODE ]*".
>
>> Could you list other packages that use
"Farblos" writes:
> For this and similar use cases (run/do not run some major mode hook only in
> Org source environment), it would be helpful to have a documented dynamic
> variable (`org-in-babel-environment'?) set by `org-babel-do-in-edit-buffer'
> or the like that one could query as
We
Jean Louis writes:
> Where you Ihor responded with this message:
> https://lists.gnu.org/archive/html/emacs-orgmode/2023-02/msg00018.html
>
>> [2022-11-12 14:00 @UTC+2]
>> [2022-11-12 14:00 @UTC-2:30]
>
>> are also fine within the proposed format.
>
> I am not sure what did you intend to show,
Jean Louis writes:
> Discussion started from something like this:
>
> 2022-11-12 12:00+02 @UTC
>
> and that is different case, where Ihor was suggesting that: 2022-11-12
> 12:00 is UTC time, not local time, where by +02 is offset (I say not
> UTC offset) to be added or deducted on that time.
On 3/9/23 14:11, Ihor Radchenko wrote:
Zelphir Kaltstahl writes:
OK, to wrap up (ha!), I want to ask:
(q1) What is a rationale, if any, behind the let-wrapping?
It makes sense in ob-emacs-lisp to not litter global Emacs state.
In other ob-* lisp backends, I am not sure.
I am CCing Daniel,
On 3/9/23 14:10, Ihor Radchenko wrote:
Zelphir Kaltstahl writes:
START
#+name: python-imports
#+begin_src python :python /usr/bin/python3 :results output replace drawer :var
x=4
import math
y = math.sqrt(x)
# print(y)
#+end_src
#+name: python-usage
#+begin_src python :python
On 3/9/23 14:04, Ihor Radchenko wrote:
Zelphir Kaltstahl writes:
I am not sure (let ...) is a correct wrapper for noweb included source blocks.
What, if I write a (define ...) in my source block and want to use that source
block via noweb in another source block? Expected behavior I think
19 matches
Mail list logo
