Re: [O] [PATCH 1/2] Fix narrowing for 1-line subtrees
Hello,j Leo Vivier writes: > The problem is inherent to Emacs's narrowing. In org-mode, the > narrowing commands use `org-end-of-subtree' to retrieve the > end-position of the region to be narrowed. However, with a 1-line > subtree, `org-end-of-subtree' moves the point to the end of the line > which is before the position where clocking and scheduling commands > print their modifications, i.e. right below the headline. > > To address the problem, we need to change the way we narrow and widen > buffers in org-mode: Thank you for your effort. However, I don't think this is going into a good direction. Narrowing should probably be the same everywhere in Emacs, including Org mode. > - We patch the narrowing commands in org-mode to always add a newline > at the end of subtrees (not only the 1-line subtrees). This ensures > that clocking and scheduling commands print their modifications > within the narrowed buffer. > - We create a wrapper for `widen' within org-mode (called `org-widen') > which deletes the newline added when we narrowed the buffer to the > subtree. > > However, for this solution to be complete, we need to ensure that the > newlines added by the narrowing commands cannot be deleted by the > user. IMO, this is very hackish. You imply that narrowing is only done interactively, but this is not always the case. In non-interactive usage, messing with newline characters could be a bad idea. In a nutshell, I suggest not going this route. Sorry for not having been clear about it earlier. Regards, -- Nicolas Goaziou
Re: [O] Bug: Org 9.2.1 table issues [9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)]
On Tuesday, 19 Feb 2019 at 03:16, Nick Helm wrote: [...] > Great, got it sorted now. Thanks again for your time. It would be great, for others that may be interested, if you could post your solution to this list. thanks, -- Eric S Fraga via Emacs 27.0.50, Org release_9.2-193-ge7901c
Re: [O] [PATCH 1/2] Fix narrowing for 1-line subtrees
Hello, Nicolas Goaziou writes: > However, I don't think this is going into a good direction. Narrowing > should probably be the same everywhere in Emacs, including Org mode. I understand. The rationale behind this idea was that it would only modify the way narrowing works for subtrees just as AUCTeX's `LaTeX-narrow-to-environment' works for environments. That's why I didn't think it was a problem. > IMO, this is very hackish. You imply that narrowing is only done > interactively, but this is not always the case. In non-interactive > usage, messing with newline characters could be a bad idea. I don't think if I've implied so, and I've written the code so that it wouldn't change non-interactive calls: [START] <---> (defun org-narrow-to-subtree (&optional newline) "Narrow buffer to the current subtree. When called interactively, ensures that there’s a newline at the end of the narrowed tree." ->(interactive "p") (save-excursion (save-match-data (org-with-limited-levels (narrow-to-region (progn (org-back-to-heading t) (point)) (progn (org-end-of-subtree t t) (when (and (org-at-heading-p) (not (eobp))) (backward-char 1) -> (when newline (insert "\n"))) (point))) -[END]- I've tried to touch as few commands as possible, and I haven't seen any weird behaviours so far. But I understand your wariness. > In a nutshell, I suggest not going this route. Sorry for not having been > clear about it earlier. You don't need to apologise, I went down this route because it was an interesting project to address my problems with 1-line subtrees. As I've said in the commit message, even if we address the problem of other commands not seeing content added outside of the narrowing, we're still left with the other problem which is that the user is not seeing those changes. I wasn't content with this solution, and that's what prompted me to write this. Could I suggest you try out this patch with its latest commit (sent on Mon, 18 Feb 2019 18:18:47 +0100) and gauge whether it affects your workflow negatively? I know you’ve only said that this patch was heading in a wrong direction rather than saying that all hell would break loose upon applying the patch, but the later commits have tried to iron out the kinks, and that might quell your wariness. At any rate, thank you for time. HTH. Best, -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2
[O] [PATCH] Fix narrowing for 1-line subtrees (squashed)
This is a squashed version of all the commits I’ve done on that branch to make it easier to apply. --- lisp/org-capture.el | 12 ++-- lisp/org-keys.el| 2 ++ lisp/org.el | 69 - 3 files changed, 67 insertions(+), 16 deletions(-) diff --git a/lisp/org-capture.el b/lisp/org-capture.el index debf1808c..fbc601875 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -746,7 +746,7 @@ captured item after finalizing." (let ((abort-note nil)) ;; Store the size of the capture buffer (org-capture-put :captured-entry-size (- (point-max) (point-min))) -(widen) +(org-widen) ;; Store the insertion point in the target buffer (org-capture-put :insertion-point (point)) @@ -1416,8 +1416,14 @@ Of course, if exact position has been required, just put it there." (defun org-capture-narrow (beg end) "Narrow, unless configuration says not to narrow." (unless (org-capture-get :unnarrowed) -(narrow-to-region beg end) -(goto-char beg))) +(narrow-to-region + (goto-char beg) + (save-excursion + (org-end-of-subtree t t) + (when (and (org-at-heading-p) (not (eobp))) + (backward-char 1) + (insert "\n")) + (point) (defun org-capture-empty-lines-before (&optional n) "Set the correct number of empty lines before the insertion point. diff --git a/lisp/org-keys.el b/lisp/org-keys.el index d103957a9..26a3852b3 100644 --- a/lisp/org-keys.el +++ b/lisp/org-keys.el @@ -532,6 +532,8 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command names." 'delete-char'org-delete-char 'delete-backward-char 'org-delete-backward-char 'kill-line 'org-kill-line + 'kill-region'org-kill-region + 'widen 'org-widen 'open-line 'org-open-line 'yank 'org-yank 'comment-dwim 'org-comment-dwim diff --git a/lisp/org.el b/lisp/org.el index ef6e40ca9..1f662a01a 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -4415,6 +4415,13 @@ If yes, offer to stop it and to save the buffer with the changes." (when (org-match-line "^[ \t]*#\\+BEGIN:[ \t]+clocktable\\>") (org-clocktable-shift dir n))) +(defun org-tree-check-narrowing () + "Check if the current buffer is a narrowed indirect subtree. +If yes, widen the buffer." + (when (and (derived-mode-p 'org-mode) +(buffer-base-buffer)) +(org-widen))) + ;;;###autoload (defun org-clock-persistence-insinuate () "Set up hooks for clock persistence." @@ -5369,6 +5376,7 @@ The following commands are available: (add-hook 'before-change-functions 'org-before-change-function nil 'local) ;; Check for running clock before killing a buffer (add-hook 'kill-buffer-hook 'org-check-running-clock nil 'local) + (add-hook 'kill-buffer-hook 'org-tree-check-narrowing nil 'local) ;; Initialize macros templates. (org-macro-initialize-templates) ;; Initialize radio targets. @@ -7392,7 +7400,9 @@ frame is not changed." (setq beg (point) heading (org-get-heading 'no-tags)) (org-end-of-subtree t t) - (when (org-at-heading-p) (backward-char 1)) + (when (and (org-at-heading-p) (not (eobp))) + (backward-char 1) + (insert "\n")) (setq end (point))) (when (and (buffer-live-p org-last-indirect-buffer) (not (eq org-indirect-buffer-display 'new-frame)) @@ -8382,24 +8392,29 @@ If yes, remember the marker and the distance to BEG." (move-marker (car x) (+ beg (cdr x (setq org-markers-to-move nil)) -(defun org-narrow-to-subtree () - "Narrow buffer to the current subtree." - (interactive) +(defun org-narrow-to-subtree (&optional newline) + "Narrow buffer to the current subtree. + +When called interactively, ensures that there’s a newline at the +end of the narrowed tree." + (interactive "p") (save-excursion (save-match-data (org-with-limited-levels (narrow-to-region (progn (org-back-to-heading t) (point)) (progn (org-end-of-subtree t t) - (when (and (org-at-heading-p) (not (eobp))) (backward-char 1)) + (when (and (org-at-heading-p) (not (eobp))) + (backward-char 1) + (when newline (insert "\n"))) (point))) -(defun org-toggle-narrow-to-subtree () +(defun org-toggle-narrow-to-subtree (&optional newline) "Narrow to the subtree at point or widen a narrowed buffer." - (interactive) + (interactive "p") (if (buffer-narrowed-p) - (widen) -(org-narrow-to-subtree))) + (org-widen) +(org-narrow-to-subtree newline))) (defun org-narrow-to-block () "Narrow buffer to the current block." @@ -8411,6 +8426,15 @@ If yes, remember the marker and the distance to BEG." (narrow-to-region (car blockp) (cdr blockp)) (user-error "No
Re: [O] Bug: Org 9.2.1 table issues [9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)]
Eric S Fraga writes: > On Tuesday, 19 Feb 2019 at 03:16, Nick Helm wrote: > > [...] > >> Great, got it sorted now. Thanks again for your time. > > It would be great, for others that may be interested, if you could post > your solution to this list. Sure, patch below. It's a bit crude, but it works for 9.2.1-dist (needs changes for today's master): --- a/lisp/org-table.el 2019-02-19 14:06:13.0 +1300 +++ b/lisp/org-table.el 2019-02-19 14:07:58.0 +1300 @@ -3938,7 +3938,7 @@ (list (org-table--make-shrinking-overlay start end (concat (make-string (max 0 (1+ width)) ?-) - org-table-shrunk-column-indicator) + "-") ""))) (t ;; If the field is not empty, consider using two overlays: one for @@ -3962,7 +3962,7 @@ ;; white space characters to the right overlay. (org-table--make-shrinking-overlay (1- end) end (concat (make-string (- width w) ?\s) - org-table-shrunk-column-indicator) + " ") contents) ;; Find cut location so that WIDTH characters are visible. (org-table--make-shrinking-overlay @@ -3979,7 +3979,10 @@ ((pred (< width)) (setq upper mean)) (_ (setq lower mean) upper)) -end org-table-shrunk-column-indicator contents) +end (if (> (length contents) width) + org-table-shrunk-column-indicator + " ") + contents) (delq nil (list pre-overlay post-overlay)) (defun org-table--read-column-selection (select max)
Re: [O] [PATCH 1/2] Fix narrowing for 1-line subtrees
Hello, Leo Vivier writes: > I understand. The rationale behind this idea was that it would only > modify the way narrowing works for subtrees just as AUCTeX's > `LaTeX-narrow-to-environment' works for environments. That's why I > didn't think it was a problem. It doesn't work the way `LaTeX-narrow-to-environment' works. In particular, AUCTeX's function /does not modify the buffer/. This is a big no-no, really. > You don't need to apologise, I went down this route because it was an > interesting project to address my problems with 1-line subtrees. As > I've said in the commit message, even if we address the problem of other > commands not seeing content added outside of the narrowing, we're still > left with the other problem which is that the user is not seeing those > changes. I wasn't content with this solution, and that's what prompted > me to write this. I suggest to not use narrowing, then. Maybe try editing remotely a subtree, similar to what is done for footnotes. I have the feeling this would have its own set of issues, too. > Could I suggest you try out this patch with its latest commit (sent on > Mon, 18 Feb 2019 18:18:47 +0100) and gauge whether it affects your > workflow negatively? It is not about my workflow. I don't use 1-line subtrees. But anything related to narrowing or widening should not alter the buffer, per design. I may sound stubborn, but I don't think this is a way to handle the problem. Regards, -- Nicolas Goaziou
Re: [O] Bug: Org 9.2.1 table issues [9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)]
Nicolas Goaziou writes: > Anyway, I changed the algorithm, so shrinking should now obey to > alignment. By the way, I think this change may have introduced a new bug. When the specified column width is one or two characters wider than the longest cell in the column (26 and 27 char in the example below), the shrunk column indicator and right-hand table borders do not draw correctly. For example, shrink the following with C-c TAB: | <26> | | this cell is 25 char long | | | and you get: | <26> …| | this cell is 25 char long …| | | One char wider gives: | <27> …| | this cell is 25 char long …| | … org-version -> org-9.2.1-252-g3a106a
Re: [O] Rationale for org-directory (any?)
I use it for dynamic folder sync, I can use it different machine, just change the ~org-directory~ variable. I use this variable in many place to concatenate a whole path. Carlos Pita writes: > Hi all, > > I often wonder if the way org-directory is currently used has any > sense or is just a historical artifact. > > I mean, when I list my refile targets and agenda files I have to > specify full paths, which isn't very convenient. But if instead of a > list I provide a file listing the paths, then the items in this list > are taken to be relative to org-directory. Also, capture targets are > relative to this variable. The result is a mix of relative and > absolute paths in my init.el that makes me turn everything absolute in > order to keep it sane. > > Why does it work that way? Is it because some paths are resolved > relative to the current directory (unless they are configured as > absolute paths) while others don't? > > Thanks! -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
[O] org-to-xml, v0.0.1
Hello, Years ago, literally, I asked about converting an org-mode file to XML. I finally got around to writing it. Probably very badly. Comments, etc. most welcome. https://github.com/ndw/org-to-xml Be seeing you, norm -- Norman Walsh | It is well to remember that the entire http://nwalsh.com/| universe, with one trifling exception, | is composed of others.--John Andrew | Holmes signature.asc Description: PGP signature
Re: [O] [PATCH 1/2] Fix narrowing for 1-line subtrees
Hello again, Nicolas Goaziou writes: > Hello, > > It doesn't work the way `LaTeX-narrow-to-environment' works. In > particular, AUCTeX's function /does not modify the buffer/. This is > a big no-no, really. I see your point, and I understand why it would be strange for narrowing commands to modify the buffer. I’d built this patch under three assumptions: 1. We should only change the interactive behaviour of `org-narrow-to-subtree' so as to not disturb other commands/functions. 2. When called interactively, as long as our wrapper for `widen' cancels out what's been added by `org-narrow-to-subtree', changing the buffer is acceptable. 3. If the buffer were to be closed between `org-narrow-to-subtree' and our wrapper for `widen', the only thing you'd have is a spurious newline. This wouldn't be a big deal because some commands in org already do that in a narrowed context [1]. That said, I completely understand your reticence and you've made me understand that my solution was more 'hackish' than I intended it to be. > I suggest to not use narrowing, then. Maybe try editing remotely > a subtree, similar to what is done for footnotes. I have the feeling > this would have its own set of issues, too. I thought about other options before heading into this. One of them was to yank the subtrees to a temporary buffer to edit them and hook onto the saving commands to update the corresponding buffer accordingly. In retrospect, that seems a lot more 'hackish'. Maybe we could salvage some of the patch for `org-capture' since it's different from narrowing, but I've got a better idea. > It is not about my workflow. I don't use 1-line subtrees. But anything > related to narrowing or widening should not alter the buffer, per > design. I may sound stubborn, but I don't think this is a way to handle > the problem. I'd like to suggest a middle ground which I think would be more acceptable. You've asked me in a previous exchange to make a list of the commands which didn't work as expected when the buffer was narrowed to a 1-line subtree [2]. Would it be possible to patch those commands so that they conditionally refresh the narrowing of the buffer if the information they add would be spawned *outside* of the restriction? The rationale behind it is that, in Emacs, commands trying to act on regions outside the current restriction throw an error. Therefore, in the context of 1-line subtrees, we could justify that conditional behaviour by saying that it prevents your command from working outside of the current restriction. I was pleased to see that property-adding functions didn't behave badly with 1-line subtrees. Maybe we could investigate those commands and patch their behaviour onto the problematic ones? If that sounds good to you, I could work on it and submit another patch. Thank you. HTH. Footnotes: [1] As a quick aside, here's an example for 3. where X represents `point': [START] \| * Tree \| |X1|2| -[END]- When narrowed (or at the end of a buffer), if you press : - `point' moves to '2'. - Table is realigned. - Newline is added at the end of the table. [2] We've already addressed `org-clock-out-when-done', but I've found another one. Although adding scheduling/deadline information works within a 1-line subtree (the information isn't visible, but it's there in the widened buffer), you cannot remove them from within that environment. Best, -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2
[O] Error in org-element-parse-buffer?
Hi,
I’ve just noticed that org-element-parse-buffer loses whitespace
sometimes.
Consider this org-mode file:
This is a *bold* word.
What org-element-parse-buffer returns is:
(org-data nil (section (:begin 1 :end 24 :contents-begin 1 :contents-end 24
:post-blank 0 :post-affiliated 1 :parent #0) (paragraph (:begin 1 :end 24
:contents-begin 1 :contents-end 24 :post-blank 0 :post-affiliated 1 :parent
#1)
#("This is a " 0 10 (:parent #2))
(bold (:begin 11 :end 18 :contents-begin 12 :contents-end 16
:post-blank 1 :parent #2) #("bold" 0 4 (:parent #3)))
#("word." 0 6 (:parent #2)
Note that the whitespace between “bold” and “word.” has been lost.
Well, possibly it’s recoverable from the various begin/end positions,
I can’t quite decide although (1) it doesn’t seem obviously to be the
case and (2) it’d be *way* more convenient if the space was in the
data structure as text. I guess it’d have to be either a single space
between them, or at the beginning of “ word.”.
Or do I misunderstand something about the data structure?
Be seeing you,
norm
--
Norman Walsh | The cure for boredom is curiousity.
http://nwalsh.com/| There is no cure for curiosity.--Ellen
| Parr
signature.asc
Description: PGP signature
Re: [O] [PATCH 1/2] Fix narrowing for 1-line subtrees
Hello again, Leo Vivier writes: > I was pleased to see that property-adding functions didn't behave badly > with 1-line subtrees. Maybe we could investigate those commands and > patch their behaviour onto the problematic ones? > > If that sounds good to you, I could work on it and submit another patch. I’ve investigated the problem, and I’ve stumbled upon something interesting. I’ve started by looking at the differences between `org-set-property' and `org-schedule' which respectively led me to `org-insert-property-drawer' and `org-add-planing-info'. The interesting difference is in the way they handle newline insertion: `org-insert-property-drawer': [START] ... (insert "\n:PROPERTIES:\n:END:") ... -[END]- `org-add-planing-info': [START] ... (insert-before-markers "\n"); Inside a cond ... (insert (cl-case what ; Inside a later cond (closed org-closed-string) ... ) " ") ... -[END]- By adapting the `org-add-planing-info' to insert the newline with the scheduling information, I could get it to insert its text *inside* the narrowing with a 1-line subtree. I'm providing a patch at the end of this email, but it's rough around the edges. Notably, I didn't have time to make it work with the condition tree, which means that re-scheduling as well as adding a deadline on top of a scheduled time results in spurious newlines. Correct me if I'm wrong, but I believe we'd be departing the 'hackish' territory with that solution, which would be great. Here's the patch: [START] Move newline insertion --- lisp/org.el | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index ef6e40ca9..6c43d9b25 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -13046,18 +13046,19 @@ WHAT entry will also be removed." (unless (= (skip-chars-backward " \t" p) 0) (delete-region (point) (line-end-position))) ((not what) (throw 'exit nil)) ; Nothing to do. -(t (insert-before-markers "\n") - (backward-char 1) +(t (backward-char 1) (when org-adapt-indentation (indent-to-column (1+ (org-outline-level)) (when what ;; Insert planning keyword. -(insert (cl-case what - (closed org-closed-string) - (deadline org-deadline-string) - (scheduled org-scheduled-string) - (otherwise (error "Invalid planning type: %s" what))) +(insert "\n" +(cl-case what + (closed org-closed-string) + (deadline org-deadline-string) + (scheduled org-scheduled-string) + (otherwise (error "Invalid planning type: %s" what))) " ") +(end-of-line) ;; Insert associated timestamp. (let ((ts (org-insert-time-stamp time -- 2.20.1 -[END]- HTH. Best, -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2
Re: [O] [PATCH 1/2] Fix narrowing for 1-line subtrees
Sorry, the patch I've submitted wasn't right: it had part of another test I was running, hence the `end-of-line'. Here's the proper version: [START] lisp/org.el | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index ef6e40ca9..4514407e7 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -13046,17 +13046,17 @@ WHAT entry will also be removed." (unless (= (skip-chars-backward " \t" p) 0) (delete-region (point) (line-end-position))) ((not what) (throw 'exit nil)) ; Nothing to do. -(t (insert-before-markers "\n") - (backward-char 1) +(t (backward-char 1) (when org-adapt-indentation (indent-to-column (1+ (org-outline-level)) (when what ;; Insert planning keyword. -(insert (cl-case what - (closed org-closed-string) - (deadline org-deadline-string) - (scheduled org-scheduled-string) - (otherwise (error "Invalid planning type: %s" what))) +(insert "\n" +(cl-case what + (closed org-closed-string) + (deadline org-deadline-string) + (scheduled org-scheduled-string) + (otherwise (error "Invalid planning type: %s" what))) " ") ;; Insert associated timestamp. (let ((ts (org-insert-time-stamp -- 2.20.1 -[END]- Best, -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2
Re: [O] Error in org-element-parse-buffer?
Hello,
Norman Walsh writes:
> Consider this org-mode file:
>
> This is a *bold* word.
>
> What org-element-parse-buffer returns is:
>
> (org-data nil (section (:begin 1 :end 24 :contents-begin 1 :contents-end
> 24
> :post-blank 0 :post-affiliated 1 :parent #0) (paragraph (:begin 1 :end 24
> :contents-begin 1 :contents-end 24 :post-blank 0 :post-affiliated 1
> :parent #1)
> #("This is a " 0 10 (:parent #2))
> (bold (:begin 11 :end 18 :contents-begin 12 :contents-end 16
>:post-blank 1 :parent #2) #("bold" 0 4 (:parent #3)))
^
it is here.
Regards,
--
Nicolas Goaziou
Re: [O] Bug: Org 9.2.1 table issues [9.2.1 (9.2.1-dist @ /Users/nick/.emacs.d/lisp/org-9.2.1/)]
Hello, Nick Helm writes: > When the specified column width is one or two characters wider than the > longest cell in the column (26 and 27 char in the example below), the > shrunk column indicator and right-hand table borders do not draw > correctly. > > For example, shrink the following with C-c TAB: > > | <26> | > | this cell is 25 char long | > | | > > and you get: > > | <26> …| > | this cell is 25 char long …| > | | > > One char wider gives: > > | <27> …| > | this cell is 25 char long …| > | … Fixed. Thank you. Regards, -- Nicolas Goaziou
[no subject]
x-uw-ex-currentlocation-365-recipient: Outside x-microsoft-exchange-diagnostics: =?utf-8?B?MTtDWTFQUjA4MDFNQjIxNTY7MjM6U0MySWlETVUrV1g5UTRjNEc1UWlodGRu?= =?utf-8?B?NkJDNW53ZHJzNHhpNCs0aXc1NklhK0xoWlgxSU5kMjdsZUlTcGVxY3dYc0c5?= =?utf-8?B?M3B0OHVNQ2lEdm5Gb2JPRFo4WDZUOHRlazExQVpWazE4UHlLK1ltcnFLRSt2?= =?utf-8?B?V1FVS1daNEE3WGFIZUFvcTFScGowb3M2cTBLUGRJWENrc3NQQXo4aGN2RFBX?= =?utf-8?B?WGpMZHBwWGVVdU9sSXpyTklSQmZ5NXJqUENVbnpicVhGd1BrNjNrSXdhNHhM?= =?utf-8?B?UjBXUklMYTEwT2xrYUNEK3Z6N0wxUlc5eFFSMmYvOS9SYnR1VlpDMllvSEtq?= =?utf-8?B?REZUSkdTbitLL0prQnI3dFk5b1J6c0V5S2toSDhxYzhKUkt4cCsydTdEVUdE?= =?utf-8?B?clBkdEM0UUxnMStZUTdVZzdzaFc1amV6L1JQU1RQOHBsN1VGdlRtYzZYVGNl?= =?utf-8?B?WFlKdXR5NnNCelAxdEI1WXFBY3FpUGVCcmtidHFPOFd2OStwYjBBRk00Skp6?= =?utf-8?B?Nzd4czhFTFRqUWZFRnBqZHREM1c0UmpnZzBOSnAxTDFXKzBzYTJCUVVuVWRx?= =?utf-8?B?RWw4SUpWUisramZjakw2czRmdzNCVWQ2QkV4dk45dk9GYWpnd1pSZDlmcE14?= =?utf-8?B?VjUxVUg1U0UrTjBJQWR0OUtySk5QSytUMW1XQ3RrMUFUajlVYVpBb1RTajdz?= =?utf-8?B?MUJaUmg0dGNlT0FFTVRYNUNzSktjb0twdzgySHlHU1lzbHF4WDJqbnc4eXVw?= =?utf-8?B?aWcvdmZBRkVHM09Oa09NaG1RalMwVnZGQWJVNlVMRWlPb2l2SlZWV3FzNHlF?= =?utf-8?B?S2dydnByZVdmUHdWVmpuL25CdCtCTngrQTVqUTVuVVh2bEFFcGxHc1k0RmF3?= =?utf-8?B?S0QrMVVwRHphdmkyajA5TzBjTVU1QUNaT1o0ZXU2dlAraElrNHR0RXBZQ1NQ?= =?utf-8?B?YmF5d1E4TFpKZDc1cUg3b1RncWRwRGZYMVYxSEtSVm1lak5hNnZJRTQ1TWJH?= =?utf-8?B?dUN0QU5jN09RMGJ1blM2UGZBY0pyY0pKSEtZWjg3UWNlWmsxWTNxeWRHcWt3?= =?utf-8?B?ZW13amVtWHJWaFl0Qk5KMXpKWU9URzMyWjB6RE90MGNZc01TQWwwVjAyaC9G?= =?utf-8?B?WEhVUlkyOUpxOGpnSlFJWG5Zd3Rkc0cvbXdRbndTY256K1FqK05wUWV3ZkhR?= =?utf-8?B?bFhLbUFtYkljWStGam1Jd3pscUIrbUhKZVQxL2UxY2JWNmRmS25FZ0dIY3dE?= =?utf-8?B?ZmFvRUxoT09HWks0dVpkV2VRNzJBdVVCbVpwRmltUEY5WlBwTlJaeWpSWk9t?= =?utf-8?B?bDJ0bjNQZkJOV3NIU2orWkhSUkc5azI4d0lKVWlZbUhqMWtidEZHYURSaWYz?= =?utf-8?B?OWhUQjVXNVpRR1lKb3V6aG1GZjAyMStqWmZ3Z1B6WDZjZlBuYTZORjRvVGlL?= =?utf-8?B?d0YybWNuM0NrOUFLZHlEWmFldkVLYS9FdjJ6aFNTbElpMUNUVjhhd0VMaUhr?= =?utf-8?B?SW5naEJZbDVRem5NNjBuWFp5Q2JCV3RNM00wd3pBaWdXVE01ZGNiU1lXU0dO?= =?utf-8?B?aTBJc0RrVnJjeEVNUE4vRUcxUTRhQzhCeEN2RksvdzJQekRDOWVWVms4VWRz?= =?utf-8?B?a1BGeUpPMFFrTDdlVFhyZ043OWZEK0NCZVRJblMvcW1UbU11aGw2dGxuZGdL?= =?utf-8?B?bkd3dVpHUzFjR1JTZS9NUlZTY2lxWlFqcVFVa2huRjMyOHdRVWRFbm9VOFds?= =?utf-8?B?UEZzekYyVDlIZitLaTBKMEM2RW5rZDdHSHlPREVzSVRZUHFGSjhqOEVMandi?= =?utf-8?Q?GdUJ9N58pvYpcoM?= x-microsoft-antispam-prvs: x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(3986042)(376002)(346002)(136003)(497574002)(199004)(189003)(786003)(2616005)(316002)(25786009)(2351001)(6306002)(476003)(53936002)(54896002)(75432002)(6506007)(186003)(79071)(966005)(1005)(256004)(68736007)(5024004)(566032)(47861)(564073)(88552002)(3846002)(6116002)(6486002)(486006)(83716004)(7119041)(8936002)(6916009)(7736002)(102836004)(99286004)(7120041)(6436002)(81156014)(33656002)(81166006)(2501003)(36756003)(66066001)(105586002)(86362001)(26005)(6512007)(106356001)(2906002)(14454004)(97736004)(82746002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0801MB2156; H:CY1PR0801MB2156.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uw.edu does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6DJPfPH7XOLRFiRW37zA/7Kf1Jq4pG8p3HwmBJcnQ7HsFd40+eoIKTilQ4ZHXDnqMgbjuDoiTVhcT5/f4mXtLuaL4+0fUofOW08vKBMCKVBQHyiTV1UDqnmfhcJmUZtC4wdvbvxw5cClF2fcmCZZfFECt9ysMX9jpQuS+y6yYb1GMM1Bd4J2HqY9nuJfnYB2ZcYJwOmdxlnzKVHAhB3yudNq1Cv++I4uztzQavnppSNBft9C96hE0iWtpiNrXHQEvpa6XdjxTaJKU6FQMloCST3bubuOMRMycchYghK4Zw1ezX7M+Up28q726Z8bmxVyi2tWipqckusw6oUhaq5HKczvC06v4pR3bTKaIlyjpiNnV7BSDTP0pqfjsSf6qNbIVJ6yZ4bK6avTYKC96waM/gKyeTTU/S2iiQqVRh7kLjo= Content-Type: multipart/alternative; boundary="_000_AEF95D43C2114D31AD6428AC2253636Buwedu_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4cc881d6-364b-4b4d-410f-08d6969e48b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2019 19:13:08.6900 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f6b6dd5b-f02f-441a-99a0-162ac5060bd2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0801MB2156 X-OriginatorOrg: uw.edu X-PMX-Version: 6.4.6.2792898, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.2.19.190616, AntiVirus-Engine: 5.58.0, AntiVirus-Data: 2019.2.19.5580003 X-PMX-Server: mxout22.s.uw.edu X-Uwash-Spam: Gauge=I, Probability=9%, Report=' HTML_90_100 0.1, HTML_95_100 0.1, HTML_98_100 0.1, HTML_99_100 0.1, BODYTEXTH_SIZE_3000_MORE 0, BODY_SIZE_1_PLUS 0, DKIM_SIGNATURE 0, FROM_EDU_TLD 0, SPF_NEUTRAL 0,
[no subject]
x-uw-ex-currentlocation-365-recipient: Outside x-microsoft-exchange-diagnostics: =?utf-8?B?MTtDWTFQUjA4MDFNQjIzNDU7MjM6RWNydHRFUEVySG53U0M3N0JRWXROWG1V?= =?utf-8?B?MXZta0l2a21vQkhTZng3MUUxZzJjZm1XVG4rc05UckR2MTlxVFJyZUV1S2lW?= =?utf-8?B?N2xWdHAxRXdWa1pIdHp6M0I4NXBmaGkyTzNlazJod0p3TEk2K3hGd04zUG9S?= =?utf-8?B?cXhuMCszVmpla3I4dTJVOFErRE03MGRDOUhyODQ1SUw5SFZraDZLM3JBeFJ5?= =?utf-8?B?QlVCS0JtNnB5T1BEV200aGd2cnB0T012T0EwcVk0cVVPRzNlZ1NBS2FTSVlq?= =?utf-8?B?YU1GL2cydEp3M3FTY3VoOVI3SGlVT1V3T0F2TmRSdEQ1clMxcUZvTmcvY1h0?= =?utf-8?B?ZTJ2ZHFmOEhzWjRzL29RaXRWMmFRR1A5MExYem1vVDJQam5QS3pGMEhmaGxX?= =?utf-8?B?Zm1oaDVLWUtGSFVsOEdmRzlJOVFHS01oODhCbXFCTjM0MlZHOHNRNG42NEFP?= =?utf-8?B?dTFzditFUUJ6UzJIdGdwSTV4RzFzbk84TXF6SnAvRk5jQkRuNzJKWDhMNkRD?= =?utf-8?B?bmFET2F2T2tnUDZnNWxzTVNkVytjemhPOTRKQ2I5VW9WWGc0T1NvSlVPTTIr?= =?utf-8?B?L0p4MU9yR3BhbEtDZWwwb3NYeUVsNzJNa0xWZE93QU5HUXhhTUIvdkZjcUE5?= =?utf-8?B?M3lETEt3UUE0RDFKOUkya0p6ei8yTXMvYzhYRmc3U3p0cDlSeVUrU2tmc3RY?= =?utf-8?B?NWZrc1NiZmk3RVRLcDhsNGVEMkR1eDVnWGg2QWE5NCtqK096Y0Z5a3JnNVZt?= =?utf-8?B?c0d4UUpBNGltLzNlVGRpMDBJeldrUlU1S01NZTRaVGIyaUd0TzJDZnhoTS9T?= =?utf-8?B?SjVoQXVFVDlsYlZJVGorTm1aWjd3K3Z0Yk1LL3ZTWWE2OWtBSXBLQTltUTRG?= =?utf-8?B?bEQyT2gwZitrbTJPdEh5VDBBaHdpTHAydzFGR0xNMUdMT01Ha2F4NmxjWk5S?= =?utf-8?B?VXUyWmh4Wll2R0cvbG1DMHMxZUZEdlloVUVCeDB1ZGZxb0pkQWgzaExmZkl3?= =?utf-8?B?ZDZZZzl4ZlFtQ1l0N3VUK2dhbmNvY3BjN0VMMW1MV0ZuNVVVM1VIZ2tJZDNX?= =?utf-8?B?Mms0blZnSUJUZ25pa3BXUkhaMCtSZWJlTjhVZ3B6YVdISkhDS0V2WkFsbkRx?= =?utf-8?B?enR1aWFST09RMDVUdEdxejljaDE5V2lTY25PQ0JScUhtbDBvQTE1amwzdldw?= =?utf-8?B?WUh5NjNzU2dzaDZpb3drcWlvaDZEQU9sNTdPNHlBbU5rRFZqckUwYTdCQ3M5?= =?utf-8?B?bVl5QjdnM2pWdkRLYWJmK1ZwNXVRUnM3ZHpKNFIyendHQnpVY1RzMXMwMTJi?= =?utf-8?B?ZnczYmZFbjhZQWdjNU5UZWJyTDJTS3NvYmwzZTdmRml1Ny8wS090WTR4TjBT?= =?utf-8?B?ekZQaXBEa0Y1OTdQOTMwcHh1Ly9oaVJ6cmJaaHJYVXNBMHNZbHlRTGxrZVpW?= =?utf-8?B?dlZhZHVVekhIRDBqTHc3ZTFaUDBZclc0NnJEVUYzclBLTWkvbkdaUkVjK2Iy?= =?utf-8?B?Vk1CbVBtWkVvYkJFVWdLYjZMbGxaVFFBN3FzSXNOa0xSTEpqNnFLYUwrUWlz?= =?utf-8?B?bHlpVXoyWU9LNnYybmswUXNKQXZoaTc2MzAvYTN3QTFPbHhaRy9UcEFNWU9P?= =?utf-8?B?VHFseFI4S3puNTBzT3lYVmdWR2ZEL1RLbWZDUndDclFsNDlKMzI3OXV2eWZ1?= =?utf-8?B?eFhsNlFKNWVWZHFIVzlSN1d2YUlEL2plT25DV3Zoc3RnekhNVnZnRWRTYVpH?= =?utf-8?B?VUZjMHFQRVFTSmxrdEMzTWFORUJSbEhuNEM4R0lyZms2c3JjTThnZ2pESW4v?= =?utf-8?B?Q0lFRnpWMGpZeDJHL3FqQUlxM0x1VTZCTGtnV29IZnZNYm05SkppOVh1OWtS?= =?utf-8?B?ZzZ0NU5mVUpkQVRsL0xzK2c3Q0dGMThXeVJ3OXkwMjZYdmRaaktwaENIbmht?= =?utf-8?B?b3dGRjlSZEMwT2xtMWZtODl4RTI2Mis0eFJYTXk1Q09DaEs0U25oWG9ycVlZ?= =?utf-8?B?Q0wxTldYanoyNU80RVIyT2plUlVqVytvdEFGd3ZBPT0=?= x-microsoft-antispam-prvs: x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(396003)(346002)(366004)(3986042)(199004)(189003)(497574002)(68736007)(76176011)(81156014)(8676002)(7120041)(7119041)(83716004)(6512007)(446003)(229853002)(6306002)(54896002)(2351001)(14454004)(8936002)(36756003)(236005)(606006)(99286004)(82746002)(1005)(11346002)(2501003)(7736002)(6246003)(102836004)(256004)(566032)(81166006)(6506007)(53546011)(5024004)(33656002)(66066001)(97736004)(6916009)(25786009)(186003)(2616005)(2906002)(88552002)(86362001)(53936002)(486006)(476003)(105586002)(106356001)(316002)(75432002)(6486002)(966005)(3846002)(79071)(6116002)(786003)(564073)(26005)(6436002)(47861); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0801MB2345; H:CY1PR0801MB2156.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uw.edu does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TNj2FN6W7JwRAN9WDl54nNmCjH0OiU7rCr/vP6MTBPyYUtwohCX0OyMOuTTMiHt5Oa73FlnPQcVtVm9jP0iQQGgyqIddk0WKEy8awxDkTJu6RSNEr+TigTM2vDGVbrCeAkTd0dEHkGEiD+ieyEWrcNBdCBm1u7ed2FO/u0HrHaxRkSWZl5mIv+A/lr5xGVziPLmIStZchvrfSPreLguZrW8XStriSf070abJ9FkFNBKwY+3WEHTgqjbgBm1XBa2zUeF3AyEb43eBvFahFEeG7omzwim+4+NUh45m/OdujnKc2OYo5EKhCgE6Bpys5IRzvu/HDY3g8hdaNuhjxQD9SJBs2duk5BKjMUZMTdH5ZjJWt4yikqJ1p5eCnmgD6VisM/zj4Vbt+aAZHIwHS7DiKQxX7mMHHVl/FDPooByqKA8= Content-Type: multipart/alternative; boundary="_000_3933A05C76CF44B1BD91DFE16CBC33A2uwedu_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1326589c-ab7d-44c2-cd08-08d696a0dfef X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2019 19:31:41.3300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f6b6dd5b-f02f-441a-99a0-162ac5060bd2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0801MB2345 X-OriginatorOrg: uw.edu X-PMX-Version: 6.4.6.2792898, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.2.19.192417, AntiVirus
Re: [O] Bug: org-agenda fails when a scheduled/deadline date is in the past [9.1.9 (release_9.1.9-65-g5e4542 @ /Users/borwick/.emacs.d/elpa/org-plus-contrib-20190218/)]
Hello, John Borwick writes: > If I execute in *scratch* > > (org-agenda-get-day-entries "~/Dropbox/org/main-todo.org" '(2 18 2019) > :deadline :scheduled :timestamp :sexp) > > and main-todo.org contains this entry: > > *** TODO Medium priority inboxes > :@work_online: > SCHEDULED: <2019-02-18 Mon> > > (where 2019-02-18 is yesterday), I get the error "Wrong number of > arguments: (0 . 0), 2". > > If I change the SCHEDULED date to today: > > *** TODO Medium priority inboxes > :@work_online: > SCHEDULED: <2019-02-19 Tue> > > and execute the same org-agenda-get-day-entries statement, I do not get > this error. > > It appears to me that there is some issue with scheduled and deadline > dates that are in the past? > > > I found this after finding that =C-c a a= was erroring out with the same > “Wrong number of arguments: (0 . 0), 2”. Here is the backtrace from trying to > show my agenda: > > Debugger entered--Lisp error: (wrong-number-of-arguments (0 . 0) 2) > org-get-tags(nil nil) Could you use latest Org release and try again. It might have been fixed in the meantime. Thank you! Regards, -- Nicolas Goaziou
[no subject]
x-uw-ex-currentlocation-365-recipient: Outside x-microsoft-exchange-diagnostics: =?utf-8?B?MTtDWTFQUjA4MDFNQjIyOTc7MjM6UmJFcDdTR0wvNHBPcjhVcWNXZGtLdXdm?= =?utf-8?B?S2ROdDl5VjFIaGhuQTh3TGFIa253Y0NBc3ZxRUhPYWVrRVd4ZWc0ZXJxbjM3?= =?utf-8?B?aTN3TGtiMXNKMmlGS3V6OHBPNlVXUXlBNTEwalVNaUhQMHdTZHNoM0czVVFx?= =?utf-8?B?R2xIQW0vdUN4RUw4SHhvTzd1RGsyY2ZuUnk0cllNcDMrazVuS3NCMVd6WjVt?= =?utf-8?B?dEYrNnJiMVlZUm96c01sMHkrVDZGVjJrNjVYaXpYWTkveFdVb0NSUlgzQnVS?= =?utf-8?B?OFdjeHlxbFN1NmhlaVY1VDZOeENNY2pPZlN0T2ZTK3FJVlg4NHVFdXp6Z0lx?= =?utf-8?B?T3cybGd5Z0xJUzd0WlJsd0t2QUtZK0hWclpKcDFrOUdnNXp1TFBFS1pPc1Vv?= =?utf-8?B?OTM0WlY2b2MxWWVOK29nWGtnaDE1ZDBwdUszSzBLb1BIQ25lMlRJL3hDODA1?= =?utf-8?B?Rkc4S2sybGF2RmZBT3ZuVjNUa2MwSVhHVFpJTUhic2RSbmdxL0gwN285Tk5q?= =?utf-8?B?T3ZXQTl1aVpaR3drVE91U1BJTTd0Rm40ZjU4QU10c2RiNnpGNEdUdGNuM09U?= =?utf-8?B?dkVDcjhOZlRRS21PdDVGQ3h6WWYzUWJJc1B1dTdNeFNWZFJMMVlzVmp3cG8z?= =?utf-8?B?Qm5aYjZrQ0M1MjZUaG83bUd0OWRjSjcyKzVuSGdFeDl3cTBIWDYwTVQzczZJ?= =?utf-8?B?dUN4S005WStNZFJMd2tXem1kMVdSQzBQNXgxQSt6MWJGaXhxUnNaa3BYM1Fv?= =?utf-8?B?cVY2U1RUK1VwYS9pclZhRDVpeldicjNtSFFVZ2lsdWtwb3g2VHRlMWxKUkFZ?= =?utf-8?B?S29Nc1hzVDNMZ25MWmRXcGNOZzBLelNOV09xQWZWVWVOMFdoM1pCY1hITWd4?= =?utf-8?B?d3BPS0x2R3FpZ1BJUUJhbWxzdElYZVhuR2ZUYjhZclZtdzRNaEgxZmNKTU1J?= =?utf-8?B?Umd4cU1PRjNUL201Vmc1RDhHQW84MnJnZ3V3WkJhbmRNbDUrSXRsMlE0R0Uz?= =?utf-8?B?TWJSZkxVZmhuZGwzYlhMODIwNlNjQUN2all5UlhrL3ViUTVPdEN3Q0JwVThi?= =?utf-8?B?UlBVTUdYZW9BNzd3eUZQUDV2bWRKdEgvSHlEa1NocmtqcWZGQTNsamVhNTgr?= =?utf-8?B?M1l4eEQxSGlkcHp0NTV0dWFSNkZXR3ZrUktuSDFqTzUvWG5IV04rVWkveWhu?= =?utf-8?B?MEl3WGU4Q0l3aFBvU2JCMEc0ak1UME5ubVgvNzFsWGZKMmp6QlFqOVA5OUZR?= =?utf-8?B?Y2lqYlZNdjArQnE2YmtQYzN5UWErUWZYYndGa3puVmxwVk1oVnE2dXpKSG01?= =?utf-8?B?dXRhcHo1YjJrQkZBQ3NXMFNTdWpvaWtEZWo3QUV3dUlNeE4ya015eHpuVVk1?= =?utf-8?B?MnpiTUZ4UXhoMVJURGZLYWZqaHNvUjJPUUV1OEhEVzc2Wk84eTVmVTJlVXBL?= =?utf-8?B?bVVWdnkyVmtkWHJwZ1lzaWw1MVdUcG90VVJvaDlDblVJRDM3eU9KSFdRNVNE?= =?utf-8?B?K3luSXhiSjdHSW9EYnFnZlNoQktGem1qV3p5UC9xVGtiK3FQQ0dmcDVqcXQz?= =?utf-8?B?a1QrZ1dKVEZPNDZIaFIxNUZPZ2tQRWJ2TG50Q3RSdzhVSjZpZW93QWdxYzEx?= =?utf-8?B?ODFJZVU1NEFmQkMxVUJxNUtjM0t0OFptbkJiK2RTSE9sVWJSRmEzL09PWmpD?= =?utf-8?B?cGd4aTl5bWdycmc1S3hRRC9oY0hMemZUSUtSeUFUUUt3dEpsd3BKaytUVkht?= =?utf-8?B?NkwrTTBpWHJnWjlYNnJneWlOVDQ4aTIwai85eGlSdzVqdFpkdDJGRjRyVEp5?= =?utf-8?Q?Ee35Nr6AEzsdnQ4?= x-microsoft-antispam-prvs: x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(3986042)(376002)(366004)(346002)(136003)(497574002)(189003)(199004)(55674003)(8676002)(2906002)(36756003)(81166006)(88552002)(81156014)(256004)(75432002)(83716004)(7120041)(25786009)(6346003)(68736007)(6506007)(66066001)(53936002)(105586002)(7119041)(14454004)(566032)(8936002)(99286004)(6512007)(53546011)(102836004)(106356001)(26005)(86362001)(305945005)(4326008)(7736002)(486006)(186003)(6486002)(47861)(2616005)(229853002)(82746002)(476003)(6436002)(3846002)(786003)(6246003)(6916009)(125075)(316002)(97736004)(6116002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0801MB2297; H:CY1PR0801MB2156.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uw.edu does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=borw...@uw.edu; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: P/JvSLRyhtaZ0y/q8SpDCgabGajQGKTdcth0H9GLwEnE92zIXNKCDF62gE6I+5ZB4DungapoYYJ2amezUA/eFZDwBMG8Fazh0pZ184uoCNwHkz+2COESXQLO4A29vwZ1DHjjme6LA0ty9UBpbsJ3Fe8TPHYyV8lBRIr0Tzcr6Wtx6Mi1o0reBxOjWin0PP2dMuUj/gdYzpagNHYx4506B+lVjqP3RvebMYGyaZgrJNVCvZr3Re7Rk2lNYB9BRK9HP7KXhuMB6OXUNL21gng9f8H4Mzft5KfehIpa9UvmNrCjwmJyP7JBgij75gMjPTTMcrAKHhsw+FHYygBtkBMRPkSpbwsxzRWMjd8+3Gl/cyE3og3ACUGrxJuCLsBKFYS+KTukgxoM72Df4NcxZTx0a1Ttn9YSEdpL9+exMvJFq6Y= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 741e71b0-61c0-4518-5155-08d696b32453 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2019 21:42:27.1015 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f6b6dd5b-f02f-441a-99a0-162ac5060bd2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0801MB2297 X-OriginatorOrg: uw.edu X-PMX-Version: 6.4.6.2792898, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.2.19.213316, AntiVirus-Engine: 5.58.0, AntiVirus-Data: 2019.2.19.5580003 X-PMX-Server: mxout25.s.uw.edu X-Uwash-Spam: Gauge=, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_S
[O] typo in org-track.el manual
binV_LTZlQ4nF.bin Description: application/pgp-encrypted bin8UiPPrykhr.bin Description: Binary data
Re: [O] typo in org-track.el manual
binZMEXuhGks6.bin Description: application/pgp-encrypted binoD3igvt0Pw.bin Description: Binary data
[O] Org can't export inline image link to PDF
I have an inline image link like this in Org file: ```org #+ATTR_ORG: :width 300 #+ATTR_LATEX: :width 3.0in #+ATTR_HTML: :width 300px [[file:data/images/me_picture%2023.jpg]] ``` When I export to PDF file, others work fine, but just no image, no link at the inline image link position. Just blank. Do I need some extra settings to make it work? -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
[O] [Proposal] Make Org keybinding popup buffer/window controllable?
My notebook computer is a smaller screen computer. When I open 5, 6 windows, it will make every window small. When I using `org-insert-structure-template` or `org-export-dispatch`, They have a long length content, if those popup buffer are display in my small size window. I can't see part of them. This is really annoying me. Emacs built-in has a dynamic variable `display-buffer-alist'. I hope Org can use functions which support this. Of course there are some packages there to control popup buffers/windows. But seems not work well on Org popup buffers. So, please improve Org popup buffers. Really. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
[O] How to simply add tag system for org-publish blog?
I'm currently using *org-publish* for blogging. But I want it to have tag system. About why not using other static site blogging system, because I like Org Mode. The tag system should have following functions: - get blog tags from Org file headline tags, or property etc. - show tags on blog post page. - click on the blog tag can list out all posts having this tag. I don't know much about web technology. So if asked a dummy question, please forgive me about this. And if someone have any idea, welcome to tell me. Thanks. -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: [O] Org can't export inline image link to PDF
Now I figured out, because the filename contains a space, which Org auto converted to `%20' when exit org-insert-link. That's why can't see the inline image in exported PDF file. After I renamed image filename with replace space with underline "_". Problem solved. But, if possible, I still hope Org can fix this problem. stardiviner writes: > I have an inline image link like this in Org file: > > ```org > #+ATTR_ORG: :width 300 > #+ATTR_LATEX: :width 3.0in > #+ATTR_HTML: :width 300px > [[file:data/images/me_picture%2023.jpg]] > ``` > > When I export to PDF file, others work fine, but just no image, no link > at the inline image link position. Just blank. > > Do I need some extra settings to make it work? -- [ stardiviner ] I try to make every word tell the meaning what I want to express. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix: stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
