Re: [O] Python source block and :dir header arg
Joao Cortes writes: > Consider the following python source block, > > #+begin_src python :results output : session :dir ./run > import os; > cwd = os.getcwd() > print(cwd) > #+end_src > > The dir header arg should change the directory used to run the session, > in this case to the directory "../base/run", where "base" is the parent > directory the file visited by the current buffer. Instead, I get > "../base". Is this a bug? It works fine in my machine. It print absolute path to "/run". > > Thank you > Joao Cortes -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
[O] [ANN] org-conflict add-on: timing conflicts detector and resolver for Org agenda
With this post, I'd like to submit org-conflict, a new Org add-on, to
the community for enjoyment, scrutiny and feedback.
Org-conflict aims to help Org agenda users prevent creating scheduling
conflicts. If you use the agenda for calendar purposes, you might
benefit from validating timestamps before you commit them.
My own demand for conflict-free timestamps arose from using Org as the
back end of an iCalendar client I created for VM which exports Org
entries. Most people who send me meeting requests use MS Outlook and
I got envious when I saw that Outlook informs them immediately of any
scheduling conflict when it processes incoming iCalendar data.
Initially, org-conflict was intended just as a Lisp predicate called
from the VM presentation buffer. Adding an interactive mode, so that
it could be used on regular Org timestamps, was fairly easy. Having
then added conflict resolution, I thought this might have enough
functionality to count as an Org add-on.
So here it is as the attached org-conflict.el, tested with Org 9.0 and
9.2. Its implementation is "pure Org" and relies only on code that is
loaded anyway when Org is running.
Instead of posting a longish message to this list, I opted to explain
org-conflict in the attached FAQ document, of course a .org file. The
added benefit being that the document is a self-contained demo.
Following the guided tour, you know after a couple of minutes
interaction if this package is for you.
If this is all tl;dr, here's org-conflict in brief:
- compares a test time/timestamp/-range against 'org-agenda-files.
Eligible timestamps in there are event-type, ie. contain a
time-of-day and encode a duration
- detects overlaps ("conflicts"), computes a resolution
- supports intervals between events ("coffee breaks")
- supports virtual ranges (end time is before start time)
- customizable levels of automation
- designed to be put on the C-c C-c hook, makes timestamps magic
- dedicated interactive and non-interactive modes
Please let me know if this package is remotely useful, completely
misses the point or has crippling bugs and oversights.
Regards,
Thomas
org-conflict.el
Description: Binary data
org-conflict-faq.org
Description: Binary data
Re: [O] org-eldoc error on shell src blocks
Hi folks, I just verified the proposed patch to org-eldoc.el in contrib dir, works well. But the problem is we lost an appropriate contact point because https://bitbucket.org/ukaszg/org-eldoc was removed. Who can amend org-eldoc.el in contribution directory? Best regards, Takaaki > On Mar 31, 2019, at 17:53, 甲斐常伸 wrote: > > Hello, > > I encounted the same error and I found it happens because "org-eldoc.el" > doesn't reflect a value of "org-src-lang-modes". When I redefine > "org-eldoc-get-mode-local-documentation-function" to reflect a value of > "org-src-lang-modes" as below, the error disappeared. > > (defun org-eldoc-get-mode-local-documentation-function (lang) > "Check if LANG-mode sets eldoc-documentation-function and return its > value." > (let ((cached-func (gethash lang org-eldoc-local-functions-cache > 'empty)) > (mode-func (org-src--get-lang-mode lang)) > doc-func) > (if (eq 'empty cached-func) > (when (fboundp mode-func) > (with-temp-buffer > (funcall mode-func) > (setq doc-func (and eldoc-documentation-function > (symbol-value > 'eldoc-documentation-function))) > (puthash lang doc-func org-eldoc-local-functions-cache)) > doc-func) > cached-func))) > > The practical change is a one line. > > diff --git a/contrib/lisp/org-eldoc.el b/contrib/lisp/org-eldoc.el > index 556b945..fca13c3 100644 > --- a/contrib/lisp/org-eldoc.el > +++ b/contrib/lisp/org-eldoc.el > @@ -110,7 +110,7 @@ > (defun org-eldoc-get-mode-local-documentation-function (lang) >"Check if LANG-mode sets eldoc-documentation-function and return its > value." >(let ((cached-func (gethash lang org-eldoc-local-functions-cache > 'empty)) > -(mode-func (intern-soft (format "%s-mode" lang))) > +(mode-func (org-src--get-lang-mode lang)) > doc-func) > (if (eq 'empty cached-func) > (when (fboundp mode-func) > > > I confirmed this change works good on the following two environments. > > - Emacs 26.1 on Windows 10 > - (emacs-version) ; GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ > Version 3.22.30) of 2018-05-29 > - (org-version) ; Org mode version 9.2.2 (9.2.2-13-g0007df-elpaplus @ > /home/kai2nenobu/.emacs.d/elpa/org-plus-contrib-20190318/) > > - Emacs 26.1 on Ubuntu 18.04 on WSL (on above Windows 10) > - (emacs-version) ; GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) of > 2018-05-31 > - (org-version) ; Org mode version 9.2.1 (9.2.1-8-g1b1797-elpaplus @ > c:/Users/kai2nenobu/.emacs.d/elpa/org-plus-contrib-20190211/) > > > I'm ready to contribute this patch, but I don't know how to contribute to > "org-eldoc.el". Please tell me how to do it. > > > Best Regards, > > > 2018年2月4日(日) 16:56 Nicolas Goaziou : > Hello, > > "numbch...@gmail.com" writes: > > > After some dive in deeper > > > > - [X] emacs minimal init test, confirmed issue in org-mode. > > - [X] from the error log, seems `org-eldoc` try to call `(progn (funcall > > mode-func) ...`. This caused `shell-mode()`. > > - [ ] check out `org-eldoc.el` source code, have not found any solution or > > options. > > > Hope some org-mode hacker can help to fix this issue? > > I'm Cc'ing Org Eldoc author about it. > > > And this might be a unit test in Org-mode testing? > > We don't test contrib packages. However, they can provide their own > tests. > > Regards, > > -- > Nicolas Goaziou > signature.asc Description: Message signed with OpenPGP
Re: [O] [ISSUE] links navigation not consistent behavior
Hello, Nick Dokos writes: > | I can reproduce this and traced it to this code: > | > | , > | | (catch :found > | | (while (funcall search-fun org-link-any-re nil t) > | | (pcase (org-element-lineage (org-element-context) '(link) t);;; > < HERE > | | (`nil nil) (link > | | (goto-char (org-element-property :begin link)) (when > | | (org-invisible-p) (org-show-context)) (throw :found t > | ` > | > | which is a rewrite of org-next-link in commit 4ff8947ea8. > | > | There is some asymmetry in how forward and backward searches behave: > | > | - in the forward case, the search ends up at the end of the first > |link where `org-element-lineage' returns nil, so the loop repeats; > |we then end up at the end of the second link where > |`org-element-lineage' returns the link, we go to the beginning of > |the link and return. > | > | - in the backward case, we end up at the beginning of each link in > |turn, in which case `org-element-lineage' returns a link, so both > |links are found. > | > | So it may be that `org-element-context' should return a structure with > | the link included when called at the end of the first link or it may > | be that the search should back up one char in the forward case, before > | calling org-context. > ` > > This may be wrong but I did not have time to continue with it: I hope it's > useful. Fixed. Thank you. Regards, -- Nicolas Goaziou
