Re: [BUG] Fix for inlinetask visibility cycling causes infinite loop for
Something like this could work. Just ensuring that we haven’t ended back at the start of the current (degenerate) inlinetask. I don’t know if this would be the most elegant solution though. I also considered whether org-inlinetask-goto-end should really move to the point after the last line of an inlinetask (is this consistent with org-element BTW?), but that would require changes across a big part of org-inlinetask and probably complicate other things. diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el index 07aa94f32..c28f5e7b4 100644 --- a/lisp/org-inlinetask.el +++ b/lisp/org-inlinetask.el @@ -334,12 +334,15 @@ (defun org-inlinetask-hide-tasks (state) (org-inlinetask-goto-end) (`children (save-excursion - (while - (or (org-inlinetask-at-task-p) - (and (outline-next-heading) (org-inlinetask-at-task-p))) -(org-inlinetask-toggle-visibility) -(org-inlinetask-goto-end) - (backward-char)) + (let ((startpoint-at-bol -1)) + (while +(or (and (org-inlinetask-at-task-p) + (not (eq startpoint-at-bol (point-at-bol +(and (outline-next-heading) (org-inlinetask-at-task-p))) + (setq startpoint-at-bol (point-at-bol)) + (org-inlinetask-toggle-visibility) + (org-inlinetask-goto-end) + (backward-char))) (defun org-inlinetask-remove-END-maybe () "Remove an END line when present."
[BUG] Fix for inlinetask visibility cycling causes infinite loop for "degenerate" inlinetasks
Hi, I use "degenerate" inlinetasks (without an "*** END" line) quite a lot (for example for "coding" snippets in my orgqda package https://git.sr.ht/~andersjohansson/orgqda/). Degenerate inlinetasks are stated as allowed in the documentation at the beginning of org-inlinetask.el, but are maybe not so common since org-inlinetask-insert-task always inserts the END-line. Since April, an infinite loop is caused when cycling an entry containing degenerate inlinetasks by commit: 5f184b org-inlinetask.el: Fix visibility cycling for inlinetasks Sample for reproducing: - * Heading *** Degenerate inlinetask - Cycling "Heading" will call org-inlinetask-hide-tasks where the last calls in the loop of `inlinetask-goto-end` takes us to the line below the inlinetask, but `backward-char` takes us back to the point at the end of the inlinetask, so `inlinetask-at-task-p` is still t and the loop continues infinitely in this fashion. I don’t have a good suggestion for a solution that would still solve the problem addressed in that commit. Best, Anders Johansson
[BUG] org-get-buffer-tags no longer strips text properties
Hi, Commit 819409 introduced a change where the text-properties of tags collected from a buffer are no longer stripped, which means tags may be fontified in unwanted ways in completing-read (this became especially ugly using org-modern and code for right aligning tags with display properties). Something like this would fix it: @@ -11974,7 +11974,7 @@ (defun org-get-buffer-tags () (org-element-cache-map (lambda (el) (dolist (tag (org-element-property :tags el)) - (puthash (list tag) t hashed + (puthash (list (substring-no-properties tag)) t hashed Best, Anders Johansson
[Style] Shouldn’t the macros in org-fold-core have (indent 0)
Hi, When looking through the code in org-fold-core (while debugging a tricky problem that seems to be an interaction with org-modern, I may get back to it) I noticed that all the macros that wrap a “body” argument have (indent 1), but I gather that they should have (indent 0), similar to for example `with-silent-modifications`. I didn’t want to create a patch, since it would involve whitespace changes on quite a lot of places, but I thought it could be good to highlight now that org-fold just got merged. Best, Anders Johansson
[PATCH v2 24/38] Fix typo: delete-duplicates → delete-dups
--- lisp/org-fold-core.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-fold-core.el b/lisp/org-fold-core.el index 6ea374498..121c6b5c4 100644 --- a/lisp/org-fold-core.el +++ b/lisp/org-fold-core.el @@ -592,7 +592,7 @@ (defun org-fold-core--property-symbol-get-create (spec buffer return-o (org-fold-core-cycle-over-indirect-buffers (push (current-buffer) bufs)) (push buf bufs) - (delete-duplicates bufs) + (delete-dups bufs) ;; Copy all the old folding properties to preserve the folding state (with-silent-modifications (dolist (old-prop (cdr (assq 'invisible char-property-alias-alist))) -- 2.35.1 -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
[PATCH v2 25/38] Fix bug in org-get-headingFixes #26, where fontification could make the matching and extraction of heading
Fixes #26, where fontification could make the matching and extraction of heading components fail. --- lisp/org.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 0f31e7794..ff17bf001 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -6167,8 +6167,9 @@ (defun org-get-heading ( no-tags no-todo no-priority no-comment) (let ((case-fold-search nil)) (looking-at org-complex-heading-regexp) ;; When using `org-fold-core--optimise-for-huge-buffers', -;; returned text may be invisible. Clear it up. -(org-fold-core-remove-optimisation (match-beginning 0) (match-end 0)) +;; returned text will be invisible. Clear it up. +(save-match-data + (org-fold-core-remove-optimisation (match-beginning 0) (match-end 0))) (let ((todo (and (not no-todo) (match-string 2))) (priority (and (not no-priority) (match-string 3))) (headline (pcase (match-string 4) -- 2.35.1 -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
[PATCH v2 26/38] Rename remaining org-force-cycle-archived
--- lisp/org-cycle.el | 2 +- lisp/org-keys.el | 4 ++-- lisp/org.el | 1 + 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/lisp/org-cycle.el b/lisp/org-cycle.el index d2fcc356c..df0a3761a 100644 --- a/lisp/org-cycle.el +++ b/lisp/org-cycle.el @@ -811,7 +811,7 @@ (defun org-cycle-hide-archived-subtrees (state) (org-get-tags nil 'local))) (message "%s" (substitute-command-keys "Subtree is archived and stays closed. Use \ -`\\[org-force-cycle-archived]' to cycle it anyway.")) +`\\[org-cycle-force-archived]' to cycle it anyway.")) (provide 'org-cycle) diff --git a/lisp/org-keys.el b/lisp/org-keys.el index e6b8ff459..782ffa871 100644 --- a/lisp/org-keys.el +++ b/lisp/org-keys.el @@ -94,7 +94,7 @@ (declare-function org-feed-update-all "org" ()) (declare-function org-fill-paragraph "org" ( justify region)) (declare-function org-find-file-at-mouse "org" (ev)) (declare-function org-footnote-action "org" ( special)) -(declare-function org-force-cycle-archived "org-cycle" ()) +(declare-function org-cycle-force-archived "org-cycle" ()) (declare-function org-force-self-insert "org" (n)) (declare-function org-forward-element "org" ()) (declare-function org-forward-heading-same-level "org" (arg invisible-ok)) @@ -444,7 +444,7 @@ (org-defkey org-mode-map (kbd "C-c C-x") (make-sparse-keymap)) TAB key with modifiers (org-defkey org-mode-map (kbd "TAB") #'org-cycle) -(org-defkey org-mode-map (kbd "C-c C-") #'org-force-cycle-archived) +(org-defkey org-mode-map (kbd "C-c C-") #'org-cycle-force-archived) ;; Override text-mode binding to expose `complete-symbol' for ;; pcomplete functionality. (org-defkey org-mode-map (kbd "M-TAB") nil) diff --git a/lisp/org.el b/lisp/org.el index ff17bf001..796a05fad 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -106,6 +106,7 @@ (defalias 'org-global-cycle #'org-cycle-global) (defalias 'org-overview #'org-cycle-overview) (defalias 'org-content #'org-cycle-content) (defalias 'org-reveal #'org-fold-reveal) +(defalias 'org-force-cycle-archived #'org-cycle-force-archived) ;; `org-outline-regexp' ought to be a defconst but is let-bound in ;; some places -- e.g. see the macro `org-with-limited-levels'. -- 2.35.1 -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Bug: Changed behaviour of org-at-timestamp-p after recent change
Hi, I noticed that this commit: b1a570b3b org-agenda: Fix regression when diary sexp timestamps are ignored made a call like (org-at-timestamp-p 'agenda) match against the regexp `org-element--timestamp-regexp`. However, this regexp doesn’t have the match groups setup as the others (`org-ts-regexp3` and `org-ts-regexp2`) so the last part of the docstring for org-at-timestamp-p doesn’t hold anymore (that the timestamp parts should now be put in match groups). I was using this in some code of mine, but I also realize that this doesn’t feel all that clean anyway. I am not sure if this is used elsewhere in org though. Best, Anders
Re: [wip-cite-new] Exporting to pandoc md (and from there to zotero odt)
Hi, >We should also get pandoc to support updated org-cite syntax. > https://github.com/jgm/pandoc/issues/7329 Now that pandoc has org-cite support, I found it simpler to reuse ox-pandoc (https://github.com/emacsorphanage/ox-pandoc) and just do this very simple configuration. ox-pandoc exports to an intermediary org file, so we can just make sure to reinsert citations in org format. (use-package ox-pandoc :custom (org-pandoc-options-for-odt '((lua-filter . "/home/aj/lib/bbt-pandoc-zotero.lua") (metadata . "zotero_author_in_text=true" (org-cite-register-processor 'pandoc :export-citation #'oc-pandoc-export-citation :export-bibliography #'oc-pandoc-export-bibliography) (defun oc-pandoc-export-citation (citation _style _ _info) "Export CITATION object in org format." (org-element-citation-interpreter citation (mapconcat (lambda (r) (org-element-citation-reference-interpreter r nil)) (org-cite-get-references citation (defun oc-pandoc-export-bibliography (_k _f _s _p _b _i) "Generate a #+print_bibliography:" "#+print_bibliography:")
Re: Suggestion: convert dispatchers to use transient
I agree that transient dispatchers would be great and consistent. What is not so great with transient currently is it’s lacking support for lisp-variable/option workflows. Transient is good for command-line arguments, but setting options for emacs functions is not as streamlined (this would be relevant for the export dispatcher for example). Some new classes for these types of options would probably need to be defined, since the default infix-classes assume all options are strings. I recently did try to implement a transient dispatcher this for my orgqda package: https://gitlab.com/andersjohansson/orgqda/-/blob/main/orgqda-transient.el Partly inspired by org-ql: https://github.com/alphapapa/org-ql/blob/048de35b07d8d29fc6fa49c34d7ba1fd1c912011/org-ql-view.el#L501 I now store the options as plists in buffer-local-variables, which I am not sure is optimal and perhaps goes against the idea of saving options with transient. So still some work to do there. By the way. Getting started with transient is way easier with this tutorial than with the rather abstract info pages: https://github.com/magit/transient/wiki/Developer-Quick-Start-Guide Best, Anders Johansson
Re: [BUG] org-element-cache: The inherited property is set wrong
> I don’t know if this is the best solution though. > Perhaps this is needed also in org--get-local-tags where a similar > thing is done? (but only the fontification seems to matter there) I now noted that this differed in Ihor's org-fold-universal-core branch which I use and main (org-get-tags has an extra argument fontify for org-fold). But I believe the caching issue is relevant on both branches (and in either case a topic for Ihor). Best, Anders
[BUG] org-element-cache: The inherited property is set wrong
Hi, I had some trouble with completing tags, where the already set tags were wrongly identified. I have dug this down to a problem with caching. with org-element-use-cache=t and org-use-tag-inheritance=t --- Org * headline 1 :tag1: ** headline 2 :tag2: --- end org When invoking org-set-tags-command (and quitting), on headline 1, then headline 2, then headline 1 again, "tag1" is no longer shown as one of the existing tags in the minibuffer. This is because it has erronously been assigned an :inherited property in the cache-representation for headline 1 when inherited tags were calculated for headline 2. This happens in org-get-tags, where inherited tags are parsed from the cache and given the :inherited property, but unfortunately this is done to the same string objects, so that this property is added in the cache tree both for the taglist of headline 1 and headline 2. (cl-copy-list cached-tags) is used there, but only copies the list and not the string objects. A solution that seems to work for me was to change (cl-copy-list cached-tags) to (mapcar #'copy-sequence cached-tags) (found it here: https://stackoverflow.com/a/47794586) I don’t know if this is the best solution though. Perhaps this is needed also in org--get-local-tags where a similar thing is done? (but only the fontification seems to matter there) Best, Anders Johansson (who is otherwise as mentioned in an earlier discussion very appreciative of org-element-cache)
Re: [BUG?] Cache: org-scan-tags behaves differently on inlinetasks with and without cache
> Thanks for reporting! You encountered a bug in org-get-tags. It ignored > inlinetasks in some cases. Fixed in 7a14d6035. Thank you! It works very well now, and indeed the counting and collection of tagged extracts (done with org-scan-tags) is much quicker now with cache enabled. I tested with some generated files, and it looks like with caching (assuming an updated cache) the time scales linearly with the number of headlines/inlinetasks to match versus some power function (n^1.6) with the old buffer-scanning. I had considered to implement some kind of cache in my code, but now I get this "for free"! I originally didn't use org-scan-tags but some custom and "simpler" code for scanning, but I am glad I refactored to use org-scan-tags, because now I get this speedup without a single code change in orgqda. Best, Anders
[BUG?] Cache: org-scan-tags behaves differently on inlinetasks with and without cache
Hi,
I use inlinetasks with tags extensively in my library for coding
qualitative research data
(https://gitlab.com/andersjohansson/orgqda/).
With the new org-element caching functionality (which hopefully can
provide substantial speedups for my case, thanks Ihor!) I have
stumbled on a difference in how inlinetasks are handled by
org-scan-tags.
Without cache, inlinetasks are matched, but with cache they are not.
A minimal test file:
#+BEGIN_ORG
* Test heading :testtag:
Contents
* Another heading
*** An inlinetask :testtag:
#+END_ORG
Executing this code in this file
#+BEGIN_SRC emacs-lisp
(let ((org-element-use-cache nil))
(org-scan-tags
(lambda () (buffer-substring-no-properties (point-at-bol) (point-at-eol)))
(cdr (org-make-tags-matcher "testtag"))
nil))
#+END_SRC
Yields: ("* Test heading :testtag:" "*** An inlinetask :testtag:")
That is, both the headline and inlinetask were matched
However:
#+BEGIN_SRC
(let ((org-element-use-cache t))
(org-scan-tags
(lambda () (buffer-substring-no-properties (point-at-bol) (point-at-eol)))
(cdr (org-make-tags-matcher "testtag"))
nil))
#+END_SRC
Yields: ("* Test heading :testtag:")
Only the headline was matched.
The difference is in org-scan-tags, where the code using cache always
retrieves tags for matching with org-get-tags, whereas the code
without cache takes tags from group 4 of the scanning regexp ("re").
It appears that org-get-tags doesn't fetch tags for inlinetasks, is
this really right? Otherwise, the small patch below gets me the right
behaviour (tags returned also for inlinetasks) for these tests.
Best,
Anders Johansson
---
lisp/org.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index 17b7ff597..98ff5dba7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11808,7 +11808,7 @@ (defun org-get-tags ( pos-or-element
local fontify)
(org-before-first-heading-p))
(unless (org-element-type pos-or-element) (org-back-to-heading t))
(let ((ltags (if (org-element-type pos-or-element)
- (org-element-property :tags
(org-element-lineage pos-or-element '(headline) t))
+ (org-element-property :tags
(org-element-lineage pos-or-element '(headline inlinetask) t))
(org--get-local-tags fontify)))
itags)
(if (or local (not org-use-tag-inheritance)) ltags
--
2.34.0
Re: [PATCH] Fix bug assuming canonical duration units in org-agenda-format-items
> >> I think a proper fix would be to change `org-duration-from-minutes' so
> >> it removes any unknown unit from what is provided from fmt or
> >> `org-duration-format', and defaults to (special . h:mm) if nothing is
> >> left.
> >>
> >> WDYT?
> >>
> > Perhaps. I don't understand `org-duration-from-minutes` well enough to
> > change it.
>
> You don't really need to understand it. I suggest using a filter as the
> very first step of the function.
>
> > I guess the stripping of unknown units from fmt or
> > `org-duration-format` would then have to compare either against
> > `org-duration-units` or `org-duration-canonical-units` depending on
> > the canonical argument.
>
> Exactly.
>
>
> Regards,
> --
> Nicolas Goaziou
Included is a patch for the filtering (I assumed cl-intersection was
reasonable to use since cl-lib is a requirement).
However, I do not think this is enough, since it can cause quite
unexpected results when canonical is used without specifying the
format, Hence, I do think the previous patch should also be applied.
For my case, org-duration-format is (("m") ("w") ("d") (special . h:mm)).
This call to org-duration-from-minutes (like in org-agenda-format-item):
(org-duration-from-minutes MINUTES nil t)
will then result in a full format amounting to (("d")), (since
"special" is not part of the canonical units), which is hardly what is
expected for the agenda.
Best,
Anders Johansson
[PATCH] Ensure valid duration format in org-duration-from-minutes
Filter out any elements of the duration format that is not in
org-duration-units or org-duration-canonical-units.
---
lisp/org-duration.el | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/lisp/org-duration.el b/lisp/org-duration.el
index e627d0936..eb4b6075f 100644
--- a/lisp/org-duration.el
+++ b/lisp/org-duration.el
@@ -314,13 +314,19 @@ (defun org-duration-from-minutes (minutes
fmt canonical)
"Return duration string for a given number of MINUTES.
Format duration according to `org-duration-format' or FMT, when
-non-nil.
+non-nil. Invalid units in the duration format are discarded.
When optional argument CANONICAL is non-nil, ignore
`org-duration-units' and use standard time units value.
Raise an error if expected format is unknown."
- (pcase (or fmt org-duration-format)
+ (pcase (cl-intersection
+ (or fmt org-duration-format)
+ (if canonical
+ org-duration-canonical-units
+org-duration-units)
+ :key #'car
+ :test #'equal)
(`h:mm
(format "%d:%02d" (/ minutes 60) (mod minutes 60)))
(`h:mm:ss
--
2.33.0
Re: [PATCH] Fix bug assuming canonical duration units in org-agenda-format-items
Hi, Oh, I sent a response but failed to send it to the list and only to Nicolas (hard to do things right using the gmail web interface) I include it below: > I think a proper fix would be to change `org-duration-from-minutes' so > it removes any unknown unit from what is provided from fmt or > `org-duration-format', and defaults to (special . h:mm) if nothing is > left. > > WDYT? > Perhaps. I don't understand `org-duration-from-minutes` well enough to change it. I guess the stripping of unknown units from fmt or `org-duration-format` would then have to compare either against `org-duration-units` or `org-duration-canonical-units` depending on the canonical argument. But the full logic of org-duration-from-minutes escapes me. I also noted that the only other invocations of `org-duration-from-minutes` with the canonical argument is in `org-columns--format-age` (where a format is provided). Overall the interaction of these functions across the codebase seems quite complex now.
[PATCH] Fix bug assuming canonical duration units in org-agenda-format-items
org-duration-from-minutes was called with canonical = t, but without
providing a corresponding format only using the canonical units. This
broke if the user’s org-duration-format used other than the canonical units.
---
lisp/org-agenda.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index b4e5547d7..e78ab6b72 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -6749,7 +6749,7 @@ (defun org-agenda-format-item (extra txt
with-level with-category tags
(org-duration-from-minutes
(+ (org-duration-to-minutes s1 t)
org-agenda-default-appointment-duration)
- nil t)))
+ '(("d" (special . h:mm))) t)))
;; Compute the duration
(when s2
(setq duration (- (org-duration-to-minutes s2)
--
2.32.0
Re: [wip-cite-new] Exporting to pandoc md (and from there to zotero odt)
> Anders, I just want to say that I tested this out and it works great. It's > quite shocking, actually, to have such an easy path from org to odt with live > citations. I'd love to see this stuff in MELPA or otherwise made more > generally accessible, as i think it fills a substantial need. Hi Matt, Great that it works for you! I have also been testing it out a bit over the last few days (along with transferring from helm to the newer completion packages, spurred by testing the nice completion given by bibtex-actions. Thanks Bruce). I do miss some of the possibilities of customizing the odt export (easier when exporting via ox-odt). In particular having numbered sections, which doesn't seem to be supported for odt exports from pandoc (https://pandoc.org/MANUAL.html#option--number-sections). I just added a custom variable for passing additional parameters to pandoc in ox-md-pandoc-zotero (at https://gitlab.com/andersjohansson/ox-md-pandoc-zotero), but apparently, --number-sections didn't make a difference for odt.
[wip-cite-new] Exporting to pandoc md (and from there to zotero odt)
Hi all,
I appreciate the work done on the cite functionality!
I use zotero for managing my library and have previously used zotxt
and org-zotxt (along with some additions in my zotxt-extra library)
for being able to cite in org-mode and export correctly to various
formats.
https://gitlab.com/egh/zotxt
https://gitlab.com/egh/zotxt-emacs
https://gitlab.com/andersjohansson/emacs-zotxt-extra
Zotxt has used a custom link format for citations (similar to org-ref)
which links to zotero but optionally also contains a citekey (defined
via the zotero-better-bibtex extension to zotero). I actually wrote my
PhD thesis with this setup, but the connection to Zotero has always
felt a little wobbly and Zotero is also quite slow for my large
library.
Now seems to be a great time to convert to a workflow with the new
cite format. To enable a conversion from org mode to word processors
with Zotero ”active” citations I created two libraries to manage this
via pandoc and the pandoc filter created for the zotero-better-bibtex
extension.
(see: https://retorque.re/zotero-better-bibtex/exporting/pandoc/)
This allows me a workflow like:
1. keep an updated .bib-file of my library in zotero (with the help
of zotero-better-bibtex)
2. cite in org-mode (for me with completion via helm-bibtex and
https://github.com/bdarcus/bibtex-actions/pull/113)
3. Export to an odt-file with active zotero citations (with oc-pandoc
and ox-md-pandoc-zotero)
I attach them here in case anyone else finds some part of this workflow usable.
https://gitlab.com/andersjohansson/org-cite-pandoc
https://gitlab.com/andersjohansson/ox-md-pandoc-zotero
I couldn’t find any previous definitions for exporting to the pandoc
cite format so I quickly hacked up org-cite-pandoc. I suppose it could
be be widely useful and included in org. Feel free to use it as
suitable (I have FSF copyright assignment for emacs).
Best,
Anders Johansson
;;; oc-pandoc.el --- Export org to pandoc markdown with citations -*- lexical-binding: t; -*-
;; Copyright (C) 2021 Anders Johansson
;; Author: Anders Johansson
;; Created: 2021-06-23
;; Modified: 2021-06-23
;; Keywords: org, wp
;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
;; GNU General Public License for more details.
;; You should have received a copy of the GNU General Public License
;; along with this program. If not, see <https://www.gnu.org/licenses/>.
;;; Commentary:
;;
;;; Code:
(require 'oc)
(require 'ox)
(require 'org-element)
(defun org-cite-pandoc--get-key (ref)
"Return @key from REF object."
(concat "@" (org-element-property :key ref)))
(defun org-cite-pandoc--format-citation (citation noauthor info)
"Format CITATION object according to pandoc format.
NOAUTHOR non-nil for noauthor style.
INFO is the export state, as a property list."
(org-export-data
(org-cite-concat "["
(when noauthor "-")
;; no support for global prefix or suffix
;; (org-element-property :prefix citation)
(org-cite-mapconcat
(lambda (ref)
(org-cite-concat
(org-element-property :prefix ref)
(org-cite-pandoc--get-key ref)
(when-let ((suf (org-element-property :suffix ref)))
(org-cite-concat "," suf
(org-cite-get-references citation)
";")
;; (org-element-property :suffix citation)
"]")
info))
(defun org-cite-pandoc-export-citation (citation style _ info)
"Export CITATION object.
STYLE is the expected citation style, as a pair of strings or nil. INFO is the
export communication channel, as a property list."
(pcase style
(`(,(or "text" "t") . ,_)
;; This would generate multiple in-text citations like:
;; AuthorA (2020), Author B (2021)
(mapconcat #'org-cite-pandoc--get-key (org-cite-get-references citation) ", "))
;; "noauthor" style.
(`(,(or "noauthor" "na") . ,_)
(org-cite-pandoc--format-citation citation t info))
;; Default ("nil") style.
(`(,_ . ,_)
(org-cite-pandoc--format-citation citation nil info))
;; This should not happen.
(_ (error "Invalid style: %S" style
(defun org-cite-pandoc-export-bibliography (_k _f _s _p backend _i)
"Generate bibliography.
Just outputs a #refs se
[PATCH] Fix bug in org-num check for commented headlines
I found an easily solved bug in org-num. This happens when org-num-skip-commented is non-nil. When creating a new headline, often org-num--skip-value is invoked before any headline text is created. This means that ‘title‘ is nil and the string-match check breaks. Checking if title is non-nil fixes this. TINYCHANGE --- lisp/org-num.el | 1 + 1 file changed, 1 insertion(+) diff --git a/lisp/org-num.el b/lisp/org-num.el index e816080..a5b044e 100644 --- a/lisp/org-num.el +++ b/lisp/org-num.el @@ -254,6 +254,7 @@ (defun org-num--skip-value () org-footnote-section (equal title org-footnote-section)) (and org-num-skip-commented + title (let ((case-fold-search nil)) (string-match org-num--comment-re title)) t) -- 2.28.0
[O] [PATCH] Use regexp-opt in org-set-tag-faces
I just noticed a place where it would be appropriate to use
regexp-opt instead of doing:
(concat ":\\(" (mapconcat 'car value "\\|") "\\):"
regexp-opt promises to be more efficient.
--
Anders Johansson
>From 2a70a709dcbdb1ff7d00b20de8410935d725ac70 Mon Sep 17 00:00:00 2001
From: Anders Johansson
Date: Thu, 31 Jan 2019 15:04:30 +0100
Subject: [PATCH] org-faces.el: Use regexp-opt in org-set-tag-faces
* org-faces.el (org-set-tag-faces): Use appropriate call to regexp-opt
TINYCHANGE
---
lisp/org-faces.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index 1ba5b5e..1b9118f 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -311,7 +311,7 @@ determines if it is a foreground or a background color."
(if (not value)
(setq org-tags-special-faces-re nil)
(setq org-tags-special-faces-re
- (concat ":\\(" (mapconcat 'car value "\\|") "\\):"
+ (concat ":" (regexp-opt (mapcar 'car value) t) ":"
(defface org-checkbox '((t :inherit bold))
"Face for checkboxes."
--
2.20.1
Re: [O] Tracking Tags ??
Anyone have a good method of tracking the Tags that you've use across all of your Org files? Some sort of Tag Index to help you keep track of the tags you've used and where you've used them so that you don't start creating new tags that differ from old ones by (say) capitalization? Or to help you find everything tagged a certain when you're moving to a new tagging style? Perhaps an index where you could keep a note on why and when you created the tag? Is there any tools for this? I have struggled with similar issues in the context of using tags for coding in qualitative data analysis. The stuff that I’ve hacked together for solving this (pretty particular) use case are available here: https://gitlab.com/andersjohansson/orgqda Maybe some of the ideas there can help? This is centred around projects (a bunch of files with research material in text form) and I haven’t thought much about adapting it to be used for all my org files. For a project, you can easily extract a list of all used tags, rename and merge them. You can define a file for each project as a codebook, where the use of each tag is documented. There is also a more fancy tag-completion via helm that optionally fetches info from the codebook file. Another approach for keeping a sort of index is John Kitchin’s org-db http://kitchingroup.cheme.cmu.edu/blog/2017/01/03/Find-stuff-in-org-mode-anywhere/ Current code: https://github.com/jkitchin/scimax/blob/master/org-db.el -- Anders Johansson
[O] Better org-indent alignment when using variable-pitch-mode
I suggest a possible change to org-indent--compute-prefixes to alleviate the problem. When using variable-pitch-mode (which I particularly like as I write a lot of prose in org-mode), the indent between headlines and body text can be off, depending on the difference in the width of asterisk and space characters in the variable-pitch font. A workaround is to customize the org-indent face to a monospace font to get it to match somewhat better, but this does not lead to perfect results. The indent of headlines and text is constructed like this: !!!##* Headline !!!Body text This is for a third-level headline where ! denotes invisible space, # invisible asterisks (in buffer text, but hidden here because org-indent by default enables org-hide-leading-stars), and * visible asterisks. This means we can still have misalignment since it is only the invisible characters (added as wrap-prefix and line-prefix with the org-indent face) that will (possibly if the user intervenes) be set to a monospace font. We can’t assume that the last two (I think) invisible (line-prefix) spaces before the body text will have the same width as the indent characters. One solution that seemed to work pretty well for me however was to force org-indent to use the same character (*) for all indents and let the face org-indent use the variable-pitch face (no customization of face org-indent). This results in: #* Headline ##!Body text That is, exactly the same characters (#=hidden asterisks, !=hidden space) preceding the beginning of the text in the headline and the body (the last character before the body text is given by org-indent-boundary-char, which is by default set to a space). So for this use-case we get a much better alignment with the prefix characters set to asterisk. That is changing line 155 in org-indent, org-indent--compute-prefixes from: (concat (make-string (+ n indentation) ?\s) to: (concat (make-string (+ n indentation) ?*) If people configure the org-indent face in some other way (with visible characters for example, although I don’t know why this would be a good idea) this could be a bad idea though. Could it perhaps be made an option? What do you think? A case which won’t be completely solved by this however, is if the headline faces are customized to be larger than text (some like to do that for a more word-processor-like editing experience). Then the “* ” in the beginning of the headline will probably be taking up more space than any character set for indent with a default size. There may have been other cases I overlooked as well. An earlier discussion of this was here: https://lists.gnu.org/archive/html/emacs-orgmode/2014-12/msg00014.html -- Anders Johansson
[O] Bug? Encoding trouble in org-id-locations-load
Hi, I use org-id and got some surprising reports of duplicate IDs. It seems that the issue is that one of my files containing IDs has a filename consisting of some non-ascii characters (a Swedish ä). When this filename is read in from ~org-id-locations-file~ in ~org-id-locations-load~ the ä is interpreted as “\303\244”. But ~org-id-files~ and ~org-id-locations~ is also populated from currently open files, so I usually get that file represented twice as two different files in ~org-id-files~. So I get both “j-allmänt.org” and j-allm\303\244nt.org“. Both seem to be scanned correctly by ~org-id-update-id-locations~ and this results in duplicate IDs. I tried changing the call to ~insert-file-contents-literally~ in ~org-id-locations-load~ to just ~insert-file-contents~ and this seemed to fix the behaviour (as correct decoding is done then?). I don’t know if there are other unwanted effects from using ~insert-file-contents~, but otherwise this seems to me to be a more correct solution. Cheers, Anders Johansson
[O] [PATCH 1/1] org.el: Make faces org-quote and org-verse be appended
This means fontification of emphasis, links etc. is kept in quote and verse blocks even with org-fontify-quote-and-verse-blocks non-nil. TINYCHANGE --- lisp/org.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 3290a2b..282c078 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5934,9 +5934,9 @@ by a #." '(org-block))) ; end of source block ((not org-fontify-quote-and-verse-blocks)) ((string= block-type "quote") - (add-text-properties beg1 (min (point-max) (1+ end1)) '(face org-quote))) + (add-face-text-property beg1 (min (point-max) (1+ end1)) 'org-quote t)) ((string= block-type "verse") - (add-text-properties beg1 (min (point-max) (1+ end1)) '(face org-verse + (add-face-text-property beg1 (min (point-max) (1+ end1)) 'org-verse t))) (add-text-properties beg beg1 '(face org-block-begin-line)) (add-text-properties (min (point-max) (1+ end)) (min (point-max) (1+ end1)) '(face org-block-end-line)) -- 2.11.1
[O] Why does quote and verse block fontification have to override local fontification?
Hi, I want to fontify quote blocks (i use them a lot for note taking and writing paper) so that they stand out (and so I enable org-fontify-quote-and-verse-blocks) but it would be useful to preserve the local fontification of emphasis, links etc. inside quote blocks. This can easily be achieved with a patch like this org.el: 6096,6099c6096,6099 < ((string= block-type "quote") < (add-face-text-property beg1 (min (point-max) (1+ end1)) 'org-quote t)) < ((string= block-type "verse") < (add-face-text-property beg1 (min (point-max) (1+ end1)) 'org-verse t))) --- ((string= block-type "quote") (add-text-properties beg1 (min (point-max) (1+ end1)) '(face org-quote))) ((string= block-type "verse") (add-text-properties beg1 (min (point-max) (1+ end1)) '(face org-verse In this invocation add-face-text-property appends org-quote to the face property, and hence all other fontification is kept. Does this interfere with something else or what people would expect? In my view it looks much better, but I guess that can depend on the appearance of org-quote and org-verse (I have them as font-lock-comment-face, just a slightly different colour, on top of which italics etc. look good). -- Anders Johansson
Re: [O] Some projects
Anders Johansson gmail.com> writes: > I hacked together something like this a while ago when I needed to add > inline-comments that would later be exported as odt-comments (but I also > made it work for latex). > > I chose to implement it via a unicode-bracket ❰❙❱, like this: > > ❰Simple comment❱ > ❰Text that is commented on❙Comment❱ > ❰[Author] Simple comment❱ > ❰Commented text❙[Author] Comment❱ > > These are inserted with a custom command to make it easy (including an > author-history-list selectable with helm). > > I've put it up in a gist if anyone finds it useful: > https://gist.github.com/andersjohansson/6baa1e42ad4d7353e125 > > Cheers, > Anders Johansson > But taking a look at org-annotate (https://github.com/girzel/org-annotate) i see that it is a much more complete first attempt at a solution. Stupid that I didn't find that when I needed it this summer. /Anders Johansson
Re: [O] Some projects
Marcin Borkowski mbork.pl> writes: > > > On 2015-10-25, at 19:12, Nicolas Goaziou nicolasgoaziou.fr> wrote: > > > Fabrice Popineau supelec.fr> writes: > > > >> 2015-10-25 18:57 GMT+01:00 Thomas S. Dye tsdye.com>: > >> > >> > >>> would suggest an alternate wording. In this case, it would be super > >>> helpful to have a function that replaced annotated text with the > >>> annotation, so the author could easily accept the editor's suggestion. > >>> > >>> > >> In this case, it would be nice if annotations could have an author > >> too! > > > > The full proposal was at > > <http://permalink.gmane.org/gmane.emacs.orgmode/97468> but it didn't get > > much positive feedback. Therefore I suggested a simplified version, with > > a single author. > > I like it! I'm not sure I would use it a lot (and definitely not with > other people - there are not many people using Org-mode in my > institution, in fact I guess I'm the only one), but it does seem > useful. > > One thing: there /must/ be a way to export annotations. For LaTeX, the > todonotes package (https://www.ctan.org/pkg/todonotes) seems a natural > choice. > I hacked together something like this a while ago when I needed to add inline-comments that would later be exported as odt-comments (but I also made it work for latex). I chose to implement it via a unicode-bracket ❰❙❱, like this: ❰Simple comment❱ ❰Text that is commented on❙Comment❱ ❰[Author] Simple comment❱ ❰Commented text❙[Author] Comment❱ These are inserted with a custom command to make it easy (including an author-history-list selectable with helm). I've put it up in a gist if anyone finds it useful: https://gist.github.com/andersjohansson/6baa1e42ad4d7353e125 Cheers, Anders Johansson
Re: [O] Organizing and taming hectic Academia work (faculty viewpoint)? Tips or a good guides sought after :)
Xebar Saram zeltakc at gmail.com writes:
Hi all
Im a young assistant professor (in humanities and thus my horrific coding
skills..basically non ) and having been using orgmode for a year or two now.
I love orgmode dearly and use it mainly for note taking, lists etc
I am aware of the fantastic orgmode capabilities that could benefit me
greatly such as exporting, email tie-ins, beamer support, organizing my
bibliography (i have switched to a .bib file recently for my references),
agenda capabilities and so much moreand have tried several of these with
mild success.
unfortunately (and this maybe due to me not being very technical and lack
of coding skills) i still feel like im really not using orgmode to its
potential and still feel miserably lost in terms of organizing my work in
academia from all aspects.
i am looking for 2 things really:
1. as i said in the post topic a good guide if anyone is aware of or
detailed examples of using org in Academia (mainly aimed at faculty :))
2. related to that as a young researcher with multiple students, paper
writing, grant applications, department duties, endless TODOS, endless email
i would really be grateful for even non org specific tips on how other
people organize all this to make life more..well..organized :)
thanks alot in advance and sorry for the long mail
best
Z
I have to collaborate in Word but can at least start out writing my papers
in org-mode. I use Zotero for reference management and with the help of
several tools I can insert citations that can be formatted by Zotero in the
final version of the paper.
Here is my configuration:
https://gist.github.com/andersjohansson/324a01364eb5a5435c65
It uses Erik Hetzners org-zotxt and org-pdcite, ox-odt for converting to
odt, and then the tool http://zotero-odf-scan.github.io/zotero-odf-scan/ to
convert the generated citations like { | Smith, (2012) | |
|zu:2433:WQVBH98K} to Zotero citation marks in the odt-file.
Perhaps someone else will have use for this as well,
Cheers,
Anders Johansson
[O] Bug: Inlinetask bodies begun with a link (or other invisible elements) are not folded correctly
Hi, I had an inlinetask that started with a link, like this: Inlinetask heading [[file:filename][link desc]] some text. Some more text. END It didn't fold on TAB. Looking into org-inlinetask-toggle-visibility I see ;; Inlinetask was folded: expand it. ((get-char-property (1+ start) 'invisible) which is true for all kind of chars that are invisible I guess (even if the value of the 'invisible property is 'org-link) A quick test showed that adding a test for if the hiding is outline worked: ;; Inlinetask was folded: expand it. ((eq 'outline (get-char-property (1+ start) 'invisible)) I don't know if this has any unwanted side-effects though. Or if this should be avoided for some reason. This is using the latest org from git. Cheers, Anders Johansson Emacs : GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.9) of 2015-03-21 on kissel, modified by Debian Package: Org-mode version 8.2.10 (release_8.2.10-417-g0e5069 @ /home/aj/kodat/elisp/org-mode/)
Re: [O] Bug? Changed behaviour makes tags in headlines without a title parsed as the title
Den 2015-04-10 18:24, Nicolas Goaziou skrev: Hello, Anders Johansson mejlaande...@gmail.com writes: I have been using degenerate inlinetasks with empty titles but many tags for implementing a kind of coding scheme for coding texts for qualitative data analysis. Like this: - Some text that I want to tag (The inlinetask in my scheme refers to the paragraph above it) *** :tag1:tag2:tag3: Other text (no inlinetask-END, mostly) - Building org from the master branch, I recently noticed a changed behaviour in that these tags as are not parsed as tags but instead as the title, meaning my exports don't work as expected (and possibly other things, but searching for tags etc.doesn't seem to be affected. Those functions don't use org-element perhaps?). Indeed. As far as I could see, this comes from the changes in commit 98ee73: org-element: Avoid `org-element-parse-secondary-string', where tags are matched with the regexp: (org-re [ \t]+\\(:[[:alnum:]_@#%:]+:\\)[ \t]*$) which needs whitespace after the non-existent title. I haven't checked all the different changes going on in org-element though. I don't know if this changed behaviour is intended. Otherwise I guess it's a bug. Empty headings are a pathological case. What if I want to write *** :title: ? Your interpretation prevents that. Of course, Org is expected to be consistent. However I'm not convinced supporting empty headlines with tags is a good thing. Regards, Great, that sounds reasonable. I guess I'll change my practice then. Cheers,
[O] Bug? Changed behaviour makes tags in headlines without a title parsed as the title
Hi, I have been using degenerate inlinetasks with empty titles but many tags for implementing a kind of coding scheme for coding texts for qualitative data analysis. Like this: - Some text that I want to tag (The inlinetask in my scheme refers to the paragraph above it) *** :tag1:tag2:tag3: Other text (no inlinetask-END, mostly) - Building org from the master branch, I recently noticed a changed behaviour in that these tags as are not parsed as tags but instead as the title, meaning my exports don't work as expected (and possibly other things, but searching for tags etc.doesn't seem to be affected. Those functions don't use org-element perhaps?). As far as I could see, this comes from the changes in commit 98ee73: org-element: Avoid `org-element-parse-secondary-string', where tags are matched with the regexp: (org-re [ \t]+\\(:[[:alnum:]_@#%:]+:\\)[ \t]*$) which needs whitespace after the non-existent title. I haven't checked all the different changes going on in org-element though. I don't know if this changed behaviour is intended. Otherwise I guess it's a bug. Cheers,
Re: [O] [Bug] org-indent-mode underindents body in variable-pitch-mode
Anders Johansson mejlaandersj at gmail.com writes: Anders Johansson mejlaandersj at gmail.com writes: Tobias Getzner tobias.getzner at gmx.de writes: Hello, After updating to Emacs 24.4 and org-mode 20141020, I’ve noticed that org-indent-mode now underindents item bodies when variable-pitch-mode is used. I. e., in the following document, «lorem», «ipsum», and «etc.» will fall successively short of the item’s respective indent level. * first lorem ** second ipsum *** third etc. My last working version was 20140915 on Emacs 24.3. Kind regards, Tobias Hi, I'm experiencing the exact same problem. Debugging might be a little tricky if it involves changes in both Emacs and org. I think the problem depends on the text-properties wrap-prefix and line-prefix being set to a number of spaces and a number of stars, respectively, in headlines and only spaces in body text. When variable-pitch fonts don't have as wide stars as spaces we get a mismatch. But I don't know how this can have worked better before. Doesn't anyone else use variable-pitch-mode for org and suffer from this? Cheers, Anders Johansson Hi again, Ok, I have tracked it down a bit. It must be due to changes in Emacs outside of org. I tried with the combination Emacs 24.3.1 and org: Org-mode version 8.2.10 (8.2.10-20-gaa65ac-elpa at /home/aj/.emacs.d/elpa/org-20141124/) There it works. But never in 24.4, regardless of org version. How Emacs handles line-prefix and wrap-prefix must have changed in some way. I don't know if that is a bug in Emacs or something org should accommodate for though. Cheers, Anders Johansson And then it worked. Ok, I'm quite sure this depends on the changes discussed here: http://lists.gnu.org/archive/html/bug-gnu-emacs/2013-08/msg00776.html which (as far as I understand it) means that wrap-prefix (and line-prefix?) now uses the currently active face (or something like that) instead of default. The working indent in variable-pitch-mode thus depended on wrap-prefix and line-prefix having the wrong (default) face instead of the variable-pitch face that is now used. One workaround is to customize the face org-indent in some way to make it roughly match the width of your stars: (set-face-attribute 'org-indent nil :family YOUR_DEFAULT_FAMILY) This worked ok for me. Just inheriting default didn't seem to work. I think that is overridden by variable-pitch mode. I don't know if this could be generalized in a good way that could be put into org-mode since the desired width (or family) depends on each users configuration. One possibility could be if it would be possible to get the pixel-width of a star in some way and then set line-prefix to a correct pixel-width (multiple of this). Cheers, Anders Johansson
Re: [O] [Bug] org-indent-mode underindents body in variable-pitch-mode
Tobias Getzner tobias.getzner at gmx.de writes: Hello, After updating to Emacs 24.4 and org-mode 20141020, I’ve noticed that org-indent-mode now underindents item bodies when variable-pitch-mode is used. I. e., in the following document, «lorem», «ipsum», and «etc.» will fall successively short of the item’s respective indent level. * first lorem ** second ipsum *** third etc. My last working version was 20140915 on Emacs 24.3. Kind regards, Tobias Hi, I'm experiencing the exact same problem. Debugging might be a little tricky if it involves changes in both Emacs and org. I think the problem depends on the text-properties wrap-prefix and line-prefix being set to a number of spaces and a number of stars, respectively, in headlines and only spaces in body text. When variable-pitch fonts don't have as wide stars as spaces we get a mismatch. But I don't know how this can have worked better before. Doesn't anyone else use variable-pitch-mode for org and suffer from this? Cheers, Anders Johansson
Re: [O] [Bug] org-indent-mode underindents body in variable-pitch-mode
Anders Johansson mejlaandersj at gmail.com writes: Tobias Getzner tobias.getzner at gmx.de writes: Hello, After updating to Emacs 24.4 and org-mode 20141020, I’ve noticed that org-indent-mode now underindents item bodies when variable-pitch-mode is used. I. e., in the following document, «lorem», «ipsum», and «etc.» will fall successively short of the item’s respective indent level. * first lorem ** second ipsum *** third etc. My last working version was 20140915 on Emacs 24.3. Kind regards, Tobias Hi, I'm experiencing the exact same problem. Debugging might be a little tricky if it involves changes in both Emacs and org. I think the problem depends on the text-properties wrap-prefix and line-prefix being set to a number of spaces and a number of stars, respectively, in headlines and only spaces in body text. When variable-pitch fonts don't have as wide stars as spaces we get a mismatch. But I don't know how this can have worked better before. Doesn't anyone else use variable-pitch-mode for org and suffer from this? Cheers, Anders Johansson Hi again, Ok, I have tracked it down a bit. It must be due to changes in Emacs outside of org. I tried with the combination Emacs 24.3.1 and org: Org-mode version 8.2.10 (8.2.10-20-gaa65ac-elpa @ /home/aj/.emacs.d/elpa/org-20141124/) There it works. But never in 24.4, regardless of org version. How Emacs handles line-prefix and wrap-prefix must have changed in some way. I don't know if that is a bug in Emacs or something org should accommodate for though. Cheers, Anders Johansson And then it worked.
[O] Suggestion, ox-latex: Perhaps a line break should be inserted into low-level headlines
Hi,
Currently low-level headlines in latex export to:
\item HEADLINE-TEXT
\label{sec-1-3}
CONTENTS
This makes the headline text and contents go together in the same line
with just a space in between. I think there should be a line break or
paragraph break between them.
Something like
\item HEADLINE-TEXT
\label{sec-1-3}\\
CONTENTS
Or:
\item HEADLINE-TEXT
\label{sec-1-3}
CONTENTS
The first variant means modifying the headline-label variable (or
something like that) in org-latex-headline. The second is less messy to
implement.
Cheers,
Anders Johansson
Re: [O] Suggestion, ox-latex: Perhaps a line break should be inserted into low-level headlines
Nicolas Goaziou writes:
Hello,
Anders Johansson mejlaande...@gmail.com writes:
Currently low-level headlines in latex export to:
\item HEADLINE-TEXT
\label{sec-1-3}
CONTENTS
Not really. Export respects blank lines between the headline an its
contents. So
* Headline
Contents
will be exported as
\item Headline
\label{whatever}
Contents
This makes the headline text and contents go together in the same line
with just a space in between. I think there should be a line break or
paragraph break between them.
I don't think is should be mandatory.
* Low-level-headline ---
Some conents
is meant to be inserted on the same line.
Regards,
Hi,
I see. This just didn't really fit with my use-case. I seldom decide
before what will be considered low-level headlines and make them
special. For my large generated documents I'll hack something together
then.
I guess that even if it's not mandatory it could always be an option :-)
Cheers,
[O] Bug in org-paste-subtree
Hi, The force-level check in org-paste-subtree seems to contain a small bug. If I try to paste a subtree at the end of a line only containing some stars, I get an error Wrong type argument: number-or-marker-p, nil. The problem is (- (match-end 1) (match-end 1)) (see below) We have no subexpression to match, it should be zero. (force-level (cond (level (prefix-numeric-value level)) ((and (looking-at [ \t]*$) (string-match ^\\*+$ (buffer-substring (point-at-bol) (point (- (match-end 1) (match-beginning 1))) ((and (bolp) (looking-at org-outline-regexp)) (- (match-end 0) (point) 1 Cheers, Anders Johansson
[O] Bug: ob-ditaa fails in generating pdf correctly
Hi, Example input: #+header: :eps t #+header: :file hello.pdf #+BEGIN_SRC ditaa +--+ | | |Hello | | | +--+ #+END_SRC When using the above code (which I guessed should be the correct way) with ob-ditaa to produce a pdf (through DitaaEps - epstopdf) it fails in producing the pdf correctly and instead writes an eps to hello.pdf. This isn't surprising, looking at the code where cmd should be constructed to produce the eps as an intermediary file in /tmp (which is expected in the construction of pdf-cmd) but doesn't. An ugly patch to fix it is attached (this is ugly because it repeats the line: (org-babel-process-file-name (concat in-file .eps)) ) Cheers, Anders Johansson --- /home/aj/H\303\244mtningar/ob-ditaa.el2014-05-22 17:15:35.489071991 +0200 +++ ob-ditaa.el 2014-05-22 17:08:46.617089186 +0200 @@ -90,6 +90,12 @@ (java (cdr (assoc :java params))) (in-file (org-babel-temp-file ditaa-)) (eps (cdr (assoc :eps params))) +(pdf-cmd (when (and (or (string= (file-name-extension out-file) pdf) +(cdr (assoc :pdf params + (concat +epstopdf + (org-babel-process-file-name (concat in-file .eps)) + -o= (org-babel-process-file-name out-file (cmd (concat org-babel-ditaa-java-cmd java org-ditaa-jar-option (shell-quote-argument @@ -97,13 +103,10 @@ (if eps org-ditaa-eps-jar-path org-ditaa-jar-path))) cmdline (org-babel-process-file-name in-file) - (org-babel-process-file-name out-file))) -(pdf-cmd (when (and (or (string= (file-name-extension out-file) pdf) -(cdr (assoc :pdf params - (concat -epstopdf - (org-babel-process-file-name (concat in-file .eps)) - -o= (org-babel-process-file-name out-file) + (if pdf-cmd + (org-babel-process-file-name (concat in-file .eps)) + (org-babel-process-file-name out-file +) (unless (file-exists-p org-ditaa-jar-path) (error Could not find ditaa.jar at %s org-ditaa-jar-path)) (with-temp-file in-file (insert body))
[O] Bug: org-beamer-select-environment (ox-beamer.el) should temporarily disable persistent tags
Hi, Having some persistent tags configured (in org-tag-persistent-alist) means those get added to the selection window for org-beamer-select-environment possibly interfering with the selection of beamer environments. These tags should be explicitly disabled in the let in org-beamer-select-environment: (org-tag-persistent-alist nil) Cheers, Anders Johansson
Re: [O] Bug? org-set-tags never uses ido
A hack to get ido selection for multiple tags. It uses ido-completing-read-multiple (available here and included below: https://gist.github.com/mgalgs/1329188) to allow for completing one tag at a time and ending it by typing :. I haven't tested it much and it might possibly break things (or most certainly it's implemented in an ugly way). Perhaps someone more than me will find it useful. Cheers, Anders (defadvice org-icompleting-read (around org-use-ido-for-tags (prompt coll optional pred reqm initial hist def) activate) Advised to use ido for multiple completion of tags (setq ad-return-value (if (string= Tags: prompt) (mapconcat 'identity (ido-completing-read-multiple prompt (mapcan 'copy-list org-last-tags-completion-table) pred reqm initial hist def :) :) ad-do-it))) (defun ido-completing-read-multiple (prompt choices optional predicate require-match initial-input hist def sentinel) Read multiple items with ido-completing-read. Reading stops when the user enters SENTINEL. By default, SENTINEL is \*done*\. SENTINEL is disambiguated with clashing completions by appending _ to SENTINEL until it becomes unique. So if there are multiple values that look like SENTINEL, the one with the most _ at the end is the actual sentinel value. See documentation for `ido-completing-read' for details on the other parameters. (let ((sentinel (if sentinel sentinel *done*)) (done-reading nil) (res ())) ;; uniquify the SENTINEL value (while (find sentinel choices) (setq sentinel (concat sentinel _))) (setq choices (cons sentinel choices)) ;; read some choices (while (not done-reading) (setq this-choice (ido-completing-read prompt choices predicate require-match initial-input hist def)) (if (equal this-choice sentinel) (setq done-reading t) (setq res (cons this-choice res ;; return the result res ))
[O] org-entities: Another issue [was: org-entities: why \lang instead of \langle?]
(I continue in the same thread as this is related) org-entities has: (slash / nil / / / /) A LaTeX user entering \slash would probably expect to have this exported as \slash (which produces a breaking /, not the same thing as just entering / in LaTeX). So it should rather be: (slash \\slash nil / / / /) Could this be changed without breaking people's documents? Cheers, Anders Johansson
Re: [O] Bug: Problems with sub/super-script when using: org-cdlatex + org-pretty-entities + org-catch-invisible-edits
2014-02-23 16:20, Anders Johansson wrote:
Hi,
I used the configuration:
org-catch-invisible-edits 'show
org-pretty-entities t
together with org-cdlatex. This breaks the insertion of subscripts
and superscripts through org-cdlatex because _{} is fontified and the
{} are hidden so typing for example: a _ bc results in a_{b}c (or
sometimes a_bc, but should be a_{bc}) and gives the message
Unfolding invisible region around point before editing.
Setting org-catch-invisible-edits to nil let's cdlatex do it's work
so I guess an easy solution would be to let that in
org-cdlatex-underscore-caret.
Hi,
I realized that my solution won't work since
org-check-before-invisible-edit does it's work after
org-cdlatex-underscore-caret has called cdlatex-sub-superscript
and inserted _{}.
Maybe then org-catch-invisible-edits should be nil all the time in
org-cdlatex-mode? But this would be unexpected. Maybe this can be
treated as a special case in org-check-before-invisible-edit in some
way?
Digging into it some more it's actually the pretty entities folding
which is the problem, regardless of org-check-before-invisible-edit. The
cursor jumps out of the {}-brackets after the first character, when the
hiding/folding is done. I have no idea what should be done about this.
In case anyone has the same problem, my current workaraound for this is
disabling pretty entities for sub/superscript when using cdlatex:
(add-hook 'cdlatex-mode-hook
(lambda () (when (eq major-mode 'org-mode)
(make-local-variable 'org-pretty-entities-include-sub-superscripts)
(setq org-pretty-entities-include-sub-superscripts nil
Cheers,
Anders Johansson
[O] Suggestion for improvement, org-read-date: prefer-closest-date instead of only prefer-future*
Hi. I sometimes use timestamps for scheduling, sometimes for logging things (manually and a few days later). It would be pretty convenient if one could define a preferred range of time for incomplete dates, instead of just prefer-future or default to current month or year. Example: It's 2013-12-25 and I want to schedule something for 2014-01-05 and add a log timestamp for something last week, 2013-12-20. It would be convenient if entering 01-05 and 12-20 would do the right thing regardless of the setting of org-read-date-prefer-future. This could be to prefer the closest date, but even more configurability would be added if a sliding range of dates along a year were preferred. For example, 9 months into the future and 3 in the past so that entering 9-26 would give 2013-09-26 and entering 9-24 would give 2014-09-24. I think something like this is reasonable as it might be more common to enter a date a few months back than one almost a year into the future. I don't know if this applies as much to the case of only entering a day number though, maybe there entering -x covers the case of wanting to enter a date a few days back and preferring the future otherwise. Perhaps this would add to much complexity to org-read-date, with little gain, and there may certainly be complications I haven't thought of, but I think it would be an interesting option for many people. Cheers, Anders Johansson
Re: [O] Bug? org-set-tags never uses ido
Looking at this again I realize that the reason for this behavior is that we want completion of possibly several tags. This is what the org-tags-completion-function does when supplied as the second argument of completing-read. As ido-completing-read and org-iswitchb-completing-read doesn't support this, they are not used. I don't know if there would be a way of getting both ido and multiple input. As it is now though, it's pretty meaningless to have that call to org-icompleting-read there as it never gets activated. It could as well be: (completing-read Tags: 'org-tags-completion-function nil nil current 'org-tags-history) Cheers, Anders Johansson 2013-11-01 02:33, Eric Abrahamsen skrev: Anders Johansson mejlaande...@gmail.com writes: Greetings, I want to use ido everywhere and wanted to know why this doesn't seem to work for setting org-mode tags (it never has for me). Using edebug to step through the call to org-icompleting-read which org-set-tags does I can see that it never gets to using ido since the last condition below is false: org.el:10147-10150 (package repository version 20131028): (if (and org-completion-use-ido (fboundp 'ido-completing-read) (boundp 'ido-mode) ido-mode (listp (second args))) This is not strange, since org-icompleting-read is called like this in org-set-tags: org.el:14519-14521 (org-icompleting-read Tags: 'org-tags-completion-function nil nil current 'org-tags-history)) Hmm, shouldn't that 'org-tags-completion-function be replaced with org-last-tags-completion-table? A quick test shows that works, and from glancing at the code it seems like org-last-tags-completion-table should hold the proper assortment of tags... E ido apparently needs a list of possible completions, not a single symbol. I don't understand much more of this really. Is it a bug? Have I misunderstood something? Greetings, Anders Johansson
Re: [O] Bug? org-set-tags never uses ido
2014-03-05 01:20, Samuel Wales wrote: There are several packages that allow ido to work everywhere. The one I use, ido-hacks, works fine for tags out of the box. A quick look at ido-hacks.el here: https://github.com/scottjad/ido-hacks/blob/master/ido-hacks.el suggests that this doesn't really solve the problem of being able to select multiple tags separated by colon at the same time with ido. I haven't tried it but the docstring for the advice of completing-read says: Advice `completing-read' to always use `ido-read-internal', unless `this-command' has a (ido ignore) property or the inherit-input-method argument is non-nil or the collection argument is a function (which ido can't handle). which seems to suggest that passing 'org-tags-completion-function as the second argument (collection) to the advised completing-read wouldn't use ido in this case either Cheers, Anders Johansson
[O] org-entities: why \lang instead of \langle?
Hi, I noticed that in org-entities these symbols are defined: (lang \\langle t lang; ⟨) (rang \\rangle t rang; ⟩) But nothing for langle and rangle. I guess it seems pretty confusing when you try to use the latex-macros you are used to. Maybe these aliases could also be added, like what is done for e.g. clubs: (langle \\langle t lang; ⟨) (rangle \\rangle t rang; ⟩) Cheers, Anders Johansson
[O] Bug: Problems with sub/super-script when using: org-cdlatex + org-pretty-entities + org-catch-invisible-edits
Hi,
I used the configuration:
org-catch-invisible-edits 'show
org-pretty-entities t
together with org-cdlatex. This breaks the insertion of subscripts and
superscripts through org-cdlatex because _{} is fontified and the {} are
hidden so typing for example: a _ bc results in a_{b}c (or sometimes
a_bc, but should be a_{bc}) and gives the message Unfolding
invisible region around point before editing.
Setting org-catch-invisible-edits to nil let's cdlatex do it's work so I
guess an easy solution would be to let that in
org-cdlatex-underscore-caret.
Cheers,
Anders Johansson
Re: [O] Bug: Problems with sub/super-script when using: org-cdlatex + org-pretty-entities + org-catch-invisible-edits
Hi,
I used the configuration:
org-catch-invisible-edits 'show
org-pretty-entities t
together with org-cdlatex. This breaks the insertion of subscripts and
superscripts through org-cdlatex because _{} is fontified and the {}
are hidden so typing for example: a _ bc results in a_{b}c (or
sometimes a_bc, but should be a_{bc}) and gives the message
Unfolding invisible region around point before editing.
Setting org-catch-invisible-edits to nil let's cdlatex do it's work so
I guess an easy solution would be to let that in
org-cdlatex-underscore-caret.
Cheers,
Anders Johansson
Hi,
I realized that my solution won't work since
org-check-before-invisible-edit does it's work after
org-cdlatex-underscore-caret has called cdlatex-sub-superscript and
inserted _{}.
Maybe then org-catch-invisible-edits should be nil all the time in
org-cdlatex-mode? But this would be unexpected. Maybe this can be
treated as a special case in org-check-before-invisible-edit in some way?
Cheers,
Andes Johansson
Re: [O] Bug: Problems with sub/super-script when using: org-cdlatex + org-pretty-entities + org-catch-invisible-edits
Hi,
I used the configuration:
org-catch-invisible-edits 'show
org-pretty-entities t
together with org-cdlatex. This breaks the insertion of subscripts
and superscripts through org-cdlatex because _{} is fontified and the
{} are hidden so typing for example: a _ bc results in a_{b}c (or
sometimes a_bc, but should be a_{bc}) and gives the message
Unfolding invisible region around point before editing.
Setting org-catch-invisible-edits to nil let's cdlatex do it's work
so I guess an easy solution would be to let that in
org-cdlatex-underscore-caret.
Hi,
I realized that my solution won't work since
org-check-before-invisible-edit does it's work after
org-cdlatex-underscore-caret has called cdlatex-sub-superscript
and inserted _{}.
Maybe then org-catch-invisible-edits should be nil all the time in
org-cdlatex-mode? But this would be unexpected. Maybe this can be
treated as a special case in org-check-before-invisible-edit in some
way?
Digging into it some more it's actually the pretty entities folding
which is the problem, regardless of org-check-before-invisible-edit. The
cursor jumps out of the {}-brackets after the first character, when the
hiding/folding is done. I have no idea what should be done about this.
Cheers,
Anders Johansson
[O] Suggestion/bug: Parse inlinetask END with level sensitivity
Hi. I recently started using inlinetasks to be able to tag and comment long texts (a kind of simple qualitative data analysis). I thought that I would be able to use both tasks with and without an END line interchangeably: *** inlinetask without end some text *** inlinetask with end text inside inlinetask *** END The problem (not so surprising really) is that the parser finds the END of the second inlinetask and makes them nested in an export. I thought this could be solved with using different numbers of stars for tasks with and without END, judging from these lines in org-inlinetask.el: ;; If you need to have a time planning line (DEADLINE etc), drawers, ;; for example LOGBOOK of PROPERTIES, or even normal text as part of ;; the inline task, you must add an END headline with the same ;; number of stars. But the search for END in the parser is actually star-insensitive so this didn't solve my problem either. I suggest requiring the END-line to contain as many stars as it's beginning line by doing something like this (there is certainly a cleaner way doing it) to org-element-inlinetask-parser: @@ -972,7 +972,9 @@ plist (task-end (save-excursion (end-of-line) - (and (re-search-forward ^\\*+ END limit t) + (and (re-search-forward + (concat ^ (mapconcat 'identity (make-list (nth 1 components) \\*) ) END) + limit t) (match-beginning 0 (contents-begin (progn (forward-line) (and task-end ( (point) task-end) (point But perhaps this is too unstable? (Although it could be expected from the comments above). Cheers, Anders Johansson
Re: [O] Suggestion/bug: Parse inlinetask END with level sensitivity
Great! Taking a look at your solution I realize where the bug lay as well. Level is unimportant, it just scanned too long previously (it should only look if the next headline contains END, not look for the next headline with END). Regards, Anders Johansson Den mån 17 feb 2014 23:05:02 skrev Nicolas Goaziou: Hello, Anders Johansson mejlaande...@gmail.com writes: I thought that I would be able to use both tasks with and without an END line interchangeably: *** inlinetask without end some text *** inlinetask with end text inside inlinetask *** END The problem (not so surprising really) is that the parser finds the END of the second inlinetask and makes them nested in an export. This should be fixed in maint. Thank you for reporting it. For the record, inlinetasks cannot be nested, and the number of stars is not meaningful, as long as it is greater than `org-inlinetask-min-level'. Regards,
[O] Bug: org-beamer-select-environment (ox-beamer.el) assumes org-use-fast-tag-selection is on
Hi, I recently set org-use-fast-tag-selection to nil in my configuration. This meant org-beamer-select-environment stopped working since it assumes that org-set-tags will launch the fast-tag-selection mechanism when it has set org-tag-alist to it's special value. Fix: Explicitly set org-use-fast-tag-selection to t in the let*-construct in org-use-fast-tag-selection, as is now done with org-fast-tag-selection-single-key. Greetings, Anders Johansson
[O] Bug? org-set-tags never uses ido
Greetings, I want to use ido everywhere and wanted to know why this doesn't seem to work for setting org-mode tags (it never has for me). Using edebug to step through the call to org-icompleting-read which org-set-tags does I can see that it never gets to using ido since the last condition below is false: org.el:10147-10150 (package repository version 20131028): (if (and org-completion-use-ido (fboundp 'ido-completing-read) (boundp 'ido-mode) ido-mode (listp (second args))) This is not strange, since org-icompleting-read is called like this in org-set-tags: org.el:14519-14521 (org-icompleting-read Tags: 'org-tags-completion-function nil nil current 'org-tags-history)) ido apparently needs a list of possible completions, not a single symbol. I don't understand much more of this really. Is it a bug? Have I misunderstood something? Greetings, Anders Johansson
[O] Suggestion: Weektree
Greetings, It's very nice to keep a journal in a datetree (using the capture mechanism) but for my uses it would actually be even more useful to keep it in a /weektree/. Something like this: * 2013 ** W39 (September 23 - September 29) *** 2013-09-23 Monday note 1 note 2 *** 2013-09-24 Tuesday *** 2013-09-25 Wednesday ** W52 (December 23 - December 29) *** 2013-09-25 Wednesday Christmas, no work done. * 2014 ** W1 (December 30 - January 5) *** 2013-09-31 Tuesday New year's eve party! (with names of months and days localised as usual) Motivations: This would keep working weeks together (not broken over month boundaries). At least here in Sweden it's pretty common to refer to weeks by number so this would perhaps be useful for that reason. Problems: My suggestion above uses ISO-weeks (http://en.wikipedia.org/wiki/ISO_week_date), maybe other conventions should also be an option (http://en.wikipedia.org/wiki/Seven-day_week#Week_numbering). Implementation: I tried to see if this could be implemented on top of the datetree code, but as far as I could tell, to much of that mechanism was hardcoded into months etc. The task seemed to difficult for me. If someone else thinks this is a good idea I think there are more people than me that would find it quite useful though. Greetings from Sweden, Anders Johansson
[O] Bug: Setting HTML_INCLUDE_STYLE: nil doesn't work [8.0.3 (8.0.3-32-g0c789f-elpa @ /home/aj/.emacs.d/elpa/org-20130617/)]
I put: #+HTML_INCLUDE_STYLE: nil at the top of my org-file and expect the exported html file to not include the standard styles in it's header (documentation section 12.6.9 CSS support). This does not work and the styles are included as usual. A quick debugging with edebug reveals that nil is interpreted as a string, nil, in the info-plist and therefore evaluates as true in the check in org-html--build-head: (when (plist-get info :html-head-include-default-style) (org-element-normalize-string org-html-style-default)) (from: ox-html.el:1448) Greetings, Anders Johansson Emacs : GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.6.4) of 2013-04-14 on marid, modified by Debian Package: Org-mode version 8.0.3 (8.0.3-32-g0c789f-elpa @ /home/aj/.emacs.d/elpa/org-20130617/) current state: == (setq org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) outline-minor-mode-hook '((lambda nil (local-set-key outline-mode-prefix-map) (define-key outline-minor-mode-map [(control tab)] (quote org-cycle)) (define-key outline-minor-mode-map [(shift tab)] (quote org-global-cycle))) ) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-occur-hook '(org-first-headline-recenter) org-metaup-hook '(org-babel-load-in-session-maybe) org-capture-after-finalize-hook '(orgaj-after-capture-options) org-confirm-shell-link-function 'yes-or-no-p org-speed-commands-user '((p ded/org-show-previous-heading-tidily) (n ded/org-show-next-heading-tidily)) org-startup-folded nil org-default-notes-file ~/org/notes.org org-startup-indented t org-after-todo-state-change-hook '(org-clock-out-if-current) org-capture-mode-hook '((lambda nil (remove-hook (quote org-capture-after-finalize-hook) (quote (lambda nil (delete-frame ) ) org-from-is-user-regexp \\Anders Johansson\\ org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-tags-column -90 org-agenda-before-write-hook '(org-agenda-add-entry-text) org-babel-pre-tangle-hook '(save-buffer) org-mode-hook '(#[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes) org-use-speed-commands t org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-hide-inline-tasks org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-M-RET-may-split-line '((headline . t) (default . t)) org-hide-emphasis-markers t org-confirm-elisp-link-function 'yes-or-no-p org-metadown-hook '(org-babel-pop-to-session-maybe) org-fontify-whole-heading-line t org-agenda-files '(~/org/attsalja.org ~/org/attkopa.org ~/org/sakerattfixa.org) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) org-after-todo-statistics-hook '(org-summary-todo) )
[O] Icalendar-export, priorities missing, possible bug
Hi, When I'm exporting to icalendar, the priorities of todo items (or perhaps any items) don't get carried through correctly. It always falls back to priority 5 (the default). After doing some edebugging I found that (string-match org-priority-regexp hd) [org-icalendar.el:539] never seems to match. This might be because 'hd' is group 4 True headline from the matching done with 'org-complex-heading-regexp' whereas group 3 according to this variable's docstring should hold the Priority cookie. I guess someone who has greater knowledge of the code could see if this is really the case and fix it. I can provide more debugging output and examples if needed and if others can't reproduce this. Greetings, Anders Johansson
Re: [O] Icalendar-export, priorities missing, possible bug
Hi, 2013-02-10 20:31, Nicolas Goaziou skrev: Hello, Anders Johansson mejlaande...@gmail.com writes: When I'm exporting to icalendar, the priorities of todo items (or perhaps any items) don't get carried through correctly. It always falls back to priority 5 (the default). After doing some edebugging I found that (string-match org-priority-regexp hd) [org-icalendar.el:539] never seems to match. This might be because 'hd' is group 4 True headline from the matching done with 'org-complex-heading-regexp' whereas group 3 according to this variable's docstring should hold the Priority cookie. I guess someone who has greater knowledge of the code could see if this is really the case and fix it. I can provide more debugging output and examples if needed and if others can't reproduce this. iCalendar export back-end has been rewritten. It is accessible from the git distribution of Org. I didn't check if that bug is still present though. Regards, Oh, that looks completely different. Taking a look at the newest git source, priority is now found like this (ox-icalendar.el) 705 (let ((pri (or (org-element-property :priority entry) 706 org-default-priority))) and assuming this is consistent with the new framework it should of course work, but I haven't tested yet. Funny that I found this problem now, using the less than a week old ELPA-package (20130204), when the new export framework was moved into core (commit 8dd2bf) just three days ago. Greetings, Anders Johansson
