[O] coderef does not provide file path for org-insert-link when not in original buffre

Suppose I have a src block: #+begin_src emacs-lisp (let ((case-fold-search nil) (str (prin1-to-string (with-temp-buffer (set-buffer-multibyte nil) ; (ref:set the temp buffer to unibyte) (insert (with-current-buffer

Re: [O] Inheriting some local variables from source code block editing buffers

Hello, Sorry for the silence, I've finally got around to implementing this, and implemented it as an advice, which supports both an ‘:edit-bindings’ Babel header argument for source code blocks, and an #+ATTR_EDIT: element property for export blocks, etc. Find the code below, and attached an Org

Re: [O] Bug: Inconsistent effort handling in clock totals in maint [9.1.13 (release_9.1.13 @ /home/bernt/git/org-mode/lisp/)]

Nicolas Goaziou writes: > Hello, > > Bernt Hansen writes: > >>Notice modeline total has [0:05/0:15] >>So 'do something' has an effort of 15 minutes. It may be entered wrong >> but it is a bare 15 value >>instead of 15:00 or 00:15 >> >>

Re: [O] Inheriting some local variables from source code block editing buffers

Hello, Göktuğ Kayaalp writes: > Sorry for the silence, I've finally got around to implementing this, and > implemented it as an advice, which supports both an ‘:edit-bindings’ > Babel header argument for source code blocks, and an #+ATTR_EDIT: > element property for export

Re: [O] Typo on org-tag-alist

Nicolas Goaziou writes: > Hello, > > Bernt Hansen writes: > >> I think there is a typo in the output of >> >> C-h v org-tag-alist RET >> >> ':engroup' instead of ':endgroup' > > Fixed. Thank you. Nope. I think you found another one

Re: [O] Bug: Inconsistent effort handling in clock totals in maint [9.1.13 (release_9.1.13 @ /home/bernt/git/org-mode/lisp/)]

Hello, Bernt Hansen writes: > I am fine with plain numbers being interpretted as hours. I don't > think we need a second interpretation for it (as minutes). The second interpretation already exists. "org-colview.el" is the sole place where plain numbers are treated as hours.

Re: [O] Typo on org-tag-alist

Bernt Hansen writes: > Nope. I think you found another one (org-tag-persistent-alist) and > fixed that instead. org-tag-alist is the one I reported. > > $ git grep -n engroup > lisp/org.el:3424:`:startgrouptag', `:grouptags', `:engroup', > `:endgrouptag' or > > Thanks for

Re: [O] Inheriting some local variables from source code block editing buffers

Hi Göktuğ, This patch looks good, thanks. Of course, for merging to org core it will need to be an actual patch and not advice. There is also copyright assignment to think of. Do you already have a FSF copyright assignment on file? 2018ko maiatzak 14an, Göktuğ Kayaalp-ek idatzi zuen: [...]

Re: [O] Tag completion does not work well with org-complete-tags-always-offer-all-agenda-tags

Nicolas Goaziou writes on Mon 14 May 2018 16:43: > Hello, > > alain.coch...@unistra.fr writes: > > > Thank you for not giving up on me! Turned out that the problem was > > due to a "::" in one of my tag lists in one of my agenda files... > > > > Specifically, doing as you did above, I

Re: [O] Proposal: references from code to text.

It seems like this is nearly all possible already (see below). It is a little wonky that you have to put text in a src txt block to achieve it, but otherwise what is missing? * Main document See [[id:BAD97113-3561-4A4A-BA07-0CD5BF6BA35F][There is a reason we only support two args]] (text to

[O] Advice for debugging org-export

Hi, I find debugging my exporters for org-mode a real pain. Consider the following: #+name: get-task-list-as-exported-text #+begin_src emacs-lisp :exports code (defun my-filter-out-done-lines (s backend info) "Filter out lines ending in :done" (apply 'concat (--remove

Re: [O] Bug: Inconsistent effort handling in clock totals in maint [9.1.13 (release_9.1.13 @ /home/bernt/git/org-mode/lisp/)]

Nicolas Goaziou writes: > Bernt Hansen writes: > >> I am fine with plain numbers being interpretted as hours. I don't >> think we need a second interpretation for it (as minutes). > > The second interpretation already exists. "org-colview.el" is the sole

Re: [O] Tag completion does not work well with org-complete-tags-always-offer-all-agenda-tags

Nicolas Goaziou writes on Sun 13 May 2018 23:01: > Here is what I did. > > I created a file "mini-init.el", containing the following lines: > > --8<---cut here---start->8--- > (add-to-list 'load-path "/path/to/org-mode/lisp/") > (setq

Re: [O] Inheriting some local variables from source code block editing buffers

On 2018-05-14 14:13 +02, Nicolas Goaziou wrote: > You shouldn't add another "attr" keyword, which is reserved for export > back-ends. Actually, every Babel header can be located either on the > block opening line, e.g., > > #+begin_src emacs-lisp :some-property

Re: [O] Inheriting some local variables from source code block editing buffers

Göktuğ Kayaalp writes: > The attr was meant for BEGIN_EXPORT blocks because it seems to me that > an equivalent of ‘org-babel-get-src-block-info’ does not exist for those > blocks, and that function _only_ works with BEGIN_SRC blocks. Is there > a function available or would

Re: [O] Tag completion does not work well with org-complete-tags-always-offer-all-agenda-tags

Hello, alain.coch...@unistra.fr writes: > Thank you for not giving up on me! Turned out that the problem was > due to a "::" in one of my tag lists in one of my agenda files... > > Specifically, doing as you did above, I don't have the problem, while > I do get it if replacing ":bar:" by

Re: [O] Tag completion does not work well with org-complete-tags-always-offer-all-agenda-tags

alain.coch...@unistra.fr writes: > > Could you describe exactly the context where that happened? I.e., what > > is exactly "a "::" in one of my tag lists in one of my agenda > > files...": > > > > * This :tag::tag2: > > Yes, this. OK. I added a checker in Org Lint.

Re: [O] Inheriting some local variables from source code block editing buffers

On 2018-05-14 14:33 +01, Aaron Ecay wrote: > Hi Göktuğ, > > This patch looks good, thanks. Of course, for merging to org core it > will need to be an actual patch and not advice. Certainly; this is meant as a ‘tangible’ example, and can easily be turned into a patch if you

Re: [O] Proposal: references from code to text.

... continued ... although I found a strange bug in the tangling and noweb syntax. I didn't want to have quotes in the text so I removed them and put them in the lisp src block instead: #+begin_src org ,#+NAME: ADD ,#+BEGIN_SRC emacs-lisp -n -r :noweb yes :tangle test.el (defun add (x y)

Re: [O] Proposal: references from code to text.

On Monday, 14 May 2018 at 08:05, John Kitchin wrote: > It seems like this is nearly all possible already (see below). It is a > little wonky that you have to put text in a src txt block to achieve it, > but otherwise what is missing? Ah, yes, quite nice. Thanks! -- Eric S Fraga via Emacs

Re: [O] [PATCH] Add new keyword :coding for #+include directive

Hello, And sorry for the delay. Nicolas Goaziou writes: > Hello, > > pierre.techouey...@free.fr (Pierre Téchoueyres) writes: > >> Hello Nicolas, >> Did you have time to review the patches ? > > Sorry for the delay, I have been sidetracked. > > I admit I don't fully