Re: [BUG] org-mode binds C-c C-TAB, which seems illegal [9.5 (9.5-g0a86ad @ /home/il/.config/emacs/elpa/org-9.5/)]
On Fri, Oct 01 2021 23:16 (+0200), Ingo Lohmar wrote: > 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 > > https://orgmode.org/manual/Feedback.html#Feedback > > Your bug report will be posted to the Org mailing list. > > > In 9.5, org-key-map binds org-force-cycle-archived to (kbd "C-c C-TAB"). > At least on my machine, this specification is illegal: it generates an > entry in org-key-map, but the key presses yield an "undefined" message. > > Binding the command to (kbd "C-c C-") instead works, but not on a > tty. > > It's been my understanding that "TAB" is the ascii control character, > identical to C-i, and hence "C-TAB" cannot work. "" is the GUI > system's key event (in my case, X), and does not work on a terminal. > > Emacs : GNU Emacs 28.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version > 3.24.24, cairo version 1.16.0) > of 2021-09-02 > Package: Org mode version 9.5 (9.5-g0a86ad @ > /home/il/.config/emacs/elpa/org-9.5/) Hi all, it seems that the above bug report has gone unnoticed. It seems the change was introduced in 565361eb698b0b39c1d823ad1565f5bd88fa2034 and persists. Can people actually enter "C-c C-TAB" into their emacs (how?), or has everybody has just bound another key in their config? Best, Ingo
[BUG] org-mode binds C-c C-TAB, which seems illegal [9.5 (9.5-g0a86ad @ /home/il/.config/emacs/elpa/org-9.5/)]
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 https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. In 9.5, org-key-map binds org-force-cycle-archived to (kbd "C-c C-TAB"). At least on my machine, this specification is illegal: it generates an entry in org-key-map, but the key presses yield an "undefined" message. Binding the command to (kbd "C-c C-") instead works, but not on a tty. It's been my understanding that "TAB" is the ascii control character, identical to C-i, and hence "C-TAB" cannot work. "" is the GUI system's key event (in my case, X), and does not work on a terminal. Emacs : GNU Emacs 28.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2021-09-02 Package: Org mode version 9.5 (9.5-g0a86ad @ /home/il/.config/emacs/elpa/org-9.5/)
[PATCH] Fix timestamp agenda setting global agenda name [9.4.6]
Dear All, a few weeks ago, I reported the original bug with a minimal complete example in https://lists.gnu.org/archive/html/emacs-orgmode/2021-05/msg00757.html My first patch attempt was wrongly based on the master branch, see https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00378.html Also, I probably messed up the subject, and replying to my first mail did not work as intended, please accept my apologies for any confusion caused by this. Below, I attach a clean patch against the 'maint' branch. Two tests fail, but the same tests fail on maint w/o my commit. 'make compile' does not complain. I have a copyright assignment for Emacs on file with the FSF. Please let me know of anything else I can do to get the fix in. >From 167bda641e70989a5b679b89f3024f47ec68244c Mon Sep 17 00:00:00 2001 From: Ingo Lohmar Date: Sat, 19 Jun 2021 17:04:56 +0200 Subject: [PATCH] Fix timestamp agenda setting global agenda name * lisp/org.el (org-follow-timestamp-link): Do not set global agenda name The tmp value for the agenda buffer name is used in `org-agenda-list' to set `org-agenda-buffer-name'. Wrap the call in a let-binding for this symbol (like the agenda dispatcher does), since otherwise it inadvertently sets the global value. --- lisp/org.el | 36 +++- 1 file changed, 19 insertions(+), 17 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index a8b584ee4..467485b2c 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -9098,24 +9098,26 @@ or to another Org file, automatically push the old position onto the ring." (defvar org-agenda-start-on-weekday) (defun org-follow-timestamp-link () "Open an agenda view for the time-stamp date/range at point." - (cond - ((org-at-date-range-p t) -(let ((org-agenda-start-on-weekday) - (t1 (match-string 1)) - (t2 (match-string 2)) tt1 tt2) - (setq tt1 (time-to-days (org-time-string-to-time t1)) - tt2 (time-to-days (org-time-string-to-time t2))) + ;; Avoid changing the global value. + (let ((org-agenda-buffer-name org-agenda-buffer-name)) +(cond + ((org-at-date-range-p t) + (let ((org-agenda-start-on-weekday) + (t1 (match-string 1)) + (t2 (match-string 2)) tt1 tt2) + (setq tt1 (time-to-days (org-time-string-to-time t1)) + tt2 (time-to-days (org-time-string-to-time t2))) + (let ((org-agenda-buffer-tmp-name + (format "*Org Agenda(a:%s)" + (concat (substring t1 0 10) "--" (substring t2 0 10) + (org-agenda-list nil tt1 (1+ (- tt2 tt1)) + ((org-at-timestamp-p 'lax) (let ((org-agenda-buffer-tmp-name - (format "*Org Agenda(a:%s)" - (concat (substring t1 0 10) "--" (substring t2 0 10) - (org-agenda-list nil tt1 (1+ (- tt2 tt1)) - ((org-at-timestamp-p 'lax) -(let ((org-agenda-buffer-tmp-name - (format "*Org Agenda(a:%s)" (substring (match-string 1) 0 10 - (org-agenda-list nil (time-to-days (org-time-string-to-time - (substring (match-string 1) 0 10))) - 1))) - (t (error "This should not happen" + (format "*Org Agenda(a:%s)" (substring (match-string 1) 0 10 + (org-agenda-list nil (time-to-days (org-time-string-to-time + (substring (match-string 1) 0 10))) + 1))) + (t (error "This should not happen") ;;; Following file links -- 2.30.2
[PATCH] Re: Bug: org-agenda-buffer-name wrongly persists [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Here's a local-tested fix to the bug described previously. The attached patch does not change anything about the overall handling of the agenda buffer names, it only fixes org-follow-timestamp-link to introduce a let-binding similar to what the standard org-dispatcher does. >From 2c0166449de2f4252435ecfea8a2d1287eafc04b Mon Sep 17 00:00:00 2001 From: Ingo Lohmar Date: Sat, 19 Jun 2021 17:04:56 +0200 Subject: [PATCH] org.el (org-follow-timestamp-link): Do not set global agenda name The tmp value for the agenda buffer name is used in `org-agenda-list' to set `org-agenda-buffer-name'. Wrap the call in a let-binding for this symbol (like the agenda dispatcher does), since otherwise it inadvertently sets the global value. --- lisp/org.el | 36 +++- 1 file changed, 19 insertions(+), 17 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 1bd9e02eb..4fd8b6fa6 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -9165,24 +9165,26 @@ or to another Org file, automatically push the old position onto the ring." (defvar org-agenda-start-on-weekday) (defun org-follow-timestamp-link () "Open an agenda view for the time-stamp date/range at point." - (cond - ((org-at-date-range-p t) -(let ((org-agenda-start-on-weekday) - (t1 (match-string 1)) - (t2 (match-string 2)) tt1 tt2) - (setq tt1 (time-to-days (org-time-string-to-time t1)) - tt2 (time-to-days (org-time-string-to-time t2))) + ;; Avoid changing the global value. + (let ((org-agenda-buffer-name org-agenda-buffer-name)) +(cond + ((org-at-date-range-p t) + (let ((org-agenda-start-on-weekday) + (t1 (match-string 1)) + (t2 (match-string 2)) tt1 tt2) + (setq tt1 (time-to-days (org-time-string-to-time t1)) + tt2 (time-to-days (org-time-string-to-time t2))) + (let ((org-agenda-buffer-tmp-name + (format "*Org Agenda(a:%s)" + (concat (substring t1 0 10) "--" (substring t2 0 10) + (org-agenda-list nil tt1 (1+ (- tt2 tt1)) + ((org-at-timestamp-p 'lax) (let ((org-agenda-buffer-tmp-name - (format "*Org Agenda(a:%s)" - (concat (substring t1 0 10) "--" (substring t2 0 10) - (org-agenda-list nil tt1 (1+ (- tt2 tt1)) - ((org-at-timestamp-p 'lax) -(let ((org-agenda-buffer-tmp-name - (format "*Org Agenda(a:%s)" (substring (match-string 1) 0 10 - (org-agenda-list nil (time-to-days (org-time-string-to-time - (substring (match-string 1) 0 10))) - 1))) - (t (error "This should not happen" + (format "*Org Agenda(a:%s)" (substring (match-string 1) 0 10 + (org-agenda-list nil (time-to-days (org-time-string-to-time + (substring (match-string 1) 0 10))) + 1))) + (t (error "This should not happen") ;;; Following file links -- 2.30.2
Bug: org-agenda-buffer-name wrongly persists [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
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
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
The global variable org-agenda-buffer-name, once set, wrongly (IMO)
affects all future agenda buffer names for composite commands.
Minimal complete example (in emacs -q):
Evaluate
(setq org-agenda-custom-commands
'(("z" "Std Agenda"
((tags "select"
((org-agenda-overriding-header "*select*ed")))
(agenda "" ((org-agenda-span 2)))
(("z" "Std Agenda" ((tags "select" ...) (agenda "" ...
(org-agenda nil "z")
and get a custom agenda with the default buffer name "*Org Agenda*"
(OK).
Create a buffer "test.org" and switch it to `org-mode', insert a
timestamp (C-c .). Now follow the timestamp link (C-c C-o), and get an
agenda with buffer name "*Org Agenda(a:2021-05-15)" (OK).
Now re-do
(org-agenda nil "z")
which has the same buffer name including the date (BUG).
I do not pretend to understand how the global variable
org-agenda-buffer-name is supposed to work (not even mentioning the
-sticky- functionality here). What I understand is the following:
The org-agenda dispatcher let-binds o-a-buffer-name to the global value.
"Simple" agenda commands (like a todo list) called from the dispatcher
set this let-bound o-a-buffer-name, so they use the correct default
value.
"Composite" custom commands called via the dispatcher do not set the
let-bound value, so they use the original let-bound value (the global
value at the start of org-agenda).
`org-follow-timestamp-link' calls the `org-agenda-list' command directly
(not via the dispatcher), hence sets the global (not a local let-bound)
value of o-a-buffer-name.
I have little constructive advice to offer regarding a solution. It
seems to me that the global variable o-a-buffer-name is only harmful and
I would try to get rid of it, but I guess it is necessary for sticky
agendas (not using them).
Emacs : GNU Emacs 28.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.24,
cairo version 1.16.0)
of 2021-05-01
Package: Org mode version 9.4.4 (release_9.4.4 @
/usr/local/share/emacs/28.0.50/lisp/org/)
Re: Bug: org-link-descriptive needs to be buffer-local [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
On Mon, Apr 05 2021 22:36 (-0400), Kyle Meyer wrote: >> I suggest a simple fix that I just tested: make `org-link-descriptive' >> automatically buffer-local, by adding ":local t" to the defcustom. > > Hmm, I think a problem with `:local t' (or, equivalently, > make-variable-buffer-local for backward compatibility reasons) is that > then you'd interfere with user customization that directly sets this > after ol.el is loaded. You could also still get into a mismatched state > like you described above if you load an Org buffer, set the value > through the customization interface, and then call > org-toggle-link-display in that buffer. > > Instead I've updated the body of `org-mode' to make org-link-descriptive > buffer-local (702e782cb). I am not sure that I understand the problem you're describing.. Maybe it's because I don't use the customize interface myself, but I think any such customization would only set the default value, wouldn't it? But in any case, I am (of course) perfectly fine with your fix, thanks a lot for the quick response!
Bug: org-link-descriptive needs to be buffer-local [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
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 https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. I stumbled upon weird behavior when using `org-toggle-link-display', and I finally checked what that is about. Observation: - use `org-toggle-link-display' in org buffer A, and (coming from the defaults) links are now shown in full (not just the description), but only in buffer A - switch to org buffer B, still only showing the description part, and again use `o-t-l-d' --- nothing changes - the state for new org buffers is as before, onle link descriptions are shown. This behavior is very confusing, IMO. The reason is simple. The display hiding comes from changing the `buffer-invisibility-spec', which is automatically buffer-local. But the state of the org toggle is kept in `org-link-descriptive', which is global! I suggest a simple fix that I just tested: make `org-link-descriptive' automatically buffer-local, by adding ":local t" to the defcustom. NB: This also fixes a related bug that eval: (org-toggle-link-display) in the file-local works properly --- it did not work for me before. Thanks. Emacs : GNU Emacs 28.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2021-03-27 Package: Org mode version 9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)
Re: Emacs master, faces with :extend t let cursor vanish at EOL?!
On Tue, Feb 04 2020 11:07 (+0100), Bastien wrote: > Hi Ingo, > > Ingo Lohmar writes: > >> Using this with a current elpa pkg of org-mode, and setting :extend t on >> faces like `org-block`, "often" the cursor vanishes at the EOL of a line >> using such a face. It reliably happens for `org-block', only sometimes >> for `secondary-selection'. > > can you keep track of this issue and related discussions? > > I doubt there is anything we can do in Org itself, but perhaps a hint > in a docstring could help. > > Let us know, thanks, Hi Bastien, I am confused, I thought this was fixed, but I have a really hard to find the bug.. Some time later: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38330 Best, Ingo
[O] Emacs master, faces with :extend t let cursor vanish at EOL?!
I am writing to the org-mode list first, because I have only been able to reproduce this problem in org-mode. With a recent Emacs master build, faces can have the :extend t property to indicated that they should extend after the newline. This is useful for a user to customize, eg, for `org-block', and it also applies to default faces like `region', `highlight' or `secondary-selection'. Using this with a current elpa pkg of org-mode, and setting :extend t on faces like `org-block`, "often" the cursor vanishes at the EOL of a line using such a face. It reliably happens for `org-block', only sometimes for `secondary-selection'. Has anybody else experienced that as well, or do you have any pointers on how to further investigate this? I think I remember that org-mode does something with text overlays, but I can't relate that to what I see. There might also be an issue with face inheritance and the new :extend attribute --- I might post on emacs-devel to get a better idea of that as well. Thanks, Ingo
[O] Bug: missing `save-excursion' in `org-fast-tag-selection' [9.2.3 (9.2.3-9-g0803e2-elpa @ /home/il/.emacs.d/elpa/org-20190422/)]
Hi all,
I tried to use `org-agenda-set-tags'. The source buffer (where the
change should be applied) is visible at the same time as the agenda is.
Also, fast tag selection with a single key is enabled.
Under these circumstances, the tag text is appended to the line (not
even necessarily a heading!) where point is in the source buffer visible
next to the agenda, instead of the correct heading that I acted upon.
I tracked this done to a missing `save-excursion' wrapped around the
`save-window-excursion' in `org-fast-tag-selection' (org.el line 14567
in my version). This would be analogous to what is done in
`org-fast-todo-selection' and fixes my issue.
Thanks!
Emacs : GNU Emacs 27.0.50 (build 24, x86_64-pc-linux-gnu, X toolkit, Xaw3d
scroll bars)
of 2019-02-16
Package: Org mode version 9.2.3 (9.2.3-9-g0803e2-elpa @
/home/il/.emacs.d/elpa/org-20190422/)
current state:
==
(setq
org-agenda-window-setup 'current-window
org-fast-tag-selection-single-key t
org-tag-persistent-alist '(("REFILE" . 82) ("SELECT" . 115)))
[O] Bug: missing `save-excursion' in `org-fast-tag-selection' [9.2.3 (9.2.3-9-g0803e2-elpa @ /home/il/.emacs.d/elpa/org-20190422/)]
Hi all,
I tried to use `org-agenda-set-tags'. The source buffer, where the
change should be applied is visible at the same time as the agenda is.
Also, fast tag selection with a single key is enabled.
Under these circumstances, the tag text is appended to the line (not
even necessarily a heading!) where point is in the source buffer visible
parallel to the agenda, instead of the correct heading that I acted
upon.
I tracked this done to a missing `save-excursion' wrapped around the
`save-window-excursion' in `org-fast-tag-selection' (org.el line 14567
in my version). This would be analogous to what is done in
`org-fast-todo-selection' and fixes my issue.
Thanks!
Emacs : GNU Emacs 27.0.50 (build 24, x86_64-pc-linux-gnu, X toolkit, Xaw3d
scroll bars)
of 2019-02-16
Package: Org mode version 9.2.3 (9.2.3-9-g0803e2-elpa @
/home/il/.emacs.d/elpa/org-20190422/)
current state:
==
(setq
org-fast-tag-selection-single-key t
org-tag-persistent-alist '(("REFILE" . 82) ("SELECT" . 115))
org-src-window-setup 'other-window)
[O] Bug: org-table-separator-space breaks alignment of existing tables [9.1.5 (9.1.5-1-gb3ddb0-elpaplus @ /home/il/.emacs.d/elpa/org-plus-contrib-20171225/)]
Here's a simple table example that breaks (info and columns lost etc) on
`org-table-align`. I traced it down to org-table-separator-space ---
setting it to a plain " " (effectively the situation before the last
9.1.5 commit) works for me, but I do not understand why the change
breaks that. Or is this "breakage" expected?
| No | Name| cpr1 | drv1 | ?ch1 | fla1 | xt12 | enh | pit1 |
mtd1 | dly1 | xt11 | xt1 (2) | Amp [sd0 but def.3] | Cab
| Rev | Comment|| WIP/TODO
|
|| | | | | | | rt/ph/trm | |
| | | | |
| |||
|
|+-+--+--+--+--+--+---+--+--+--+--+-+--+--+---+++---|
| 0 | JC 120 |4 | |8 |2 | | | |
4 |2 | DlyIn 30-100% | | brt m10 | 94 2x12 slv
alnico | sm room | 102bpm; orig ~CE-1 (more shimmer etc) ||
|
I have removed a few confidential settings, none of which I believe
could have anything to do with this issue. I have a feeling it might
have something to do with org-indent-mode (would not be the first
time)...
Thanks for the ongoing work on org-mode!
Regards,
Ingo
Emacs : GNU Emacs 27.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.22.24)
of 2017-12-27
Package: Org mode version 9.1.5 (9.1.5-1-gb3ddb0-elpaplus @
/home/il/.emacs.d/elpa/org-plus-contrib-20171225/)
current state:
==
(setq
org-clock-persist-query-save t
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-scheduled-leaders '("" "%3d*")
org-after-todo-state-change-hook '(my/org-prune-logbook-entries
org-clock-out-if-current org-checklist)
org-agenda-tags-column 78
org-agenda-skip-scheduled-if-deadline-is-shown 'not-today
org-blank-before-new-entry '((heading) (plain-list-item))
org-babel-after-execute-hook '(my/org-babel-post-execute)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-archive-save-context-info '(time olpath category itags ltags)
org-src-tab-acts-natively t
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-special-ctrl-a/e t
org-notmuch-open-function 'org-notmuch-follow-link
org-agenda-files '("~/Documents/personal.org" "~/Documents/contacts.org"
"~/Documents/collect.org")
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-tag-alist '(("computer" . 99) ("phone" . 112) ("read" . 114) (:startgroup)
("@context" . 64) (:grouptags) ("@home" . 104)
("@work" . 119) ("@errand" . 101) (:endgroup))
org-modules '(org-bibtex org-docview org-id org-info org-habit org-irc
org-protocol org-indent org-checklist org-notmuch org-man
org-contacts)
org-startup-folded 'content
org-cycle-include-plain-lists nil
org-id-link-to-org-use-id 'use-existing
org-mode-hook '(org-clock-load #[0 "\300\301!\207" [goto-address-mode -1] 2]
#[0 "\301\211\207" [truncate-lines t] 2]
er/add-org-mode-expansions
#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-block-all append local] 5]
#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-clock-persist 'history
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-outline-path-complete-in-steps nil
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-startup-indented t
org-startup-with-inline-images t
org-tag-persistent-alist '(("REFILE" . 82))
org-agenda-skip-timestamp-if-done t
org-todo-repeat-to-state "NEXT"
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn
ENTRY)"]
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-contacts-matcher "Email<>\"\"|Birthday<>\"\"|Phone<>\"\"|Mobile<>\"\""
org-agenda-deadline-faces '((1.0 . org-warning) (0.5 . org-upcoming-deadline)
(0.0 . org-scheduled))
org-contacts-files '("~/Documents/contacts.org")
org-notmuch-search-open-function 'org-notmuch-search-follow-link
org-babel-pre-tangle-hook '(save-buffer)
org-file-apps '((directory lambda (file
Re: [O] Heading/item insert commands
Hi Nicolas, I am not sure I understand: As I tried to make clear, I am *not* interested in changing the UI for anybody but myself. I probably should have omitted the "long-run" comment altogether. What I am interested in is refactoring: add a layer of functions that cleanly do what is now done in an ad-hoc way, eg, inside of-insert-todo-heading, or which is not done at all. Or are you talking about the parameters of such new functions? On Oct 4, 2017 12:33 PM, "Nicolas Goaziou" <m...@nicolasgoaziou.fr> wrote: Hello, Ingo Lohmar <i.loh...@gmail.com> writes: > What I have in mind for starters: > > Add orthogonal internal functions that can handle *all* sensible > combinations of requirements. Then rewrite existing commands in terms > of these, but possibly adding new ones. > > I would not want to break any workflows, of course. But in the *long* > run, we could rethink if the existing commands and their prefix-arg > behavior are really what users want, or if we provide other ones by > default. > > Does that sound reasonable, or are there any grave obstacles I did not > consider, or any hard reasons why such changes could not be accepted? I think, as a starter, we should discuss and agree on how the UI should be. IMO, implementation follows, not the other way around. WDYT? Regards, -- Nicolas Goaziou
[O] Heading/item insert commands
Dear All, I have been heavily and happily using orgmode for more than 6 years now. During this time, I have returned 4 or 5 times to changing, tweaking and generally being puzzled by the code and commands used to insert headings and list items. Now, for the first time, I have tried to systematically write down for myself the different dimensions of the problem, what kind of combinations I want, and I have written small wrapper commands that make it happen the way I want. But that has basically confirmed my gut feeling that the code dealing with these tasks is fairly convoluted. There is no symmetry between todo/non-todo elements, nor between headings and plain list items (inasmuch as possible), arguments are used inconsistently, heading insertion may or may not fallback to list items etc. Thankfully, we are not talking about a lot of code, and it seems to be amenable to refactoring. Is there any interest in me trying that (no promises as to the success)? I could not find any previous discussions about this topic, but wanted to get some feedback before spending my time on this. To me, there are a few dimensions of requirements: - insert a heading or an item, or decide based on context? - insert a todo or a non-todo something? - insert right here (possibly splitting a line), after the current something, or at the end of current's something parent? Plus some specialties of the current code: For a todo heading, which keyword to use? Override the heading level by an argument? What I have in mind for starters: Add orthogonal internal functions that can handle *all* sensible combinations of requirements. Then rewrite existing commands in terms of these, but possibly adding new ones. I would not want to break any workflows, of course. But in the *long* run, we could rethink if the existing commands and their prefix-arg behavior are really what users want, or if we provide other ones by default. Does that sound reasonable, or are there any grave obstacles I did not consider, or any hard reasons why such changes could not be accepted? Thanks, Ingo
Re: [O] org-protocol: deal with broken links on windows
Hi Nikolay, Thanks for your reply. I checked a few things today: I am using Org mode version 9.0.9 (9.0.9-82-gb862c2-elpaplus, org-plus-contrib-20170814/) and the unofficial emacs build GNU Emacs 25.2.1 (x86_64-w64-mingw32) of 2017-04-24 from http://sourceforge.net/projects/emacsbinw64/ (supposedly straight from original sources). > emacsclientw.exe > "org-protocol:/capture?template=w=http%3A%2F%2Fjira%2Fbrowse%2FSDST-705=SOMETHING=" 1) Without any patch/advice, calling emacsclientw directly on this address (modulo template letter) works fine, as does a call with the full executable path. I think the path prefix is weird, but fine with me. The culprit (independent of the prefix) is the "/" before the query string. So thanks for narrowing this down, first of all. 2) Just a side note: store-link (instead of capture) shows the exact same behavior. 3) Here are the bookmarklets I use... >--< javascript:location.href='org-protocol://store-link?url='+encodeURIComponent(location.href)+'='+encodeURIComponent(document.title)+'='+encodeURIComponent(window.getSelection()) javascript:location.href='org-protocol://capture?template=y='+encodeURIComponent(location.href)+'='+encodeURIComponent(document.title)+'='+encodeURIComponent(window.getSelection()) >--< 4) ...and the registry entries >--< REGEDIT4 [HKEY_CLASSES_ROOT\org-protocol] @="URL:org-protocol" "URL Protocol"="" [HKEY_CLASSES_ROOT\org-protocol\shell] [HKEY_CLASSES_ROOT\org-protocol\shell\open] [HKEY_CLASSES_ROOT\org-protocol\shell\open\command] @="\"C:\\Program Files\\Emacs\\bin\\emacsclientw.exe\" --no-wait \"%1\"" >--< I think this is all as it should be, and I have tried to make the minimal changes to get a working system. 5) Soo the remaining puzzle: How can the "/" get in there? As I said, it happens when called from both FF (although I have not used that for a few weeks now) and Iridium. It seems to happen somewhere b/w the browser and emacsclientw, ie, in the Windows "protocol" handling, I suppose? If other people can confirm (or even explain) this behavior, we could decide if there should be a transformation on the FNAME argument. In that case, it should definitely leave the leading executable path alone. Thanks a lot so far! Ingo
[O] org-protocol: deal with broken links on windows
Dear all, It appears that org-capture (with the no-frills, no-extensions method of adding a registry entry for org-protocol) using new-style links is not working correctly on Windows (tested with recent Firefoxes as well as the Chromium derivative Iridium). What happens is that the browser binary with full path is prepended to the protocol, and an extra "/" is added before the URL query string. That is, what *should* read org-protocol:/capture?template=y=http%3A%2F%2Fjira%2Fbrowse%2FSDST-705=SOMETHING is actually passed as c:/Program Files/Iridium/58.0.0.0/org-protocol:/capture/?template=y=http%3A%2F%2Fjira%2Fbrowse%2FSDST-705=SOMETHING as the FNAME argument to `org-protocol-check-filename-for-protocol'. I have no idea what brought about this crazy change, but I've long ago stopped trying to understand Windows' ways --- nowadays I just lobby against using it. Anyway, I've successfully (regular use for several weeks) patched this with an advice: >--< (defun adv/sanitize-broken-windows-link (args) (let ((fname (car args))) (cons (if (string-match "^[a-z]:/[-a-zA-Z0-9 /._]+/\\(org-protocol:/[^/\\?]*\\)/\\(\\?.*\\)$" fname) (concat (match-string 1 fname) (match-string 2 fname)) fname) (cdr args (advice-add #'org-protocol-check-filename-for-protocol :filter-args #'adv/sanitize-broken-windows-link) >--< I only use this on the Windows machine, where FNAME reliably has the above form for me (probably better ONLY use it when (eq system-type 'windows-nt)). Also, the regexp is probably too unspecific even on Windows. Could we still add this or an improved transformation of FNAME to `org-protocol-check-filename-for-protocol' (assuming there's no better way)? Thank you! Ingo
Re: [O] org-agenda fails on particular construct
On Thu, Dec 15 2016 21:02 (+0100), Ingo Lohmar wrote: > [Sorry for not replying in-thread...] > > Hi All, > > after updating I'm getting the same result, but I could not reproduce it > even with my org-config until now. > > The culprit seems to be in org-agenda.el, ll. 6098 ff., in > org-agenda-get-deadlines: > > ((eq org-agenda-skip-deadline-prewarning-if-scheduled > 'pre-scheduled) > ;; Set pre-warning to no earlier than SCHEDULED. > (min (- deadline scheduled) org-deadline-warning-days)) > > So it needs an item with deadline *and* scheduled time, and the > 'pre-scheduled setting of the config var > org-agenda-skip-deadline-prewarning-if-scheduled. > > Subtracting "scheduled" fails: every date in the procedure is an > integer, scheduled is still the raw string from the item. At the > moment, I am too tired to figure out why that is, sorry. Hope this is > still of some help. It seems replacing "scheduled" by (org-agenda--timestamp-to-absolute scheduled) does the trick, but I have zero idea about the other args that can be passed (down to org-time-string-to-absolute).
Re: [O] org-agenda fails on particular construct
[Sorry for not replying in-thread...] Hi All, after updating I'm getting the same result, but I could not reproduce it even with my org-config until now. The culprit seems to be in org-agenda.el, ll. 6098 ff., in org-agenda-get-deadlines: ((eq org-agenda-skip-deadline-prewarning-if-scheduled 'pre-scheduled) ;; Set pre-warning to no earlier than SCHEDULED. (min (- deadline scheduled) org-deadline-warning-days)) So it needs an item with deadline *and* scheduled time, and the 'pre-scheduled setting of the config var org-agenda-skip-deadline-prewarning-if-scheduled. Subtracting "scheduled" fails: every date in the procedure is an integer, scheduled is still the raw string from the item. At the moment, I am too tired to figure out why that is, sorry. Hope this is still of some help.
[O] Bug: org-indent-mode incomplete refresh after org-toggle-heading [8.3.2 (8.3.2-51-g713fe8-elpaplus @ /home/il/.emacs.d/elpa/org-plus-contrib-20151221/)]
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-mode mailing list.
emacs -nw -q testfile,
M-x org-mode
M-x org-indent-mode
Enter following plain list:
- item1
- item1.1
- item2
Move to first line ("item1") and C-c * to org-toggle-heading. "item1"
becomes a heading (ok), "item1.1" gets line/wrap prefix for indentation
(ok), but "item2" is not affected at all.
I believe the last list item should get the prefixes as well, as it
belongs to the same subtree.
The same thing happens in a large tree structure (ie, it does not depend
on the first or the only heading being inserted). Debugging the
after-change function was sketchy (sometimes it was applied in a
narrowed buffer of zero length etc), but it seems that
org-indent-refresh-maybe does *not* realize it has affected a headline
and should work with the whole subtree.
Emacs : GNU Emacs 25.1.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.5)
of 2015-12-11
Package: Org-mode version 8.3.2 (8.3.2-51-g713fe8-elpaplus @
/home/il/.emacs.d/elpa/org-plus-contrib-20151221/)
Re: [O] [PATCH] fix org-insert-todo-heading-respect-content in plain list item
Hi Nicolas, sure: emacs -q -nw, and in the scratch buffer (add-to-list 'load-path ~/src/org-mode/lisp/) ;refer to HEAD as of yesterday (org-mode) ;and enter/paste: * test - an -!- item - another one Then, with the cursor at -!- (for example), hitting C-S-return breaks the line, while it /should/ create a todo heading after the subtree. Replacing the t with '(4) (which is what org-todo-heading comapres with) fixes this. HTH, regards, Ingo On Mon, Oct 28 2013 09:43 (+0100), Nicolas Goaziou wrote: Hello, Ingo Lohmar i.loh...@gmail.com writes: please find attached a 1-4-char patch fixing the behavior of the above function when inside a plain list. [...] Subject: [PATCH] fix org-insert-todo-heading-respect-content in plain list item * lisp/org.el (org-insert-todo-heading-respect-content): pass correct prefix arg to always insert heading TINYCHANGE This function used a second argument t, which is eventually passed to org-insert-heading, adding a list item when inside a plain list. Use the proper argument '(4) now, to always create a heading, just like the function's name and documentation imply. Thank you for your patch. Could you provide a test case, because, after a quick test, I do not see any difference before and after applying your patch. Regards, -- Nicolas Goaziou
[O] [PATCH] fix org-insert-todo-heading-respect-content in plain list item
Hi guys, please find attached a 1-4-char patch fixing the behavior of the above function when inside a plain list. Best, Ingo From e22f9ffe3f6af69cde2397f56a7efebaaa7710e0 Mon Sep 17 00:00:00 2001 From: Ingo Lohmar i.loh...@gmail.com Date: Sun, 27 Oct 2013 17:34:22 +0100 Subject: [PATCH] fix org-insert-todo-heading-respect-content in plain list item * lisp/org.el (org-insert-todo-heading-respect-content): pass correct prefix arg to always insert heading TINYCHANGE This function used a second argument t, which is eventually passed to org-insert-heading, adding a list item when inside a plain list. Use the proper argument '(4) now, to always create a heading, just like the function's name and documentation imply. --- lisp/org.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 0fd531d..275f480 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7770,7 +7770,7 @@ This is a list with the following elements: Insert TODO heading with `org-insert-heading-respect-content' set to t. (interactive P) (let ((org-insert-heading-respect-content t)) -(org-insert-todo-heading force-state t))) +(org-insert-todo-heading force-state '(4 (defun org-insert-todo-heading (arg optional force-heading) Insert a new heading with the same level and TODO state as current heading. -- 1.7.10.4
[O] org-store-link BUG for notmuch message
Hi all, I am using org-notmuch to store links to individual messages, and recently this has broken. As far as I can see, it is due to the last 10 lines in org.el's org-store-link: It looks to me like the if clause misses a progn: the true clause is too short and does not store the link (both pushes are in the false clause of the if form). Since I only have the packaged version, I would be very grateful if someone else could restore the working state --- I cannot check previous versions right now. Please let me know if you need any more info! Thanks a lot, and best regards Ingo
[O] [BUG] org-open-at-point fails with multiple links in entry
Hi all, recently a common workflow of mine broke: I have an entry, and in the text are several links to websites. I can go to the heading or its line in an agenda and do `org-open-at-point', and I get a list of links inside the entry. But selecting them all with RET gives an error now: emacs -Q -nw - (setq package-user-dir ~/src/elpa package-enable-at-startup nil) (package-initialize) (require 'org) ;checked org-version is 7.9.3a (org-mode) insert - * test heading http://www.google.com http://www.sz.de go to headline, do `org-open-at-point', and select all.. org-open-at-point: Wrong type argument: stringp, (#(http://www.google.com; 0 6 (fontified t...LONGISH. Bottom line: It gets a list of propertized strings and expect a single one. Any help what broke this? I do not have much time to dig into the code right now, unfortunately. Regards, Ingo
Re: [O] [PATCH] Nicer fontification for org-todo-list
Hi Bastien and all, Is anything still to be fixed before the patch that I sent can be applied? I am curious since there was no reaction and no change in the repo as far as I can tell... Best Ingo
Re: [O] [PATCH] Nicer fontification for org-todo-list
On Tue, Dec 04 2012 15:39 (+0100), Bastien wrote: Hi Ingo, sorry nobody had the time to test the patch and report. It looks good to me and does the right thing. Do you mind resending it using git? Don't forget to add a changelog entry (with `C-x 4 a' in the modified places) and a TINYCHANGE cookie at the end of the entry. Note that we cannot accept patches larger than 20 lines, so if you want to contribute further, maybe you can consider signing the FSF papers? See http://orgmode.org/cgit.cgi/org-mode.git/plain/request-assign-future.txt Thanks for your contribution/patience! -- Bastien Hi Bastien, No worries, and thanks for taking the time. Below is the patch in git format, I hope the format is ok (incl changelog), otherwise please bear with me... Will send the mail regarding the FSF papers soon! Ingo From 1ecc9832bcda75638dc29565f71516416e599e89 Mon Sep 17 00:00:00 2001 From: Ingo Lohmar i.loh...@gmail.com Date: Thu, 6 Dec 2012 20:51:59 +0100 Subject: [PATCH] Propertize keywords in todo list header * org-agenda.el (org-todo-list): Propertize keywords with their proper faces in the header of a todo list agenda. TINYCHANGE --- lisp/org-agenda.el | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 2c484b5..15321e1 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -4509,6 +4509,17 @@ in `org-agenda-text-search-extra-files'. ;;; Agenda TODO list +(defun org-propertize-todo-keyword-list (keywords) + (concat + (if (or (equal keywords ALL) (not keywords)) + (propertize ALL 'face 'warning) + (mapconcat + (lambda (kw) +(propertize kw 'face (org-get-todo-face kw))) + (org-split-string keywords |) + |)) + \n)) + (defvar org-select-this-todo-keyword nil) (defvar org-last-arg nil) @@ -4569,9 +4580,7 @@ for a keyword. A numeric prefix directly selects the Nth keyword in (concat ToDo: (or org-select-this-todo-keyword ALL (org-agenda-mark-header-line (point-min)) - (setq pos (point)) - (insert (or org-select-this-todo-keyword ALL) \n) - (add-text-properties pos (1- (point)) (list 'face 'org-warning)) + (insert (org-propertize-todo-keyword-list org-select-this-todo-keyword)) (setq pos (point)) (unless org-agenda-multi (insert Available with `N r': (0)[ALL]) -- 1.7.10.4
Re: [O] [PATCH] Nicer fontification for org-todo-list
Hey guys, It seems that whatever I send to this mailing list goes unnoticed and then gets lost in some black hole. :) Could anybody let me know if there's any interest in the patch, or if there's any more work for me to do or anything left to explain/sort out? Otherwise I'll bite the bullet and make it a private patch to apply during my update routine.. Regards, Ingo
[O] [PATCH] Nicer fontification for org-todo-list
Hi all, recently I was bothered by a very minor thing in my custom agenda: the headline showing the keywords is always using the warning face for the selected keyword(s), instead of the proper faces used to display to them everywhere else. Attached is a patch that changes this that should work under all conditions as far as I can see (and tested). Do you think this is useful? I feel it is the right thing (TM) to do. I used a separate function for the propertization (is that a word?), in case it might become useful elsewhere --- feel free to refactor this to your liking. I would be happy to see this change applied. Standard disclaimer: Not using the git version, but works in the elpa version from last night. Regards, Ingo - --- org-agenda-orig.el 2012-11-02 18:26:43.848678550 +0100 +++ org-agenda.el 2012-11-02 18:43:23.38537 +0100 @@ -4490,6 +4490,17 @@ ;;; Agenda TODO list +(defun org-propertize-todo-keyword-list (keywords) + (concat + (if (or (equal keywords ALL) (not keywords)) + (propertize ALL 'face 'warning) + (mapconcat + (lambda (kw) +(propertize kw 'face (org-get-todo-face kw))) + (org-split-string keywords |) + |)) + \n)) + (defvar org-select-this-todo-keyword nil) (defvar org-last-arg nil) @@ -4550,9 +4561,7 @@ (concat ToDo: (or org-select-this-todo-keyword ALL (org-agenda-mark-header-line (point-min)) - (setq pos (point)) - (insert (or org-select-this-todo-keyword ALL) \n) - (add-text-properties pos (1- (point)) (list 'face 'org-warning)) + (insert (org-propertize-todo-keyword-list org-select-this-todo-keyword)) (setq pos (point)) (unless org-agenda-multi (insert Available with `N r': (0)[ALL])
Re: [O] [PATCH] Nicer fontification for org-todo-list
Apart from a spurious to in my explanation, I should clarify: This is a patch to org-todo-list in org-agenda.el.
Re: [O] [PATCH] make org-agenda-later honor arg when current span is a number
Hey folks,
I am slightly puzzled that there has been no reaction at all to this patch.
To me it seems entirely unambiguous, and it fixes a bug (as per the docstring
of org-agenda-{later,earlier}).
Is there anything I can do to help include this half-line patch in org? I am
sorry that I do not use the git version of org, but I checked that the state
of affairs has not changed.
Thanks and regards,
Ingo
[O] [PATCH] make org-agenda-later honor arg when current span is a number
Hi All, I just fixed an oversight (I suppose) in org-agenda.el. When org-current-agenda-span is a number of days (my standard agenda shows 2 days), org-agenda-later does not respect the argument. In particular that means pressing b goes forward instead of backward! The trivial patch for release 7.9.2: --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -7071,7 +7071,7 @@ greg2) (cond ((numberp span) - (setq sd (+ span sd))) + (setq sd (+ (* span arg) sd))) ((eq span 'day) (setq sd (+ arg sd))) ((eq span 'week) Regards, Ingo
[O] PATCH: follow timestamp link also in heading
Hi there, I stumbled upon the functionality to open the agenda for a timestamp using org-open-at-point. That is really sweet, but as it turns out, it does not work in a headline (as of 7.8.10, with no changes to the relevant code since then). I cannot see a good reason for this, and it is a one-line patch to fix it. Sorry for not using the development version proper, hence just a unified diff (below). It would be great if this could be included! Ingo --- a/lisp/org.el +++ b/lisp/org.el @@ -9606,6 +9606,7 @@ (org-remove-occur-highlights nil nil t) (cond ((and (org-at-heading-p) +(not (org-at-timestamp-p)) (not (org-in-regexp (concat org-plain-link-re \\| org-bracket-link-regexp \\|
Re: [O] PATCH: follow timestamp link also in heading
Dammit. Should work (as in normal text) with inactive timestamps as well! See below. --- a/lisp/org.el +++ b/lisp/org.el @@ -9606,6 +9606,7 @@ (org-remove-occur-highlights nil nil t) (cond ((and (org-at-heading-p) +(not (org-at-timestamp-p t)) (not (org-in-regexp (concat org-plain-link-re \\| org-bracket-link-regexp \\|
Re: [O] [PATCH] fix org-indent-mode for org-indent-indentation-per-level != 2
On Sun, 11 Dec 2011 09:57:50 +0100, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Ingo Lohmar i.loh...@gmail.com writes: Below is an updated patch that works with the 7.7 release (sorry for not using the development version right now). org-indent.el has been heavily modified since 7.7 release. You may want to test development version first, as your patch might not be necessary anymore. Hi Nicolas, My bad, and bad timing: Should have checked the development status. Turns out, it is very different now, but unfortunately still wrong. I will check how to fix it and come back (hopefully) with a new patch. Regards, Ingo
Re: [O] [PATCH] fix org-indent-mode for org-indent-indentation-per-level != 2
On Sun, 11 Dec 2011 14:04:38 +0100, Nicolas Goaziou n.goaz...@gmail.com wrote: Ingo Lohmar i.loh...@gmail.com writes: My bad, and bad timing: Should have checked the development status. Turns out, it is very different now, but unfortunately still wrong. Unless I'm missing your point, I don't see anything wrong in the current behaviour. Whatever may be the value of `org-indent-indentation-per-level', the text is always aligned with the headline. Hmmm, just did a clean test: emacs -Q, require org-install and org-indent. If I use the std setting of 2 and turn on org-indent-mode, all is fine: * 1st-level heading Here goes the text. *** 2nd-level heading More text. Setting the indentation to 1: * 1st-level heading Here goes the text. ** 2nd-level heading More text. That is, missing one space. Will check again.
Re: [O] [PATCH] fix org-indent-mode for org-indent-indentation-per-level != 2
On Sun, 11 Dec 2011 14:25:11 +0100, Nicolas Goaziou n.goaz...@gmail.com wrote: Ingo Lohmar i.loh...@gmail.com writes: Hmmm, just did a clean test: emacs -Q, require org-install and org-indent. If I use the std setting of 2 and turn on org-indent-mode, all is fine: * 1st-level heading Here goes the text. *** 2nd-level heading More text. Setting the indentation to 1: * 1st-level heading Here goes the text. ** 2nd-level heading More text. I cannot reproduce this. Could you try to byte-compile again all Org files, or call org-reload with an argument? Guys, I am terribly sorry --- my apologies for the noise. I had an issue with shadowed load paths. From what I can see, org-indent works just fine in the development version. Learned one or two things :) Regards, Ingo
[O] [PATCH] fix org-indent-mode for org-indent-indentation-per-level != 2
Dear All, After two years with explicit whitespace indentation, I am now a happy user of org-indent-mode. But I like org-indent-indentation-per-level set to 1 (instead of 2), which rendered the indented parts not aligned with their heading. In the old thread http://thread.gmane.org/gmane.emacs.orgmode/26169 a fix for org-indent-add-properties was described, but the thread died with the implication that this is not a bug, but a matter of style. I disagree: the sole purpose of using org-indent-mode is to have the body text align (no ambiguity here IMO) with its heading. Below is an updated patch that works with the 7.7 release (sorry for not using the development version right now). I have been using this for weeks without any issues. As discussed in the above thread, the calculated indentation is negative before the first heading, but the function is never actually used there. Best, Ingo --- org-indent.el 2011-12-10 13:18:16.920914213 +0200 +++ org-indent.el 2011-12-10 13:27:42.660937366 +0200 @@ -255,15 +255,15 @@ (aref org-indent-stars nstars) 'wrap-prefix (aref org-indent-strings -(* (funcall get-real-level e level) - org-indent-indentation-per-level) + (+ 2 (* (1- (funcall get-real-level e level)) + org-indent-indentation-per-level)) (when ( e b) (add-text-properties b e (list 'line-prefix (aref org-indent-strings n) 'wrap-prefix (aref org-indent-strings n (setq b (1+ (point-at-eol)) - n (* (funcall get-real-level b level) -org-indent-indentation-per-level))) + n (+ 2 (* (1- (funcall get-real-level b level)) + org-indent-indentation-per-level (defvar org-inlinetask-min-level) (defun org-indent-refresh-section ()
