Re: [O] interaction between org-latex-custom-lang-environments and name when exporting to latex
Hello,
I was wondering if someone had been able to reproduce this, and if so
should I file it as a bug?
Thanks,
Alan
On 2015-11-16 13:59, Alan Schmitt writes:
> Hello,
>
> I want to export some code for a custom language environment (to be able
> to use minted's global customization), and I find there is a strange
> interaction with adding a name to the block. Here is an ECM.
>
> Init file:
> (defvar emacsd-dir "~/.emacs.d/")
> (add-to-list 'load-path (concat emacsd-dir "org/emacs/site-lisp/org"))
> (require 'org)
>
> (require 'ox-latex)
>
> (setq org-latex-listings 'minted)
>
> (setq org-latex-custom-lang-environments
> '((emacs-lisp "common-lisp-code")))
>
> Org file:
> #+name: test
> #+BEGIN_SRC emacs-lisp
> (message "hello")
> #+END_SRC
>
> Exported latex (only for the source block):
> \begin{common-lisp-code}
> (message "hello")
> \label{orgsrcblock1}
>
> \end{common-lisp-code}
>
> The problem is the “\label” in the middle of the source block, which
> plays badly with minted.
>
> Is this a known bug?
>
> Thanks,
>
> Alan
--
OpenPGP Key ID : 040D0A3B4ED2E5C7
Athmospheric CO₂ (Updated November 9, 2015, Mauna Loa Obs.): 399.06 ppm
signature.asc
Description: PGP signature
Re: [O] Using orgstruct-mode (or just org-cycle) in emacs-lisp-mode
Hi Jonas, Jonas Bernoulli writes: > Nicolas Goaziou writes: > >> Jonas Bernoulli writes: >> >>> Nicolas Goaziou writes: >>> Jonas Bernoulli writes: > Thanks. But could you please change it to > > (if (or outline-minor-mode orgstruct-mode) > (call-interactively #'show-children) > ...) You could set `orgstruct-mode' to a non-nil value whenever `outline-minor-mode' is enabled. >>> >>> I could (instead I am currently just maintaining a local patch), >>> but what is the reasoning for not just doing what I suggested? >> >> There is no reason for Org's core to know about `outline-minor-mode', or >> any other minor mode in the wild. > > I wouldn't group `outline-minor-mode' among "any other minor mode > in the wild", after all it was Outline which gave birth to Org and > `outline-minor-mode' is part of `outline.el'. Didn't Carsten write > `outline-magic.el' (containing `outline-cycle') before moving on to > greater things? Unfortunately though `outline-magic.el' does not appear > to have aged so well (at least that's how I remember it from when I last > checked). orgstruct-mode is a mess and we plan to address it. When someone finds the time to do so. Indeed, there was a thread about the issue of org-show-children some time ago. Cheers, Rasmus -- Dung makes an excellent fertilizer
Re: [O] Using orgstruct-mode (or just org-cycle) in emacs-lisp-mode
Nicolas Goaziou writes: > Jonas Bernoulli writes: > >> Nicolas Goaziou writes: >> >>> Jonas Bernoulli writes: >>> Thanks. But could you please change it to (if (or outline-minor-mode orgstruct-mode) (call-interactively #'show-children) ...) >>> >>> You could set `orgstruct-mode' to a non-nil value whenever >>> `outline-minor-mode' is enabled. >> >> I could (instead I am currently just maintaining a local patch), >> but what is the reasoning for not just doing what I suggested? > > There is no reason for Org's core to know about `outline-minor-mode', or > any other minor mode in the wild. I wouldn't group `outline-minor-mode' among "any other minor mode in the wild", after all it was Outline which gave birth to Org and `outline-minor-mode' is part of `outline.el'. Didn't Carsten write `outline-magic.el' (containing `outline-cycle') before moving on to greater things? Unfortunately though `outline-magic.el' does not appear to have aged so well (at least that's how I remember it from when I last checked). Anyway I think `outline-minor-mode' deserves some special attention, but of course that's the call of the maintainers. > IMO, using a hook is much more simple than maintaining a local patch. Not for me. I install all packages using Git submodules, which is very convenient because I contribute to most packages I use, at least in some minor way like addressing compilation warnings. If a patch isn't accepted upstream, then the only additional work required is to call `git config branch.master.rebase true' once and then occasionally `git push tarsius master'.
[O] Place skeleton code in source block template?
I have customized the org-structure-template-alist to include a special version of an emacs-lisp source code block (attached to
Re: [O] bug#21818: 24.5; org-set-tags-to indentation problems when called programmatically
Nicolas Goaziou writes: > I don't consider it to be a bug. > > `org-element-interpret-data' produces a string, which is expected to be > syntactically correct, but doesn't guarantee aesthetics. In particular, > `org-element-headline-interpreter' tries to align tags as accurately as > possible, but, in this case, fails to succeed as it would require to > introduce fontification in the process. This is out of the scope of the > function. Hmmm, that doesn't really make sense to me. Shouldn't the flow of 1. Edit a document with org-mode 2. (org-element-interpret-data (org-element-parse-buffer)) be as close to the original as possible? Seems like the fontification aspect is just an implementation detail. In any case, I looked more into the code and would be happy to submit a patch to change it if it makes sense to you. - Emanuel
[O] Org-babel shell evaluate with session does not return results
Hi, I am trying to run a shell commands from org-mode with using sessions. I would like to use the session property, so I could continue with the previous history. But when I execute the following, #+BEGIN_SRC shell :session test echo foo #+END_SRC nothing happens with emacs is unresponsive and the echo area says: executing Shell code block... I am able to quit with C-g and there is buffer with name test created which has bash prompt. I was also able to run the shell commands without session and it returns the output, like below #+BEGIN_SRC shell echo foo #+END_SRC #+RESULTS: : foo Any reason why org babel execute for shell with session does not terminate ? Thank you very much in advance for any response, -GP
Re: [O] long running processes
Unfortunately, changing from the current synchronous to asynchronous processing probably requires changes to the API that would require changes to every existing language mode. A better way forward may simply be to implement a new block type and then let people gradually convert their language bindings to that. I'll have a look at it for Python. Tom On Thu, Nov 19, 2015 at 5:38 AM, John Kitchin wrote: > Your suggestions sounds possible to me. If you are up for it, I suggest > trying to implement it, and offering it as a patch. > > Tom writes: > > > On Wed, Nov 18, 2015 at 2:55 PM, John Kitchin > > wrote: > > > >> I am pretty sure this is not directly possible right now. > >> > >> Some approaches that resemble it could be: > >> 1. write a src block that will be tangled to a script. > >> 2. tangle the block > >> 3. Run the script in a shell src block with an & so it runs > >> non-blocking. > >> > >> or, use an elisp block like: > >> > >> (org-babel-tangle) > >> (async-shell-command "your script" some-output-buffer) > >> > >> I don't know a way to get continuous updated output in an org-buffer > >> though. > >> > > > > Thanks for the response. I didn't necessarily expect continuous output > into > > the org-buffer itself to work, but I don't see why the Python subprocess > > can't display output as it occurs. After all, it uses comint, and comint > > certainly has facilities for collecting output incrementally while still > > displaying it (cf comint-output-filter-functions). > > > > It looks to me like the problem is that org-babel-comint-with-output > uses a > > "while" loop to collect process output (ob-comint.el:92). At least, it > > could insert the output into the subprocess buffer and make redisplay > > happen. > > > > But I'm not sure why the code is written that way anyway. Long running > > "while" loops in Emacs code don't seem like a good idea to begin with. > > Wouldn't the more natural way for this code to be written in Emacs be the > > following? > > > > - an output filter gets added to the subprocess that collects output > > - the code is sent to the subprocess for execution > > - the command returns > > - the output filter inserts any data it gets into the subprocess buffer, > > into its "results" data structure, perhaps even into the org-buffer > > - when the output filter gets the eoe-indicator, it removes itself from > the > > output filter list and sends a notification that execution has completed > > > > If the user schedules a second block for execution, the simplest thing to > > do is return an error if there is already a block executing for that > > subprocess; alternatively, it could be queued somewhere. > > > > Thanks, > > Tom > > -- > 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 >
[O] Asynchronous mobileorg push/pull
Hello, I've started using MobileOrg to do capturing and simple Org tasks on my phone. Although it seems to work well enough so far, running org-mobile-push and org-mobile-pull synchronously locks up Emacs for an unacceptably long period of time. Does anyone have any asynchronous solutions for MobileOrg syncing? signature.asc Description: PGP signature
Re: [O] Exporting a subtree
Peter Davis writes: > Thanks very much, John and Nick. I didn't realize it was so easy to > reload with uncompiled lisp. I tried this, but the export worked with > the uncompiled code! No error, so no debug backtrace. > Oh, lovely! Everybody loves heisenbugs... You might try just recompiling your org mode then and see if it goes away. -- Nick
Re: [O] Exporting a subtree
Peter Davis writes:
> Thanks for the tips. I was hoping this would be simple to answer. I
> don't really have hours of time to keep stopping and re-starting emacs
> with uncompiled org-mode files, with minimal startup, etc. If I get a
> chance, I'll post the details. Meanwhile, I'll live without this
> feature.
>
I understand the sentiment, but you will find out eventuallly that it
takes only a few minutes to do all that: the descriptions seem to make
it long and difficult but once you get down to brass tacks, it turns out
to be pretty simple ("it is easier done than said"). In particular, you
don't need to stop/start your current emacs: you can start a new one as
John described specially for this problem, do what you need to do to
reproduce the problem and kill it afterwards. It does take a little time
to come up with a minimal init file that sets up things, but there have
been examples posted on the list that you can adapt to your situation -
once you have one, just keep it around and modify it slightly for each
new situation.
In any case, the trouble here is that it does not seem to be
reproducible: at first sight at least, it seems to be related to your
particular setup, so nobody else can debug it.
And one more thing, now that I remember it: always provide versions
of your OS, emacs and org-mode. It is possible that the particular
version you are using exhibits the problem but earlier or later ones
don't. Of cource, if you update regularly, that is less of a concern,
but if you provide the version, then other people can try it with
that particular version (thanks to git, it's easy).
--
Nick
Re: [O] Exporting a subtree
Nick Dokos writes:
> John Hendy writes:
>
>> On Wed, Nov 18, 2015 at 2:29 PM, Peter Davis wrote:
>>>
>>> For the first time, I'm trying to export just a single subtree of my
>>> overall document, by typing
>>>
>>> C-c C-e C-s H O
>>>
>>> However, I get this error:
>>>
>>> apply: Wrong type argument: listp, #("Details, November 2015" 0 22 (:parent
>>> (#0)))
>>>
>>> The portion in quotes is the overall title of my document.
>>>
>>> Should this work? Is there something I need to do differently?
>>
>
> You should also provide a backtrace (with uncompiled code) if possible.
> See
>
> (info "(org) Feedback")
>
> and, in particular, the subsection "How to create a useful backtrace".
Thanks very much, John and Nick. I didn't realize it was so easy to reload with
uncompiled lisp. I tried this, but the export worked
with the uncompiled code! No error, so no debug backtrace.
Thanks,
-pd
Re: [O] long running processes
Your suggestions sounds possible to me. If you are up for it, I suggest trying to implement it, and offering it as a patch. Tom writes: > On Wed, Nov 18, 2015 at 2:55 PM, John Kitchin > wrote: > >> I am pretty sure this is not directly possible right now. >> >> Some approaches that resemble it could be: >> 1. write a src block that will be tangled to a script. >> 2. tangle the block >> 3. Run the script in a shell src block with an & so it runs >> non-blocking. >> >> or, use an elisp block like: >> >> (org-babel-tangle) >> (async-shell-command "your script" some-output-buffer) >> >> I don't know a way to get continuous updated output in an org-buffer >> though. >> > > Thanks for the response. I didn't necessarily expect continuous output into > the org-buffer itself to work, but I don't see why the Python subprocess > can't display output as it occurs. After all, it uses comint, and comint > certainly has facilities for collecting output incrementally while still > displaying it (cf comint-output-filter-functions). > > It looks to me like the problem is that org-babel-comint-with-output uses a > "while" loop to collect process output (ob-comint.el:92). At least, it > could insert the output into the subprocess buffer and make redisplay > happen. > > But I'm not sure why the code is written that way anyway. Long running > "while" loops in Emacs code don't seem like a good idea to begin with. > Wouldn't the more natural way for this code to be written in Emacs be the > following? > > - an output filter gets added to the subprocess that collects output > - the code is sent to the subprocess for execution > - the command returns > - the output filter inserts any data it gets into the subprocess buffer, > into its "results" data structure, perhaps even into the org-buffer > - when the output filter gets the eoe-indicator, it removes itself from the > output filter list and sends a notification that execution has completed > > If the user schedules a second block for execution, the simplest thing to > do is return an error if there is already a block executing for that > subprocess; alternatively, it could be queued somewhere. > > Thanks, > Tom -- 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: [O] Exporting a subtree
Nick Dokos writes:
> John Hendy writes:
>
>> On Wed, Nov 18, 2015 at 2:29 PM, Peter Davis wrote:
>>>
>>> For the first time, I'm trying to export just a single subtree of my
>>> overall document, by typing
>>>
>>> C-c C-e C-s H O
>>>
>>> However, I get this error:
>>>
>>> apply: Wrong type argument: listp, #("Details, November 2015" 0 22 (:parent
>>> (#0)))
>>>
>>> The portion in quotes is the overall title of my document.
>>>
>>> Should this work? Is there something I need to do differently?
>
> You should also provide a backtrace (with uncompiled code) if possible.
> See
>
> (info "(org) Feedback")
>
> and, in particular, the subsection "How to create a useful backtrace".
Thanks for the tips. I was hoping this would be simple to answer. I don't
really have hours of time to keep stopping and re-starting
emacs with uncompiled org-mode files, with minimal startup, etc. If I get a
chance, I'll post the details. Meanwhile, I'll live
without this feature.
Thank you!
-pd
Re: [O] Using orgstruct-mode (or just org-cycle) in emacs-lisp-mode
Hello, Jonas Bernoulli writes: > Nicolas Goaziou writes: > >> Jonas Bernoulli writes: >> >>> Thanks. But could you please change it to >>> >>> (if (or outline-minor-mode orgstruct-mode) >>> (call-interactively #'show-children) >>> ...) >> >> You could set `orgstruct-mode' to a non-nil value whenever >> `outline-minor-mode' is enabled. > > I could (instead I am currently just maintaining a local patch), > but what is the reasoning for not just doing what I suggested? There is no reason for Org's core to know about `outline-minor-mode', or any other minor mode in the wild. IMO, using a hook is much more simple than maintaining a local patch. Regards, -- Nicolas Goaziou
Re: [O] bug#21818: 24.5; org-set-tags-to indentation problems when called programmatically
Hello,
Emanuel Evans writes:
> Hi! It looks like it's fixed for `org-insert-link', but I ran across a
> similar bug with `org-element-interpret-data' that seems to be not
> entirely fixed:
>
> (defun good-indent ()
> (interactive)
> (insert (org-element-interpret-data
>`(headline (:level 1
> :title "something"
> :tags ("foo"))
>
> (defun bad-indent ()
> (interactive)
> (insert (org-element-interpret-data
>`(headline (:level 1
> :title ((link (:raw-link
> "http://www.example.com/foo/bar/baz/qux/abc123f56789";)
> "something"))
> :tags ("foo"))
>
> `good-indent' looks like:
>
> * something :foo:
>
> With org-mode 8.2.10, `bad-indent' looks like:
>
> * something:foo:
>
> With the latest master version of org-mode (d6aafd7), `bad-indent' looks
> like:
>
> * something :foo:
>
> (i.e., "almost but still not quite right").
>
> I'm not very familiar with the org-element internals, but is there any
> way to work around this for 8.2.10? (I'm writing a library that I'd like
> to be compatible with Emacs 24.5.)
I don't consider it to be a bug.
`org-element-interpret-data' produces a string, which is expected to be
syntactically correct, but doesn't guarantee aesthetics. In particular,
`org-element-headline-interpreter' tries to align tags as accurately as
possible, but, in this case, fails to succeed as it would require to
introduce fontification in the process. This is out of the scope of the
function.
I think it is the duty of the caller, here `bad-indent', to align the
tags properly.
Regards,
--
Nicolas Goaziou
