`org-ctags' unilaterally sets the hook `org-open-link-functions' to a
bunch of org-ctags functions and enables itself by default. That has
the unfortunate consequence of invalidating the documentation for
internal CUSTOM_ID links - see
https://emacs.stackexchange.com/questions/76351/how-to-follow-
Do `C-h v org-read-date-force-compatible-dates` and read the doc
string of the variable. You can customize the variable and set it to
`nil' which will give you a much wider range of dates to choose from
*assuming that your Emacs is compiled for and runs on a system that
can deal with such dates* (
--=-=-=
Content-Type: text/plain
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
---
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
---
Hello again,
Roger Mason writes:
...snip...
> Is ob-async known to be broken?
No. The user is broken.
It seems ob-async must be required in the file in which it is to be used
(I had it in my init file). I ran into a further problem that is
resolved using:
(defun no-hide-overlays (orig-fun
Hello,
I installed ob-async from MELPA. It does not seem to work. For example
the following simple source block is run synchronously, i.e., emacs
shows the cursor as a watch and it is not possible to move point, or to
type, until the source block completes.
#+begin_src ruby :tangle test.rb
slee
When I org-capture from elfeed-entry buffer (I defined custom functions to
extract elfeed entry buffer content) in the second time and later, the
bellowing error raised up. The first-time capture is fine.
Here is the error backtrace:
#+begin_example
Debugger entered--Lisp error: (wrong-type-argume
Ihor Radchenko writes:
> Daniel Kraus writes:
>
>>> The only downside is that people might need to
>>> (require 'ob-clojurescript)
>>> I am thinking if ob-core.el should try to automatically guess the
>>> correct library to be loaded.
>>
>> We could just (require 'ob-clojurescript) inside ob-cl
Ihor Radchenko writes:
> stardiviner writes:
>
>> For now, ob-clojure.el contains lot of code for ClojureScript. Only some
>> code has same functionality. Like CIDER backend. In the future,
>> ClojureScript part code will increase and different. So I suggest
>> separate them into two source cod
For now, ob-clojure.el contains lot of code for ClojureScript. Only some
code has same functionality. Like CIDER backend. In the future,
ClojureScript part code will increase and different. So I suggest
separate them into two source code files.
WDYT?
--
[ stardiviner ]
I try to make every word
Daniel Kraus writes:
>> The only downside is that people might need to
>> (require 'ob-clojurescript)
>> I am thinking if ob-core.el should try to automatically guess the
>> correct library to be loaded.
>
> We could just (require 'ob-clojurescript) inside ob-clojure.el ?!
Sure. Though it will g
11 matches
Mail list logo
