Re: suggest using E-M-S 3-line notation from HAL/S for super/subscripting
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 next few days. The T&C when renewing the address goes to a "nothing" page in transition, so I let it go. I should resurface from sdf.org ) -- VL
Re: Automatic LaTeX preview toggling
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 long > time ago here: > http://slumpy.org/blog/2017-02-01-automatic-latex-preview-in-org-mode > > which is based on even older post originally written by John Kitchin: > > http://kitchingroup.cheme.cmu.edu/blog/2015/10/09/Automatic-latex-image-toggling-when-cursor-is-on-a-fragment/ > > unfortunately stopped working. I guess I missed it, at some point it seems > org--list-latex-overlays function was removed. > > Does anyone know if there's updated version of this thing somewhere? Or maybe > this was extracted into some plugin or something that can be installed from > MELPA maybe and I don't even know? -- 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
Re: Documentation: Side effects of org-entry-properties and others
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 it would mean > adding warnings practically everywhere). I think this is unrealistic. If you need to save match data, execute non-trivial code, and use the saved match data, I suggest to use `save-match-data'. Regards, -- Nicolas Goaziou
Item descriptions get surrounded by wrong curly braces in LaTeX export
Hi,
I noticed that in LaTeX export, descriptions in description lists are
surrounded by {} instead of [] in LaTeX export, making them not correctly
rendered.
For example, the following
- Description :: Item
- Description :: Item
gets exported as
\begin{description}
\item{Description} Item
\item{Description} Item
\end{description}
instead of
\begin{description}
\item[Description] Item
\item[Description] Item
\end{description}
and thus they are not correctly rendered in the PDF output.
I'm currently using Org mode version 9.3.6 (9.3.6-4-gdfa7a3-elpaplus @
c:/Users/joon/.emacs.d/elpa/org-plus-contrib-20200217/)
Re: Documentation: Side effects of org-entry-properties and others
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 using this that is wrapped in save-match-data). John --- 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 On Mon, Feb 17, 2020 at 6:20 PM D wrote: > 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 inconsistently or throw errors. I think it would be a good idea > to add a prominent warning to such interfacing functions, or document it > somewhere in the module. > > 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 it would mean > adding warnings practically everywhere). > > Regards, > > D. > >
Documentation: Side effects of org-entry-properties and others
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 inconsistently or throw errors. I think it would be a good idea to add a prominent warning to such interfacing functions, or document it somewhere in the module. 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 it would mean adding warnings practically everywhere). Regards, D.
Re: Org agenda -- checking for invisible tasks after filtering...
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-filter-apply`. But I can see what than would happen, the hook > would be called several times when more filter types are set. The added hook is not intrusive and useful, outside the needs related to your patch to org-super-agenda. Adding a hook to a function that is called many times is calling for problems, I don't want to go that way. > A other option would be the call the hook at the end of all the > org-agenda-filter* functions, perhaps. Not sure what you mean (patch welcome just to understand). But again I think we don't need more hooks. Maybe you can explore using post-command-hook in org-super-agenda-mode in a way that checks whether the last command was a filter command and then act from there? Just an idea, not sure it is correct. Best, -- Bastien
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
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 like to have enough information to reproduce the bug myself. Sometimes a formal MCE does the job, sometimes informal recollection does too. I'll keep your patch in mind for further investigation when I have some time. Thanks, -- Bastien
Re: [BUG] Infinite loop in org-agenda-show-new-time
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
Re: [PATCH] (Tiny) Tweak Python session null return value
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 this change to > 9.5, if at all. So instead of updating NEWS, I'd prefer to revert this > commit for now. Sorry for the noise! Looking forward to 9.4. Sure, I just reverted the commit. This discussion made me realize that the various Babel backends may have different approaches wrt evaluating blocks, returning output and results, interpreting empty output/result, etc. The mere notion of a "session" may differ from one language to another. I wish we can push for more consistency here--perhaps the first stop would be (1) to pick major backends and (2) document their behaviors. I'm sure this could help enhancing Org babel code too. Thanks, -- Bastien
Re: [PATCH] (Tiny) Tweak Python session null return value
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 the value, it is not > simply > > the last thing that gets evaluated. > > This is true for non-session blocks, which require explicitly calling > "return". However, session blocks aren't wrapped in functions and don't > use "return" (even before the most recent patches). The problem is that > variables created in a function have local scope, so session blocks > can't be wrapped in functions. > Fair point, I am not a python session user (I have used the ob-ipython for a long time, or stand-alone python blocks), and I had forgotten or not known of this. Indeed in a REPL, you get something closer to what you originally suggested. >>> a = 1 >>> if a: ... True ... else: ... False ... True I guess I would expect something like that if I was using a Python session in org-mode. It is like a REPL that is easier to edit. My earlier concern is mostly related to consistency of what an org Python block does compared to what you might do at a REPL or from a script. I also note that I almost never use :results value, and almost always prefer :results output. That reflects the kind of stuff we usually do here though, and may not be representative of others. > > Your example clarified to me at least why it would be tricky to figure > > it out, you can't rely on the last line, for example. > > Since the recent patches, we do extract the last line, using the Python > ast module, however this only works if the last line is a top-level > statement like "f()" or "1+1", not an assignment (like "x = 1+1") or an > indented block (like "if:...else:..."). > > > I don't know if there is some special Python variable that contains > > that. > > There actually is -- in most Python interpreters, the variable "_" > (underscore) refers to the last statement, unless it's been explicitly > assigned to. This is what was previously relied on. Unfortunately, using > "_" for a dummy variable is a common Python idiom (e.g. "for _ in > range(10)"), and if used would break all subsequent Python session > blocks. So we no longer rely on "_". > In the standard Python interpreter, we can also use "__builtins__._", > but this doesn't work in IPython. Furthermore, this only works for code explicitly entered in the shell, it won't work for code executed in > "exec()" or "eval()", which we now rely on, because it handles > indentation much more robustly. In particular, ob-python sessions have > had longstanding issues with multiline indented blocks, which are now > solved in the recent patches. >
Re: Org agenda -- checking for invisible tasks after filtering...
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, it would work for all org-agenda-filter* functions, if the hook would be called at the end of `org-agenda-filter-apply`. But I can see what than would happen, the hook would be called several times when more filter types are set. A other option would be the call the hook at the end of all the org-agenda-filter* functions, perhaps. -Christian
Re: [PATCH] (Tiny) Tweak Python session null return value
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. This is true for non-session blocks, which require explicitly calling "return". However, session blocks aren't wrapped in functions and don't use "return" (even before the most recent patches). The problem is that variables created in a function have local scope, so session blocks can't be wrapped in functions. > Your example clarified to me at least why it would be tricky to figure > it out, you can't rely on the last line, for example. Since the recent patches, we do extract the last line, using the Python ast module, however this only works if the last line is a top-level statement like "f()" or "1+1", not an assignment (like "x = 1+1") or an indented block (like "if:...else:..."). > I don't know if there is some special Python variable that contains > that. There actually is -- in most Python interpreters, the variable "_" (underscore) refers to the last statement, unless it's been explicitly assigned to. This is what was previously relied on. Unfortunately, using "_" for a dummy variable is a common Python idiom (e.g. "for _ in range(10)"), and if used would break all subsequent Python session blocks. So we no longer rely on "_". In the standard Python interpreter, we can also use "__builtins__._", but this doesn't work in IPython. Furthermore, this only works for code explicitly entered in the shell, it won't work for code executed in "exec()" or "eval()", which we now rely on, because it handles indentation much more robustly. In particular, ob-python sessions have had longstanding issues with multiline indented blocks, which are now solved in the recent patches.
Re: [PATCH] (Tiny) Tweak Python session null return value
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 why it would be tricky to figure it out, you can't rely on the last line, for example. I don't know if there is some special Python variable that contains that. It is also a little strange to me to put return specifically in like this: #+begin_src python :session :results value if some_condition: a = True else: a = False return a #+end_src or: #+BEGIN_SRC python :results value a = 1 return True if a else False #+END_SRC #+RESULTS: : True because it is not valid syntax in a script (try it with :results output), but this is how it has been for ob-python all along when what you want is the value returned. John --- 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 On Mon, Feb 17, 2020 at 2:06 PM Jack Kamm wrote: > 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 following sort of block: > > #+begin_src python :session :results value > if some_condition: > True > else: > False > #+end_src > > #+RESULTS: > : None > > Ideally, it would return True/False, but the current implementation > cannot grab that result unfortunately. (In its defense, it at least > doesn't crash like it did before). > > I was thinking not printing anything at all under "#+RESULTS" would be > less surprising than printing "None". But both are admittedly surprising > at first. > > I agree your preference of returning "None" is the more technically > consistent behavior though. > > I don't want to rush a decision now, I think I need to gather more user > feedback after the 9.4 release. I'll ask Bastien to revert that commit > and put this off to 9.5, rather than writing an updated NEWS entry like > he asked. > > Either way, we'll need to update Worg to clearly document what's going > on here. >
Re: [BUG] Infinite loop in org-agenda-show-new-time
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 from... 2013 :) > > Best, > > -- > Bastien >
Re: [PATCH] (Tiny) Tweak Python session null return value
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 all. So instead of updating NEWS, I'd prefer to revert this commit for now. Sorry for the noise! Looking forward to 9.4.
Re: [PATCH] (Tiny) Tweak Python session null return value
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 following sort of block: #+begin_src python :session :results value if some_condition: True else: False #+end_src #+RESULTS: : None Ideally, it would return True/False, but the current implementation cannot grab that result unfortunately. (In its defense, it at least doesn't crash like it did before). I was thinking not printing anything at all under "#+RESULTS" would be less surprising than printing "None". But both are admittedly surprising at first. I agree your preference of returning "None" is the more technically consistent behavior though. I don't want to rush a decision now, I think I need to gather more user feedback after the 9.4 release. I'll ask Bastien to revert that commit and put this off to 9.5, rather than writing an updated NEWS entry like he asked. Either way, we'll need to update Worg to clearly document what's going on here.
Re: ox-html: Bug or feature for export of title and meta information?
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 part is confusing. I think > > (org-element-interpret-data auth) > > is sufficient. I pushed a change in that direction. Thank you! The function org-element-interpret-data seems to return the empty string for nil. Is that by contract or accident? In the former case, maybe use (org-element-interpret-data (plist-get info :author)) instead of the let statement? What do you think about applying org-element-interpret-data (instead of org-export-data) when let-binding title, like the following? (org-html-encode-plain-text (org-element-interpret-data (plist-get info :title))) As far as I can tell, this would create valid (X)HTML. Best wishes Jens
Re: [PATCH] (Tiny) Tweak Python session null return value
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 and let the maintainers handle it. It > would be nice to include in 9.4, but not a big deal if I've missed the > window. Applied, thanks for the patch and the precaution not to commit it directly. > Now for an explanation of the patch: 9.4 changes Python session blocks > to fix several bugs and improve robustness overall [0]. However, there > is a cost to these fixes, which is that the session blocks can only > return a result when it is a top-level expression on the last line of > the block. If the last line is not a top-level expression, the block > would previously print "None". However, after some testing, I think this > is a little counter-intuitive, and it would be better if it returned a > blank (empty) result instead of "None". 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. Thanks, -- Bastien
Re: Bug: R src blocks fail to produce link to graphics file [9.3 org-plus-contrib-20200127]
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 taking care of this! Best, Jack
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
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
Re: [PATCH] (Tiny) Tweak Python session null return value
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 University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Mon, Feb 17, 2020 at 11:25 AM Jack Kamm wrote: > 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. It > would be nice to include in 9.4, but not a big deal if I've missed the > window. > > Now for an explanation of the patch: 9.4 changes Python session blocks > to fix several bugs and improve robustness overall [0]. However, there > is a cost to these fixes, which is that the session blocks can only > return a result when it is a top-level expression on the last line of > the block. If the last line is not a top-level expression, the block > would previously print "None". However, after some testing, I think this > is a little counter-intuitive, and it would be better if it returned a > blank (empty) result instead of "None". > > [0] https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00190.html > > Best, > Jack > > >
Re: Org agenda -- checking for invisible tasks after filtering...
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! Best, -- Bastien
[PATCH] (Tiny) Tweak Python session null return value
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. It would be nice to include in 9.4, but not a big deal if I've missed the window. Now for an explanation of the patch: 9.4 changes Python session blocks to fix several bugs and improve robustness overall [0]. However, there is a cost to these fixes, which is that the session blocks can only return a result when it is a top-level expression on the last line of the block. If the last line is not a top-level expression, the block would previously print "None". However, after some testing, I think this is a little counter-intuitive, and it would be better if it returned a blank (empty) result instead of "None". [0] https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00190.html Best, Jack >From 0b44c3f1c7454e7948cd34eb02995924046b6976 Mon Sep 17 00:00:00 2001 From: Jack Kamm Date: Mon, 17 Feb 2020 08:11:49 -0800 Subject: [PATCH] ob-python: Session returns empty string if no return value * lisp/ob-python.el (org-babel-python--eval-ast): Change sessions to return an empty string, instead of None, if there is no return value. --- etc/ORG-NEWS | 12 +++- lisp/ob-python.el | 2 +- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index b6ee443e4..1b5429870 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -12,13 +12,15 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org. * Version 9.4 (not yet released) ** Incompatible changes -*** Python session return values must be top-level expression statements +*** Change how Python sessions handle return values Python blocks with ~:session :results value~ header arguments now only -return a value if the last line is a top-level expression statement, -otherwise the result is None. Also, None will now show up under -"#+RESULTS:", as it already did with ~:results value~ for non-session -blocks. +return a value if the last line is a top-level expression +statement. If the last line is not a top-level expression statement, +the block will return a blank (empty) result. + +Also, a return value of ~None~ will now show up under "#+RESULTS:", as +it already did for non-session blocks. *** In HTML export, change on how outline-container-* is set diff --git a/lisp/ob-python.el b/lisp/ob-python.el index de718b04b..b9e36dba0 100644 --- a/lisp/ob-python.el +++ b/lisp/ob-python.el @@ -260,7 +260,7 @@ (defconst org-babel-python--eval-ast "\ __org_babel_python_final.value), '', 'eval')) else: exec(compile(__org_babel_python_ast, '', 'exec')) -__org_babel_python_final = None +__org_babel_python_final = '' except Exception: from traceback import format_exc __org_babel_python_final = format_exc() -- 2.25.0
Re: suggest using E-M-S 3-line notation from HAL/S for super/subscripting
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 (probably?) not what you are looking for but if you want something
that meets the output requirements for LaTeX export (i.e. to PDF), you
can use the =mhchem= package [1] and typing
\(\ce{^{21}Ne}\) and \(\ce{^{3}He}\)
will generate what you want.
No special editing unfortunately.
HTH,
eric
Footnotes:
[1] https://www.ctan.org/pkg/mhchem?lang=en
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-316-g5dd772
Re: Org agenda -- checking for invisible tasks after filtering...
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 new hook `org-agenda-filter(-(apply|after))?-hook`? Calling org-agenda-finalize at the end of org-agenda-filter-apply wont work, because org-agenda-finalize calls org-agenda-filter-apply, and hence, would result in an infinite recursion. org-agenda-filter-remove-all and org-agenda-remove-filter do call org-agenda-finalize, so this way works. Thanks Bastien Bastien writes: > Hi Christian, > > you might want to have a look at org-agenda-finalize-hook, though I'm > not sure it can help, I'm not familiar with org-super-agenda enough. > > HTH,
bug#38592: 27.0.50; org mode insinuates itself into calendar
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 added another fix (in Org's maint branch, the one that will be released soon and sync with Emacs): requiring 'org-agenda whenever both org-compat.el and calendar are loaded. Thanks for reporting this, I'll close the bug when upstream Org is merged into Emacs and you can confirm the fix. Best, -- Bastien
Re: suggest using E-M-S 3-line notation from HAL/S for super/subscripting
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 but
> (1) I'm not sure the editing experience would be so smooth and (2) the
> implementation would be quite complex -- enough, at least, for me to
> not undertake anything about it.
The nearest thing to it I can think of is the way
org-insert-structure-template works or org-insert-link works. That,
would apply to a sequence of prefix_sub^super/symbol/postfix_sub^super,
which, would expand to the three E-M-S notation on editing as in
HAL/S [1], and, pretty print as a single line for reading.
> You might want to share this idea with emacs-orgmode@gnu.org, perhaps
> someone can hack something useful to you and others interested.
I will cc this reply to that list.
Have a look at ^{3}He and ^{21}Ne in the following linked article.
#+name: see-3He-21Ne-as-prefix-superscript [2]
#+begin_example
We determined that at least 12 of the analyzed grains were parts of
aggregates in the interstellar medium: The large difference in nuclear
recoil loss of cosmic ray spallation products 3He and 21Ne enabled us
to estimate that the irradiated objects in the interstellar medium
were up to 30 times larger than the analyzed grains.
#+end_example
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.
PS. Please reply to the list if
there is interest as I won't be
able to reply directly.
Footnotes:
[1] https://www.hq.nasa.gov/office/pao/History/computers/contents.html
[2] https://www.pnas.org/content/117/4/1884
-- VL
Re: [rfc] Make column view less rigid for rescale?
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 > size of the header-line. Ahh, right, good catch. > I've pushed this change in master, please test it and report. LGTM! Thanks!
Bug: Macro incorrectly expanded when exporting to beamer [9.4 (nil @ /home/yangsheng/.emacs.d_doom_27/.local/straight/build/org-mode/)]
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 correct export shold be:
'''
\begin{itemize}
\item
\item a
\item
\item a
\end{itemize}
'''
This behavior appears on both Emacs 26.3 and Emacs 27 at 556cc727e5,
with org-mode from vanilla Emacs, and org-contrib at 2096c9c76. This
problem does not exist when exporting to LaTeX.
In case you need, the whole output file is:
'''
% Created 2020-02-17 一 06:13
% Intended LaTeX compiler: pdflatex
\documentclass[presentation]{beamer}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\usetheme{default}
\author{Sheng Yang}
\date{\today}
\title{}
\hypersetup{
pdfauthor={Sheng Yang},
pdftitle={},
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 27.0.60 (Org mode 9.4)},
pdflang={English}}
\begin{document}
\begin{frame}{Outline}
\tableofcontents
\end{frame}
\begin{frame}[label={sec:orgb5f5f6a}]{test}
\begin{itemize}
\item
\item a
\itemmacro
\item a
\end{itemize}
\end{frame}
\end{document}
'''
Emacs : GNU Emacs 27.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.13)
of 2020-02-17
Package: Org mode version 9.4 (nil @
/home/yangsheng/.emacs.d_doom_27/.local/straight/build/org-mode/)
current state:
==
(setq
org-footnote-auto-label 'plain
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-fontify-whole-heading-line t
org-columns-default-format "%50ITEM(Task) %10CLOCKSUM %16TIMESTAMP_IA"
org-link-shell-confirm-function 'yes-or-no-p
org-mode-local-vars-hook '(eldoc-mode)
org-babel-after-execute-hook '(org-redisplay-inline-images)
org-insert-heading-respect-content t
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-noter-insert-note-no-questions t
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-follow-link-hook '(+org-delayed-recenter-h
+nav-flash-delayed-blink-cursor-h)
org-refile-targets '((nil :maxlevel . 3) (org-agenda-files :maxlevel . 3))
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-highlight-sparse-tree-matches nil
org-noter-auto-save-last-location t
org-enforce-todo-dependencies t
org-src-tab-acts-natively t
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-special-ctrl-a/e t
org-notmuch-open-function 'org-notmuch-follow-link
org-agenda-files '("~/Documents/org/Research.org" "~/Documents/org/papers.org"
"~/Documents/org/Tasks.org"
"~/Documents/org/Birthdays.org" "~/Documents/org/gcal.org"
"~/Documents/org/Schedule.org")
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-reveal-start-hook '(org-decrypt-entry)
org-modules '(ol-bibtex)
org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent)
org-mode-hook '((closure (t) (&rest _) (add-hook 'before-save-hook
'org-encrypt-entries nil t))
er/add-org-mode-expansions yang/pangu-spacing-mode-on
doom--setq-pangu-spacing-real-insert-separtor-for-org-mode-h
LaTeX-math-mode org-tempo-setup
yang/org-mode-setup #[0 "\301\211.\207"
[imenu-create-index-function org-imenu-get-tree] 2]
#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all
append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
doom-disable-show-paren-mode-h
doom-disable-show-trailing-whitespace-h
+org-enable-auto-reformat-tables-h
+org-enable-auto-update-cookies-h
+org-unfold-to-2nd-level-or-point-h evil-org-mode
org-bullets-mode toc-org-enable
+evil-embrace-latex-mode-hook-h embrace-org-mode-hook
org-eldoc-load org-journal-update-auto-mode-alist)
org-clock-persist 'history
org-export-with-smart-quotes t
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-outline-path-complete-in-steps nil
org-archive-hook '(org-attach-archive-delete-maybe)
org-agenda-finalize-hook '(+org-exclude-agenda-buffers-from-workspace-h)
org-startup-indented t
org-clock-history-length 23
org-journal-mode-hook '((closure
(org-journal-search-mode-abbrev-table
org-journal-search-mode-syntax-table
view-exit-action org-journal-mode-abbrev-table
org-journal-mode-syntax-table t)
nil (add-hook org-journal-en
bug#38592: 27.0.50; org mode insinuates itself into calendar
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/org/org-compat.el index 4446a169d7..ea66bb82be 100644 --- a/lisp/org/org-compat.el +++ b/lisp/org/org-compat.el @@ -1043,7 +1043,7 @@ org--setup-calendar-bindings ((guard (not (lookup-key calendar-mode-map "c"))) (local-set-key "c" #'org-calendar-goto-agenda)) (_ nil)) - (unless (eq org-agenda-diary-file 'diary-file) + (unless (and (boundp 'org-agenda-diary-file) (eq org-agenda-diary-file 'diary-file)) (local-set-key org-calendar-insert-diary-entry-key #'org-agenda-diary-entry))) I suspect other assumptions are made that `ob` cannot be required without `org`.
Re: [rfc] Make column view less rigid for rescale?
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 size of the header-line. I've pushed this change in master, please test it and report. Thanks for this suggestion! -- Bastien
[rfc] Make column view less rigid for rescale?
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'.) What do you think? Ciao!
Re: attachment: link type export to HTML invalid attach dir
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 probably a good time to advertize changes that may break existing ol-* libraries that we are not aware of -- provided we clearly explain what needs to be changed, of course. > I'll do that instead. Thanks, -- Bastien
Re: attachment: link type export to HTML invalid attach dir
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 with the previous one, since the signature changed. So, we have two options: either we write a workaround, as is done for :export (i.e., `condition-case' with `wrong-number-of-arguments'), or we add new keywords so old code still works during transition. 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'll do that instead. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Nicolas Goaziou writes: >> FWIW, I'm for delaying the removal for 9.5, not 9.4. > > Sure, I added it back. Thanks! -- Bastien
Re: ox-html: Bug or feature for export of title and meta information?
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 information. `org-element-interpret-data' means: "down with HTML, go back to Org syntax". IOW, it mean the author is supplied as-is. > 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 part is confusing. I think (org-element-interpret-data auth) is sufficient. I pushed a change in that direction. Regards, -- Nicolas Goaziou
Re: attachment: link type export to HTML invalid attach dir
Hello, Bastien writes: > FWIW, I'm for delaying the removal for 9.5, not 9.4. Sure, I added it back. Regards, -- Nicolas Goaziou
How to make org-babel expand <> but _not_ evaluate the code fed into another block?
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" :results output :stdin for-input (eval (read)) #+end_src At the moment this doesn't work, because babel _evaluates_ for-input before feeding it into the next block. It is also not possible to make the "for-input" block a +begin_quote block, because then <> syntax doesn't get expanded. At the moment I am getting around it the following way: #+name: for-expansion #+begin_src scheme (display "hello world\n") #+end_src #+name: for-input #+begin_src shell cat <> EOF #+end_src #+name: block-in-question #+begin_src shell :stdin for-input (eval (read)) #+end_src This is not very good for two reasons or which the first one is not super importand, but the second is: 1)I am losing syntax highlighting in the for-input block 2)I lose the ability to use the EOF letter combination in the scheme code, which is quite bad, since scheme doesn't have almost any forbidded characters which I could use to demarcate scheme code. Is there some way to tell babel to _not_ evaluate a block, but rather feed it in as is? Or, maybe, instead, allow <> references inside the +begin_example blocks? (I tried substituting begin_quote with begin_example, but they both seem to be not expanding <>. Any recommendations? Lockywolf -- Yours sincerely, Vladimir Nikishkin
