Re: Interest in an Org video meetup?
Hi all, I’m super happy to see the interest in getting an org-mode usergroup off the ground! I’m even happier about the fact that we could help you address the technical and logistical issues that have been raised in this thread. Since EmacsConf 2020, Sacha and I have been working with Emacs usergroup organizers to provide them with the tools needed to publicize, host, and record their sessions. We have a page on the EmacsWiki which lists all the usergroups we know of: https://www.emacswiki.org/emacs/Usergroups For the recording problem at hand, we’d be able to offer you access to a BigBlueButton (BBB) [0] instance running on a server we own (kindly provided to us by Fosshost). BBB provides server-side recording for all audio and video feeds, and we’ve been using it to record and publish the live Q with EmacsConf speakers without problems. George Mauer writes: > One thing I always mention when conversations about recording come up > is that if you promote recordings as a resource, it is considered good > form to have transcription available. Captions are also something we could help you with! Last year, for EmacsConf 2021, we managed to get almost all the talks captioned before broadcast thanks to our team of volunteers. This year, we’ve improved our process by introducing speech recognition via OpenAI Whisper [1], and we’ve been pretty happy with the results. We’d be happy to help you get set up for captioning too, especially if there’s a great talk you’d like to extract and share. Let me know what you're interested in and we’ll set you up with everything. :) Notes: [0] BigBlueButton (BBB) is FLOSS Video conferencing suite. For details, see: https://bigbluebutton.org/ [1] https://openai.com/blog/whisper/ Best, -- Leo Vivier Freelance Software Developer Website: www.leovivier.com | Blog: www.zaeph.net
[PATCH] lisp/org-persist.el (org-persist-gc): Fix pcase pattern
Hi there,
Quick patch to fix a typo in a pcase pattern which quotes a function.
It results in `(function numberp foo)' when expanded, which in turns
throws `(wrong-number-of-arguments function 2)' when eval’d.
Best,
--
Leo Vivier
Freelance Software Developer
Website: www.leovivier.com | Blog: www.zaeph.net
>From 762d1774fb70313e20951343a7511051a3626cad Mon Sep 17 00:00:00 2001
From: Leo Vivier
Date: Sat, 4 Jun 2022 10:28:07 +0200
Subject: [PATCH] lisp/org-persist.el (org-persist-gc): Fix pcase pattern
* lisp/org-persist.el (org-persist-gc): Fix pcase pattern
Otherwise, `(pred #'numberp)' expands to `(function numberp foo)'
where foo is the first arg of pcase.
---
lisp/org-persist.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/org-persist.el b/lisp/org-persist.el
index ca6ee4f4d..068f58cec 100644
--- a/lisp/org-persist.el
+++ b/lisp/org-persist.el
@@ -929,7 +929,7 @@ Also, remove containers associated with non-existing files."
('t t)
('check-existence
(file-exists-p file))
- ((pred #'numberp)
+ ((pred numberp)
(<= org-persist-remote-files remote-files-num))
(_ nil)))
(setq expired? t)))
--
2.35.1
Re: New website - back to the old unicorn!
Hi there, TEC writes: > These issues have now been fixed! Go wild :P I really like the new design. You’ve done some fantastic work, Timoty, as well as all the people who’ve contributed. :) I especially like the new page for Tools: https://orgmode.org/tools.html The only nitpick I’d have on that page is that we’re grabbing the picture from remote domains, which means that users of uMatrix have to greenlight them before they can be displayed. A solution could be to host them ourselves, which should have a minimal footprint. Best, -- Leo Vivier Freelance Software Engineer Website: www.leovivier.com | Blog: www.zaeph.net
Re: Shower thought: submit an IETF RFC to register Org as a MIME type
Bastien writes: > Sorry, perhaps I was not clear: (1) and (2) do not need to be separate > documents. No, you were quite clear. I just surmised that two documents would be required, but upon thinking about it some more, (1) and (2) would make for a cohesive whole. > Great, thanks for volunteering. I think this is something you should > perhaps do with a long time Org user, ping-pong'ing with commits, not > alone. Sure, I’d be up for that. > Would it be okay for you if we rename worg/dev/org-syntax.org to > something like worg/dev/org-elements-syntax.org or would that be > confusing? Since we already have worg/dev/org-element-api.org [1], I think the rename to worg/dev/org-element-syntax.org would be welcome. Notes : [1] https://orgmode.org/worg/dev/org-element-api.html -- Leo Vivier Freelance Software Engineer Website: www.leovivier.com | Blog: www.zaeph.net
Re: Shower thought: submit an IETF RFC to register Org as a MIME type
Hi there, Bastien writes: > As the first paragraph says: > > "This document describes and comments Org syntax as it is currently > read by its parser (Org Elements)" > > while we need a description of Org's syntax from the point of view of > (1) a human writer and (2) any possible Org parser. I agree that (1) and (2) should be two different documents. (2) would be especially interesting since there are quite a few projects afoot to parse Org documents outside of Emacs: - go-org (Go) https://github.com/niklasfasching/go-org - orgize (Rust) https://docs.rs/orgize/0.8.4/orgize/ They are in various stages of advancement, but a design document would go a long way in federating those efforts. > I don't know how difficult it is, but I suspect it is quite a lot of > work. I assume that it would be, yes. However, as someone with a vested interest in developing an efficient external parser for Org documents, I’d love to contribute. I’ve been playing around lately with ox.el to write an exporter to Jupyter (more on that soon), and since it makes extensive use of org-element.el, I’d have a modicum of knowledge upon which I could initiate the effort. Best, -- Leo Vivier Freelance Software Engineer Website: www.leovivier.com | Blog: www.zaeph.net
Re: a catastrophic orgmode issue - a definite show stopper, put on your tin hats
Hi there, hj-orgmod...@hj.proberto.com writes: > Aliens! Beware! ... We will be looking for Bastien. Give us back our > Bastien, or you will have a war on your hands! Before waging war, please make sure to get a copyright assignment from them. We wouldn’t want to have an intergalactic hold-up on the next release. Best, -- Leo Vivier Freelance Software Engineer Website: www.leovivier.com | Blog: www.zaeph.net
Re: [PATCH] org-capture: Update plist before finalizing
Hi there, Kyle Meyer writes: > Thanks for the detailed write-up and the patch (and sorry for the slow > reply). No worries, and thanks for the review. > It'd be good to at least point to the motivation/usecase for this change > here. (Your description section above already does a nice job of > that.) Done. I’ve also added a link to this thread. > Convention nit: please end your comment with a period. Done. > Perhaps add a brief mention of `org-capture-after-finalize' (or some > other hint of why) here. I’ve added some details to bridge the gap with the docstring for `org-capture-current-plist'. You’ll find the amended commit below. Best, -- Leo Vivier Freelance Software Engineer Website: www.leovivier.com | Blog: www.zaeph.net >From ab47e50dae4029622d3e8378f816f77153c180d9 Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Sat, 25 Jul 2020 21:53:07 +0200 Subject: [PATCH] org-capture: Update plist before finalizing MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * lisp/org-capture.el (org-capture-finalize): Update `org-capture-plist' with local-value before finalizing. We use the global-variable `org-capture-plist' to populate the local-variable `org-capture-current-plist' on the init of the `org-capture' buffer. However, we do not do the opposite (i.e. update the global-variable with the local-variable) on `org-capture-finalize'. This is fine for the majority of `org-capture-finalize', since we’re using the LOCAL arg of `org-capture-get' to read `org-capture-current-plist' instead of `org-capture-list', but this trick does not work for `org-capture-after-finalize', since the hook is run after the `org-capture-buffer' has been closed. This causes problem with `:kill-buffer t', and it limits what can be done with cleanup functions in `org-capture-after-finalize'. See <https://orgmode.org/list/87h7tv9pkm.fsf@hidden/> for details. --- lisp/org-capture.el | 5 + 1 file changed, 5 insertions(+) diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 0ca75c772..b74978c82 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -735,6 +735,11 @@ captured item after finalizing." (run-hooks 'org-capture-prepare-finalize-hook) + ;; Update `org-capture-plist' with the buffer-local value. Since + ;; captures can be run concurrently, this is to ensure that + ;; `org-capture-after-finalize-hook' accesses the proper plist. + (setq org-capture-plist org-capture-current-plist) + ;; Did we start the clock in this capture buffer? (when (and org-capture-clock-was-started org-clock-marker -- 2.28.0
[PATCH] org-capture: Update plist before finalizing
Hi there,
I’m working on the parallelisation of `org-capture' for Org-roam, and
I’ve run into a problem with the updating of `org-capture-plist'.
;;-
;; DESCRIPTION
;;-
We use the global-variable `org-capture-plist' to populate the
local-variable `org-capture-current-plist' on the init of the
`org-capture' buffer. However, we do not do the opposite (i.e. update
the global-variable with the local-variable) on `org-capture-finalize'.
This is fine for the majority of `org-capture-finalize', since we’re
using the LOCAL arg of `org-capture-get' to read
`org-capture-current-plist' instead of `org-capture-list', but this
trick does not work for `org-capture-after-finalize', since the hook is
run after the `org-capture-buffer' has been closed.
This causes problem with `:kill-buffer t', and it limits what can be
done with cleanup functions in `org-capture-after-finalize'.
;;-
;; DEMONSTRATION
;;-
Tested in emacs -Q.
Summary:
- Start a capture process (A)
- Start another capture process (B)
- Cancel B
- Cancel A
Form:
[START]
;; Eval the following form:
(progn
(setq org-capture-templates
'(("a" "foo" plain (file "/tmp/foo.org") "* %?"
:kill-buffer t)
("b" "bar" plain (file "/tmp/bar.org") "* %?"
:kill-buffer t)))
(let* ((a (save-window-excursion
(org-capture nil "a")
(current-buffer)))
(b (save-window-excursion
(org-capture nil "b")
(current-buffer
(with-current-buffer b
(org-capture-kill))
(with-current-buffer a
(org-capture-kill
;; Result: (error "Selecting deleted buffer")
;; `foo.org' is still alive
-[END]-
;;-
;; ANALYSIS
;;-
The problem happens during `org-capture-after-finalize'. A’s
`org-capture-finalize' does not update `org-capture-plist' with the value
of `org-current-capture-plist' during its execution, which means that
`org-capture-plist' still holds B’s value, including :buffer. Since B’s
base-buffer was killed, :buffer points to a killed buffer, which is what
is raising the error.
;;-
;; PATCH
;;-
I propose to update `org-capture-plist' early in `org-capture-finalize'.
I don’t think this would have unforeseen effects, since
`org-capture-list' is already meant to be transient, and we’d only be
expanding its use from init-only to init-and-exit.
HTH,
--
Leo Vivier
>From d14f15ab76d60c3f65837a6d14712dadabf324bf Mon Sep 17 00:00:00 2001
From: Leo Vivier
Date: Sat, 25 Jul 2020 21:53:07 +0200
Subject: [PATCH] org-capture: Update plist before finalizing
* lisp/org-capture.el (org-capture-finalize): Update
`org-capture-plist' with local-value before finalizing.
---
lisp/org-capture.el | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 2cc1ce394..223ed4124 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -728,6 +728,9 @@ captured item after finalizing."
(run-hooks 'org-capture-prepare-finalize-hook)
+ ;; Update `org-capture-plist' with the local-value
+ (setq org-capture-plist org-capture-current-plist)
+
;; Did we start the clock in this capture buffer?
(when (and org-capture-clock-was-started
org-clock-marker
--
2.27.0
Re: [PATCH] org: Update example in docstring to accommodate new name and new format
Hi there, Kyle Meyer writes: > Thanks. Applied (c9abb4c29), adding a period after the changelog > description. Splendid, thank you for the merge, and sorry for the period. > I also added a TINYCHANGE cookie based on your status listed at > <https://orgmode.org/worg/org-contribute.html>. You're bumping up > against the tiny change threshold, so please consider submitting the > copyright assignment paperwork. I have already filled the paperwork, and I will send you the scan in a separate email. Could you move me to the list of current contributors? Thanks. Best, -- Leo Vivier
Re: [PATCH] org: Update example in docstring to accommodate new name and new format
Hi there, Kyle Meyer writes: > Anyway, in my view the example doesn't really add much value. What do > you think about just removing it? Yeah, I agree. I thought it was an interesting way to discover `condition-case' for those who didn’t know about it, so I think we could keep the mention. The example itself can go. Thanks for the review. HTH, -- Leo Vivier >From 48b50f0ebb5d21ca6b337d78a16a203888161d43 Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Mon, 20 Jul 2020 22:11:15 +0200 Subject: [PATCH] org: Remove useless example in docstring * lisp/org.el (org-find-olp): Remove useless example in docstring --- lisp/org.el | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 12a853bd6..9ac513d0c 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -13490,29 +13490,23 @@ completion." '((effort . identity) (effort-minutes . org-duration-to-minutes)) nval) (when (string= org-clock-current-task heading) (setq org-clock-effort nval) (org-clock-update-mode-line))) (run-hook-with-args 'org-property-changed-functions key nval))) (defun org-find-olp (path this-buffer) "Return a marker pointing to the entry at outline path OLP. -If anything goes wrong, throw an error. -You can wrap this call to catch the error like this: - - (condition-case msg - (org-mobile-locate-entry (match-string 4)) -(error (nth 1 msg))) - -The return value will then be either a string with the error message, -or a marker if everything is OK. +If anything goes wrong, throw an error, and if you need to do +something based on this error, you can catch it with +`condition-case'. If THIS-BUFFER is set, the outline path does not contain a file, only headings." (let* ((file (if this-buffer buffer-file-name (pop path))) (buffer (if this-buffer (current-buffer) (find-file-noselect file))) (level 1) (lmin 1) (lmax 1) end found flevel) (unless buffer (error "File not found :%s" file)) -- 2.26.2
Re: [PATCH] org: Update example in docstring to accommodate new name and new format
Hi again, I forgot a closing paren in the previous commit. You’ll find an amended version below, as well as a little more context-lines. Sorry! HTH, -- Leo Vivier >From 01acc00866f14a6e70e3abcb024534c392dc8a27 Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Mon, 20 Jul 2020 22:11:15 +0200 Subject: [PATCH] org: Update docstring * lisp/org.el (org-find-olp): Update example in docstring to accommodate new name and new format --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 12a853bd6..a5d552fc0 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -13494,21 +13494,21 @@ completion." (setq org-clock-effort nval) (org-clock-update-mode-line))) (run-hook-with-args 'org-property-changed-functions key nval))) (defun org-find-olp (path this-buffer) "Return a marker pointing to the entry at outline path OLP. If anything goes wrong, throw an error. You can wrap this call to catch the error like this: (condition-case msg - (org-mobile-locate-entry (match-string 4)) + (org-find-olp (list (match-string 4)) t) (error (nth 1 msg))) The return value will then be either a string with the error message, or a marker if everything is OK. If THIS-BUFFER is set, the outline path does not contain a file, only headings." (let* ((file (if this-buffer buffer-file-name (pop path))) (buffer (if this-buffer (current-buffer) (find-file-noselect file))) (level 1) -- 2.26.2
[PATCH] org: Update example in docstring to accommodate new name and new format
Hi there, I’ve spotted an example in a docstring that wasn’t updated when the command was renamed and moved to another file in d34786f2279d0fd02e7d0484e36bc22adc760de2. I took the liberty to update it. HTH, -- Leo Vivier >From 83dde9d0735cc6223233aa18c938a4ae14b4c88c Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Mon, 20 Jul 2020 22:11:15 +0200 Subject: [PATCH] org: Update docstring * lisp/org.el (org-find-olp): Update example in docstring to accommodate new name and new format --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 12a853bd6..5900e692a 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -13501,7 +13501,7 @@ If anything goes wrong, throw an error. You can wrap this call to catch the error like this: (condition-case msg - (org-mobile-locate-entry (match-string 4)) + (org-find-olp (list (match-string 4) t) (error (nth 1 msg))) The return value will then be either a string with the error message, -- 2.26.2
Re: [PATCH] org-element.el: Fix properties being upcased by parser
Hello, Nicolas Goaziou writes: > Leo Vivier writes: > >> Yeah, I’ve reached the same conclusion, and I agree that we could >> mention the normalisation in a docstring. Do you want me to take care >> of it? > > Sure! Thank you. The patch is attached. HTH, -- Leo Vivier >From e96e96931109026f406b3cabb0186319e902aca7 Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Fri, 12 Jun 2020 06:45:32 +0200 Subject: [PATCH] org-element.el: Update comment * org-element.el (org-element-keyword-parser): Mention that `keyword' is normalized by being upcased --- lisp/org-element.el | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index a5641e6ee..a693cb68d 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -2174,9 +2174,9 @@ the buffer position at the beginning of the first affiliated keyword and CDR is a plist of affiliated keywords along with their value. -Return a list whose CAR is `keyword' and CDR is a plist -containing `:key', `:value', `:begin', `:end', `:post-blank' and -`:post-affiliated' keywords." +Return a list whose CAR is a normalized `keyword' (uppercase) and +CDR is a plist containing `:key', `:value', `:begin', `:end', +`:post-blank' and `:post-affiliated' keywords." (save-excursion ;; An orphaned affiliated keyword is considered as a regular ;; keyword. In this case AFFILIATED is nil, so we take care of -- 2.26.2
[PATCH] org-element.el: Update comment
Hi there, I’ve noticed that a comment on the caching of org-element wasn’t up to date, so I went ahead and updated it. I’ve also fixed a missing quote for one of the variables. HTH, -- Leo Vivier >From bf1fcc1c0650c30e1e12244df084ab344a2cac59 Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Tue, 9 Jun 2020 09:57:03 +0200 Subject: [PATCH] org-element.el: Update comment MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * lisp/org-element.el (org-element-normalize-contents): Update comment The comment mentions that caching for `org-elements' is enabled by default, but this isn’t the case anymore since bbdecd1e64a07b3821714d905a58eaca12828cb6, cf. `org-element-use-cache'. --- lisp/org-element.el | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index ac41b7650..a5641e6ee 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -4821,10 +4821,12 @@ indentation removed from its contents." ;; ;; A single public function is provided: `org-element-cache-reset'. ;; -;; Cache is enabled by default, but can be disabled globally with +;; Cache is disabled by default for now because it sometimes triggers +;; freezes, but it can be enabled globally with ;; `org-element-use-cache'. `org-element-cache-sync-idle-time', -;; org-element-cache-sync-duration' and `org-element-cache-sync-break' -;; can be tweaked to control caching behavior. +;; `org-element-cache-sync-duration' and +;; `org-element-cache-sync-break' can be tweaked to control caching +;; behavior. ;; ;; Internally, parsed elements are stored in an AVL tree, ;; `org-element--cache'. This tree is updated lazily: whenever -- 2.26.2
Re: [PATCH] org-element.el: Fix properties being upcased by parser
Hi there, Nicolas Goaziou writes: > IMO, this is not worth changing. Besides, I'm quite sure it will break > some code elsewhere. Why bother? Yeah, I’ve reached the same conclusion, and I agree that we could mention the normalisation in a docstring. Do you want me to take care of it? Best, -- Leo Vivier
Re: [PATCH] org-element.el: Fix properties being upcased by parser
Hello, Nicolas Goaziou writes: > This is unrelated to capitalization usage in Org buffers. Upcasing is > used to tell the difference between, e.g., :value and :VALUE. I understand, but I think the function is also used to modify file-parameters like `#+title`. If you run `org-element-parse-buffer` on a buffer with the following content: [START] #+title: Foo -[END]- Here’s what you get: [START] (org-data nil (section (:begin 1 :end 14 :contents-begin 1 :contents-end 14 :post-blank 0 :post-affiliated 1 :parent #0) (keyword (:key "TITLE" ; <-- :value "Foo" :begin 1 :end 14 :post-blank 0 :post-affiliated 1 :parent #1 -[END]- This caused us some head-scratching when we updated Org-roam to use lower case file-parameters. Here’s how my Edebug session went: org-element-parse-buffer -> org-element--parse-elements -> org-element--current-element [START] ((looking-at "\\+\\S-+:") (beginning-of-line) (org-element-keyword-parser limit affiliated)) -[END]- Ultimately, it’s not changing anything for the users, but I did find it a little counterintuitive. HTH, -- Leo Vivier
[PATCH] org-element.el: Fix properties being upcased by parser
Hi there, I’ve noticed that `org-element-parser` upcases the keywords, even though the standard established in 13424336a6f30c50952d291e7a82906c1210daf0 is to ‘Prefer lower case letters for blocks and keywords’. I’ve changed it to `downcase` to maintain consistency. This might cause problems with some hard-coded upper case letters in the codebase, but I haven’t run into any issue so far. HTH, -- Leo Vivier >From 574549a1ab07fd1500111a25d3f1caec4aa40bfb Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Mon, 8 Jun 2020 12:14:55 +0200 Subject: [PATCH] org-element.el: Fix properties being upcased by parser MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * org-element.el (org-element-keyword-parser): Downcase properties instead of upcasing them. This is to follow the standard established by 13424336a6f30c50952d291e7a82906c1210daf0 to ‘Prefer lower case letters for blocks and keywords’. TINY CHANGE --- lisp/org-element.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index ac41b7650..e73b37b2b 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -2184,7 +2184,7 @@ containing `:key', `:value', `:begin', `:end', `:post-blank' and (let ((begin (or (car affiliated) (point))) (post-affiliated (point)) (key (progn (looking-at "[ \t]*#\\+\\(\\S-*\\):") - (upcase (match-string-no-properties 1 + (downcase (match-string-no-properties 1 (value (org-trim (buffer-substring-no-properties (match-end 0) (point-at-eol (pos-before-blank (progn (forward-line) (point))) -- 2.26.2
[PATCH] Fix typo in doc
Hello, I’ve spotted a small mistake in the doc. Best, -- Leo Vivier >From b2b2582b4eb1deb1a41f200a17876dfbcbf26b5e Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Sun, 19 Apr 2020 12:01:30 +0200 Subject: [PATCH] * lisp/org.el (org-mode-map): fix typo --- lisp/org-keys.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-keys.el b/lisp/org-keys.el index 066720fdf..d358da763 100644 --- a/lisp/org-keys.el +++ b/lisp/org-keys.el @@ -219,7 +219,7 @@ ;;; Variables (defvar org-mode-map (make-sparse-keymap) - "Keymap fo Org mode.") + "Keymap for Org mode.") (defvaralias 'org-CUA-compatible 'org-replace-disputed-keys) -- 2.26.0
[PATCH] Fix small mistake in doc
Hello, I’ve noticed a small mistake in the doc for `org-time-stamp-inactive`. You’ll find the details in the patch. HTH. Best, -- Leo Vivier >From 021dd8d98b7d8e86fcfdff659cb225be6dc51939 Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Wed, 8 Apr 2020 10:22:20 +0200 Subject: [PATCH] org: Fix doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * lisp/org.el (org-time-stamp-inactive): Change ‘active’ to ‘inactive’ in the doc --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 57682fd16..a46b1c56b 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -13466,7 +13466,7 @@ If the user specifies a time like HH:MM or if this command is called with at least one prefix argument, the time stamp contains the date and the time. Otherwise, only the date is included. -When called with two universal prefix arguments, insert an active time stamp +When called with two universal prefix arguments, insert an inactive time stamp with the current time without prompting the user." (interactive "P") (org-time-stamp arg 'inactive)) -- 2.25.1
Re: [O] [PATCH] Fix narrowed 1-line subtrees
Hello, Samuel Wales writes: > most users and many writers of code are likely to mark a region by > going to bol, not eol. they don't likely think the region should end > before the final newline, in most cases. I don't know about most users, but that's what I do. It's easier to mark the beginning of a region and then `forward-line' your way to the end of the region. > but org calls some outline function or two that grabs or narrows to or > marks a region that is shorter by 1 char than imo it should be. I'm not sure. It might be a case of Stockholm syndrome, but I've found that not including the final newline in the narrowed subtree holds some semantic value, especially when you like to keep your .org files tight with only 1 newline between two headings, i.e. `*Tree 1^J*Tree 2'. When `(org-end-of-subtree t)' lands you somewhere where the hl-line does not extend to the right fringe, it means that you (or a misbehaving commands) haven't introduced any spurious newline. > i reported one bug, which joined two lines [including headers], that > had remained unfixed for many years. > > this is probably because noticing certain types of data corruption /at > the time of corruption/ can sometimes be tricky. thus, linking it to > user behavior or org code changes can be tricky and the bug report > would be like "um, i have no mwe but...". Thank you for your insight. I think this is something we could address with an arsenal of tests. The idea would be to run in a narrowed subtree all the commands which would add or remove content below it. Then, we widen the buffer and check whether the following tree has been corrupted. I'll get on it as soon as I can. > in this particular case, when you did find joined lines, it was likely > to be long after the corruption. [low s/n.] > > the problem was that when you sorted headers in a narrowed region, it > joined lines. the region was off by one because the outline function > is [imo] off by one. > > it would not surprise me if long-term users checked their files now > for joined lines, such as headers, they'd find old corruption. Maybe we could add a function to `org-lint' which would throw a warning when a regex like "\\(\\sw\\|\\s.\\)\\(\\* .*$\\)" matches something. With the following structure: [START] * Test 1* Corrupted 1 * Test 2 With text in the body.* Corrupted 2 * Test 3 * Not corrupted -[END]- The regex correctly matches `Corrupted 1' and `Corrupted 2', but we'd obviously need to find a way to make it safer. But as it stands, it could be used as a way to address past corruptions. So, to recap: 1. We address *potential corruptions* by adding more tests in order to catch them before they get a chance to corrupt anything. 2. We address *past corruptions* by adding a function to `org-lint' which catches corrupted subtrees and throw a warning. HTH. Best, -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2
Re: [O] [PATCH] Fix narrowed 1-line subtrees
Hello, Samuel Wales writes: > i have not been able to follow this conversation, but is it possible > that /all/ of this complexity is due to outline-mode's dubious choice > of not considering the final newline in an entry to be part of an > entry? I don't know much about outline-mode, but I doubt it would be the case. In my email sent on Thu, 21 Feb 2019 16:41:43 +0100, I've investigated the problem, and one of my conclusions was the following: [START] Going back to our example, if narrowing to a 1-line subtree included that last newline, we could delete it inside our narrowed buffer. If that newline was also the beginning of a new subtree, the subtree would not be functional anymore, since we'd end up with something like this: `*Subtree 1* Subtree 2'. -[END]- So, if we kept the newline, we'd put the user at risk of breaking the following subtree. An option could be to protect that newline by modifying our deletion commands, but after having done that in a previous implementation, it'd bring its fair share of complexity. >From my point of view, I do not see it as 'complex', but rather as a different way from doing what we'd been doing so far. Most of the functions are only *slightly* modified to preserve the ambiguous newline. HTH. Best, -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2
Re: [O] [PATCH] Fix narrowed 1-line subtrees
Hello again,
Leo Vivier writes:
> You'll find those three patches at the bottom alongside another with all
> the patches until now squashed together (except the patch for
> `org-remove-timestamp-with-keyword' which wasn't related).
I ended up sending the wrong patch, i.e. the one for
`org-remove-timestamp-with-keyword'. You'll find the squashed patch
below.
Sorry for that.
Best,
--
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2
>From c00c911f06ba059b61d8246f25e679f06a8f8491 Mon Sep 17 00:00:00 2001
From: Leo Vivier
Date: Thu, 21 Feb 2019 00:16:27 +0100
Subject: [PATCH] Fix narrowed 1-line subtrees (squashed)
* lisp/org.el (org-add-planning-info): Ensure insertion in current
restriction.
(org-remove-timestamp-with-keyword): Respect ambiguous newline when
narrowed to 1-line-subtree.
(org-remove-empty-drawer-at): Respect ambiguous newline when
narrowed to 1-line subtree.
(org-entry-delete): Respect ambiguous newline when narrowed to
1-line subtree.
(org-log-beginning): Ensure insertion in current restriction.
(org-store-log-note): Ensure insertion in current restriction.
* lisp/org-clock.el (org-clock-find-position): Ensure clock-drawer
insertion in current restriction.
(org-clock-in): Ensure insertion in current
restriction.
This patch addresses multiple issues occuring when running commands on
a 1-line subtree when the buffer is narrowed to it. A 1-line subtree
is a subtree only containing a heading and a newline at the end.
Typical problem:
---
* Tree 1
:PROPERTIES:
:TEST: t
:END:
* Tree 2
---
With point on `Tree 1', run the following:
(progn
(org-narrow-to-subtree)
(org-delete-property "TEST")
(org-back-to-heading)
(end-of-line)
(delete-char 1)
(widen))
Result:
---
* Tree 1* Tree 2
---
Observation:
The newline between the two headings has been removed despite the fact
that it wasn't in the buffer restriction.
The problem is due to two things:
- The way that narrowing works in Emacs, notably how restrictions are
restored after `save-restriction'.
- The ambiguous newline between the end of a 1-line subtree and a
following subtree.
The solution is to stop the problematic commands from interacting with
the ambiguous newline in order to preserve the narrowed region's
`point-max'. This is done by inserting or removing newlines from
the top of a heading rather than its bottom.
Visually, instead of deleting the following bracketed region...
---
* Tree 1
{:PROPERTIES:
:TEST: t
:END:
}* Tree 2
---
We delete the following one:
---
* Tree 1{
:PROPERTIES:
:TEST: t
:END:}
* Tree 2
---
org-log-beginning: Fix drawer creation
* lisp/org.el
This commit ensures that the log-drawer for state-changes and notes is
created within the current restriction.
org-store-log-note: Fix drawer-less logging
* lisp/org.el (org-log-beginning):
---
lisp/org-clock.el | 14 --
lisp/org.el | 27 +++
2 files changed, 23 insertions(+), 18 deletions(-)
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index b20158df6..5c9b0a1cf 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -1292,6 +1292,7 @@ the default behavior."
(org-todo org-clock-in-switch-to-state)))
(setq org-clock-heading (org-clock--mode-line-heading))
(org-clock-find-position org-clock-in-resume)
+ (forward-char -1)
(cond
((and org-clock-in-resume
(looking-at
@@ -1315,8 +1316,8 @@ the default behavior."
(sit-for 2)
(throw 'abort nil))
(t
- (insert-before-markers "\n")
- (backward-char 1)
+ (insert "\n")
+ (org-indent-line)
(org-indent-line)
(when (and (save-excursion
(end-of-line 0)
@@ -1508,12 +1509,13 @@ line and position cursor in that line."
(when (and org-clock-into-drawer
(or (not (wholenump org-clock-into-drawer))
(< org-clock-into-drawer 2)))
- (let ((beg (point)))
- (insert ":" drawer ":\n:END:\n")
+ (let ((beg (1- (point
+ (forward-char -1)
+ (insert "\n:" drawer ":\n:END:")
(org-indent-region beg (point))
(org-flag-region
- (line-end-position -1) (1- (point)) t 'org-hide-drawer)
- (forward-line -1
+ (line-end-position 0) (point) t 'org-hide-drawer)
+ (beginning-of-line
;; When a clock drawer needs to be
Re: [O] [PATCH] Fix narrowed 1-line subtrees
Hello, I've found and fixed three new functions which didn’t behave properly when the buffer was restricted to a subtree: * lisp/org.el (org-log-beginning): Fix drawer creation. * lisp/org.el (org-store-log-note): Fix drawer-less logging. * lisp/org-capture.el (org-clock-in): Fix drawer-less clocking. You'll find those three patches at the bottom alongside another with all the patches until now squashed together (except the patch for `org-remove-timestamp-with-keyword' which wasn't related). HTH. Best, -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2 >From 745e106406a5f5b296bbd9dbda9f9dbd965a2e30 Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Fri, 22 Feb 2019 18:03:24 +0100 Subject: [PATCH 1/3] org-log-beginning: Fix drawer creation * lisp/org.el (org-log-beginning): Ensure insertion in current restriction. This commit ensures that the log-drawer for state-changes and notes is created within the current restriction. --- lisp/org.el | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 4c3c3cd78..f22f8b807 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -13118,12 +13118,13 @@ narrowing." ;; No drawer found. Create one, if permitted. (when create (unless (bolp) (insert "\n")) - (let ((beg (point))) - (insert ":" drawer ":\n:END:\n") + (let ((beg (1- (point + (forward-char -1) + (insert "\n:" drawer ":\n:END:") (org-indent-region beg (point)) (org-flag-region - (line-end-position -1) (1- (point)) t 'org-hide-drawer)) - (end-of-line -1) + (line-end-position 0) (point) t 'org-hide-drawer)) + (end-of-line 0) (t (org-end-of-meta-data org-log-state-notes-insert-after-drawers) (skip-chars-forward " \t\n") -- 2.20.1 >From c94c86fdac09a97267c29f7e3d4dcf5c3398 Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Fri, 22 Feb 2019 18:17:35 +0100 Subject: [PATCH 2/3] org-store-log-note: Fix drawer-less logging * lisp/org.el (org-log-beginning): Ensure insertion in current restriction. This commit ensures that drawer-less state-changes and notes are created within the current restriction. --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index f22f8b807..27cd2bbd7 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -13263,7 +13263,7 @@ EXTRA is additional text that will be inserted into the notes buffer." ;; Note associated to a clock is to be located right after ;; the clock. Do not move point. (unless (eq org-log-note-purpose 'clock-out) - (goto-char (org-log-beginning t))) + (goto-char (1- (org-log-beginning t ;; Make sure point is at the beginning of an empty line. (cond ((not (bolp)) (let ((inhibit-read-only t)) (insert "\n"))) ((looking-at "[ \t]*\\S-") (save-excursion (insert "\n" -- 2.20.1 >From 2fc86ae438725e5f0656c8966eaa4935e0203ee4 Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Fri, 22 Feb 2019 18:23:40 +0100 Subject: [PATCH 3/3] org-clock-in: Fix drawer-less clocking * lisp/org-clock.el (org-clock-in): Ensure insertion in current restriction. This commit ensures that drawer-less clock-lines are created within the current restriction. --- lisp/org-clock.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 5624af32a..5c9b0a1cf 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -1292,6 +1292,7 @@ the default behavior." (org-todo org-clock-in-switch-to-state))) (setq org-clock-heading (org-clock--mode-line-heading)) (org-clock-find-position org-clock-in-resume) + (forward-char -1) (cond ((and org-clock-in-resume (looking-at @@ -1315,8 +1316,8 @@ the default behavior." (sit-for 2) (throw 'abort nil)) (t - (insert-before-markers "\n") - (backward-char 1) + (insert "\n") + (org-indent-line) (org-indent-line) (when (and (save-excursion (end-of-line 0) -- 2.20.1 >From bb5a7feee1684cf47f1e8a29805c442c8ae64c37 Mon Sep 17 00:00:00 2001 From: Leo Vivier Date: Thu, 21 Feb 2019 12:44:26 +0100 Subject: [PATCH] Fix spaces with `org-remove-timestamp-with-keyword' MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * lisp/org.el (org-remove-timestamp-with-keyword): Fix space deletion between timestamps When an entry had a CLOSED, a DEADLINE and a SCHEDULED timestamps, removing the middle one caused the space between the 1st and 3rd to be removed as well. Checking whether we’re at the end of the line before deleting the space fixes it. --- lisp/org.el | 1 + 1 file changed, 1 insertion(+) diff --git a/lisp/org.el b/lisp/org.el index ef6e40ca9..b8e378e73 100644 ---
[O] [PATCH] Fix spaces with `org-remove-timestamp-with-keyword'
* lisp/org.el (org-remove-timestamp-with-keyword): Fix space deletion between timestamps When an entry had a CLOSED, a DEADLINE and a SCHEDULED timestamps, removing the middle one caused the space between the 1st and 3rd to be removed as well. Checking whether we’re at the end of the line before deleting the space fixes it. --- Here’s a little unrelated patch for an issue I’ve stumbled upon whilst testing the previous patch. lisp/org.el | 1 + 1 file changed, 1 insertion(+) diff --git a/lisp/org.el b/lisp/org.el index ae9494672..4c3c3cd78 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -12944,6 +12944,7 @@ nil." (while (re-search-backward re beg t) (replace-match "") (if (and (string-match "\\S-" (buffer-substring (point-at-bol) (point))) +(eolp) (equal (char-before) ?\ )) (backward-delete-char 1) (when (string-match "^[ \t]*$" (buffer-substring -- 2.20.1
Re: [O] [PATCH] Fix narrowed 1-line subtrees
e previous restriction,
`save-restriction' looks for those special characters and try to
include them all inside the new restriction. Practically, this is
done by looking for the first and last characters with that special
property and using them as the new `point-min' and `point-max'.
This last bit is important to understand why the second example with
the :PROPERTIES: drawer didn't behave properly. The original command
deletes the drawer from the ambiguous newline to the bottom of the
heading, which means that the newline at the end of the heading isn't
touched. When `save-restriction' attempts to resume the previous
narrowing, since the former `point-max' has been deleted (it was the
`:' at the end of the :PROPERTIES: drawer), it looks for the first
special character. But the problem is that this first character is the
bottom of the heading, and that it has now become ambiguous.
The solution is the same: we do not touch the ambiguous newline.
Instead, we delete the newline at the end of the heading so that upon
restoring the restriction, it becomes the last special character.
Visually, instead of deleting the following bracketed region...
[START]
* Tree 1
{:PROPERTIES:
:TEST: t
:END:
}* Tree 2
-[END]-
We delete the following one:
[START]
* Tree 1{
:PROPERTIES:
:TEST: t
:END:}
* Tree 2
-[END]-
It's likely that I haven't addressed all the commands that do not play
well with the ambiguous newlines. However, the solutions I've
presented here should be enough to address them.
---
HTH
Best,
--
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2
[O] [PATCH] Fix narrowed 1-line subtrees
* lisp/org.el (org-add-planning-info): Ensure insertion in current
restriction.
(org-remove-timestamp-with-keyword): Respect ambiguous newline when
narrowed to 1-line-subtree.
(org-remove-empty-drawer-at): Respect ambiguous newline when
narrowed to 1-line subtree.
(org-entry-delete): Respect ambiguous newline when narrowed to
1-line subtree.
* lisp/org-clock.el (org-clock-find-position): Ensure clock-drawer
insertion in current restriction.
This patch addresses multiple issues occuring when running commands on
a 1-line subtree when the buffer is narrowed to it. A 1-line subtree
is a subtree only containing a heading and a newline at the end.
Typical problem:
---
* Tree 1
:PROPERTIES:
:TEST: t
:END:
* Tree 2
---
With point on `Tree 1', run the following:
(progn
(org-narrow-to-subtree)
(org-delete-property "TEST")
(org-back-to-heading)
(end-of-line)
(delete-char 1)
(widen))
Result:
---
* Tree 1* Tree 2
---
Observation:
The newline between the two headings has been removed despite the fact
that it wasn't in the buffer restriction.
The problem is due to two things:
- The way that narrowing works in Emacs, notably how restrictions are
restored after `save-restriction'.
- The ambiguous newline between the end of a 1-line subtree and a
following subtree.
The solution is to stop the problematic commands from interacting with
the ambiguous newline in order to preserve the narrowed region's
`point-max'. This is done by inserting or removing newlines from
the top of a heading rather than its bottom.
Visually, instead of deleting the following bracketed region...
---
* Tree 1
{:PROPERTIES:
:TEST: t
:END:
}* Tree 2
---
We delete the following one:
---
* Tree 1{
:PROPERTIES:
:TEST: t
:END:}
* Tree 2
---
---
Please see my reply to this message for a detailed account of the
problem and the solution.
lisp/org-clock.el | 9 +
lisp/org.el | 16 +---
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index b20158df6..5624af32a 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -1508,12 +1508,13 @@ line and position cursor in that line."
(when (and org-clock-into-drawer
(or (not (wholenump org-clock-into-drawer))
(< org-clock-into-drawer 2)))
- (let ((beg (point)))
- (insert ":" drawer ":\n:END:\n")
+ (let ((beg (1- (point
+ (forward-char -1)
+ (insert "\n:" drawer ":\n:END:")
(org-indent-region beg (point))
(org-flag-region
- (line-end-position -1) (1- (point)) t 'org-hide-drawer)
- (forward-line -1
+ (line-end-position 0) (point) t 'org-hide-drawer)
+ (beginning-of-line
;; When a clock drawer needs to be created because of the
;; number of clock items or simply if it is missing, collect
;; all clocks in the section and wrap them within the drawer.
diff --git a/lisp/org.el b/lisp/org.el
index ef6e40ca9..ae9494672 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -12937,7 +12937,7 @@ nil."
"Remove all time stamps with KEYWORD in the current entry."
(let ((re (concat "\\<" (regexp-quote keyword) " +<[^>\n]+>[ \t]*"))
beg)
-(save-excursion
+(org-with-wide-buffer
(org-back-to-heading t)
(setq beg (point))
(outline-next-heading)
@@ -12949,7 +12949,8 @@ nil."
(when (string-match "^[ \t]*$" (buffer-substring
(point-at-bol) (point-at-eol)))
(delete-region (point-at-bol)
- (min (point-max) (1+ (point-at-eol))
+ (point-at-eol)
+ (delete-char -1
(defvar org-time-was-given) ; dynamically scoped parameter
(defvar org-end-time-was-given) ; dynamically scoped parameter
@@ -13046,8 +13047,8 @@ 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)
+ (insert "\n")
(when org-adapt-indentation
(indent-to-column (1+
Re: [O] [PATCH 1/2] Fix narrowing for 1-line subtrees
Hello, Nicolas Goaziou writes: > Thank you. It looks good. Could you write a few tests about that? I’ve never done it, but it should be pretty easy to figure out how to write them with all the macros. I’ll look into it. I’ll also continue the work on the patch to figure out how to handle the condition tree for `org-add-planing-info'. I’ll update you when I’ve made progress. Thanks. 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] [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
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] [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 ( 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 ( 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 ( 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 "Not in a block"
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 ( 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 problems
* lisp/org-capture.el (org-capture-narrow): Fix point position after narrowing. * lisp/org-keys.el (org-remap): Remove remaps for `kill-buffer' and `kill-buffer-and-window'. * lisp/org.el (org-tree-check-narrowing): Use `kill-buffer-hook' instead of wrappers for kill-region commands. (org-kill-region): Add docstring. There was a problem in org-capture with templates which didn't specify `%?'. It was due to the position of the point upon exiting `org-capture-narrow' which caused the `search-backward' and `search-forward' at the end of `org-capture-place-entry' to potentially act on region outside the viewport. I've moved away from wrappers for `kill-buffer' and `kill-buffer-and-window' in favour of a hook to `kill-buffer-hook'. Problems would have been likely to arise with user-written commands using `kill-buffer' instead of `org-kill-buffer' (it did for me). Running `org-tree-check-narrowing' at `kill-buffer-hook' avoids this problem and is a lot more convenient. There's also a minor problem which I do not know if we can address. When the user switches between an indirect buffer and the buffer which spawned it, the last newline of the subtree isn't protected in the spawning buffer. Deleting that newline in the spawning buffer also deletes it in the indirect buffer, thereby undermining all our efforts to protect it. However, if that's the only edge case we have to deal with, I'd consider it a minor nuisance. --- lisp/org-capture.el | 14 +++--- lisp/org-keys.el| 2 -- lisp/org.el | 40 +--- 3 files changed, 20 insertions(+), 36 deletions(-) diff --git a/lisp/org-capture.el b/lisp/org-capture.el index ff3134fb4..fbc601875 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -1416,14 +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) -(goto-char beg) (narrow-to-region - beg - (progn (org-end-of-subtree t t) -(when (and (org-at-heading-p) (not (eobp))) - (backward-char 1) - (insert "\n")) -(point) + (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 ( 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 0f4fd5b6d..26a3852b3 100644 --- a/lisp/org-keys.el +++ b/lisp/org-keys.el @@ -533,8 +533,6 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command names." 'delete-backward-char 'org-delete-backward-char 'kill-line 'org-kill-line 'kill-region'org-kill-region - 'kill-buffer'org-kill-bufer - 'kill-buffer-and-window 'org-kill-buffer-and-window 'widen 'org-widen 'open-line 'org-open-line 'yank 'org-yank diff --git a/lisp/org.el b/lisp/org.el index ef86423e8..7846a27b7 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. @@ -7442,27 +7450,6 @@ frame is not changed." (make-indirect-buffer buffer bname 'clone) (error (make-indirect-buffer buffer bname) -(defun org-kill-buffer ( buffer-or-name) - "Kill the buffer specified by BUFFER-OR-NAME. -The argument may be a buffer or the name of an existing buffer. -Argument nil or omitted means kill the current buffer. Return t if the -buffer is actually killed, nil otherwise. - -Wrapper for org. See `kill-buffer' for more info." - (interactive) - (when (buffer-base-buffer) -(org-widen)) - (kill-buffer buffer-or-name)) - -(defun org-kill-buffer-and-window () - "Kill the current buffer and delete the selected window. - -Wrapper for org. See `kill-buffer-and-window' for more
[O] [PATCH] Fix other commands for exiting narrowing (2)
* lisp/org.el (org-toggle-narrow-to-subtree): Different interactive calls and use wrapper for widen --- Same deal as the last email. Sorry for only noticing those commands now; I don't use them in my workflow. The change in `interactive' is to ensure that only the interactive calls to `org-narrow-to-subtree' produce the last newline. lisp/org.el | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 292807138..ef86423e8 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -8421,12 +8421,12 @@ end of the narrowed tree." (when newline (insert "\n"))) (point))) -(defun org-toggle-narrow-to-subtree () +(defun org-toggle-narrow-to-subtree ( 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." -- 2.20.1
[O] [PATCH] Fix other commands for exiting narrowing
* lisp/org.el (org-kill-buffer): Create a wrapper for kill-buffer to handle last newline deletion. (org-kill-buffer-and-window): Create a wrapper for kill-buffer-and-window to handle last newline deletion. * lisp/org-keys.el (org-remap): Remap kill-buffer and kill-buffer-and-window to org wrappers. --- I'd forgotten to patch the commands for exiting indirect buffers spawned by `org-tree-to-indirect-buffer'. This needs to be squashed with the first commit. Sorry for the bother. lisp/org-keys.el | 2 ++ lisp/org.el | 21 + 2 files changed, 23 insertions(+) diff --git a/lisp/org-keys.el b/lisp/org-keys.el index 26a3852b3..0f4fd5b6d 100644 --- a/lisp/org-keys.el +++ b/lisp/org-keys.el @@ -533,6 +533,8 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command names." 'delete-backward-char 'org-delete-backward-char 'kill-line 'org-kill-line 'kill-region'org-kill-region + 'kill-buffer'org-kill-bufer + 'kill-buffer-and-window 'org-kill-buffer-and-window 'widen 'org-widen 'open-line 'org-open-line 'yank 'org-yank diff --git a/lisp/org.el b/lisp/org.el index 02130ab6a..292807138 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7442,6 +7442,27 @@ frame is not changed." (make-indirect-buffer buffer bname 'clone) (error (make-indirect-buffer buffer bname) +(defun org-kill-buffer ( buffer-or-name) + "Kill the buffer specified by BUFFER-OR-NAME. +The argument may be a buffer or the name of an existing buffer. +Argument nil or omitted means kill the current buffer. Return t if the +buffer is actually killed, nil otherwise. + +Wrapper for org. See `kill-buffer' for more info." + (interactive) + (when (buffer-base-buffer) +(org-widen)) + (kill-buffer buffer-or-name)) + +(defun org-kill-buffer-and-window () + "Kill the current buffer and delete the selected window. + +Wrapper for org. See `kill-buffer-and-window' for more info." + (interactive) + (when (buffer-base-buffer) +(org-widen)) + (kill-buffer-and-window)) + (defun org-set-frame-title (title) "Set the title of the current frame to the string TITLE." (modify-frame-parameters (selected-frame) (list (cons 'name title -- 2.20.1
[O] [PATCH 1/2] Fix narrowing for 1-line subtrees
* lisp/org.el (org-narrow-to-subtree): Ensure newline at end of subtree. (org-tree-to-indirect-buffer): Ensure newline at end of subtree. (org-widen): Create wrapper for `widen' to handle end newline. * lisp/org-capture.el (org-capture-finalize): Replace `widen' with `org-widen'. (org-capture-narrow): Ensure newline at end of subtree. * lisp/org-keys.el (org-remap): Remap `widen' to `org-widen'. There was a problem with narrowed 1-line subtrees which caused clocking and scheduling commands to print their modifications outside of the current narrowing, e.g. `org-clock-in'. This also prevented some commands from working as expected, e.g. `org-clock-out-when-done', since the clock-drawer isn't visible. Previous commits have addressed this problem by patching those commands to act on a widened buffer within a `save-restriction' environment (cf. 8fc22d464, 503ede74b, and 6872088c7) but this does not address the original problem, namely the modifications not being visible in the narrowed buffer. 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: - 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. --- This is an implementation of the solution I've discussed in 'Bug: org-clock commands spawn drawer outside of narrowing' on Fri, 15 Feb 2019 09:48:00 +0100. I've tried it with `emacs -q' and with different numbers of blank-lines between headings, and I haven't encountered any problem so far. The code doesn't make any assumption about how many lines you should have between your headings, which means that it shouldn't interfere with `org-blank-before-new-entry'. If there are more idiomatic ways to write some of the functions, please let me know. Thank you. lisp/org-capture.el | 12 +--- lisp/org-keys.el| 1 + lisp/org.el | 26 +- 3 files changed, 31 insertions(+), 8 deletions(-) diff --git a/lisp/org-capture.el b/lisp/org-capture.el index debf1808c..ff3134fb4 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))) +(goto-char beg) +(narrow-to-region + beg + (progn (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 ( 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..90e8139b0 100644 --- a/lisp/org-keys.el +++ b/lisp/org-keys.el @@ -532,6 +532,7 @@ 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 + '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 ebec2befa..3110f14ba 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7391,7 +7391,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
[O] [PATCH 2/2] Prevent deletion of newline added by narrowing
* lisp/org.el (org-delete-backward-char): Prevent deletion of newline added by narrowing (org-delete-char): Prevent deletion of newline added by narrowing (org-kill-line): Prevent deletion of newline added by narrowing (org-kill-region): Create wrapper for `kill-region' to prevent deletion of newline added by narrowing * lisp/org-keys.el (org-remap): Remap `kill-region' to `org-kill-region' This ensures that the newline added by the narrowing commands cannot be deleted by the user. It does so by having every interactive deletion command check whether it would delete the last newline of a narrowed buffer. If it would, the new command deletes whatever the original command normally would but keep the last newline. If the original command would have resulted in a movement, e.g. `org-delete-backward-char', the new command also moves the point as if the last newline had been deleted. --- lisp/org-keys.el | 1 + lisp/org.el | 28 2 files changed, 25 insertions(+), 4 deletions(-) diff --git a/lisp/org-keys.el b/lisp/org-keys.el index 90e8139b0..26a3852b3 100644 --- a/lisp/org-keys.el +++ b/lisp/org-keys.el @@ -532,6 +532,7 @@ 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 diff --git a/lisp/org.el b/lisp/org.el index 3110f14ba..02130ab6a 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -18851,7 +18851,11 @@ because, in this case the deletion might narrow the column." (looking-at-p ".*?|") (org-at-table-p)) (progn (forward-char -1) (org-delete-char 1)) - (backward-delete-char N) + (if (and (eobp) + (save-excursion (forward-char -1) + (looking-at "\n"))) + (forward-char -1) +(backward-delete-char N)) (org-fix-tags-on-the-fly (defun org-delete-char (N) @@ -18868,7 +18872,9 @@ because, in this case the deletion might narrow the column." (eq (char-after) ?|) (save-excursion (skip-chars-backward " \t") (bolp)) (not (org-at-table-p))) - (delete-char N) + (unless (and (save-excursion (forward-char) (eobp)) +(looking-at "\n")) + (delete-char N)) (org-fix-tags-on-the-fly)) ((looking-at ".\\(.*?\\)|") (let* ((update? org-table-may-need-update) @@ -22301,8 +22307,12 @@ depending on context." (user-error (substitute-command-keys "`\\[org-kill-line]' aborted as it would kill a hidden subtree"))) -(call-interactively - (if (bound-and-true-p visual-line-mode) 'kill-visual-line 'kill-line))) +(unless (and (looking-at-p "\n") +(save-excursion + (forward-char 1) + (eobp))) + (call-interactively + (if (bound-and-true-p visual-line-mode) 'kill-visual-line 'kill-line ((org-match-line org-tag-line-re) (let ((end (save-excursion (goto-char (match-beginning 1)) @@ -22314,6 +22324,16 @@ depending on context." (org-align-tags)) (t (kill-region (point) (line-end-position) +(defun org-kill-region (beg end region) + (interactive (list (mark) (point) 'region)) + (kill-region + beg + end + region) + (save-excursion +(when (eobp) + (insert "\n" + (defun org-yank ( arg) "Yank. If the kill is a subtree, treat it specially. This command will look at the current kill and check if is a single -- 2.20.1
Re: [O] [PATCH] org.el: Fix newline at eob in org-insert-heading
Hello, Nicolas Goaziou writes: >> The problem is due to `eobp' returning t when point is on the last >> character of the narrowed buffer (as explained in its docstring). >> Since those `eobp' predicates in `org-insert-heading' are probably >> there to ensure a newline at the end of the *file*, checking whether >> the buffer is *narrowed* (with `buffer-narrowed-p') prior to inserting >> the newline fixes the problem. > > I don't think this would be a sufficient fix, because the buffer can be > narrowed and, yet, showing the end of the file. Yes, this is also something that I noticed, and I’d sent another patch that address issue as a reply to the original email. However, not knowing whether to submit the patch as is, squash it with the previous one, or send it as a new thread altogether, I ended doing a clumsy job. If you check it, you’ll see at the end of the commit message an appended note on that issue. > Anyway, I don't think this final newline is needed. I removed it. This > should fix your issue. Please let me know if you encounter other > glitches in that area. Thank you. I’ll let you know if I encounter anything unexpected. Best, P.S.: I’d sent the patches with the wrong email. This is now resolved. -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2
Re: [O] Bug: Bug: org-clock commands spawn drawer outside of narrowing [9.2.1 (9.2.1-2-gc6d37c-elpaplus @ /home/zaeph/.emacs.d/elpa/org-plus-contrib-20190204/)]
Hello, I’d forgotten to CC the list in my previous message, so I’ve included all the context from our two previous emails. Nicolas Goaziou writes: > Leo Vivier writes: > >> You’re right, that’s the behaviour we would expect from M-RET. However, >> with C-RET, the new heading should respect the content of the tree at >> point. > > I disagree. C-RET is expected to move point, so it should obviously > operate on the accessible part of the buffer. > > The only other option, AFAICT, would be to automatically widen the > buffer, which would be most surprising. > >> Even though this is an expected behaviour with narrowed buffers, maybe >> we could find a way to work around this limitation. The reason I’m >> suggesting this is because I often find myself dealing with 1-line tree >> which are meaningful parts of my documents. > > Then you ought to include the final newline character in the narrowed > part of the buffer. It mitigate some issues you are encountering. Including the final newline mitigates most of the problems I’m encountering, you’re right, but I have two issues with this solution: - ‘org-narrow-to-subtree’ does not do that by default (although it’d probably be easy to patch in a conditional behaviour). - The included newline isn’t protected, meaning that the user can delete it without warning. MWE: [START] * Inbox ** Captured task * Tree -[END]- - Narrow to ‘* Captured task^J’ (i.e. including the new-line at eol). This is the state we’d have with a patched org-narrow-to-subtree. - ‘(end-of-buffer)’ - ‘(delete-char 1)’ - ‘(widen)’ Result: [START] * Inbox ** Captured task*Tree -[END]- Since the line is visible in the buffer, it follows that the user is able to delete it, but I wonder if that’s something s/he’d ever want to do. This goes back to the tentative solution I’ve mentioned in my previous email. >> I’m aware that this problem only affects people who do not have >> empty-lines between their trees. However, 90% of the time, those 1-line >> trees are the result of simple org-capture templates on which no work >> has been done. When the time comes, I access them from the agenda with >> ‘org-agenda-tree-to-indirect-buffer’. I have no way to know that the >> buffer is narrowed char-wise rather than line-wise. So, when >> clocking-in on that tree, it doesn’t feel right that the clock-table >> should be spawned outside of the view-port. >> > > I'm not sure about "this problem" you're talking about. You are > encountering different "problems". Some are certainly genuine bugs, but > not all of them, per above. In any case, please report them precisely so > we can see if there is something to fix, piece-wise. I’ll make sure to specify those behaviours, then. >> Since the problem only happens with 1-line trees, a tentative solution >> could be the following: >> - When evaluating ‘org-narrow-to-subtree’ or >>‘org-agenda-tree-to-indirect-buffer’ >>1. Check whether the tree being considered is a 1-line tree. >>2. If t: Add a newline at the end of the heading. >> (This bypasses the narrowing limitation.) >>3. Store the result of the check in a local variable. >> - When evaluating ‘widen’ inside commands like ‘org-capture-finalize’ >>1. Check whether the local variable mentioned above is set and true. >>2. If t: Remove newline at the end of the narrowed buffer if it still >> exists. >> >> If this solution seems sound, I could work on it and submit a patch. >> >>>> - `org-clock-out-when-done` isn’t respected since the drawer is not >>>> visible >>> >>> This is a bug. I fixed it. >> >>Thank you for the fix. Thanks for your help. Best, -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2
[O] Bug: Bug: org-clock commands spawn drawer outside of narrowing [9.2.1 (9.2.1-2-gc6d37c-elpaplus @ /home/zaeph/.emacs.d/elpa/org-plus-contrib-20190204/)]
Hello, Version info: - Emacs : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30), of 2018-07-05 - Package: Org mode version 9.2.1 (9.2.1-2-gc6d37c-elpaplus) The bug only happens in narrowed org-mode buffers when the tree at point (or targeted by the resolving) is a single line not followed by a blank line. I was able to replicate the problem with `emacs -q`. MWE: [START] * Tree 1 * Tree 2 -[END]- - Narrow to ‘Tree 1’l - Clock in. Observations: - No clock drawer visible in the narrowed buffer. - Feedback in the minibuffer that the clock was started. - Widening the buffer confirms the presence of the buffer where it should be. Whilst the observations would lead one to think that everything ‘Just Works™’, it causes a slew of problems. Two examples: - After clocking in, adding a new heading ‘Subtree’ bellow ‘Tree 1’ would make the drawer belong to ‘Subtree’ instead of ‘Tree 1’ - `org-clock-out-when-done` isn’t respected since the drawer is not visible It seems to be part of a larger set of bugs related to single-line trees, such as the one I’d reported before and which was addressed in 503ede74bc0a1db59fd2fb7bac0bf1ba7352d15b. I tried to fix it on my own by tracking down the problem with edebug, and that led me to the `save-restriction` used in `org-clock-in`, `org-clock-out`, and `org-clock-resolve-clock`. Those calls to `save-restriction` are sometimes embedded into macros, such as `org-with-wide-buffer` or `org-with-point-at`. I initially thought that replacing those calls in favour of a `widen` followed by a `org-narrow-to-subtree` would refresh the bounds of the narrowing. This proved to be a lot more finicky than I anticipated, and I’d hate to break anything. Would you be able to look into it? Thank you for your time, -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2
[O] [PATCH] org.el: Fix newline at eob in org-insert-heading
* lisp/org.el (org-insert-heading): Check if narrowed before inserting newline at eob When narrowed into an org-buffer (e.g. when capturing), adding a new heading with C- or M- on the last line of a buffer (i.e. that not without a newline at the end) would result in the insertion of a newline at the bottom of the narrowed capture buffer. - C-: `org-insert-heading-respect-content' - M-: `org-meta-return' Both functions use `org-insert-heading' in their definitions. The problem is due to `eobp' returning t when point is on the last character of the narrowed buffer (as explained in its docstring). Since those `eobp' predicates in `org-insert-heading' are probably there to ensure a newline at the end of the *file*, checking whether we are at the end of the *widened* buffer prior to inserting the newline fixes the problem. The patch I'd originally submitted failed to address narrowed buffer whose `(max-pos)` was also that of the widened buffer. Rather than using `(buffer-narrowed-p)`, I opted for a `(widen)` followed by `(eobp)`. TINYCHANGE --- I was able to replicate the problem with `emacs -q`, so the problem doesn't seem to come from custom options in my own setup. The problematic lines were inserted in the following commit: b16feed40c7f519ada0cd9315251dcc257be31d2 . Their goal was to C- more predictable, and I don't think I've modified that behaviour in a any way. Let me know if you'd rather have me squash the changes. lisp/org.el | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 7e74c2199..fef13f818 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7542,8 +7542,9 @@ unconditionally." (unless (and blank? (org-previous-line-empty-p)) (org-N-empty-lines-before-current (if blank? 1 0))) (insert stars " ") - (when (and (eobp) - (not (buffer-narrowed-p))) + (when (save-restriction + (widen) + (eobp)) (save-excursion (insert "\n"))) ;; When INVISIBLE-OK is non-nil, ensure newly created headline ;; is visible. @@ -7572,15 +7573,17 @@ unconditionally." (when blank? (insert "\n")) (insert "\n" stars " ") (when (org-string-nw-p split) (insert split)) - (when (and (eobp) - (not (buffer-narrowed-p))) + (when (save-restriction + (widen) + (eobp)) (save-excursion (insert "\n") (t (end-of-line) (when blank? (insert "\n")) (insert "\n" stars " ") -(when (and (eobp) -(not (buffer-narrowed-p))) +(when (save-restriction + (widen) + (eobp)) (save-excursion (insert "\n")) ;; On regular text, turn line into a headline or split, if ;; appropriate. -- 2.20.1
[O] [PATCH] org.el: Fix newline at eob in org-insert-heading
* lisp/org.el (org-insert-heading): Check if narrowed before inserting newline at eob When narrowed into an org-buffer (e.g. when capturing), adding a new heading with C- or M- on the last line of a buffer (i.e. that not without a newline at the end) would result in the insertion of a newline at the bottom of the narrowed capture buffer. - C-: `org-insert-heading-respect-content' - M-: `org-meta-return' Both functions use `org-insert-heading' in their definitions. The problem is due to `eobp' returning t when point is on the last character of the narrowed buffer (as explained in its docstring). Since those `eobp' predicates in `org-insert-heading' are probably there to ensure a newline at the end of the *file*, checking whether the buffer is *narrowed* (with `buffer-narrowed-p') prior to inserting the newline fixes the problem. TINYCHANGE --- lisp/org.el | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index e2258749b..7e74c2199 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7542,7 +7542,9 @@ unconditionally." (unless (and blank? (org-previous-line-empty-p)) (org-N-empty-lines-before-current (if blank? 1 0))) (insert stars " ") - (when (eobp) (save-excursion (insert "\n"))) + (when (and (eobp) + (not (buffer-narrowed-p))) +(save-excursion (insert "\n"))) ;; When INVISIBLE-OK is non-nil, ensure newly created headline ;; is visible. (unless invisible-ok @@ -7570,12 +7572,16 @@ unconditionally." (when blank? (insert "\n")) (insert "\n" stars " ") (when (org-string-nw-p split) (insert split)) - (when (eobp) (save-excursion (insert "\n") + (when (and (eobp) + (not (buffer-narrowed-p))) + (save-excursion (insert "\n") (t (end-of-line) (when blank? (insert "\n")) (insert "\n" stars " ") -(when (eobp) (save-excursion (insert "\n")) +(when (and (eobp) +(not (buffer-narrowed-p))) + (save-excursion (insert "\n")) ;; On regular text, turn line into a headline or split, if ;; appropriate. ((bolp) -- 2.20.1
Re: [O] Bug: ‘(org-resolve-clocks)’ picks the wrong target for placing a new clock-drawer when ‘org-clock-out-remove-zero-time-clocks’ is set to t [9.1.14 (9.1.14-9-g131531-elpa @ ~/.emacs.d/elpa/or
Hello, Thank you for your quick patch. Since I wasn’t able to solve it on my own, I’ll take a look at your solution to understand what you did. Have a great day. Best, Nicolas Goaziou writes: Hello, Leo Vivier writes: Hello, There seems to be a bad interaction between ‘(org-resolve-clocks)’ and ‘org-clock-out-remove-zero-time-clocks’ set to t. Whilst the right tree is targeted by ‘(org-resolve-clocks)’ to delete the clock-line and clock-drawer, it adds a new clock-drawer in the next tree rather than on the one being acted on. I was able to replicate this problem with ‘emacs -Q’. DESCRIPTION: I use org-clock regularly, and recently re-discovered ‘org-clock-out-remove-zero-time-clocks’. When I forget to clock an item, I run the following commands in quick succession: # -- (org-clock-in) (org-resolve-clocks) : g 10 (For indicating that I ‘got back’ 10 min ago) # -- Because those commands are run in quick succession, the time between ‘(org-clock-in)’ and ‘(org-resolve-clocks)’ is usually equal to 0 min. Therefore, when ‘(org-resolve-clocks)’ calls ‘(org-clock-out)’ after pressing , the clock-line is deleted, and if the clock-drawer was created by ‘(org-clock-in)’, it also gets deleted. The problem occurs in this context (‘|’ represents ‘(point)’): # -- * Subtree 1 ** Item| * Subtree 2 # -- ‘Item’ is the subtree we want to clock in the past. ‘Subtrees 1 & 2’ are regular subtrees without any newlines separating them (the white-space is important). Please note that I was only able to get ‘(org-resolve-clocks)’ to trigger in an agenda-file with already had clocking info. I recommend that you try the snippet in one of your own agenda-files rather than trying it in a blank buffer. Fixed. Thank you. Regards, -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2
[O] Bug: ‘(org-resolve-clocks)’ picks the wrong target for placing a new clock-drawer when ‘org-clock-out-remove-zero-time-clocks’ is set to t [9.1.14 (9.1.14-9-g131531-elpa @ ~/.emacs.d/elpa/org-2018
ibly remove zero time clocks. However, do not add ;; a note associated to the CLOCK line in this case. (cond ((and org-clock-out-remove-zero-time-clocks (= (+ h m) 0)) (setq remove t) (delete-region (line-beginning-position) (line-beginning-position 2))) (org-log-note-clock-out (org-add-log-setup 'clock-out nil nil nil (concat "# Task: " (org-get-heading t) "\n\n" (when org-clock-mode-line-timer (cancel-timer org-clock-mode-line-timer) (setq org-clock-mode-line-timer nil)) (when org-clock-idle-timer (cancel-timer org-clock-idle-timer) (setq org-clock-idle-timer nil)) (setq global-mode-string (delq 'org-mode-line-string global-mode-string)) (setq frame-title-format org-frame-title-format-backup) (when org-clock-out-switch-to-state (save-excursion (org-back-to-heading t) (let ((org-clock-out-when-done nil)) (cond ((functionp org-clock-out-switch-to-state) (let ((case-fold-search nil)) (looking-at org-complex-heading-regexp)) (let ((newstate (funcall org-clock-out-switch-to-state (match-string 2 (when newstate (org-todo newstate ((and org-clock-out-switch-to-state (not (looking-at (concat org-outline-regexp "[ \t]*" org-clock-out-switch-to-state "\\>" (org-todo org-clock-out-switch-to-state)) (force-mode-line-update) (message (concat "Clock stopped at %s after " (org-duration-from-minutes (+ (* 60 h) m)) "%s") te (if remove " => LINE REMOVED" "")) (run-hooks 'org-clock-out-hook) (unless (org-clocking-p) (setq org-clock-current-task nil))) # -- There’s another ‘(save restriction)’ in ‘(org-clock-remove-empty-clock-drawer)’, but I figured that since it is a ‘(save-restriction)’ within another one, it shouldn’t matter. # -- (defun org-clock-remove-empty-clock-drawer () "Remove empty clock drawers in current subtree." ->(save-excursion (org-back-to-heading t) (org-map-tree (lambda () (let ((drawer (org-clock-drawer-name)) (case-fold-search t)) (when drawer (let ((re (format "^[ \t]*:%s:[ \t]*$" (regexp-quote drawer))) (end (save-excursion (org-end-of-subtree (while (re-search-forward re end t) (org-remove-empty-drawer-at (point)) # ------ I’m going to investigate further to see if I can fix it reliably on my own, but in the meantime, would you have any idea on how to fix it? Thanks for taking the time to look at my report. HTH, -- Leo Vivier English Studies & General Linguistics Master Student, English Department Université Rennes 2
Re: [O] Bug: Modifying org-latex-pdf-process doesn't modify the async export behaviour
Hello, Thank you for pointing me in the right direction. I've created another init file just for async-export, and not only have I got it to work, but it's also quite a lot faster than it used to be. All that remains now is to find a way to re-write my function. My knowledge of elisp if fairly limited, and I don't see how to communicate with the background process other than by writing the value of my toggle-variable to a file. I guess I could also make a modularise async-init.el and control which module is loaded from the main init.el. At any rate, thank you for your prompt reply. Best, On 07/04/18 09:59, Nicolas Goaziou wrote: Hello, Leo Vivier <leo.viv...@gmail.com> writes: I've encountered an issue trying to write a function to toggle between two org-latex-pdf-process states (short & long). The function works as intended when using synchronous export (the PDF is created with the appropriate number of steps), but it doesn't work with asynchronous export (org-latex-pdf-process isn't grabbed past the first run). [...] I've tried appending (org-reload) to my function, but it didn't work. I've also tried modifying org-latex-pdf-process on a fresh emacs session prior to any async export, and I can confirm that it grabs the latest state of org-latex-pdf-process. I'd surmise that async export has a process running in the background, but I don't know how to force it to reload. The background process doesn't use whatever configuration is loaded in current Emacs. Instead it loads a configuration file. See `org-export-async-init-file'. You may also use local variables in your document, or switch async configuration files. Regards, -- Leo Vivier English Studies & General Linguistics Master Student, English Department Rennes 2
[O] Bug: Modifying org-latex-pdf-process doesn't modify the async export behaviour
Hi,
I've encountered an issue trying to write a function to toggle between
two org-latex-pdf-process states (short & long). The function works as
intended when using synchronous export (the PDF is created with the
appropriate number of steps), but it doesn't work with asynchronous
export (org-latex-pdf-process isn't grabbed past the first run).
Here's my function:
# --
(defvar zaeph/org-latex-pdf-process-mode)
(defun zaeph/toggle-org-latex-pdf-process ()
"Toggle the number of steps in the xelatex PDF process."
(interactive)
(if (or (not (bound-and-true-p zaeph/org-latex-pdf-process-mode))
(string= zaeph/org-latex-pdf-process-mode "short"))
(progn (setq org-latex-pdf-process '("xelatex -shell-escape\
-interaction
nonstopmode\
-output-directory
%o %f"
"biber %b"
"xelatex -shell-escape\
-interaction
nonstopmode\
-output-directory
%o %f"
"xelatex -shell-escape\
-interaction
nonstopmode\
-output-directory
%o %f")
zaeph/org-latex-pdf-process-mode 'long)
(message "XeLaTeX process mode: Long"))
(progn (setq org-latex-pdf-process '("xelatex -shell-escape\
-interaction nonstopmode\
-output-directory %o %f")
zaeph/org-latex-pdf-process-mode 'short)
(message "XeLaTeX process mode: Short"
(zaeph/toggle-org-latex-pdf-process)
# --
I've tried appending (org-reload) to my function, but it didn't work.
I've also tried modifying org-latex-pdf-process on a fresh emacs session
prior to any async export, and I can confirm that it grabs the latest
state of org-latex-pdf-process. I'd surmise that async export has a
process running in the background, but I don't know how to force it to
reload.
Would you have any idea?
Thanks.
Best,
--
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Rennes 2
[O] Bug: org-tables: Broken alignment when using numbers of different lengths [9.1.5 (9.1.5-1-gb3ddb0-elpa @ .emacs.d/elpa/org-20171225/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Hi there,
This is my first bug report, so please bear with me if I'm doing
anything wrong.
I also think I've sent an HTML version previously, so sorry about that.
I've updated org-mode yesterday, and the tables do not seem to align
properly anymore.
In a minimal setup, just loading org-mode from MELPA, I've tried
entering the following table:
| foo | 1 |
| bar | 10 |
When I press in the table, visually, the table loses its alignment
(one space gets removed from at the right of the `1').
It gets worse with three lines. The following lines, for instance:
| foo | 1 |
| bar | 10 |
| test | 100 |
When I press , the separator between the two columns disappears,
and the alignment gets screwed up as well.
There definitely seems to be something going on with the length of the
strings. I've tried setting the alignment with and , but it
doesn't resolve the problem.
(Since it's my first bug report, I also want to thank everyone, and hope
that I can join the community.)
--
Emacs : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
of 2017-12-04
Package: Org mode version 9.1.5 (9.1.5-1-gb3ddb0-elpa @
/home/zaeph/.emacs.d/elpa/org-20171225/)
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-activate
org-babel-speed-command-activate)
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 '(#[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-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
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)))
)
("news" :follow
(lambda (path)
(browse-url (concat "news:; path)))
)
("shell" :follow org--open-shell-link))
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
)
--
Leo Vivier
English Studies & General Linguistics
Language Scholar, French Department
Reed College
[O] Bug: org-tables: Broken alignment when using numbers of different lengths [9.1.5 (9.1.5-1-gb3ddb0-elpa @ .emacs.d/elpa/org-20171225/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Hi there,
This is my first bug report, so please bear with me if I'm doing
anything wrong.
I've updated org-mode yesterday, and the tables do not seem to align
properly anymore.
In a minimal setup, just loading org-mode from MELPA, I've tried
entering the following table:
| foo | 1 |
| bar | 10 |
When I press in the table, visually, the table loses its alignment
(one space gets removed from at the right of the `1').
It gets worse with three lines. The following lines, for instance:
| foo | 1 |
| bar | 10 |
| test | 100 |
When I press , the separator between the two columns disappears,
and the alignment gets screwed up as well.
There definitely seems to be something going on with the length of the
strings. I've tried setting the alignment with and , but it
doesn't resolve the problem.
(Since it's my first bug report, I also want to thank everyone, and hope
that I can join the community.)
--
Emacs : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
of 2017-12-04
Package: Org mode version 9.1.5 (9.1.5-1-gb3ddb0-elpa @
/home/zaeph/.emacs.d/elpa/org-20171225/)
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-activate
org-babel-speed-command-activate)
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 '(#[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-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
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)))
)
("news" :follow
(lambda (path)
(browse-url (concat "news:; path)))
)
("shell" :follow org--open-shell-link))
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
)
--
Leo Vivier
English Studies & General Linguistics
Language Scholar, French Department
Reed College
