Re: [O] ob-clojure.el is not compatible with new CIDER API
No, there is no public repo and I'm not sure I even kept what little I had done - it was just a hacked elisp file. I'll have a look through my elisp archive, but don't expect much. Over the weekend, I caught up on a bit of clojure and things have progressed in the last few months. I notice the clj tool seems quite mature and there is now support for clojurescript with it as well. Don't know if inf-clojure will move (has already moved?) to be based around it or not? At any rate, I think you are probably better off starting from scratch rather than trying to 'adjust' the existing package. There are some cases where I can see someone wanting cider/slime support, but for the majority of cases, just plain clojure via inf-clojure or clojure/clj or one of the many available repl clients should be fairly straight forward. The real challenge is in deciding how to handle interaction between different clojure blocks and their dependencies. The simple solution would likely be to just start some form of repl session and have all blocks sent to that session. However, you then need to decide how to handle matters when someone opens a new org file. You probably don't want old definitions/artifacts from the previous session in the repl, so you would need a clean way of managing multiple sessions (one per org file?). Apart from that, all you really need is the ability to send a form to the repl and read back the result. The inf-clojure package already has most of the infrastructure for doing that, but from memory, it was a little hard to fit it into the existing structure of ob-clojure.el - which is why you may be better off just implementing an ob-inf-clojure.el rather than try to add a 3rd method to the existing package (which supports cide and the old slime-clojure interfaces). stardiviner writes: > Tim Cross writes: > >> I did begin to look at it. From memory, the inf-clojure integration didn't >> look that hard, >> but it did require some additional scaffolding to mae the comms work well. I >> then got >> distracted with a new job and haven't had time to go back to it. Currently, >> I've not had time >> to do any Clojure work, so it is not high on the priority list. >> > > Can I see your work? Do you have any public source code repository online of > this? -- Tim Cross
[O] org-ref, html-export, citation links
Hi! I have an older Html-file exported from an org-mode file with org-ref citations. All citation links are internal links into the reference section, fine! But if I anew export the org-mode file, now, the generated citation links are external file links to (not existing) files. For example, cite:Hales2008 is exported to "file:///.../Hales2008“. Any hints? Johannes
Re: [O] ob-clojure.el is not compatible with new CIDER API
Tim Cross writes: > I did begin to look at it. From memory, the inf-clojure integration didn't > look that hard, > but it did require some additional scaffolding to mae the comms work well. I > then got > distracted with a new job and haven't had time to go back to it. Currently, > I've not had time > to do any Clojure work, so it is not high on the priority list. > Can I see your work? Do you have any public source code repository online of this? -- [ stardiviner ] don't need to convince with trends. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
[O] ob-lilypond and 'Symbol’s function definition is void: org-babel-get-header'
Hi, I have been trying out ob-lilypond and it works really well, except for the arrange mode. Any attempt to run ly-tangle results in 'Symbol’s function definition is void: org-babel-get-header' and so does an attempt to export a file, such as the example file, in basic mode to html for instance. I was thinking it was related to sh/shell since this appears to be a common issue with regard to this error, but the ob-lilypond does not appear to use any reference to sh (the doc for ob-lilypond does). I also tried to load ob-core as was suggested in some post but that didn't work either. Other tangle other languages works fine. Any suggestions? /H
Re: [O] Feature request: Maintaining multiple init files with one org file
Hi Armin That's an interesting approach. I didn't think about giving arguments to the :tangle operator. This is basically what I was looking for. Just a bit more to write to each relevant source block. I will give it a try. Sven Amin Bandali writes: > Hello, > > Indeed, a tag-based solution (e.g. with :office:, :home:, etc) > would be great; but what I do right now looks something like > this: > > , > | #+property: header-args :tangle ~/.emacs > | > | * Default Frame > | > | ** All computers > | #+begin_src emacs-lisp > | (defvar myvar "testing") > | #+end_src > | > | ** Office Computer > | #+begin_src emacs-lisp :tangle (when (string= (system-name) "officepc") > "~/.emacs") > | (setq default-frame-alist '( > | (font . "-PfEd-DejaVu Sans > Mono-normal-normal-normal-*-26-*-*-*-m-0-iso10646-1") > | (width . 102) > | (height . 41)) > | #+end_src > | > | ** Laptop > | #+begin_src emacs-lisp :tangle (when (string= (system-name) "mylaptop") > "~/.emacs") > | (setq default-frame-alist '( > | (font . "-PfEd-DejaVu Sans > Mono-normal-normal-normal-*-12-*-*-*-m-0-iso10646-1") > | (width . 80) > | (height . 30)) > | #+end_src > | > | ** More stuff for all computers > | > | #+begin_src emacs-lisp > | (message myvar) > | #+end_src > ` > > In other words, I use `when' and `string=' (from subr.el) and > `system-name' to check the hostname. If it matches what I want, > I return the "~/.emacs" filename, nil otherwise. Alternatively, > you could probably use `if' and return "no" when it doesn't > match, but :tangle nil seems to work just fine so I went with > `when'. > > Hope that helps. > > Best, > > -amin
Re: [O] Feature request: Maintaining multiple init files with one org file
Hi Thanks for the answer. Tim Cross writes: > As your emacs init file is really just a lisp program, it is relatively > easy to implement multiple environment support within the file itself, > which is what I do. At the start of my init file, I just have some elisp > which sets variables representing the platform (linux or mac), the > hostname (I have both a linux and mac box at home and work) and the > profile (home/work). Then it is just if/cond/when conditionals where > needed. I use org to store the file mainly for documentation purposes > and will have the same file on all platforms. The advantage is that it > is the same file on all platforms, the disadvantage is that it is larger > and probably more complex than it would be if you tangled different > files per system. This is pretty much how I do it at the moment. Complexity is indeed the problem here. I have Emacs also running on an Android tablet under Termux. This one needs quite a lot of adjustments to the init file. Already the paths to the org files and to some non-elpa/melpa packages are different. Other packages are not available on Termux (e.g. aspell) or not meaningful at all (X-related stuff, mu4e etc.). Having the same init file here as on the other computers, would easily end up in a mess of IFs and WHENs (and probably slow down the start process on Android). At the moment I have a separate .emacs for the tablet and have to remember changing this file, for ex. whenever I include a new file in the org-agenda-files list. This could be much more tidy with an org approach. > For me this is just 6 of one and half a dozen of the other. YMMV. I do > find there are some things best set/managed via Emacs' custom facility, > so the most useful bit in my init file is the bit which loads different > custom files based on the platform. I don't bother keeping the custom > files in git, so they stay local to each system. I find using custom to > manage face and font settings particularly convenient over managing them > by hand in my init file. I'm trying to use customize as little as possible, since AFAIK there is no way to let customize use an org file instead of a "real" init file. Sven
