Re: [O] Bug: Updating clocktable hides other content [9.0.5 (9.0.5-elpa @ /home/christof/.emacs.d/elpa/org-20170210/)]
Hi Christof, On Sun, Mar 26, 2017 at 7:37 AM, Christof Musik wrote: > > I have noticed some problems on updating a clocktable in a dynamic block. > If you update this table with org-dblock-update, then all content besides that table > is hidden. I have not found a way to show it again without opening the file again. It's a bug with :scope subtree. I had noticed this before but haven't come to fix it. You can just widen the buffer with C-x n w, or M-x widen. -- yashi
[O] Bug: Multiple bulk actions on the same task fails [9.0.5 (9.0.5-elpaplus @ /Users/links_world/.emacs.d/elpa/org-plus-contrib-20170210/)]
Using the following agenda file as an MWE:
* Incoming
** TODO Testing1
** TODO Testing2
** TODO Testing3
I ran org-agenda and pressed 't' to list all todo items. In the agenda
buffer I marked the task 'Testing1' with 'm' and performed a bulk action with
'B' and
added a tag with '+'. This completed successfully. If I mark "Testing1'
again with 'm' and use 'B' to perform a bulk action I receive an error:
user-error: Marker # for bulk
command is invalid
If I close out of the agenda buffer and open it back up again I am able
to perform a bulk action on any entry.
Emacs : GNU Emacs 25.1.1 (x86_64-apple-darwin16.4.0, NS appkit-1504.81 Version
10.12.3 (Build 16D32))
of 2017-03-02
Package: Org mode version 9.0.5 (9.0.5-elpaplus @
/Users/links_world/.emacs.d/elpa/org-plus-contrib-20170210/)
current state:
==
(setq
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
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-confirm-shell-link-function 'yes-or-no-p
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-pre-tangle-hook '(save-buffer)
org-mode-hook '((closure
(org-inlinetask-min-level buffer-face-mode-face
org-struct-menu org-last-state org-id-track-globally
org-clock-start-time texmathp-why remember-data-file
iswitchb-temp-buflist calc-embedded-open-mode
calc-embedded-open-formula calc-embedded-close-formula
align-mode-rules-list org-export-registered-backends t)
nil (add-hook (quote change-major-mode-hook) (quote
org-show-block-all) (quote append) (quote local)))
(closure (*this* org-babel-confirm-evaluate-answer-no t) nil
(add-hook (quote change-major-mode-hook) (quote
org-babel-show-result-all) (quote append) (quote local)))
#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-block-all append local] 5]
#[0 "\300\301\302\303\304$\207" [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-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-confirm-elisp-link-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-link-parameters '(("id" :follow org-id-open) ("rmail" :follow
org-rmail-open :store org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link)
("info" :follow org-info-open :export org-info-export
:store org-info-store-link)
("gnus" :follow org-gnus-open :store org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export
:complete org-bbdb-complete-link :store
org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("file+sys")
("file+emacs") ("doi" :follow org--open-doi-link)
("elisp" :follow org--open-elisp-link) ("file" :complete
org-file-complete-link)
("ftp" :follow (lambda (path) (browse-url (concat "ftp:"
path ("help" :follow org--open-help-link)
("http" :follow (lambda (path) (browse-url (concat
"http:" path
("https" :follow (lambda (path) (browse-url (concat
"https:" path
("mailto" :follow (lambda (path) (browse-url (concat
"mailto:"; path
("message" :follow (lambda (path) (browse-url (concat
"message:" path
("news" :follow (lambda (path) (browse-url (concat
"news:"; path ("shell" :follow org--open-shell-link))
org-agenda-files '("~/tmp.org")
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
)
[O] Schedule org task for last day of every month
Hi all, How do I schedule a repeating org-mode task for the last day of every month? As is, when I set a task deadlines like |DEADLINE: <2017-03-31 Fri +1m>|, marking it done shifts the date to |DEADLINE: <2017-05-01 Fri +1m>| which is a day too late if the deadline is the end of the month. Dates scheduled for the beginning of the month properly advance to the first of the following month, regardless of number of days in each month, so there is inconsistency in how the beginning and end of months are treated. I previously posted this question on the Emacs StackExchange: http://emacs.stackexchange.com/questions/31683/schedule-org-task-for-last-day-of-every-month I received solutions involving either manually duplicating date-shifted tasks or creating a custom diary function. Since scheduling repeating deadlines for the end of each month is a common use case, I feel this should be built into org mode if it is not already. If the same logic which shifts dates at the beginning of the month is applied to the end of the month, a nice symmetry would be created without adding any additional notation. Then |<2017-03-31 Fri +1m> |would shift to |<2017-04-30 Sun +1m> |as I originally expected it to. Thoughts? I am willing to implement this feature and update the docs. Jesse
[O] org-mode and dokieli / linked-research?
(I'd be much obliged if you comment here: https://gist.github.com/VladimirAlexiev/80338cc0ec51d3a402ff6d9b9ce4ae4e) **Linked Research** is a movement to publish articles in HTML, with embedded semantic data that would allow not just citations but much deeper interactions. Sarven Capadisli is at the forefront of this, and people like Tim Berners-Lee and Soren Auer support it fully. I believe this is the **future** of scholarly publishing. - see http://csarven.ca/archives/articles for relevant articles - https://dokie.li is a template and a set of CSS that produces native HTML, LNCS and ACM styles. It also includes nice interactive tools (eg comments, citations, Sparklines) but is not yet a fully-fledge editor The best way to write research articles is, of course, plain text. Org-mode excels at writing PDF articles (amongst many other things), but fairly sucks for writing HTML articles (eg there's no standard way to give the Abstract, multiple authors with affiliations, etc etc). I believe that an enriched org HTML exporter that can produce dokieli-style articles will pave the way to that future. A first step in that direction is http://www-public.tem-tsp.eu/~berger_o/test-org-publishing-rdfa.html by Olivier Berger, and there's relevant work by John Kitchin. I asked this a couple times but there's no takeup yet... - https://gitter.im/linkeddata/dokieli?at=56a0a7813165a6af1a3d0ad8 - https://disqus.com/home/discussion/kitchinresearchgroup/the_kitchin_research_group_934/#comment-2574588842 - http://thread.gmane.org/gmane.emacs.orgmode/96910/focus=96961 There are other similar approaches: Scholarly HTML and RASH. This is a nice comparison: https://essepuntato.github.io/papers/rash-peerj2016.html#sec_related_works
Re: [O] [BUG] org-link-search fails if search string contains new lines
Nicolas Goaziou writes: >> The problem, I think, is the regexp construction in org-link-search. >> This was introduced back in August of 2015 with commit >> cfe5bc97f8b18ccbf49d0764746c7563ce8d29da. >> >> The problematic line in org.el is 10951: >> >> (s-multi-re (mapconcat #'regexp-quote words "[ \t]+\\(?:\n[ \t]*\\)?")) >> >> The constructed regexp fails because it assumes a newline will be >> preceded by whitespace. But often newlines are not preceded by >> whitespace. >> >> Is there a reason the following won't work? >> >> (s-multi-re (mapconcat #'regexp-quote words "[ \t\r\n]+")) >> >> This was the method org-link-search used prior to the commit above. Are >> we trying to avoid matching across blank lines? > > Yes, we are. > > Fixed, hopefully. Thanks Nicolas. Yes, it now works with multi-line searches that do not contain blank lines. I think there are some instances in which one might want to search across blank lines, such as when one captures a region that contains one or more blank lines. E.g., let's say org-context-in-file-links is t (the default). If one captures a section in org.el containing a blank line, org-link-search will fail to locate the section. Here's a sample link to try it out. (It assumes an org-mode repository at ~/org-mode). [[file:~/org-mode/lisp/org.el::(defsubst%20org-uniquify%20(list)%0A%20"Non-destructively%20remove%20duplicate%20elements%20from%20LIST."%0A%20(let%20((res%20(copy-sequence%20list)))%20(delete-dups%20res)))%0A%0A(defsubst%20org-get-at-bol%20(property)%0A%20"Get%20text%20property%20PROPERTY%20at%20the%20beginning%20of%20line."%0A%20(get-text-property%20(point-at-bol)%20property))%0A]] Thanks, Matt
[O] [PATCH] Allow insertion of links with multi-line search strings
>From 726eba76f31537747a26a7689ee632ec8e9bc01f Mon Sep 17 00:00:00 2001 From: Matt Lundin Date: Mon, 27 Mar 2017 09:55:33 -0500 Subject: [PATCH] Allow insertion of links with multi-line search strings * lisp/org.el: (org-insert-link): Fix regexps to match across newlines. --- lisp/org.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index e40db18f6..dcfa4fd6f 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -10330,7 +10330,7 @@ Use TAB to complete link prefixes, then RET for type-specific completion support ;; option If yes, simplify the link by using only the search ;; option. (when (and buffer-file-name - (string-match "^file:\\(.+?\\)::\\(.+\\)" link)) + (string-match "^file:\\(.+?\\)::\\(\\(.\\|\n\\)+\\)" link)) (let* ((path (match-string 1 link)) (case-fold-search nil) (search (match-string 2 link))) @@ -10340,7 +10340,7 @@ Use TAB to complete link prefixes, then RET for type-specific completion support (setq link search) ;; Check if we can/should use a relative path. If yes, simplify the link -(when (string-match "^\\(file:\\|docview:\\)\\(.*\\)" link) +(when (string-match "^\\(file:\\|docview:\\)\\(\\(.\\|\n\\)*\\)" link) (let* ((type (match-string 1 link)) (path (match-string 2 link)) (origpath path) -- 2.12.1
Re: [O] Inconsistent behavior in generating file link search strings
Matt Lundin writes:
> 1. First, org-insert-link truncates the search string. Here are the
> steps to reproduce with emacs -Q:
>
> - Store a link in a plain text file. The value of org-stored-links is:
>
> org-stored-links is a variable defined in ‘org.el’.
> Its value is
>
> (("file:~/test.txt::Duis aute irure dolor in\nreprehenderit in voluptate
> velit esse cillum dolore eu fugiat nulla\npariatur." nil))
>
> - Insert the link in an org buffer using org-insert-link. The resulting
>link looks like this:
>
>[[file:~/test.txt::Duis%20aute%20irure%20dolor%20in]]
>
> - This seems to run counter to the advertised behavior in
>org-context-in-file-links, which says the entire region will be
>stored by default.
>
> - The problem is the regex on line 10333 or org.el:
>
> (string-match "^file:\\(.+?\\)::\\(.+\\)" link))
It turns out that the line I mentioned above is actually relevant only
in some cases, as it applies only when linking to an item in the current
file.
The regex that cause the problem in most cases is line 10343:
(when (string-match "^\\(file:\\|docview:\\)\\(.*\\)" link)
In this case, insert link will also fail if the filename happens to
contain a new line (a corner-case, I admit!).
Matt
[O] Bug: save-some-buffers saves org-edit-special buffers to separate files
Hello all, This has been reported before, and as I understood was fixed. http://www.mail-archive.com/emacs-orgmode@gnu.org/msg111340.html But I am still having the same problem using org mode 9.0.5 in emacs 25.1.1. Julian -- Julian Mariano Burgos, PhD Hafrannsóknastofnun, rannsókna- og ráðgjafarstofnun hafs og vatna/ Marine and Freshwater Research Institute Skúlagata 4, 121 Reykjavík, Iceland Sími/Telephone : +354-5752037 Bréfsími/Telefax: +354-5752001 Netfang/Email: julian.bur...@hafogvatn.is
Re: [O] [patch, ox-latex] captions and latex-environments
Nicolas Goaziou writes: > I'm not sure to understand why would anyone need it. I haven't looked > hard enough, tho. Me neither. Perhaps someone would automatically generate code blocks for inclusion... In any case, no use case exists at the moment. Rasmus -- Got mashed potatoes. Ain't got no T-Bone. No T-Bone
Re: [O] [patch, ox-latex] captions and latex-environments
Hello, Rasmus writes: > I pushed a simplified version that doesn't consider > org-latex-custom-lang-environments. Thank you. > If anyone ever needs that we can add > it. I'm not sure to understand why would anyone need it. I haven't looked hard enough, tho. Regards, -- Nicolas Goaziou
Re: [O] Force center alignment in LaTeX table export?
Hello,
Phil Regier writes:
> See inline below and attached. If exporting to PDF the first table gets a
> prefix of "ced!10" and the second is the pale red highlight I was wanting.
>
> Here are the important lines in the LaTeX buffer export:
>
> \(\left[\begin{array}{>{\cocumncococ{ced!10}}c|ccc|ccc}
>
> vs.
>
> \(\left[\begin{array}{a|ccc|ccc}
>
> This latter only works because in my header I have
>
> \newcolumntype{a}{>{\columncolor{red!10}}c}
>
>
>
>
> I'm not sure I'm reading the original issue, the patch, or the surrounding
> code right, but is it possible the [lr]->c substitution was intended for
> the case where no :align was provided by the author and org generated the
> alignment automatically? If so, would it be appropriate to just move the
> substitution to the ";; Extract column groups and alignment ..." block in
> org-latex--align-string, which is to say the case (if I'm reading
> correctly) where the author has not provided an override?
>
> ox-latex.el-3154-(defun org-latex--align-string (table info)
> ox-latex.el-3155- "Return an appropriate LaTeX alignment string.
> ox-latex.el-3156-TABLE is the considered table. INFO is a plist used as
> ox-latex.el-3157-a communication channel."
> ox-latex.el:3158: (or (org-export-read-attribute :attr_latex table :align)
> ox-latex.el-3159- (let (align)
> ox-latex.el-3160-;; Extract column groups and alignment from first
> (non-rule)
>
>
>
> Org file to demonstrate problem and workaround:
>
> #+latex_header: \usepackage{xcolor}
> #+latex_header: \usepackage{colortbl}
>
> * Non-Working Example
> #+ATTR_LaTeX: :mode inline-math :environment array
> #+attr_latex: :math-prefix \left[ :math-suffix \right]
> #+attr_latex: :align >{\columncolor{red!10}}c|ccc|ccc
> | | | * | * | | |
> | * | | | * | | |
> | \hline* | | | | * | |
> | | | | | * | * |
>
>
> * Working Example
> Just define a column type that doesn't use the characters 'l' or 'r'
>
> #+latex_header: \newcolumntype{a}{>{\columncolor{red!10}}c}
>
> #+ATTR_LaTeX: :mode inline-math :environment array
> #+attr_latex: :math-prefix \left[ :math-suffix \right]
> #+attr_latex: :align a|ccc|ccc
> | | | * | * | | |
> | * | | | * | | |
> | \hline* | | | | * | |
> | | | | | * | * |
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
Re: [O] [BUG] org-link-search fails if search string contains new lines
Hello, Matt Lundin writes: > Matt Lundin writes: > >> >> Create an active region covering the third sentence and select the >> org-capture "n" template, which creates the following link: >> >> * Test >> >> [[file:~/test.txt::Duis%20aute%20irure%20dolor%20in%0Areprehenderit%20in%20voluptate%20velit%20esse%20cillum%20dolore%20eu%20fugiat%20nulla%0Apariatur.]] >> >> Try to follow the link. It will open test.txt, but it will also give the >> message and fail to locate the correct position in the file: >> >> "No match for fuzzy expression: Duis aute irure dolor in >> reprehenderit in voluptate velit esse cillum dolore eu fugiat >> nulla pariatur." >> > > The problem, I think, is the regexp construction in org-link-search. > This was introduced back in August of 2015 with commit > cfe5bc97f8b18ccbf49d0764746c7563ce8d29da. > > The problematic line in org.el is 10951: > > (s-multi-re (mapconcat #'regexp-quote words "[ \t]+\\(?:\n[ \t]*\\)?")) > > The constructed regexp fails because it assumes a newline will be > preceded by whitespace. But often newlines are not preceded by > whitespace. > > Is there a reason the following won't work? > > (s-multi-re (mapconcat #'regexp-quote words "[ \t\r\n]+")) > > This was the method org-link-search used prior to the commit above. Are > we trying to avoid matching across blank lines? Yes, we are. Fixed, hopefully. Regards, -- Nicolas Goaziou
Re: [O] Force center alignment in LaTeX table export?
On Sunday, 26 Mar 2017 at 19:13, Phil Regier wrote: > See inline below and attached. If exporting to PDF the first table > gets a prefix of "ced!10" and the second is the pale red highlight I > was wanting. Thanks for the example. I cannot add anything to your analysis. Hope somebody else can help. -- : Eric S Fraga (0xFFFCF67D), Emacs 26.0.50, Org release_9.0.5-385-g72fc2d signature.asc Description: PGP signature
