Hello, everyone!
What I want to do is roughly the following:
#+name: for-expansion
#+begin_src scheme
(display "hello world\n")
#+end_quote
#+name: for-input
#+begin_src scheme
(import (srfi 27))
<>
#+end_src
#+name: block-in-question
#+begin_src shell :shebang "#! /usr/bin/chibi-scheme" :resul
Hello,
Bastien writes:
> FWIW, I'm for delaying the removal for 9.5, not 9.4.
Sure, I added it back.
Regards,
--
Nicolas Goaziou
Hello,
Jens Lechtenboerger writes:
> Based on the treatment of meta elements for author and description
> in that function, alternatives might use org-element-interpret-data
> (author) or not (description). I do not understand the role of
> org-element-interpret-data to generate author informat
Nicolas Goaziou writes:
>> FWIW, I'm for delaying the removal for 9.5, not 9.4.
>
> Sure, I added it back.
Thanks!
--
Bastien
Hello,
Bastien writes:
> I'm not sure why the distinction between :open and :follow is needed
> in the context of the discussion for exporting attachments: is it
> because attachment need to be "open", not just followed?
The motivation is that the new behaviour for `:follow' is not compatible
w
Hi Nicolas,
Nicolas Goaziou writes:
> Thinking about it, we can stick to a single solution, e.g., the
> `condition-case' workaround. Therefore we do not need to introduce a new
> keyword. However, all "ol-" libraries need to be updated.
I think the release of 9.4 is an important one, so it's pr
Dear all,
Up to now the text-scale of org columns sticks to one size disrespecting
text rescaling. (E.g. via C-x C-+ .)
I think this rigidity is unnecessary and I'd like to see org columns
follow text rescaling.
AFAICS the change is easy. (Just set `font' to nil in
`org-columns--display-here'.
Hi Marco,
Marco Wahl writes:
> I think this rigidity is unnecessary and I'd like to see org columns
> follow text rescaling.
Agreed.
> AFAICS the change is easy. (Just set `font' to nil in
> `org-columns--display-here'.)
The change is a bit more complex, because you also need to adjust the
s
To reproduce:
emacs -Q -f package-initialize --eval "(require 'ob)" --eval "(and (cl-assert
(featurep 'ob)) (cl-assert (not (featurep 'org" --eval "(call-interactively
'calendar)"
The emacs needs to be at least 165f738382.
How about, minimally:
diff --git a/lisp/org/org-compat.el b/lisp/o
When exporting the following file to beamer,
'''
#+MACRO: SPAN @@html:$2@@
* test
- @@html:test@@
- a @@html:test@@
- {{{SPAN(emph,macro)}}}
- a {{{SPAN(emph,macro)}}}
'''
the output tex file (itemize part) is:
'''
\begin{itemize}
\item
\item a
\itemmacro
\item a
\end{itemize}
'''
While the
Hi Bastien,
>> I think this rigidity is unnecessary and I'd like to see org columns
>> follow text rescaling.
>
> Agreed.
Fine!
>> AFAICS the change is easy. (Just set `font' to nil in
>> `org-columns--display-here'.)
>
> The change is a bit more complex, because you also need to adjust the
> s
Bastien writes:
> VanL writes:
>
>> I was picturing a way to edit the
>> super/subscripts in expanded immediate mode using the EMS notation and
>> then collapsing that to single line pretty printing. Hope that makes sense.
>
> well, it kinda makes more sense now that I can better visualize it b
Hi Sam,
Sam Steingold writes:
> emacs -Q -f package-initialize --eval "(require 'ob)" --eval "(and
> (cl-assert (featurep 'ob)) (cl-assert (not (featurep 'org" --eval
> "(call-interactively 'calendar)"
OK, I understand now, thanks for the reproducible recipe.
> How about, minimally:
I add
Hi Bastien,
thank you! That would reduce it to one advice.
However, I would still need to advice the function org-agenda-filter-apply since
it doesn't call `org-agenda-finalize`. Would it make sense to call the hook
org-agenda-finalize-hook at the and of org-agenda-filter-apply or perhaps add a
n
On Tuesday, 18 Feb 2020 at 00:43, VanL wrote:
> Question for the list. Can the HAL/S notation be used for editing a
> symbol, in expanded form, with prefix/postfix sub/superscript? The
> collapsed form is a single line pretty printing tiny sub/superscript
> before and after the symbol.
Maybe (pr
Hi,
Below is a very small patch to Python session blocks, to make them
return a blank result (empty string) instead of None when there is no
return value.
Normally I would push this myself, but since we are so close to 9.4, I
thought it prudent to mail a patch and let the maintainers handle it. I
Hi Christian,
Christian Schwarzgruber writes:
> or perhaps add a new hook `org-agenda-filter(-(apply|after))?-hook`?
Yes, this one makes sense, I've added `org-agenda-filter-hook' for
functions that you need to run right after `org-agenda-filter' has
been called.
Thanks for the suggestion!
Be
I think None is correct. If you don't specify a return value in Python,
then a function returns None. I would expect that to happen in a Python
block too.
John
---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon Univers
Hi Gustavo,
Gustavo Barros writes:
> Otherwise just:
>
>> set this aside for now.
I'll set this aside for now, but I've noted to revisit the issue later
on to see if I can find a related bug---all information in this thread
will be useful to revisit this, thanks again!
--
Bastien
Hi Tyler,
>> The documentation for ob-R is now incorrect:
>>
>> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html
>
> Yes, also that page could use some other updates, e.g. there are some
> dead links in there.
Just saw that you updated the docs a few days ago. Thanks for takin
Hi Jack,
Jack Kamm writes:
> Below is a very small patch to Python session blocks, to make them
> return a blank result (empty string) instead of None when there is no
> return value.
>
> Normally I would push this myself, but since we are so close to 9.4, I
> thought it prudent to mail a patch
Hi there!
On 2020-02-17, at 10:47, Nicolas Goaziou wrote:
> Jens Lechtenboerger writes:
>> Which “non exportable objects” can be skipped by that function (as
>> mentioned in a comment in org-html--build-meta-info)? Should they also
>> be skipped for description or title?
>
> That non-exportable
Hi John,
John Kitchin writes:
> I think None is correct. If you don't specify a return value in Python,
> then a function returns None. I would expect that to happen in a Python
> block too.
Hmm, OK, thanks for your intuition, it's useful feedback.
Working this out loud, I was considering the
Hi Bastien,
> I've seen you update the NEWS entry, which is good: is there a way to
> present the enhancements in the "* New features" section? If you feel
> like it, please advertize the enhancements there too.
Given John's feedback, I now think it's better to put off this change to
9.5, if at
Thanks Bastien! I've tested this out and confirmed it works, and didn't
notice any side effects.
On Fri, Feb 14, 2020 at 6:02 AM Bastien wrote:
> Hi Andrew,
>
> thanks a lot for the minimal recipe! Very helpful.
> I confirm the bug and I have now (finally) fixed it.
>
> We can close this bug f
I can see why you would want to see True/False there, but to get the value,
you need to specifically return what you want because AFAIK the body is
wrapped in a function that is evaluated to get the value, it is not simply
the last thing that gets evaluated. Your example clarified to me at least
wh
Hi John,
John Kitchin writes:
> I can see why you would want to see True/False there, but to get the value,
> you need to specifically return what you want because AFAIK the body is
> wrapped in a function that is evaluated to get the value, it is not simply
> the last thing that gets evaluated.
Hi Bestian,
Bastien writes:
> Yes, this one makes sense, I've added `org-agenda-filter-hook' for
> functions that you need to run right after `org-agenda-filter' has
> been called.
thanks for that change. But unfortunate this one doesn't work for the
org-agenda-filter-by-* functions. However, i
On Mon, Feb 17, 2020 at 3:46 PM Jack Kamm wrote:
> Hi John,
>
> John Kitchin writes:
>
> > I can see why you would want to see True/False there, but to get the
> value,
> > you need to specifically return what you want because AFAIK the body is
> > wrapped in a function that is evaluated to get
Hi Andrew,
Andrew Hyatt writes:
> Thanks Bastien! I've tested this out and confirmed it works, and
> didn't notice any side effects.
Great, thanks for testing and confirming!
--
Bastien
Hi Jack,
Jack Kamm writes:
>> I've seen you update the NEWS entry, which is good: is there a way to
>> present the enhancements in the "* New features" section? If you feel
>> like it, please advertize the enhancements there too.
>
> Given John's feedback, I now think it's better to put off thi
Hi Samuel,
Samuel Wales writes:
> then you asked for more details so i tried to supply what i could.
>
> if that is not useful, apologies for the noise.
no need to apologize! Information is always useful. We may have been
miscommunicating: in general, when I ask for details it means that I'd
Hi Christian,
thanks for testing.
Christian Schwarzgruber writes:
> thanks for that change. But unfortunate this one doesn't work for the
> org-agenda-filter-by-* functions. However, it would work for all
> org-agenda-filter* functions, if the hook would be called at the end of
> `org-agenda-fi
Hi,
it seems a few functions meant to expose org internals to programmers
seem to cause undocumented side effects. A particular example being
org-entry-properties. When called, it changes the match-data. This can
cause issues in cases where leaking match-data can cause font-lock to
behave incon
I guess org-element-context and (org-element-at-point) also do this too (or
at least once did), because I have code that wraps them in save-match data
with notes to my self that match-data changes.
There are other things that unexpectedly do this, like split-string I think
(again based on code usi
/elpa/org-plus-contrib-20200217/)
Hello,
D writes:
> The same is true for org-element-lineage, but I am not so sure whether
> it is intended for hacking purposes as much as org-entry-properties.
> Sadly, I have no overview over the scope of this issue, so I do not know
> whether my suggestion is unrealistic (for example, because
The version I have at
https://github.com/jkitchin/scimax/blob/master/scimax-org-latex.el#L398
still works for me.
I don't use it a lot, but I just tried it now on a small example and it
seemed ok.
Ag Ibragimov writes:
> I just recently discovered that this excellent code snippet that I found lo
Thanks Eric.
I wasn't looking for anything in particular. Seeing the E-M-S 3-line
notation reminded me what a pain those invisible delimiters for
raising/lowering indexing scripts can be. Which was what made me reach
out to bzg.
(I won't be able to reply from this address as it expires in the
39 matches
Mail list logo
