Re: [O] Placement of \makeatletter with \beamer@frametextheight
Louis,
a hunch, which might work.
It seems that, if you try to set the length in your preamble,
`\beamer@frametextheight` is not yet defined.
So, you might try the hook `\AtBeginDocument` to see if the definition
comes at a better timing.
#+LATEX_HEADER:
\newlength\mytextheight\AtBeginDocument{\makeatletter\setlength\mytextheight{\beamer@frametextheight}\makeatother}
As I said, it's a hunch, for I haven't tested. But I think it may be it.
Best,
Gustavo.
On 29/11/2018 11:07, Loris Bennett wrote:
Eric S Fraga writes:
On Thursday, 29 Nov 2018 at 09:38, Julius Dittmar wrote:
Am 29.11.18 um 09:13 schrieb Julius Dittmar:
Am 29.11.18 um 08:17 schrieb Loris Bennett:
#+latex_header: \makeatletter\let\mytextheight\beamer@frametexheight\makeatother
#+attr_latex: :height 0.75\mytextheight
Oh, or perhaps just a typo is involved: is it really
\beamer@frametexheight or rather \beamer@frametextheight you are chasing
after?
Also, you may need to define your mytextheight as a length and then use
\setlength instead of \let.
After correcting the typo I followed Eric's and Julius's suggestions and
I tried adding
#+LATEX_HEADER:
\newlength\mytextheight\makeatletter\setlength\mytextheight{\beamer@frametextheight}\makeatother
to the beginning of the Org file, but in this case
\the\mytextheight
is 0.0pt. After that I tried adding the definition on the slide itself:
#+BEGIN_SRC latex
\newlength\mytextheight\makeatletter\setlength\mytextheight{\beamer@frametextheight}\makeatother
#+END_SRC
but got the error
! Undefined control sequence.
\beamer
l.153 \end{frame}
! Missing number, treated as zero.
@
l.153 \end{frame}
Any thoughts?
Cheers,
Loris
Re: [O] Bind pcomplete to C-M-i
Hi all, Hi Johannes, for the record, there has been a question regarding this in Emacs.SX as of recent: https://emacs.stackexchange.com/q/47239/18951 Best, Gustavo. On 27/01/2019 15:51, Johannes Altmanninger wrote: Hi, My installation of Emacs bundles Org mode 9.1.9 and it defines keyboard mapping for completion like this: (org-defkey org-mode-map "\M-\t" #'pcomplete) (org-defkey org-mode-map [?\e (tab)] #'pcomplete) Here I can also use C-M-i to call pcomplete. (Both in windowed and terminal mode). However, I want to use org-plus-contrib from the Org ELPA repository. which uses a slightly different definition: (org-defkey org-mode-map (kbd "M-") #'pcomplete) (org-defkey org-mode-map (kbd "ESC ") #'pcomplete) This does not bind C-M-i which I'd like to use. Is there any reason for this discrepancy? Thank you Johannes
[O] Bug: Can't access org agenda custom command [9.2.1 (9.2.1-33-g029cf6-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190225/)]
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.
Hi all,
I've been having trouble with my custom agenda commands since the latest
update.
The agenda dispatcher used to work fine until the last update, but now,
given one of my custom agenda commands, it issues the error
"org-agenda-get-restriction-and-command: Wrong number of arguments".
I do believe the problem is due to the recent changes to the mentioned
function, discussed in the following thread:
http://lists.gnu.org/archive/html/emacs-orgmode/2019-02/msg00291.html
To test things, I started with `emacs -Q`, and evaluated the following:
#+begin_src emacs-lisp
(require 'package)
(package-initialize)
(require 'org)
(custom-set-variables
'(org-agenda-files
(quote
("~/Gustavo/Documents/Pessoal/Org Agenda/pessoal.org"
"~/Gustavo/Documents/Pessoal/Org Agenda/trabalho.org")))
'(org-agenda-custom-commands
(quote
(("h" . "Home Agenda Views")
("hh" "Home Agenda"
((agenda ""
((org-agenda-overriding-header "Today (Home)")
(org-agenda-span
(quote day
(todo ""
((org-agenda-overriding-header "Tasks")
(org-agenda-todo-ignore-with-date t)
(org-agenda-skip-function
(quote
(org-agenda-skip-entry-if
(quote todo)
(quote
("SOMEDAY"
((org-agenda-files
(quote
("~/Gustavo/Documents/Pessoal/Org Agenda/pessoal.org"
nil)
("hs" "Someday Tasks" todo "SOMEDAY"
((org-agenda-files
(quote
("~/Gustavo/Documents/Pessoal/Org Agenda/pessoal.org")
("w" . "Work Agenda Views")
("ww" "Work Agenda"
((agenda ""
((org-agenda-overriding-header "Today (Work)")
(org-agenda-span
(quote day
(todo ""
((org-agenda-overriding-header "Tasks")
(org-agenda-todo-ignore-with-date t)
(org-agenda-skip-function
(quote
(org-agenda-skip-entry-if
(quote todo)
(quote
("SOMEDAY"
nil nil)
("ws" "Someday Tasks" todo "SOMEDAY" nil)
("n" "Agenda and all TODOs"
((agenda "" nil)
(alltodo "" nil))
nil)
#+end_src
With this, =M-x org-version= returns: "Org mode version 9.2.1
(9.2.1-33-g029cf6-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20190225/)".
In this setting, if I try to access my "Work Agenda", with =M-x
org-agenda w w= I get the mentioned error
"org-agenda-get-restriction-and-command: Wrong number of arguments"
If I then evaluate the previous value of
=org-agenda-get-restriction-and-command= , as contained in
=org-plus-contrib-20190218= proper behaviour is restored.
Best regards,
Gustavo Barros.
Emacs : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2019-01-02
Package: Org mode version 9.2.1 (9.2.1-33-g029cf6-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20190225/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-agenda-files '("~/Gustavo/Documents/Pessoal/Org Agenda/pessoal.org"
"~/Gustavo/Documents/Pessoal/Org Agenda/trabalho.org")
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all append local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" . php)
("C" . c) ("C++" . c++) ("asymptote" . asy)
("bash" . sh) ("beamer" . latex) ("calc" . fundamental)
("cpp" . c++) ("ditaa" . artist) ("dot" . fundamental)
("elisp" . emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh)
("sqlite" . sql))
org-occur-hook '(org-first-h
[O] Bug: Plain list indentation on 'org-indent-item' with 'org-list-demote-modify-bullet' [9.2.4 (9.2.4-3-g7bc6f8-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190701/)]
Hi all,
'org-indent-item' disrupts indentation of lines other than the first one of a
given item when 'org-list-demote-modify-bullet' is non-nil. More precisely,
the lines below the first one get one extra space upon "org-metaright".
Steps to reproduce:
- Start with =emacs -Q=
- Get the latest installed Org version with =M-x package-initialized RET=
- Evaluate:
#+begin_src emacs-lisp
(setq org-list-demote-modify-bullet
'(("+" . "-") ("-" . "+") ("*" . "+")))
#+end_src
(That’s literally the example of the manual).
- Then find Org file with following contents with point placed where "|"
indicates:
#+begin_verbatim
- foo
- |bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz
bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz
bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz
bar baz bar baz bar baz
#+begin_src emacs-lisp
(+ 1 1)
#+end_src
#+RESULTS:
: 2
#+end_verbatim
- Use "" to indent the second item, the result is:
#+begin_verbatim
- foo
+ bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz
bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz
bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz
bar baz bar baz bar baz
#+begin_src emacs-lisp
(+ 1 1)
#+end_src
#+RESULTS:
: 2
#+end_verbatim
- Indeed, by going back and forth with "" and "" one can
"pump" the lines below the first one always further away:
#+begin_verbatim
- foo
+ bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz
bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz
bar baz
bar baz bar baz bar baz bar baz bar baz bar baz bar baz bar baz
bar baz
bar baz bar baz bar baz
#+begin_src emacs-lisp
(+ 1 1)
#+end_src
#+RESULTS:
: 2
#+end_verbatim
When 'org-list-demote-modify-bullet' has its default value of nil, all the
lines of the item are kept aligned with the first one, as would be expected.
Best regards,
Gustavo Barros.
Emacs : GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2019-04-19
Package: Org mode version 9.2.4 (9.2.4-3-g7bc6f8-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20190701/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all append local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-list-demote-modify-bullet '(("+" . "-") ("-" . "+") ("*" . "+"))
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" . php)
("C" . c) ("C++" . c++) ("asymptote" . asy)
("bash" . sh) ("beamer" . latex) ("calc" . fundamental)
("cpp" . c++) ("ditaa" . artist) ("dot" . fundamental)
("elisp" . emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh)
("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("id" :follow o
[O] Bug: Scheduling capture with a single line capture template [9.2.4 (9.2.4-10-g3b006f-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190715/)]
Hi all,
When using a single line capture template for an entry, the indirect buffer
where the capture editing occurs restrains itself to that single line. As a
consequence, scheduling during capture is not visible in the capture buffer.
I’m not really sure this is technically unexpected. But it is certainly
inconvenient. In case it is expected behavior though, if anyone has any
thoughts on how to circumvent it, it would be appreciated.
Steps to reproduce:
Start =emacs -Q=, and eval for basic setup:
#+begin_src emacs-lisp
(package-initialize)
(setq org-capture-templates
'(("t" "TODO entry" entry
(file+headline "~/org/notes.org" "Capture")
"** TODO %?"
:empty-lines 1)))
#+end_src
Where file "~/org/notes.org" has the following contents:
#+begin_src org
,* Previous heading
,* Capture
,* Following heading
#+end_src
Now capture a "TODO entry" task with =M-x org-capture RET t=. Once there,
write
something for the heading if you like, like "test", but try to schedule this
captured item with =C-c C-s=. Hit return for today’s date and note that the
scheduling information is not visible in the capture buffer (it is present in
"notes.org", of course).
Note that I use =:empty-lines 1= in the capture template, so technically there
is a line following the heading in the file (if you visit "notes.org" in
another window/frame along the capture process, you will see that this is
indeed the case). I also cannot add a newline manually in the template (with,
"** TODO %?\n"), for it is ignored, unless there is some content after it.
Again, I’m not sure if this is technically unexpected behavior, but I thought
it worth reporting. And, in case it is as it should be, just let me know.
Best regards,
Gustavo Barros.
Emacs : GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2019-04-22
Package: Org mode version 9.2.4 (9.2.4-10-g3b006f-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20190715/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all append local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" . php)
("C" . c) ("C++" . c++) ("asymptote" . asy)
("bash" . sh) ("beamer" . latex) ("calc" . fundamental)
("cpp" . c++) ("ditaa" . artist) ("dot" . fundamental)
("elisp" . emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh)
("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("id" :follow org-id-open)
("eww" :follow eww :store org-eww-store-link)
("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
:export org-irc-export)
("info" :follow org-info-open :export org-info-export
:store org-info-store-link)
("gnus" :follow org-gnus-open :s
[O] Bug: Saving and killing buffers with org-capture-refile and multiple agenda files [9.2.4 (9.2.4-11-g1c3eae-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)]
Hi all,
I document here some behaviors of =org-capture-refile= which occur when
settings
involve multiple files as refile targets, with respect to saving and
killing
buffers. Most of them are designed to show some more integration
between
=org-capture= and =org-capture-refile= would be welcome, and one of them
actually
does not correspond to documented behavior.
Consider the following scenario. We have two agenda files, one for work,
another for personal tasks. They have the following content:
#+name: ~/org/home.org
#+begin_src org
,* Home tasks
,* Capture
#+end_src
#+name: ~/org/work.org
#+begin_src org
,* Work tasks
#+end_src
We start ~emacs -Q~, and do some basic setup:
#+begin_src emacs-lisp
(package-initialize)
(global-set-key (kbd "C-c c") 'org-capture)
(setq org-agenda-files
'("~/org/home.org"
"~/org/work.org"))
(setq org-refile-targets
'((org-agenda-files :maxlevel . 2)))
(setq org-capture-templates
'(("t" "TODO entry" entry
(file+headline "~/org/home.org" "Capture")
"* TODO %?"
:kill-buffer t)))
#+end_src
In particular, we are not setting the =:no-save= flag, so we expect the
default
behavior of buffers getting saved.
Now, we start a capture of an arbitrary task, and leave the capture
process by
refiling it to the heading =* Home tasks=.
If we then list-buffers ("C-x C-b"), we find that =home.org= has been
killed as
expected, given the template's =:kill-buffer= flag. But =work.org=,
which was
opened to get the refile targets, is still there.
Now we do the same operation, but refile it to the heading =* Work
tasks=
instead.
If we then list-buffers again, we find that =work.org= is not only
trailing, but
has been left unsaved.
Now we first visit =home.org= and start a capture and end it refiling to
the
heading =* Work tasks=.
Notice here in particular that =home.org= is killed, even though it was
being
visited before the capture process started. This does not correspond to
documented behavior of =:kill-buffer=.
Summing up:
1. When refiling anywhere, all agenda files (as we set them as refile
targets)
are visited to supply refile targets, so any of those which are not
the
base of a capture template are left open, even when option
:kill-buffer is
set.
2. In this same case, if the refile operation is done to a file which is
not
the capture base file, the other file is left both modified and
trailing.
3. In this same case, even if =:kill-buffer= is not set, the other file
is left
unsaved after refile.
4. Furthermore, when =:kill-buffer= is set, when leaving the capture
operation
with =org-capture-refile= the capture base file is killed
independently of
whether it was opened before or not (contrary to what is stated in
the
documentation about it).
I understand, of course, that the refile operation is an independent one
which
is layered upon =org-capture=. So items 1-3 there would, in this sense
be
"expected". But, I meant to show with these cases, which I don’t think
can be
labeled "corner" ones, that some further integration between
=org-capture= and
=org-capture-refile= would be welcome. Item 4, is indeed a behavior
that does
not correspond to documentation and, to my understanding, should be
considered
a bug.
Best regards,
Gustavo Barros.
Emacs : GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.30)
of 2019-04-19
Package: Org mode version 9.2.4 (9.2.4-11-g1c3eae-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-refile-targets '((org-agenda-files :maxlevel . 2))
org-agenda-files '("~/org/home.org" "~/org/work.org")
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis
[O] Bug: canceled capture operation results in demoted following heading when template ends with newline [9.2.4 (9.2.4-11-g1c3eae-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)]
Hi all,
When the capture template ends with a newline character and the capture
process is canceled, the following heading gets demoted. And it
shouldn’t.
Consider the following scenario. We have an agenda file with the
following content:
#+name: ~/org/agenda.org
#+begin_src org
,* Capture
,* Following heading
#+end_src
We start ~emacs -Q~, and do some basic setup:
#+begin_src emacs-lisp
(package-initialize)
(global-set-key (kbd "C-c c") 'org-capture)
(setq org-agenda-files
'("~/org/agenda.org"))
(setq org-refile-targets
'((org-agenda-files :maxlevel . 2)))
(setq org-capture-templates
'(("t" "TODO entry" entry
(file+headline "~/org/agenda.org" "Capture")
"* TODO %?\n")))
#+end_src
Now we start capture with "C-c c t" and cancel it with "C-c
k". Examination of "agenda.org" will show:
#+name: ~/org/agenda.org
#+begin_src org
,* Capture
,** Following heading
#+end_src
Both the line between them is gone, and "* Following heading" got
demoted, which is particularly unfortunate.
I’m not sure that I found a general rule in this respect. I had met
this effect before in my workflow and vaguely associated it with a
trailing "\n". Investigating it further, I could find a recipe to
reproduce the effect, as shown, but I don’t really know how general it
is.
This effect does not occur if "\n" is removed from the template, and I
don’t know if its inclusion is to be considered bad practice,
particularly as the capture templates already have a structure to handle
empty lines. But, if my memory does not betray me in this respect, one
will find plenty of those laying around in folks configs.
Best regards,
Gustavo Barros.
Emacs : GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.30)
of 2019-04-19
Package: Org mode version 9.2.4 (9.2.4-11-g1c3eae-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-refile-targets '((org-agenda-files :maxlevel . 2))
org-agenda-files '("~/org/agenda.org")
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all append
local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php)
("C" . c) ("C++" . c++) ("asymptote" . asy)
("bash" . sh) ("beamer" . latex) ("calc"
. fundamental)
("cpp" . c++) ("ditaa" . artist) ("dot"
. fundamental)
("elisp" . emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh)
("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("id" :follow org-id-open)
("eww" :follow eww :store org-eww-store-link)
("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
:export org-irc-export)
("info" :follow org-info-open :export
org-info-export
:store org-info-store-lin
Re: [O] Org-mode latex pdf export issue: Underlined lines not breaking properly
Hi all,
On Fri, Jun 14 2013, Nicolas Goaziou wrote:
>>>> Nicolas Goaziou writes:
>>>>> 1. Does \underline{中文测试} work properly (notwithstanding the line
>>>>> breaks)?
>>>>
>>>> \underline can show chinese, but the command can't resolve lines
>>>> breaking properly.
>>>>
>>>>> 2. Does \uline from "ulem" package handle it correctly, including the
>>>>> line breaks?
>>>>
>>>> \uline seem to work properly.
>>>
>>> Then, the best solution seems to add "ulem" package to
>>> `org-latex-default-packages-alist' and use \ulem for underline. "soul"
>>> will only be used for strike-through.
>>>
>>> Is there any objection to this change?
>>
>> May be \ulem should be used for strike-through too!
>
> Done.
>
I know this is a very old thread, and that perhaps this boat has sailed
definitely.
But it seems to me that the attempt to use soul back then eventually
backfired because soul does not handle utf8 properly, as Feng Shu’s
issue demonstrated. Indeed it does not. But there is a patch to soul,
by Heiko Oberdiek, to handle this precise issue, and it is the package
soulutf8.
I’ve checked the commit history around the time of this thread, and it
seems soul, rather than soulutf8, was the attempt
(https://code.orgmode.org/bzg/org-mode/commit/95eeefa9bca1b6c57fe62c248a0a35302cd7374d).
Neither soul nor ulem is very active nowadays, but are used quite
extensively, as far as I know (from following TeX.SX). And both have
their limitations. But the ability to have line breaks is a clear edge
of soul, and the reason of the original request which started this
thread.
So, if the only reason to prefer ulem back in 2013 was utf8 support,
perhaps soulutf8 might be worthy of your reconsideration.
Best regards,
Gustavo Barros.
Re: [O] Org-mode latex pdf export issue: Underlined lines not breaking properly
On Mon, Jul 29 2019, Gustavo Barros wrote: But the ability to have line breaks is a clear edge of soul, and the reason of the original request which started this thread. I must correct myself, the difference between ulem and soul is not that one allows line breaks while the other does not. More precisely, both handle line breaks, but soul is able to honor hyphenation patterns, while ulem is not. If one wants a (underlined/stricken-through) word to break with ulem, the hyphenation has to be done manually. Best, Gustavo.
[O] Bug: Language code for Brazilian in org-latex-babel-language-alist and org-latex-polyglossia-language-alist
Hi all,
`org-latex-babel-language-alist' and
`org-latex-polyglossia-language-alist' have the language code for
Brazilian as =("bt-br" . "brazilian")=. I am a native Brazilian and our
language is Portuguese, and Brazilian Portuguese is a variant. That to
say that I’ve never seen the language code "bt-br" to refer to
"brazilian", whereas the usual code is "pt-br" (hyphen or underscore).
So this looks very much like a typo.
Best regards,
Gustavo.
PS: I’ve been reporting a lot recently, as I am in the process of
rereading Org’s documentation and fine tuning my Org config. But I don’t
mean in any way to be pushy. I hope to be bringing reports which are
pertinent and useful, but if I’m overdoing it, please don’t hesitate to
let me know.
PPS: As I’m not sending this through the bug reporting interface, it’s
best if I specify I consulted the values of the variables in
"ox.latex.el" from "org-plus-contrib-20190729".
Re: [O] Bug: canceled capture operation results in demoted following heading when template ends with newline [9.2.4 (9.2.4-11-g1c3eae-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)
Hi Carsten, thank you for looking into this. On Sat, Aug 10 2019, Carsten Dominik wrote: I tried to reproduce your example, and things worked properly I followed the described steps to the letter (except for the clear typo, where I should have written 'and cancel it with "C-c C-k"'). And the result is regularly the one described. I have no idea how I could further isolate things. Could '(package-initialize)' be of any relevance? The only purpose of it here is to load the most recent version of org, instead of the built-in one. In your experience, what could be the source of the difference here and there? (OS? WM?) Can anyone else reproduce? I'm at your disposal to test any other possible intervening factors. But, as it stands, I don't know where to look at. Best regards, Gustavo.
Re: [O] Bug: canceled capture operation results in demoted following heading when template ends with newline [9.2.4 (9.2.4-11-g1c3eae-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)
Hi Carsten, yes, let’s see if anyone else can reproduce. If not, feel free to file it under the old "little piece between the keyboard and the chair". Best, Gustavo. On Sat, Aug 10 2019, Carsten Dominik wrote: Hi Gustavo, I am also on Emacs 26.2, and I don't know where to look if I cannot reproduce the problem. It would be useful if someone else tries your minimal example and reports back. Carsten On Sat, Aug 10, 2019 at 12:54 PM Gustavo Barros wrote: Hi Carsten, thank you for looking into this. On Sat, Aug 10 2019, Carsten Dominik wrote: > I tried to reproduce your example, and things worked properly I followed the described steps to the letter (except for the clear typo, where I should have written 'and cancel it with "C-c C-k"'). And the result is regularly the one described. I have no idea how I could further isolate things. Could '(package-initialize)' be of any relevance? The only purpose of it here is to load the most recent version of org, instead of the built-in one. In your experience, what could be the source of the difference here and there? (OS? WM?) Can anyone else reproduce? I'm at your disposal to test any other possible intervening factors. But, as it stands, I don't know where to look at. Best regards, Gustavo.
Re: [O] Bug: canceled capture operation results in demoted following heading when template ends with newline [9.2.4 (9.2.4-11-g1c3eae-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)
Hi Carsten,
On Sat, Aug 10 2019, Carsten Dominik wrote:
Hi Gustavo,
I am also on Emacs 26.2, and I don't know where to look if I cannot
reproduce the problem.
It would be useful if someone else tries your minimal example and
reports
back.
Carsten
I’ve tried to put my hands on possible intervening factors I could think
of.
I’ve reduced the setup further to:
#+begin_src emacs-lisp
(add-to-list 'load-path
"/home/gustavo/.emacs.d/elpa/org-plus-contrib-20190805")
(load-library "org")
(global-set-key (kbd "C-c c") 'org-capture)
(setq org-agenda-files
'("~/org/agenda.org"))
(setq org-capture-templates
'(("t" "TODO entry" entry
(file+headline "~/org/agenda.org" "Capture")
"* TODO %?\n")))
#+end_src
I’ve tried to rebuilt Emacs from source with default =./configure=
options and run =src/emacs -Q=.
I’ve tried to create the agenda file from the =emacs -Q= session in case
any encoding options of mine could intervene.
I’ve also tried my different Linux flavors (Mint 19.2 Cinnamon and MX
Linux 18 Xfce).
And in every case the behavior was the same.
The only way I could make it not happen was to remove the preexisting
line between "* Capture" and "* Following heading" headings.
As mentioned, if anyone can think of anything else I can try to narrow
this down further, I’m at your disposal.
Best regards,
Gustavo.
Re: [O] Bug: Language code for Brazilian in org-latex-babel-language-alist and org-latex-polyglossia-language-alist
Hi Nicolas,
On Thu, Aug 15 2019, Nicolas Goaziou wrote:
Hello,
Gustavo Barros writes:
`org-latex-babel-language-alist' and
`org-latex-polyglossia-language-alist' have the language code for
Brazilian as =("bt-br" . "brazilian")=. I am a native Brazilian and
our language is Portuguese, and Brazilian Portuguese is a variant.
That to say that I’ve never seen the language code "bt-br" to refer
to
"brazilian", whereas the usual code is "pt-br" (hyphen or
underscore).
So this looks very much like a typo.
Fixed. Thank you!
I hadn’t checked the commit back then, but now I was seeing if I could
remove my local workaround on this and I noticed that while
`org-latex-babel-language-alist' is now looking good,
`org-latex-polyglossia-language-alist' was not changed. (This is so in
an up to date org-plus-contrib-20190904/ox-latex.el).
Best regards,
Gustavo.
[O] Getting org-plus-contrib but releases only
Hi all, I have a question regarding Org installation. It is probably known, but I’m failing to find proper guidance on the matter. So, if I missed something obvious, a pointer would be kind enough. As far as I understand, there are three typical ways to “get” Org: the built-in version, which lags somewhat behind; (GNU) Elpa, the default package repository, which offers the latest released version; and Org Elpa, which we can add as a repository, and which offers weekly builds. Also, as far as I get, only Org Elpa contains 'org-plus-contrib' for installation. (Or am I missing something?) I am a user of some of the 'contrib' packages, and would like to keep that. But I currently would like some more stability here, so I’d like to get releases only for updates of Org (but the latest ones, such as GNU Elpa does). Is there a (recommended) way to do both of these things at the same time? Best regards, Gustavo Barros.
Re: [O] Scheduling in a narrowed subtree: Bug?
On Mon, Sep 09 2019, Michaël Cadilhac wrote: > Is this the expected behavior? > > 1. Create an empty org file > 2. Insert > * Test > * Test 2 > 3. With the cursor at Test, hit C-x n s to narrow the view to the Test subtree > 4. Hit C-c C-s to schedule the line at any date. > > As a result, the SCHEDULED keyword is _not_ included in the narrow view, and > inserting things after the Test heading > moves the SCHEDULED keyword away from its second-line position. > > Cheers, > Michaël This is likely related to https://lists.gnu.org/archive/html/emacs-orgmode/2019-07/msg00087.html Regards, Gustavo. PS: I had tried to send this yesterday, but I think I have screwed up the sending then. If this is gets to you in duplicity, my apologies for the noise.
Re: [O] Scheduling in a narrowed subtree: Bug?
On Mon, Sep 09 2019, Michaël Cadilhac wrote: > Is this the expected behavior? > > 1. Create an empty org file > 2. Insert > * Test > * Test 2 > 3. With the cursor at Test, hit C-x n s to narrow the view to the Test subtree > 4. Hit C-c C-s to schedule the line at any date. > > As a result, the SCHEDULED keyword is _not_ included in the narrow view, and > inserting things after the Test heading > moves the SCHEDULED keyword away from its second-line position. This is likely related to https://lists.gnu.org/archive/html/emacs-orgmode/2019-07/msg00087.html Regards, Gustavo.
[O] Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Hi Org list,
`org-refile-get-target', when using `org-refile-use-outline-path'
appends an "extra" slash at the end of every path, but candidates are
stored in `org-refile-history' without that extra slash. As the default
candidate passed to `completing-read' is the car of `org-refile-history'
(the last refile target), the default candidate is provided in duplicity
(once with the trailing slash and once without it). This is the case
independent of the completion framework in use, but the difference is
less prominent with the default `completing-read-default' and more so
with, e.g., `ivy-completing-read'.
Steps to reproduce:
- Start 'emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(package-initialize)
(setq org-refile-targets '(("~/org/test.org" :maxlevel . 2)))
(setq org-refile-use-outline-path 'file)
(setq org-outline-path-complete-in-steps nil)
(ivy-mode)
;; as mentioned, Ivy just makes things clearer, the issue is
independent of it
#+end_src
- Open file "~/org/test.org", with contents:
#+begin_src org
,* Top heading 1
,* Top heading 2
,** Entry 1
,** Entry 2
#+end_src
- Go to heading "Entry 1", refile it to "Top heading 1"
- Go to heading "Entry 2", and call `org-refile'
- Observe the available candidates, and notice "test.org/Top heading 1"
is there twice, once as the default candidate, without a trailing
slash, and also on the paths list, with the slash.
Best regards,
Gustavo Barros.
Emacs : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.30)
of 2019-09-30
Package: Org mode version 9.2.6 (9.2.6-4-ge30905-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-refile-targets '(("~/org/test.org" :maxlevel . 2))
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-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-outline-path-complete-in-steps nil
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite"
. sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-refile-use-outline-path 'file
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("id" :follow org-id-open) ("eww" :follow eww
:store org-eww-store-link)
("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 :export org-irc-export)
("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
Re: org-refile-target-verify-function - use inherited tag & todo
Hi Nate, On Sun, Oct 27 2019, Nathan Neff wrote: > 1) My org-agenda-files show up in the list. For example, foo.org and bar.org > show up in the refile targets, despite the > function should return nil if a heading does not contain "Tasks" Curiously, I’ve been scratching this itch just today. So I might as well share. I presume you are using some of the specific values of `org-refile-use-outline-path'. If that’s the case, the file level as a refile target is hardcoded in `org-refile-get-targets', independently of what you might have in `org-refile-target-verify-function'. We have somewhere in `org-refile-get-targets': #+begin_src emacs-lisp (when (eq org-refile-use-outline-path 'file) (push (list (file-name-nondirectory f) f nil nil) tgs)) (when (eq org-refile-use-outline-path 'buffer-name) (push (list (buffer-name (buffer-base-buffer)) f nil nil) tgs)) (when (eq org-refile-use-outline-path 'full-file-path) (push (list (file-truename (buffer-file-name (buffer-base-buffer))) f nil nil) tgs)) #+end_src (`tgs' is the local variable which is collecting candidates for return). So, you might not use `org-refile-use-outline-path'. In this case the file info will be provided in the end of the refile target in parentheses (for targets outside the current buffer). And the file level will not be offered as a target. I, however like `org-refile-use-outline-path' and set it to 'file. But I also want to not be able to refile to the file level. So I advised `org-refile-get-targets' with: #+begin_src emacs-lisp (defun my/org-refile-filter-targets (orig-fun &rest args) (let ((targets (apply orig-fun args)) (agenda-files (mapcar #'file-name-nondirectory org-agenda-files))) (cl-remove-if (lambda (x) (member (car x) agenda-files)) targets))) (advice-add 'org-refile-get-targets :around #'my/org-refile-filter-targets) #+end_src This presumes (setq org-refile-use-outline-path 'file). If you use any other value, you should probably adjust the function’s let bound variables for the case. This is also sort of hackish, so exert your own due caution in choosing whether or not to use it. HTH, Gustavo.
Re: org-refile-target-verify-function - use inherited tag & todo
Hi Nate,
On Fri, Nov 01 2019, Nathan Neff wrote:
Indeed, I do use org-refile-use-outline-path 'file. However, I have a
simple
directory specified for my org-agenda-files. ("~/org-mode")
Therefore
I'll need to
do something a bit different.
It appears that your solution creates "targets" which is the targets
list
of course, and
then it creates "agenda-files" which goes through org-agenda-files and
finds all the filenames
in org-agenda files.
It then mutates "targets", and removes any entry which is a filename
from
org-agenda-files.
Since my org-agenda-files is simply ("~/org-mode/") none of the
entries
match.
Hmmm, let me ask: Why not simply go through targets and remove any
entry
whose value is
a simple filename? Why search org-agenda-files first? This function
also
assumes that the org-refile-targets
always comes from org-agenda-files.
I'll play with your function and see what I can get -- thank you for
the
head-start!
Thanks
--Nate
I'm glad this might be useful to you. And you are correct in all of
observations.
My main point is simply that, as things stand, you won't be able to trim
the file level candidates with `org-refile-target-verify-function`, as
they are hardcoded. But this simple function is the sketch of a
(hackish) way.
`org-refile-get-targets`' main purpose is to return the list of
targets. The advice function grabs this return value, filters the list
and returns the filtered list. How it filters may depend, as you noted.
I've chosen a simple criterion which meets my use case
(`org-agenda-files`, as I specify the individual files directly there,
and use only those as refile targets). Indeed, it does make some
presumptions, as you noted. (The function does not "search
org-agenda-files" though, it just gets the list of their names, which is
contained in the variable). In your case, you will certainly have to
devise another filtering criterion. I think the one you suggest is a
good one too.
Best regards,
Gustavo.
Re: Bug: Scheduling capture with a single line capture template [9.2.4 (9.2.4-10-g3b006f-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190715/)]
Hi Bastien, thanks for looking into this. On Tue, Feb 04 2020, Bastien wrote: I cannot reproduce this issue with latest stable Org and emacs -q. Can you check and report if this still needs a fix? Yes, I can still reproduce this as described in the original report with current version (Org mode version 9.3.2 (9.3.2-24-g5c72d6-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200203/)). As the recipe for the ECM starts with "emacs -Q", I don't know what else I could isolate in my environment. One possibility I can think of. It's been some time since I reported, but if I recall correctly, the existence of a headline *after* the one in which the capture is being placed was critical to the effect. Rereading the report, it is there in the ECM, but I haven't emphasized this in the analysis. Did you try the recipe with that file structure? But anyway, if you have any other ideas, I'm at your disposal to try things out and try to pin this further down. Best, Gustavo.
Re: Bug: Scheduling capture with a single line capture template [9.2.4 (9.2.4-10-g3b006f-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190715/)]
Hi Bastien, On Tue, Feb 04 2020, Bastien wrote: I managed to reproduce this bug, it is fixed in maint now. I can report this issue is gone with the update to Org 9.3.3. Thank you very much! Best, Gustavo.
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Hi Bastien, thank you very much for looking into this. On Wed, Feb 12 2020, Bastien wrote: this should be fixed in Org master branch, thanks for the detailed report. If you can confirm the fix, even better. I tested it and indeed the duplicate candidate is gone. However, the last refile target no longer seems to be offered as the default for a subsequent refile operation. Was that intentional? To be more precise, in terms of the ECM of the initial bug report, when refiling "Entry 2" the default target is "test.org/", when I would expect it to be "test.org/Top heading 1". Best, Gustavo.
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Hi Bastien, On Wed, Feb 12 2020, Bastien wrote: this should be fixed in Org master branch, thanks for the detailed report. If you can confirm the fix, even better. By the way, I almost forgot, a small "side-report" on this. In going to test this from master, I followed the instructions in the manual (web version https://orgmode.org/manual/Installation.html) and those instruct users to: $ git clone g...@code.orgmode.org:bzg/org-mode.git I tried it, but lacked the password... Am I missing something, or wouldn't it be more appropriate `https://code.orgmode.org/bzg/org-mode.git' in the manual? Best, Gustavo.
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Hi Bastien, On Thu, Feb 13 2020, Bastien wrote: Am I missing something, or wouldn't it be more appropriate `https://code.orgmode.org/bzg/org-mode.git' in the manual? Indeed, applied, thanks! Thanks!
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Hi Bastien, On Thu, Feb 13 2020, Bastien wrote: I tested it and indeed the duplicate candidate is gone. However, the last refile target no longer seems to be offered as the default for a subsequent refile operation. Was that intentional? Nope, an oversight -- fixed in master. Thank you very much. I've tested it again, and I believe it is working as intended. I observe, however, a difference of behavior between "completing-read-default" and "ivy-completing-read" in the workings of "org-refile-get-location". Namely, with "completing-read-default" the chosen target is stored in "org-refile-history" with a trailing slash (the "extra" part), while with "ivy-completing-read" it is stored without the trailing slash. I have no idea why this is so and also don't know if this stems from Org's end. As far as I can tell, functionality of the feature with respect to this bug report is working as intended: no duplicate candidates, and history is honored. But the difference surprised me and if you think it might be important, I can provide an ECM for it. Otherwise, I think this can well closed as fixed. Once again, thanks a lot for the fix. Best, Gustavo.
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Hi Bastien,
On Fri, Feb 14 2020, Bastien wrote:
I've revisited org-refile-get-location given your new information on
ivy-completing-read but I'm not able to see something wrong in the
current implementation of org-refile-get-location. At the same time,
I don't see why ivy-completing-read would handle arguments differently
than completing-read-default, so _perhaps_ org-refile-get-location
still does something wrong.
That was pretty much my thought too.
If you - or other ivy users - have time to investigate and report,
please do so.
I've tried, when I originally reported, and now again, to pin this
further down. Alas, there is much in 'org-refile-get-location' I don't
understand (in the sense of not understanding why certain things are
being done). I also have much to learn with respect to
'completing-read'. But I can provide an ECM to reproduce it.
- Start 'emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/src/org-mode/lisp"); current master
(setq org-refile-targets '(("~/org/test.org" :maxlevel . 2)))
(setq org-refile-use-outline-path 'file)
(setq org-outline-path-complete-in-steps nil)
#+end_src
- Open file "~/org/test.org", with contents:
#+begin_src org
,* Top heading 1
,* Top heading 2
,** Entry 1
,** Entry 2
#+end_src
- Now, do some refile operations here. Inspecting 'org-refile-history'
will give us:
#+begin_src emacs-lisp
("test.org/Top heading 2/" "test.org/Top heading 2/" "test.org/Top
heading 1/" "test.org/Top heading 1/")
#+end_src
- Now, we reset 'org-refile-history' and start 'ivy-mode':
#+begin_src emacs-lisp
(setq org-refile-history nil)
(add-to-list 'load-path ".emacs.d/elpa/ivy-20200211.1338"); current
Melpa
(require 'ivy)
(ivy-mode)
#+end_src
- After some refile operations, the value of 'org-refile-history' is:
#+begin_src emacs-lisp
("test.org/Top heading 2" "test.org/Top heading 2" "test.org/Top
heading 1" "test.org/Top heading 1")
#+end_src
The difference is, as previously reported, the presence/absence of the
trailing slash (the "extra" in terms of 'org-refile-get-location'). As
far as I can tell, it is inconsequential to the working of the refile
operation, but it did intrigue me.
Environment: Org mode version 9.3.6 (release_9.3.6-298-g0fa69d @
/home/gustavo/src/org-mode/lisp/); GNU Emacs 26.3 (build 1,
x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2019-11-11;
ivy-20200211.1338
HTH,
Gustavo.
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Hi Bastien, On Fri, Feb 14 2020, Bastien wrote: I've revisited org-refile-get-location given your new information on ivy-completing-read but I'm not able to see something wrong in the current implementation of org-refile-get-location. At the same time, I don't see why ivy-completing-read would handle arguments differently than completing-read-default, so _perhaps_ org-refile-get-location still does something wrong. If you - or other ivy users - have time to investigate and report, please do so. As I said before, there is much that eludes me in 'org-refile-get-location', but I'm trying to pin this down further by getting some inspection points and trying at least to grasp where it happens. In particular, I set one inspection point exactly after the completing-read function is called to store the value of local variable "answ" which is the return value of the completing-read function. That is, right after: #+begin_src emacs-lisp (setq answ (funcall cfunc prompt tbl nil (not new-nodes) nil 'org-refile-history (or cdef (concat (car org-refile-history) extra #+end_src The value of "answ" right after this step is then: - with 'ivy-mode' off, that is with 'completing-read-default' as 'completing-read-function': "test.org/Top heading 1//" (that is with a *double trailing slash*). - with 'ivy-mode' on, that is with 'ivy-completing-read' as 'completing-read-function': "test.org/Top heading 2/" In both cases the last trailing slash seems (as far as I understand it) to be then trimmed off by 'org-refile--get-location' with: #+begin_src emacs-lisp (replace-regexp-in-string "/$" "" refloc) #+end_src Why 'ivy-completing-read' does not return the end double slash while 'completing-read-default' does, I have no idea. But the fact that 'completing-read-default' returns the refile location with a double trailing slash makes me think there is still something to be fixed in 'org-refile-get-location'. Best, Gustavo.
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Hi Bastien, On Fri, Feb 14 2020, Bastien wrote: I hope you can fix this somehow, maybe upstream. Unfortunately, I'm afraid I don't understand this enough, and what 'ivy-completing-read' was supposed to do, to be able to provide a pertinent report there. I personally don't have a problem locally. I had a workaround thus far, and with your fix, I won't even need that. As previously reported, the issue initially raised is indeed fixed, and things work as expected. I don't claim a problem persists in Org, and I was just trying to be thorough in the testing you requested. And did so with pleasure. So... From what I understand, this is not a bug in Org. ... if you are satisfied, I'm happy with that too. Thank you very very much! Best, Gustavo.
Re: Bug: org-refile-get-target offers default candidate in duplicity [9.2.6 (9.2.6-4-ge30905-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20191007/)]
Hi Bastien, On Sun, Feb 16 2020, Bastien wrote: Hi Gustavo, Gustavo Barros writes: But the fact that 'completing-read-default' returns the refile location with a double trailing slash makes me think there is still something to be fixed in 'org-refile-get-location'. if you're not tired of the hunt, please tell us when you find what needs to be fixed--since there is no bug attached to this, I'll set this aside for now. I'm afraid I have broken proper sequence of this thread unintentionally. This strip you quote comes from a message I eventually sent 14/Feb 12:33, right after a message of yours at 12:29 in which you concluded: From what I understand, this is not a bug in Org. I hope you can fix this somehow, maybe upstream. The fact is that I was writing mine when yours came, and I didn't see yours until later. And when I did, the reply was: I don't claim a problem persists in Org, and I was just trying to be thorough in the testing you requested. And did so with pleasure. So... From what I understand, this is not a bug in Org. ... if you are satisfied, I'm happy with that too. Thank you very very much! So, with the messages in proper order, I was taken the issue as settled. If, however, you do think in my message of 12:29 I hit something which might be relevant, I'd be happy to pursue this further. I'm "not tired of the hunt", but I fear the issue might well be out of my league, so there is a real risk of me wasting your time and increasing the noise on the list. Besides, as reported before, it appears not to impact functionality. But, if knowing that, you would like me to do so, I'll be glad to try. In this case, let me know. Otherwise just: set this aside for now. And thanks again! Best, Gustavo.
Bug: Repeating tasks no longer appearing on future dates in the agenda [9.3.6 (9.3.6-17-g389288-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)]
Hi All,
As of recently, repeating tasks are no longer showing up in the agenda
for future dates. Below a minimal example of the issue:
Start "emacs -Q" and do some setup:
#+begin_src emacs-lisp
(package-initialize)
(setq org-agenda-files '("~/test/agenda.org"))
#+end_src
Where "~/test/agenda.org" contains:
#+begin_src org
,* TODO weekly task
SCHEDULED: <2020-02-29 Sat +1w>
#+end_src
Open the agenda: "M-x org-agenda RET a", navigate for future dates and
notice only the first instance of the repeating task is shown.
I can narrow the emergence of the problem between the following
org-plus-contrib versions.
Latest working: Org mode version 9.3.2 (9.3.2-8-g47b104-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20200127/)
First non-working: Org mode version 9.3.2 (9.3.2-24-g5c72d6-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20200203/)
Best,
Gustavo.
Emacs : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.30)
of 2019-11-11
Package: Org mode version 9.3.6 (9.3.6-17-g389288-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-agenda-files '("~/test/agenda.org")
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all append
local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php)
("C" . c) ("C++" . c++) ("asymptote" . asy)
("bash" . sh) ("beamer" . latex) ("calc"
. fundamental)
("cpp" . c++) ("ditaa" . artist) ("dot"
. fundamental)
("elisp" . emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh)
("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-open-link
:export
org-attach-export-link :complete
org-attach-complete-link)
("id" :follow org-id-open)
("eww" :follow eww :store org-eww-store-link)
("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
:export org-irc-export)
("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)
("elfeed" :follow elfeed-link-open :store
elfeed-link-store-link)
("file+sys") ("file+emacs")
("shell" :follow org-link--open-shell)
("news" :follow
#[257 "\301\300\302Q!\207" ["news" browse-url
":"] 5
"\n\n(fn URL)"]
)
("mailto" :follow
#[257 "\301\300\302Q!\207" ["mailto" browse-url
":"]
Bug: Export dispatcher scrolling with hidden top [9.3.6 (9.3.6-17-g389288-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)]
Hi All,
The export dispatcher scrolling seems to interact unfavorably general
Emacs scroll option "scroll-margin", in particular, setting it a
positive displaces the dispatcher upwards, eventually hiding completely
the options section at the top, even when there is space in the
frame/window to fit the whole dispatcher. You can scroll back to it, but
it seems both inconvenient and hard to find if one does not know "it
should be there".
I hope the following minimal example is reproducible by you. But it
might not be, given the interaction with frame size, results may well
depend on things which are not controlled. Besides, even though I
managed to come up with this reproducible (to me) example, I'm still not
sure I grasp properly the interactions involved. So, in case you cannot
reproduce, I can provide further info as requested.
Start "emacs -Q" and do some setup:
#+begin_src emacs-lisp
(package-initialize)
(add-to-list 'default-frame-alist '(height . 42))
(setq scroll-margin 3)
#+end_src
Find an Org file in other frame with "C-x 5 f". Run org-export-dispatch
("C-c C-e"), and see that the top of the dispatcher is not visible.
Best,
Gustavo.
Emacs : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.30)
of 2019-11-11
Package: Org mode version 9.3.6 (9.3.6-17-g389288-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
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-odt-format-headline-function
'org-odt-format-headline-default-function
org-ascii-format-inlinetask-function
'org-ascii-format-inlinetask-default
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-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-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME
CONTENTS)"]
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME
CONTENTS WIDTH)"]
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php)
("C" . c) ("C++" . c++) ("asymptote" . asy)
("bash" . sh) ("beamer" . latex) ("calc"
. fundamental)
("cpp" . c++) ("ditaa" . artist) ("dot"
. fundamental)
("elisp" . emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh)
("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-odt-format-inlinetask-function
'org-odt-format-inlinetask-default-function
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-open-link
:export
org-attach-export-link :complete
org-attach-complete-link)
("id" :follow org-id-open)
("eww" :follow eww :store org-eww-store-link)
("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
:export org-irc-export)
("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)
[BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi All,
I've been meeting a small glitch on the Agenda, which had been eluding
me for some time, as it "sometimes works, sometimes doesn't", and I
wasn't being able to recognize the rule for it. So I started keeping
track of it a while, and I was thus able to come up with a ECM. I'm not
sure the "rule" is the one I came up with, since it was based on
inference, but I hope the ECM is reproducible.
The glitch is that some repeated tasks, when marked done in the Agenda,
show no visual feedback that the action has taken place, as usual, and
if you refresh the Agenda, they just vanish, which demonstrates the
action had indeed taken place in the agenda file, just not shown in the
Agenda buffer itself. And, as far as I can tell, this happens to
repeated tasks, scheduled in future. For tasks scheduled for today or
in the past, they appear to be done as expected.
The ECM runs as follows. Start ~emacs -Q~ and setup current Org and the
agenda files:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-9.5")
(setq org-agenda-files '("~/test/agenda.org"))
#+end_src
Where =~/test/agenda.org= contains:
#+begin_src org
,* TODO Foo (scheduled for yesterday)
SCHEDULED: <2021-10-28 Thu +1w>
,* TODO Bar (scheduled for today)
SCHEDULED: <2021-10-29 Fri +1w>
,* TODO Baz (scheduled for tomorrow)
SCHEDULED: <2021-10-30 Sat +1w>
#+end_src
And note the dates relative to today are critical for the ECM to
demonstrate what it intends to. So, if you try this out another day,
shift the schedules as appropriate.
Now, run ~M-x org-agenda~, then "a" to get to the default agenda. And
mark each of these tasks done with "t".
"Foo" and "Bar" appear as "DONE", as usual and expected. "Baz" does
not.
Refresh the agenda, and see they are indeed all gone from this week's
view (hence marked done in the actual file). And indeed, with "f" we
see they are there next week.
Best regards,
Gustavo.
Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2021-03-25
Package: Org mode version 9.5 (9.5-g0a86ad @
/home/gustavo/.emacs.d/elpa/org-9.5/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-agenda-files '("~/test/agenda.org")
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-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-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("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 :export org-irc-export)
("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)
("doi" :follow org-link-doi-open :export
org-link-doi-export) ("file+sys") ("file+emacs")
("shell" :follow org-link--open-shell)
("news" :follow
#[514 "\301\300\302Q\"\207" ["news" browse-url
":"] 6 "\n\n(fn URL ARG)"])
Re: [BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi Ihor, On Fri, 29 Oct 2021 at 21:40, Ihor Radchenko wrote: Confirmed Thanks for checking and marking. Best, Gustavo.
[BUG] org-link-descriptive not honored as file-local-variable [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi All,
Currently, trying to set `org-link-descriptive' as file-local-variable
is not honored by Org, and doing so, leads to one of mismatched states
between `org-link-descriptive' and the invisibility specs.
An ECM for it. Start ~emacs -Q~ and setup current Org:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-9.5")
#+end_src
Visit =document.org= containing:
#+begin_src org
[[https://orgmode.org/][Org mode for Emacs]]
# Local Variables:
# org-link-descriptive: nil
# End:
#+end_src
The default value of `org-link-descriptive' is t, and after visiting
this file, the local variable is indeed set (inspect it, and it tells
you it is nil). However, the links are still "descriptive", and
`buffer-invisibility-spec' does contain `(org-link)'. Indeed, if at
that point, you try `org-toggle-link-display', it will fail the first
time, but work the second one.
Possibly related threads:
https://list.orgmode.org/87pmzdhl4b@kenko.localhost.com/
https://list.orgmode.org/orgmode/87lfeqzm3a@gmail.com/
Best regards,
Gustavo.
Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2021-03-25
Package: Org mode version 9.5 (9.5-g0a86ad @
/home/gustavo/.emacs.d/elpa/org-9.5/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-reveal-start-hook '(org-decrypt-entry)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-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-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("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 :export org-irc-export)
("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)
("doi" :follow org-link-doi-open :export
org-link-doi-export) ("file+sys") ("file+emacs")
("shell" :follow org-link--open-shell)
("news" :follow
#[514 "\301\300\302Q\"\207" ["news" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("mailto" :follow
#[514 "\301\300\302Q\"\207" ["mailto" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("https" :follow
#[514 "\301\300\302Q\"\207" ["https" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("http" :follow
#[514 "\301\300\302Q\"\207" ["http" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("ftp" :follow
#[514 "\301\300\302Q\"\207" ["ftp" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("help" :follow org-link--open-help :store
org-link--store-help)
("file" :complete org-link-complete-file)
("elisp" :follow org-link--open-elisp))
org-link-elisp-confirm-function 'yes-or-no-p
)
[BUG] Propertized space in Agenda's mode-name [9.5.2 (release_9.5.2-3-geb9f34 @ /usr/local/share/emacs/28.0.91/lisp/org/)]
Hi All,
I'm trying out the pre-release this week, and in thus doing, I met a
particularly strange issue related to Org Agenda's `mode-name'. And one
space in particular, the one that is added before
`org-agenda-current-span'. The `mode-name' for the Agenda is set by
`org-agenda-set-mode-name', and inside it we find:
#+begin_src emacs-lisp
" "
'(:eval (org-agenda-span-name org-agenda-current-span))
#+end_src
Now, this space somehow gets propertized.
A recipe for it. Start `emacs -Q'. Set things up:
#+begin_src emacs-lisp
(setq org-agenda-files '("~/agenda.org"))
(setq eval-expression-print-level nil)
(setq eval-expression-print-length nil)
#+end_src
Let's say =agenda.org= contains:
#+begin_src org
,* TODO Task
SCHEDULED: <2022-02-28 Mon>
#+end_src
Call `M-x org-agenda RET a'. Now examine `mode-name' with `M-:
mode-name RET' to get:
#+begin_src emacs-lisp
("Org-Agenda" "" #(" " 0 1 (todo-state #("TODO" 0 4 (fontified nil
org-category "agenda")) org-habit-p nil priority 1099 warntime nil
ts-date 738214 date (2 28 2022) type "scheduled" org-hd-marker #(moves after insertion) at 1 in agenda.org> org-marker #after insertion) at 24 in agenda.org> face org-scheduled-today
undone-face org-scheduled-today help-echo "mouse-2 or RET jump to Org
file ~/agenda.org" mouse-face highlight done-face org-agenda-done
org-complex-heading-regexp "^\\(\\*+\\)\\(?: +\\(DONE\\|TODO\\)\\)?\\(?:
+\\(\\[#.\\]\\)\\)?\\(?: +\\(.*?\\)\\)??\\(?:[
]+\\(:[[:alnum:]_@#%:]+:\\)\\)?[ ]*$" org-todo-regexp
"\\(DONE\\|TODO\\)" org-not-done-regexp "\\(TODO\\)" dotime time format
(((org-prefix-has-time t) (org-prefix-has-tag nil)
(org-prefix-category-length 12) (org-prefix-has-effort nil)
(org-prefix-has-breadcrumbs nil)) (format " %s %s%s%s" (format "%s" (if
(member category-icon '("" nil)) "" (concat category-icon ""
(get-text-property 0 'extra-space category-icon (format "%-12s" (if
(member category '("" nil)) "" (concat category ":" (get-text-property 0
'extra-space category (if (member time '("" nil)) "" (format "%-12s"
(concat time ""))) (format "%s" (if (member extra '("" nil)) "" (concat
extra " " (get-text-property 0 'extra-space extra)) extra
"Scheduled: " time "" level " " txt #("TODO Task" 0 9 (fontified nil
org-category "agenda" org-heading t)) breadcrumbs nil duration nil
time-of-day nil org-priority-lowest 67 org-priority-highest 65 tags nil
org-category "agenda")) (:eval (org-agenda-span-name
org-agenda-current-span)) "" "" "" " Ddl" " Grid" "" "" "" "" "" "" ""
"" "")
#+end_src
So, it appears that the Org Agenda buffer's properties are somehow
getting to that particular space in `mode-name'. It completely beats me
how it is so but, alas, it is there.
This is a problem because, depending on what the content of your agenda
is, this might result in this space getting some visually distinctive
property. In my case, I get a blank gap in the mode-line at this point.
I couldn't generate a simple ECM that gets this effect. But, at this
point, it should be clear it can happen, given these properties are
there.
This was all tested with the latest pre-release tarball, and the Org
built-in there. (I did not get the mode-line gap with 27.2 and the
latest Org release for the same agendas).
Btw, since we are talking about this particular space in `mode-name', I
always had some qualms with the fact that it is unconditionally added
there, so that we get a double space for Agendas for which `(:eval
(org-agenda-span-name org-agenda-current-span))' results in an empty
string (e.g. a simple todo agenda). Couldn't this space be added there
conditionally there? It is likely trivial to handle it directly in
`org-agenda-span-name' (I know it also used in `org-agenda-list', but an
optional argument could make the distinction). WDYT?
Best regards,
Gustavo.
Emacs : GNU Emacs 28.0.91 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2022-02-26
Package: Org mode version 9.5.2 (release_9.5.2-3-geb9f34 @
/usr/local/share/emacs/28.0.91/lisp/org/)
current state:
==
(setq
org-link-elisp-confirm-function 'yes-or-no-p
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-agenda-files '("~/agenda.org")
org-export-before-parsing-hook '(org-attach-expand-links)
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-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-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-confirm-shell-link-function 'yes-or-no-p
outline-isearch-open-invisible-function 'outline-isearch-open-
Re: Bug: Repeating tasks no longer appearing on future dates in the agenda [9.3.6 (9.3.6-17-g389288-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)]
Hi all, I'd like to respectfully bump this bug report. It's an annoying regression of a widely used Org feature, is precisely located (to the commit) and has been reproduced by Kyle (btw, thanks, Kyle). Of course, if someone is already looking into it, and just didn't have the time yet, please disregard the bump. Best, Gustavo. On Fri, Feb 28 2020, Kyle Meyer wrote: Hi Gustavo, Gustavo Barros writes: Hi All, As of recently, repeating tasks are no longer showing up in the agenda for future dates. Below a minimal example of the issue: Thanks for the report and the minimal example to trigger the issue. This bisects to 39c656870 (org-agenda.el: Fix handling of one-time delays, 2020-02-01), which was part of the 9.3.3 release. I believe this is the thread that prompted that change: https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00353.html
Re: Bug: Repeating tasks no longer appearing on future dates in the agenda [9.3.6 (9.3.6-17-g389288-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)]
Hi Kyle, On Sun, Apr 12 2020, Kyle Meyer wrote: I'll plan to revert the commit tomorrow. Please chime in if you disagree with me doing so. Reverted in 1de7eabf2. Thank you very much for this. I've already received the weekly build, and it looks good again. Hopefully a solution for the one-time delay issue which does not trigger this new problem can be found. But I concur (if I may) it was a wise decision to revert the commit in the meantime. Best, Gustavo.
A small idea to simplify (further) time input in the date/time prompt
Hi All, the Org date/time prompt does deliver the promise in the manual that we "start getting annoyed by pretty much any other way of entering a date/time out there". It has indeed become so for me, as the date/time prompt is very neat. But there is one place where input could be even shorter, which is time input. Currently, time input mostly requires "hour colon minutes", thus a full time specification even when minutes are "00". And "mostly" because you can get away with that last part if you use am/pm convention (alas, I do not belong to those strange corners of the world). Besides, the colon is a shift-key in many common keyboard layouts (from a simple search, it seems to be so in British, American, US International, German, Spanish, and Portuguese layouts, it doesn't seem to be so for the French layout though). So I'd like to suggest a simplification there, which is: a string in the format "hour h minute" (that's small caps letter "H"), but in which "hour h" would also be recognized as a full hour and "00" minutes presumed. The mnemonic is obvious for "hour", which works well for English, French, Spanish, Portuguese, not so much for German. With this, we'd have some example inputs, and their respective results: 8h -> 08:00 10h30-> 10:30 18h -> 18:00 9h-10h -> 09:00-10:00 9h30-10h -> 09:30-10:00 14h+1h -> 14:00-15:00 This would ease input in two ways. First, it presumes the minutes in full hours, thus dispensing with this typing. Considering full hours are a very common case for scheduling and appointments, that shortening should be significant. It is also one key shorter than the am/pm way for full hours, and two keys shorter for non full hours in the same case. Second, it is easier to type "h" than it is to type ":", it is easier to reach and it is not a shift-key, so the chord is gone too. One corner case which will arise is if "zero hour" should also be presumed. Arguably midnight is not that common in most people's agenda, and could be either "0h" or "24h", so we should not really worry in shortening something like "midnight and thirty minutes" as "h30". But this is more tricky with duration specification, that is with "+". In this case minutes not comprising a full hour might well be common. So, how to specify an appointment starting at 10:00 that lasts 30 minutes? Some alternatives could be: "10h+0h30", "10h+h30", "10h+30m". On a first thought I like the last one better, but I'm really not sure what the best approach should be here. Needless to say, current input conventions should not change. This is just thought as an additional way of inputting time, alongside the ones which already exist. I'm unaware of any use of "h" in the date/time prompt (or of "m", for that matter), so I presume this should be viable without conflicting with other currently recognized input forms. That's the small suggestion I had to make for the date/time prompt. I guess, technically, this should be filed as "feature request". But it is just an idea I bring to your consideration, in the hope someone else here also likes it. Best, Gustavo.
Re: A small idea to simplify (further) time input in the date/time prompt
On Thu, May 21 2020, Gustavo Barros wrote: format "hour h minute" (that's small caps letter "H"), but ^^ Sorry, I obviously would like to have said "lowercase" here. Best, Gustavo.
Re: A small idea to simplify (further) time input in the date/time prompt
Hi Robert, On Thu, May 21 2020, Robert Horn wrote: Eric S Fraga writes: On Thursday, 21 May 2020 at 09:29, Gustavo Barros wrote: So I'd like to suggest a simplification there, which is: a string in the format "hour h minute" (that's small caps letter "H"), but in I would be strongly in favour of having this option. This is how I write times in email messages, for instance, so would be more consistent for me. And especially when I communicate with my European partners when referring to times after 12 noon. I would be opposed. There are already dozens of different formats used in different situations and locations for writing the time. This would be yet another different time format. It is relatively unique in that there is no other place in the world that uses it. I don't think that uniqueness is an argument in its favor. There some other formats that are actually in widespread use worldwide that I would prefer as available alternatives: European dot notation. Many people use the dot rather than the colon, so 13:05 is written as 13.05. I think this is mostly a keyboard, pen, and pencil thing. Colon is harder to write. It's inconveniently located on many keyboards. The problem with dot notation is potential confusion for more detailed time. "15:53:00.322348" is easy to guess and understand. "15.53.00.322348" is more confusing. Military time, which is used in most militaries, aviation, etc. hhmmZ - Time in UTC on a 24-hr clock, also called "Zulu time". The ISO 8601 time "11:21:00 -0400" would be 1521Z. This is almost mandatory when dealing with multi-location scheduling so that everyone uses the same time base. hhmmJ or hhmmh - Time in local zone on a 24-hr clock. It's widely used in military organizations for times that do not need multi-location scheduling. The time "1121J" or "1121h" is usually spoken in English as "eleven twenty one hours". These times are also lack the colon typing problem. I've not pushed for these mostly because convenience typing military time isn't worth figuring out all the changes that would be needed. It's worth looking at all the issues discussed in ISO 8601 and understanding them before you leap into time formatting changes. ISO 8601 is a compromise solution with lots of warts, but it is widely supported and understood. I do appreciate your arguments. But in reading them, I'd like to emphasize that I'm not in any way suggesting the timestamps be changed at all. The suggestion regards exclusively adding and extra way to input such times in the date/time prompt. And one which I feel is very much in the spirit of the prompt, which already takes ".", "+4d" (even just "+4"), "+2w", "+2tue" as valid date specifications. If I get this spirit correctly, it is to be smart in allowing short and easy input for the common cases, and the less common ones are handled by the full/formal date/time specification, which can always be inserted anyway. This kind of input simplification is already taken far for dates in the date/time prompt, but less so for time. And that's the only point my suggestion tries to address. I have no particular attachment for the "h" input form I suggested, except that it seemed natural (Eric's response seems to endorse it). If other ways to simplify input of time come up, they'd be equally appreciated, as far as I'm concerned. And if none come up, the current date/time prompt would still be my favorite tool for the task, of course. ;-) Best, Gustavo.
Re: Bug: Export dispatcher scrolling with hidden top [9.3.6 (9.3.6-17-g389288-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)]
Hi All,
this is a friendly ping on this export dispatcher regression.
(Considering
https://lists.gnu.org/archive/html/emacs-orgmode/2020-06/msg00038.html).
I just re-tested it now and the recipe provided in the report still
generates the issue in the current weekly build.
Of course, if anyone is already onto it, please disregard the ping.
Best,
Gustavo.
On Sat, Feb 29 2020, Gustavo Barros wrote:
Hi All,
The export dispatcher scrolling seems to interact unfavorably general
Emacs
scroll option "scroll-margin", in particular, setting it a positive
displaces
the dispatcher upwards, eventually hiding completely the options
section at
the top, even when there is space in the frame/window to fit the whole
dispatcher. You can scroll back to it, but it seems both inconvenient
and hard
to find if one does not know "it should be there".
I hope the following minimal example is reproducible by you. But it
might not
be, given the interaction with frame size, results may well depend on
things
which are not controlled. Besides, even though I managed to come up
with this
reproducible (to me) example, I'm still not sure I grasp properly the
interactions involved. So, in case you cannot reproduce, I can
provide
further info as requested.
Start "emacs -Q" and do some setup:
#+begin_src emacs-lisp
(package-initialize)
(add-to-list 'default-frame-alist '(height . 42))
(setq scroll-margin 3)
#+end_src
Find an Org file in other frame with "C-x 5 f". Run
org-export-dispatch ("C-c
C-e"), and see that the top of the dispatcher is not visible.
Best,
Gustavo.
Emacs : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.30)
of 2019-11-11
Package: Org mode version 9.3.6 (9.3.6-17-g389288-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
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-odt-format-headline-function
'org-odt-format-headline-default-function
org-ascii-format-inlinetask-function
'org-ascii-format-inlinetask-default
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-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-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME
CONTENTS)"]
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME
CONTENTS
WIDTH)"]
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php)
("C" . c) ("C++" . c++) ("asymptote" . asy)
("bash" . sh) ("beamer" . latex) ("calc"
. fundamental)
("cpp" . c++) ("ditaa" . artist) ("dot"
. fundamental)
("elisp" . emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh)
("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-odt-format-inlinetask-function
'org-odt-format-inlinetask-default-function
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-open-link
:export
org-attach-export-l
Re: A small idea to simplify (further) time input in the date/time prompt
Hi Bastien, On Tue, Jun 02 2020, Bastien wrote: I like this idea, thanks for proposing it. We are in feature freeze for core features, so we have time to work on this for Org 9.5. Of course, there's absolutely no rush in this, and this is clearly not something to be added shortly before a release. Thank you very much for considering it. Gustavo Barros writes: With this, we'd have some example inputs, and their respective results: 8h -> 08:00 10h30-> 10:30 18h -> 18:00 9h-10h -> 09:00-10:00 9h30-10h -> 09:30-10:00 All the above looks good to me as more flexible ways to input time. But: 14h+1h -> 14:00-15:00 is not necessary. Instead, 14h+1 should produce 14:00-15:00. This way, the "+" in "[hour]+N" as the same meaning, whether [hour] is formed as HH:MM or as Hh. Would you agree? I wasn't aware that a plain number after "+" in "[hour]+N" was interpreted as "N hours", I always went for a "3-4 digit plus colon" format to specify duration. But this is indeed a strong argument for things to work the same way for both kinds of input. Besides, I like the idea, but I'm probably missing something. In this case, how would you then input a duration smaller than an hour? Let's say 30 minutes? Would you like to work on this change? I'm not sure I'm up for the task, but I would be willing to try. However, there's another problem. I can't offer signed papers for the foreseeable future. I'd love to, I've contacted FSF to do so last year, but my current employment terms imposed a barrier there, which I cannot circumvent. So I've been trying to contribute in the ways that I can, with ideas, reports, and so on. And I hope to be doing so with good ones. Anyway, if you, with your knowledge of the date/time prompt, think this sort of change might fit into a "tiny change" (even if it turns out it doesn't, ex-post), I'd be willing to give it a shot. But otherwise, I've got my hands tied. Thanks again. Best, Gustavo.
Re: A small idea to simplify (further) time input in the date/time prompt
Hi stardiviner, On Tue, Jun 02 2020, stardiviner wrote: Which date/time prompt do you mean? Like set schedule or deadline? If just raw timestamp, it makes me confused whether it is time continuance. The date/time prompt is Org's interface for querying for date and time which is described in the [[info:org#The date/time prompt]] section of the manual. It is indeed the interface you get when calling 'org-time-stamp', 'org-schedule', 'org-deadline' etc. As mentioned before in the thread, the suggestion is orthogonal to the timestamp format or with document syntax. It is just an alternative way to input time in the date/time prompt, which should produce the same good old timestamp. Best, Gustavo.
Re: A small idea to simplify (further) time input in the date/time prompt
Hi Bastien,
On Tue, Jun 02 2020, Bastien wrote:
Hi Gustavo,
I like this idea, thanks for proposing it. We are in feature freeze
for core features, so we have time to work on this for Org 9.5.
[...]
Would you agree? Would you like to work on this change?
Well, I did give it a shot. And, as it turns out, this might be
manageable within my limitations.
A preliminary patch is attached, for comments.
I took here the stance of following the same treatment which is given to
am/pm times, and of using the letter "h" as sole main identifier. In
particular, standard "HH:MM" times take precedence, as is the case for
am/pm times. And duration specification with numbers only are presumed
to be hours, which was already the case, the patch does not introduce
any changes here. The input will match for this format for "number h
2-digit-number", where either the hour or the minutes, but not both, can
be omitted and, if so, is presumed to be zero. 24h format is also
presumed.
With it, some example inputs/outputs for time in the date/time prompt:
| input | output |
|---+-|
| 9h| 09:00 |
| h45 | 00:45 |
| 21h | 21:00 |
| 9h-10h| 09:00-10:00 |
| 9h--10h30 | 09:00-10:30 |
| 18h30+h30 | 18:30-19:00 |
| 18h30+1 | 18:30-19:30 |
| 18h30+1h | 18:30-19:30 |
And some sanity checks:
| input | output | Observation
|
|---+--+---|
| 10:00 9h | 10:00| by design, as for am/pm times
|
| 10am 9h | 10:00| expected from coming after am/pm
handling |
| 10:00-11h | 10:00-11:00 |
|
| 10h-11:00 | no match | am/pm also does not match here
|
| +9h | no match |
|
| -9h | no match |
|
| h | no match |
|
| 10h+h | no match |
|
| h5| no match |
|
| 10h70 | no match |
|
| 29h | 2020-06-04 Thu 05:00 | makes sense, same as for 29:00
|
| 30h | no match | as per the regexp
|
WDYT?
Best,
Gustavo.
>From 02829c7771a1f7a0c00d607a924fb8f56d2f3dd6 Mon Sep 17 00:00:00 2001
From: Gustavo Barros
Date: Wed, 3 Jun 2020 08:57:53 -0300
Subject: [PATCH] date/time prompt: Provide support for HHhMM time input
* lisp/org.el (org-read-date-analyze): Add support for HHhMM time
input, in similar way as for am/pm times.
* doc/org-manual.org (The date/time prompt): Add example to illustrate
the feature.
TINYCHANGE
---
doc/org-manual.org | 1 +
lisp/org.el| 13 +
2 files changed, 14 insertions(+)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 92252179b..bfd2aea1f 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -6017,6 +6017,7 @@ dash(es) as the separator in the former case and use =+= as the
separator in the latter case, e.g.:
| =11am-1:15pm= | \rArr{} 11:00-13:15 |
+| =11h-13h15=| \rArr{} same as above |
| =11am--1:15pm= | \rArr{} same as above |
| =11am+2:15=| \rArr{} same as above |
diff --git a/lisp/org.el b/lisp/org.el
index b869e12e1..8333e1a5a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13981,6 +13981,19 @@ user."
(setq ans (replace-match (format "%02d:%02d" hour minute)
t t ans
+;; Help matching HHhMM times, similarly as for am/pm times.
+(cl-loop for i from 1 to 2 do ; twice, for end time as well
+ (when (and (not (string-match "\\(\\`\\|[^+]\\)[012]?[0-9]:[0-9][0-9]\\([ \t\n]\\|$\\)" ans))
+ (string-match "\\(?:\\(?1:[012]?[0-9]\\)?h\\(?2:[0-5][0-9]\\)\\)\\|\\(?:\\(?1:[012]?[0-9]\\)h\\(?2:[0-5][0-9]\\)?\\)\\>" ans))
+ (setq hour (if (match-end 1)
+(string-to-number (match-string 1 ans))
+ 0)
+ minute (if (match-end 2)
+(string-to-number (match-string 2 ans))
+ 0))
+ (setq ans (replace-match (format "%02d:%02d" hour minute)
+ t t ans
+
;; Check if a time range is given as a duration
(when (string-match "\\([012]?[0-9]\\):\\([0-6][0-9]\\)\\+\\([012]?[0-9]\\)\\(:\\([0-5][0-9]\\)\\)?" ans)
(setq hour (string-to-number (match-string 1 ans))
--
2.17.1
org-lint and org-attach DIR property
Hi All, When setting the 'DIR' property for attachments for a whole file with =#+PROPERTY: DIR ...=, 'org-lint' will issue a deprecation warning and recommend the use "header-args" instead. Of course, 'org-lint' means here babel blocks, but as far as I understand, setting the 'DIR' property for attachments for the whole file this way is a legitimate use case, and is the only way to do so for org-attach. If this is the case, the warning issued by 'org-lint' might be misleading. I'm admittedly not well acquainted with 'org-lint', but thought it worth to bring the case to your attention, for your consideration. To generate such a warning, starting with =emacs -Q=, set load-path to get the proper version of Org (as your case may be): #+begin_src emacs-lisp (add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20200608") #+end_src Then visit an Org file with following contents: #+begin_src org ,#+property: DIR attachments ,* entry1 ,* entry2 #+end_src 'org-lint' will return: #+begin_example 1 low Deprecated syntax for "DIR". Use header-args instead #+end_example This was tested with "Org mode version 9.3.7 (9.3.7-2-g706970-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200608/)" and "GNU Emacs 27.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, cairo version 1.15.10) of 2020-05-20". Best, Gustavo.
Re: org-lint and org-attach DIR property
Hi Nicolas, On Fri, 12 Jun 2020 at 18:59, Nicolas Goaziou wrote: I removed the warning for dir property. Thank you. Thank you very much. Regards, Gustavo.
[FR] Add check for attachments in org-lint
Hi All, Org 'attachment:' links are essentially file links to local files and, while 'org-lint' checks 'file:' links for the existence of the corresponding files with `org-lint-link-to-local-file', as far as I can tell, the same check is not done for 'attachment:' links. So, I'd like to kindly suggest that either "attachment" be included as a case in `org-lint-link-to-local-file' or that an equivalent check for attachments be included in `org-lint'. I'd be much thankful. Best, Gustavo.
Re: [PATCH] Add mode for automatically unhiding emphasis markers in the current region
Hi Kyle, Hi Shankar, On Mon, 22 Jun 2020 at 05:40, Kyle Meyer wrote: > Shankar Rao writes: > >> This patch adds a minor mode that makes emphasis markers be automatically >> unhidden when the point is inside the region of emphasis and then the >> markers are rehidden when the point is moved elsewhere. I posted this on >> /r/orgmode on reddit ( >> https://www.reddit.com/r/orgmode/comments/gss1g4/update_i_made_my_own_sbrorgemphasizemode_that/), >> and people there suggested that I submit this here as a patch. > > I don't prefer my emphasis markers hidden (i.e. I leave > org-hide-emphasis-markers at nil), so perhaps I'm not the best to judge, > but that does sound like a nice feature. > > I'm hoping others will try this out and give their thoughts. Just an user here, but I'd like to leave my +1 to this proposed feature. I did use org-hide-emphasis-markers in the past and I liked it, but eventually dropped it because of the inconveniences of editing at the border of an emphasized region. This proposed feature eliminates the "which side of the invisible character are we?" ambiguity, so I repute it very nice indeed. I would certainly appreciate the inclusion of such a feature and, since I've been around, I've seen folks demanding something of the sort (memory here, no hard data). Indeed, I was one of the people at Reddit who suggested Shankar submitted this to the list. I did (lightly) test the code as posted on Reddit, and liked what I saw. I tried a number of cases I could think of: multiple lines, nested emphasis markers etc. As far as I tried, it did work as advertised. I also did report a corner case I found: > The only edge case I found, which in no way mars the absolute coolness > of this, is when you are actually inserting the emphasis marker. For > example, if you type *word*. Right after you type the last "*" the > emphasis will be hidden, even though the point position would have it to > be shown. Same thing if you select word and "C-c C-x C-f *". You have to > actually move point, for the mode to work in this situation. Shankar replied me this behavior is the same in prettify-symbols-mode, on which the code is based. I do not use prettify-symbols-mode myself, but did play with it a little because of this, and could not infer a regularity, so I must trust Shankar's point here. And it is indeed just a corner situation, which has no further implication I can conceive, and which does not diminish the usefulness of the feature. I can add another thought on the matter. While prettify-symbols is a mode, org-hide-emphasis-markers is an option/variable. So I wonder if the feature would fit better the current state of things in Org as either another option/defcustom or by simply expanding the range of possible values for org-hide-emphasis-markers (e.g. t, nil, not-at-point, not-at-point-right-edge). But this is just a thought, I'd be happy to see this feature be included either way. So, thanks Shankar for proposing the patch, and thanks Kyle for reviewing it. HTH. Best, Gustavo.
Re: [PATCH] Add mode for automatically unhiding emphasis markers in the current region
Hi Shankar, Detailed comments are up for Kyle, or someone more qualified than myself, but I leave one further comment regarding the suggestion I had made. On Wed, 24 Jun 2020 at 09:53, Shankar Rao wrote: I agree that adding this functionality as additional options to org-hide-emphasis-markers would be more intuitive and elegant for users, as they wouldn't have to perform (add-hook 'org-mode #'org-auto-emphasis-mode) in order to enable this mode. I didn't implement it this way first because I wanted to make the simplest, least disruptive way possible, and secondly because I didn't quite know how to implement it :-). As you can see in the patch, besides the additional functions and variables, my code only modifies one preexisting org function, replacing four lines with my new eight lines. To implement this functionality in the way Gustavo suggests, we would have to for all users add org-auto-emphasis--post-command-hook to post-command-hook, and modify it so that it only operates when org-hide-emphasis-markers is 'not-at-point or 'not-at-point-right-edge. I can try to implement this if you think it would be a good idea, but I have one concern. Even if a user is not interested in org-auto-emphasis-mode, this implementation would add a small amount of code to post-command-hook, so would have the effect of slightly slowing down their system. You have a good point here. When I made the suggestion I was naively thinking the featured could be plugged/hooked somewhere in Org, when fontification is done. But that's not really true, as the feature requires being run every time the point moves too. So, as far as I can tell, it seems using post-command-hook is unavoidable, and if so, you are right in not wanting to add some load to it for everyone, regardless of whether they want this feature or not. You and Kyle have me convinced here. And thanks again! Best, Gustavo.
Re: [PATCH] Add mode for automatically unhiding emphasis markers in the current region
Hi Nicolas, On Wed, 24 Jun 2020 at 12:46, Nicolas Goaziou wrote: Hello, Gustavo Barros writes: You have a good point here. When I made the suggestion I was naively thinking the featured could be plugged/hooked somewhere in Org, when fontification is done. But that's not really true, as the feature requires being run every time the point moves too. So, as far as I can tell, it seems using post-command-hook is unavoidable, and if so, you are right in not wanting to add some load to it for everyone, regardless of whether they want this feature or not. You and Kyle have me convinced here. Sorry for being late to the party, but, IMO, this doesn't sound like a right approach to the problem of invisible emphasis markers. A user choosing to hide emphasis markers should not need to—or even be given the opportunity to—display them in order to edit them efficiently. I do agree with what you said, as you have stated it: It'd be good if the user of `org-hide-emphasis-markers' didn't need to display the invisible character to edit them efficiently. And it is true that I argued in favor of this proposed patch giving the related editing inconveniences as a main point. But the feature is the equivalent of `prettify-symbols-unprettify-at-point' for `org-hide-emphasis-markers' and it does have an appeal in itself, for the visual cue it offers, besides the editing improvement, which is a byproduct. I like `org-hide-emphasis-markers', but if I was not "given the opportunity to display them" or if I could not edit them directly even if invisible, as a word processor does, I would probably not consider ever hiding them in the first place. I think we should upgrade `org-emphasize' command instead, so it handles both marker visibility states in a DWIM, or in a word processor, fashion. Indeed, since emphasis markers of a given type cannot be nested in Org, the WIM part is usually easy to guess, according to the context, i.e., the syntax at point, and the region. I have some draft lying somewhere in that direction. WDYT? I think that it would be great independently of the proposed patch. Indeed, that would be very useful including for users which set `org-hide-emphasis-markers' to nil. On the other hand, even with a more capable dwim `org-empasize', I'm pretty sure many users will still add emphasis markers by directly typing them, even if occasionally, or they will delete them inadvertently if invisible, in which case, the proposed patch remains very useful for this reason too. If I may, `TeX-font' in AUCTeX would be my dream `org-emphasize'. Two things it does that `org-emphasize' doesn't (as far as I know of): i) when there is no region selected, and point is within a font macro, it operates on the imediate enclosing font macro, not requiring region selection, so that we can change the font macro by calling `TeX-font' with a prefix, or remove the font macro with "C-c C-f C-d"; ii) `LaTeX-font-list' is customizable, allowing for better key bindings; it's easier to type "b" than "*", "s" than "+" etc., anyway, it gives choice. Again, just an user here, just offering a data point. (And I was quoted ;-). Best, Gustavo.
Re: [PATCH] ox: Prevent dispatcher from starting in scrolled window
Hi Kyle, On Fri, 26 Jun 2020 at 22:03, Kyle Meyer wrote: I've managed to trigger it now. Your picture gave me the hint that maybe my "making my frame height very small" wasn't the thing to do. Plus I should have realized that the default-frame-alist in your minimal configuration probably isn't going to matter on my end because I use a tiling window manager. So here's what I could trigger it: (setq scroll-margin 1) ; or anything > 0 (setq display-buffer-base-action '(display-buffer-at-bottom)) For reasons I don't really understand, if I make my frame height small (say half my computer screen) the issue goes away. Anyway, I'm able to resolve the issues I see with this patch. Can you confirm that it fixes things on your end? Nice that you could find a way to trigger it too. Indeed, that was a tricky one to pin down. And I'm glad to confirm the patch fixes things on my end for the recipe provided in the report. Same as you, I don't fully understand the interactions which trigger the issue, so I can only claim that "I can no longer reproduce". Which is great, of course. But, as far as I understand, the patch makes sense to me. Thank you very much for sticking with me and finding a fix. Best, Gustavo.
Re: [FR] Add check for attachments in org-lint
Hi Nicolas, On Sun, 28 Jun 2020 at 14:26, Nicolas Goaziou wrote: This is done in master. Thank you very much. Regards, Gustavo.
Re: [PATCH] Add mode for automatically unhiding emphasis markers in the current region
Hi Nicolas,
Hi All,
On Sun, 05 Jul 2020 at 07:50, Nicolas Goaziou
wrote:
The problem is not your implementation, really. It's just that I don't
think it should be the _built-in_ way to solve emphasis
management. IOW,
we shouldn't need to activate a minor mode to make that management
tolerable in the first place.
However, I agree that it makes senses as an extension, in the same
vein
as `org-fragtog` for LaTeX fragments.
[...]
But, really, I think an option like `org-hide-emphasis-markers' is
a one-off toggle. Having to, in a way, switch regularly between two
values is sub-optimal.
I don't think I have anything to add to the previous discussion on this
matter, and I know you took it into consideration. Also, I'm well aware
that sometimes a user interested in a feature lacks a more general
perspective a maintainer has. So I take your position here stems from
one such general design choices, and I understand and respect it.
Here it is.
The main command is `org-emphasis'. It emphasizes the minimal possible
area around point, or region. If there's already an emphasis object of
the desired type around point or region, it extends it forward
instead.
With a prefix argument, it removes the emphasis.
Interactively, the command asks for the type of emphasis to use, but
I suggest to use dedicated commands instead. Thus, I added a
key-binding
for each of the six emphasis types. For example, for bold, use
`M-o *'or`M-o M-*'
There are equivalent commands for underline (`M-o _` or `M-o M-_'),
and
so on.
Note there, even though I polished it, there are probably some
glitches
left, but it works well enough to give an idea. Tests are missing,
too.
Please evaluate the following code to try it.
This is really, really nice. Certainly a major improvement in the way
`org-emphasize' works. I specially like you've chosen to make it act on
the element around point, that you added the possibility of increasing
this scope with repetition, and that you made the functions commands we
can bind.
If I may, I'd like to add comments and report tests, for your
consideration, in the spirit of trying to help you polish the approach.
One low hanging fruit, which you probably have already considered, is to
use a transient keymap to ease the repetition of the emphasis commands.
So that we could type `M-o * * * *' to emphasize four words, instead of
`M-o * M-o * M-o * M-o *'. Even better if in this keymap we could call
a command, bound e.g. to `-', to go back one step in case we have gone
too far in the repetition. This is interesting in itself, but specially
so given a number of the markers are shift-keys, which means the first
and the second part of the bindings use different modifiers, making the
repetition quite "athletic" (I suppose we could use "M-O", but still).
A second thing is regarding the removal of the markers. I think there
is space to simplify this further and make it even more convenient. As
things are, we have six different bindings to remove an emphasis marker
around point. Of course, when adding emphasis, we have to specify which
one we want, but when removing it, the markers are already there and we
know what is the emphasis around point, and can go with a single
command, e.g. `org-remove-emphasis', and a single binding, e.g. `M-o
r/M-r', without the cognitive load of having to identify visually which
is the marker, to call the correct command to remove it. The only case
not covered by this would be if we have nested emphasis of different
types and want to remove the outer one. I'd say this is rare enough to
leave uncovered in exchange for the simplification of 6 to 1 commands
for emphasis removal. True, this seventh command could just be added,
and leave the current six as they are, but I do have a suggestion for
another use of the prefix, which see. (Perhaps an argument similar to
the one being made here for removal could be made for extending
emphasis, but I'm not sure if with the same relevance).
Still regarding emphasis removal, I see two things one might want when
"removing" emphasis: one is to remove the whole emphasis around point,
the other is to remove part of an existing emphasized region, doing the
analogous of what your six emphasis commands do, but removing emphasis
one word at a time. If this distinction is deemed useful and worth
implementing, how about `org-remove-emphasis' with no prefix doing the
first, and with prefix doing the second?
A third thing I think is worth considering is the direction of
extension, given that `org-emphasize' also works by extending an
existing emphasized region. Two things here: should one be able to
control the direction the expansion occurs? what should be the
preferred (or only) expansion direction? I'd say the first one would be
really nice, and I'd suggest using the prefix to the six emphasis
commands to achieve it ("prefix changes the default direction")
Re: [PATCH] Add mode for automatically unhiding emphasis markers in the current region
Hi Nicolas, Hi All, On Sun, 05 Jul 2020 at 17:49, Gustavo Barros wrote: A fourth issue is point placement after the emphasis is added. `org-emphasis' takes a stance here and places point within the emphasis. I do agree with this option, but it is still true that sometimes, one might want or need otherwise. This, of course, gets more interesting when `org-hide-emphasis-markers' is t. And I actually think this issue is still more general. One thing is to "add emphasis markers to existing text", another is "adding text around existing emphasis markers". The first one is superbly dealt with by this implementation of `org-emphasize', the second one, as far as I can see, not equally so. After sleeping over this problem, I think I had an interesting idea to allow some control of point position in an intuitive fashion. I thus submit it to the list. Consider the following suggested behavior for `org-emphasize': i) anything in the direction opposite to the emphasis expansion direction is ignored, regardless of whether point is at a word boundary or not on that side (this corresponds to the current implementation, but goes against my initial suggestion of considering the right boundary of a word as "part" of the previous word); ii) point never moves (and this is different from the current implementation). Simple, clear cut rules. And they would make it possible to control whether point is placed within or outside the emphasis markers by manipulating point position wrt whitespace /before/ calling `org-emphasize'. So, taking the current forward expansion direction, if we wanted to emphasize the following word, we would have: i) if the point is placed before whitespace preceding the following word, point will be left where is is, which will result to be outside the emphasis markers; ii) if point is within a word (which includes the left boundary) point will end inside the markers; it also hasn't moved, just the marker was applied before it. Some examples, again assuming forward expansion: #+begin_src org foo|·bar foo·|bar foo·b|ar foo·bar| #+end_src for `M-o *', the results would be: #+begin_src org foo|·*bar* foo·*|bar* foo·*b|ar* foo·bar| #+end_src Assuming a backwards expansion direction was to exist (and the more I think of this, the more I lean towards preferring this as the default), we could do the following. I'm typing something: #+begin_src org foo·bar| #+end_src But then I decide to emphasize "bar", and only "bar". I could go with `SPC M-o *' to get: #+begin_src org foo·*bar*·| #+end_src And be able to just keep on typing: #+begin_src org foo·*bar*·baz| #+end_src I wouldn't say this goes all the way to solve the "adding text around existing emphasis markers" problem. But, as far as my scrutiny went, I do think it goes quite a stretch. And it is quite simple, which should make for "intuitive" hopefully. WDYT? Best, Gustavo.
Bug: Org line commands and visual-line mode bindings [9.3.7 (9.3.7-15-gc9abb4-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)]
Hi All,
The Org line commands -- `org-beginning-of-line', `org-end-of-line', and
`org-kill-line' -- all take due care for the presence of
`visual-line-mode' to do the right thing if it is turned on. However,
when `visual-line-mode' is indeed on, the bindings on
`visual-line-mode-map' shadow Org's bindings, so that we actually get
`beginning-of-visual-line', `end-of-visual-line', and `kill-visual-line'
for the usual keybindings, instead of the much nicer specialized Org
commands.
To check this, start with =emacs -Q=, set load-path to get the proper
version of Org (as your case may be):
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20200727")
#+end_src
Then visit an Org file, and enable "M-x visual-line-mode", and check the
bindings with "C-h k C-a", "C-h k C-e", and "C-h k C-k" to get:
#+begin_example
beginning-of-visual-line
end-of-visual-line
kill-visual-line
#+end_example
I'm not sure this is a "bug", strictly speaking, or if it is correct
unfortunate behavior. Anyway, is there something that could be done
from Org's side?
Best,
Gustavo.
Emacs : GNU Emacs 27.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.18, cairo version 1.16.0)
of 2020-06-29
Package: Org mode version 9.3.7 (9.3.7-15-gc9abb4-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite"
. sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-open-link
:export org-attach-export-link :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow eww
:store org-eww-store-link)
("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 :export org-irc-export)
("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")
("shell" :follow org-link--open-shell)
("news" :follow #[257 "\301\300\302Q!\207"
["news" browse-url ":"] 5 "\n\n(fn URL)"])
("mailto" :follow #[257 "\301\300\302Q!\207"
["mailto" browse-url ":"] 5 "\n\n(fn URL)"])
("https" :follow #[257 "\301\300\302Q!\207"
["https" browse-url ":"] 5 "\n\n(fn URL)"])
("http" :follow #[257 "\301\300\302Q!\207"
["http" browse-url ":"] 5 "\n\n(fn URL)"])
("ftp" :follow #[257 "\301\300\302Q!\207" ["ftp"
browse-url ":"] 5 "\n\n(fn URL)"])
("help" :follow org-link--open-help) ("file"
:complete org-link-complete-file)
("elisp" :follow org-link--open-elisp) ("doi"
:follow o
Re: Bug: Org line commands and visual-line mode bindings [9.3.7 (9.3.7-15-gc9abb4-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)]
Hi Marco, thank you for your answer. On Tue, 28 Jul 2020 at 17:34, Marco Wahl wrote: >> I'm not sure this is a "bug", strictly speaking, or if it is correct >> unfortunate behavior. Anyway, is there something that could be done >> from Org's side? > > Also not sure if this is a bug. But you can configure the desired > behavior by hooking in at activation of visual line mode AFAICS. > > You could e.g. add > > > (add-hook 'visual-line-mode-hook > (lambda () (when (derived-mode-p 'org-mode) >(local-set-key (kbd "C-a") #'org-beginning-of-line) >(local-set-key (kbd "C-e") #'org-end-of-line) >(local-set-key (kbd "C-k") #'org-kill-line > > to your config. > This is a good workaround. I've been doing something else, which is simply to bind the keys directly (that is not using `[remap ...]') in `org-mode-map'. This way the remappings done by `visual-line-mode' find nothing to remap, and things work as expected. However, while I'm safe with this approach in my local settings, because I know I haven't changed the default bindings for these commands, I don't know how good this would be as a general solution for Org. Anyway, it would be nice if this worked out-of-the-box, this can be baffling behavior, especially for newer users. But I'm not sure what to suggest here. Best, Gustavo.
Re: Repeating task hourly
Hi Kyle, Hi Kevin, On Tue, 28 Jul 2020 at 22:29, Kyle Meyer wrote: > Kevin Liu writes: > >>> Is there any way to do this or are the docs out of date? >> >> I made a few quick changes to org-habit and it works prima facie. Will >> continue testing for a bit. > > The hourly repeater came in ec921a2a6 (Support hourly repeat cookies, > 2012-04-20), well after the "less than 1d" guard was added in > org-habit.el. So, perhaps it'd make sense to update org-habit.el to > support hour repeaters, particularly if habit users say there's a need. > > As a non-habit user reading through (info "(org)Tracking your habits"), > I'm a bit worried that your patch only works superficially. That node > talks about "graphs that show every day" and "colors for each day"; does > that sort of logic break down with your proposed changes? As far as I know, indeed, org-habit provides essentially a consistency graph, which shows in the agenda the regularity of the task for a certain period, being the day the least (and only) unit of the graph (1 day = 1 character). I don't think the proposed change would break anything (just a cursory look though) but, unless I'm missing something Kevin has in mind, I don't see how it would be of use, because an hourly repeater cannot really be properly conveyed in the consistency graph of org-habit. So, as far as I understand, there is nothing wrong either in the documentation or in org-habits. It is just that habits tasks are a particular kind of repeating task, and tasks that repeat in frequencies smaller than a day cannot be properly represented in the consistency graphs, though they work as documented in other cases. Kevin, how do you see an hourly repeater would work with org-habit's consistency graph? Or, more generally, what would be the purpose of an hourly repeated habit task? Best, Gustavo.
Re: Repeating task hourly
Hi Kevin, On Wed, 29 Jul 2020 at 11:46, Kevin Liu wrote: On 29 July 2020 04:06, Gustavo Barros wrote: Kevin, how do you see an hourly repeater would work with org-habit's consistency graph? Or, more generally, what would be the purpose of an hourly repeated habit task? An example of an hourly repeated habit task is exercise. You might want to stretch in the morning and then again at night. You raise a good point that the consistency graph isn't as useful as it could be. All it shows now is that the habit was done at least once on that day. I think this is still a little useful, if only to visually separate a habit from other tasks on the agenda. It could be made more useful by replacing the * with a count of the number of times the task was done that day, but that would be another patch. I get why a task (exercising, taking medicine, etc) is usefully repeated a number of times a day, of course. But a regular repeating task is perfectly fine for this. Furthermore, considering the only thing org-habit does is to provide the consistency graph for the task, and if this does not really work for hourly repeaters, I still don't see the gain here. And there would be other ways, in my view more appropriate ones, to separate some tasks, if that's desired. IMHO, what you are proposing is just eliminating an error message which was deliberately placed there by the author, considering what org-habit is designed to do. But this is just an user speaking, take this as a data point. Anyway, you have replied just for me, off-list. I presume you meant otherwise, and your point is relevant in the list, so I reincluded the CCs to it. Best, Gustavo.
Re: Repeating task hourly
On Wed, 29 Jul 2020 at 12:41, Kevin Liu wrote: The graph works for hourly repeaters in exactly the same way as it works in all other cases. It illustrates whether the task was done on a given day. But what will happen is that the task will be both "done" and "due" on the same day. Which face shall org-habit use? Which symbol? The task will be shown in the agenda, all right, whether the consistency graph is meaningful is another matter. As Kyle mentioned, I don't think authorial intent counts for a whole lot here since the code was last touched in 2009, years before hourly repeaters were added. I'm not so sure. Take a look at commit be2806d281 "Fixes to the consistency graph in org-habit", by John Wiegley, in 2009-10-22. There the following error check was then introduced: (unless (> sr-days 0) (error "Habit's scheduled repeat period is less than 1d")) Considering `sr-days' was then let-bound with: (scheduled-repeat (org-get-repeat "SCHEDULED")) (sr-days (org-habit-duration-to-days scheduled-repeat)) And that `org-habit-duration-to-days' performs its conversion of the repeaters to days with `floor', I'd say it is pretty deliberate. If this was before the introduction of hourly repeaters, I'd take this to be even more meaningful, not less. Best, Gustavo.
Bug: Org sentence commands and emphasis markers [9.3 (release_9.3 @ /usr/local/share/emacs/27.1/lisp/org/)]
Hi All, There is some adverse interaction between Emacs sentence related commands and Org emphasis markers, when whole sentences are emphasized. This report describe some cases of this interaction, for your consideration. But, as a general rule, if a whole sentence is emphasized, sentence movement and killing, and paragraph filling won't work as expected. Let's take the case of a small paragraph, with sentences ended with double spaces, and with `sentence-end-double-space' having its default value of t. And let's have the whole second sentence emphasized with bold markers. "!" represents point position. #+begin_src org Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. *At vero eos et accusam et justo duo dolores et ea rebum.* Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. #+end_src 1 - Sentence movement If we call on this paragraph the regular Org sentence movement commands `org-backward-sentence' and `org-forward-sentence', the second sentence will no longer be recognized as such. Starting from the beginning of the paragraph and calling `org-forward-sentence' will result in: #+begin_src org !Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. *At vero eos et accusam et justo duo dolores et ea rebum.* Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. #+end_src #+begin_src org Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.! *At vero eos et accusam et justo duo dolores et ea rebum.* Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. #+end_src #+begin_src org Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. *At vero eos et accusam et justo duo dolores et ea rebum.* Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.! Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. #+end_src That is, the end of the second (emphasized) sentence was missed. A similar problem occurs when going backwards with `org-backward-sentence'. 2 - Sentence killing With point at the end of the first sentence, as in; #+begin_src org Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.! *At vero eos et accusam et justo duo dolores et ea rebum.* Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. #+end_src If we call `kill-sentence' we will get: #+begin_src org Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.! Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. #+end_src That is, the second and third sentences were killed. A similar problem occurs with point somewhere on the third sentence and `backward
[Feature Request] More flexibility in org-speed-commands customization
Hi All, Org's speed keys are a very interesting feature to which I've long been attracted to. And indeed, I've flirted with it a number of times in the past. But every time I do so, I end up stepping back, because I get weary of fat fingering my documents. The whole set of speed keys is more powerful than what I would wish. I'd love to have speed keys for navigation and visibility, but I would also gladly refrain from these "too handy" editing keys. As things stand, the speed keys are defined by combining `org-speed-commands-default', a defconst, and `org-speed-commands-user', a defcustom. But the former already contains a large set of speed keys, including some quite powerful editing ones. And it is thus hard to remove these keys. Of course, it is possible. We could shadow the same key in `org-speed-commands-user' to do nothing. Or, though a defconst, `org-speed-commands-default' can be redefined after loading Org. The first is clumsy, and renders the `org-speed-command-help' buffer quite confusing. The second feels wrong (because it is). I don't know if there is a strong reason to hard-code the set of keys in `org-speed-commands-default'. But, if there isn't, could you consider (somehow) exposing the whole set of `org-speed-commands' to user customization? Best, Gustavo.
Re: [Feature Request] More flexibility in org-speed-commands customization
Hi Marco, On Mon, 17 Aug 2020 at 06:40, Marco Wahl wrote: I don't know if there is a strong reason to hard-code the set of keys in `org-speed-commands-default'. But, if there isn't, could you consider (somehow) exposing the whole set of `org-speed-commands' to user customization? This sounds like a good idea to me. Do you already have a respective patch? thank you for considering this suggestion. But, no, I haven't tried to prepare a patch, because even if I got it working, I wouldn't be able to contribute it. Unfortunately, I cannot sign the papers given my current employment contract's terms. So, for the foreseeable future, I'm stuck with this situation, and can only contribute with ideas, reports and such. Best regards, Gustavo.
Re: Bug: Org line commands and visual-line mode bindings [9.3.7 (9.3.7-15-gc9abb4-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)]
Hi Bastien, On Fri, 04 Sep 2020 at 17:20, Bastien wrote: > Hi Marco, > > Marco Wahl writes: > >> (add-hook 'visual-line-mode-hook >> (lambda () (when (derived-mode-p 'org-mode) >>(local-set-key (kbd "C-a") #'org-beginning-of-line) >>(local-set-key (kbd "C-e") #'org-end-of-line) >>(local-set-key (kbd "C-k") #'org-kill-line > > Nice -- I've added this to https://orgmode.org/worg/org-hacks.html I do think my other workaround is worth pondering to be included, so that this would work out-of-the-box. Do you see any particular drawbacks of setting these bindings directly (that is, not by remapping) in `org-mode-map'? Best, Gustavo.
Re: Bug: Org line commands and visual-line mode bindings [9.3.7 (9.3.7-15-gc9abb4-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200727/)]
Hi Bastien, On Fri, 04 Sep 2020 at 14:37, Bastien wrote: You mean by adding something like (org-defkey org-mode-map (kbd "C-a") #'org-beginning-of-line) in org-keys.el? I'm pretty sure such "hard" remapping breaks an Emacs convention--I'll ask emacs-devel, because that would indeed fix the problem you are reporting. Thanks for insisting, Yes, that is what I mean. I understand this kind of hard remapping would not be conventional, and is not the best solution. But, in this case, it is not Org, but visual-line-mode which is going a bit too far. Org takes care of the presence of visual-line-mode, but the opposite does not occur. Anyway, since you are asking emacs-devel, perhaps ask too if it would be possible for a major mode to set, something like `beginning-of-line-function' etc, which visual-line-mode, or even the original functions it substitutes, could then honor, as is done with `fill-paragraph-function', for example. Something of the sort might be the proper solution. "Hard" rebinding is what Org can currently do on its side, as far as I can tell. Best, Gustavo.
Re: [Feature Request] More flexibility in org-speed-commands customization
Hi Bastien, On Fri, 04 Sep 2020 at 14:45, Bastien wrote: Hi Gustavo, I don't know if there is a strong reason to hard-code the set of keys in `org-speed-commands-default'. But, if there isn't, could you consider (somehow) exposing the whole set of `org-speed-commands' to user customization? Yes, I think the two variables should be merged into a single `org-speed-commands' option. Unless someone strongly objects, I will do after Org 9.4. Thanks for the suggestion, Thank you for considering this suggestion. I'm sure many people here have some fat-fingered "friend" who will rejoice to use the speed-keys with more tranquility. ;-) Best, Gustavo.
Re: Bug: Repeating tasks no longer appearing on future dates in the agenda [9.3.6 (9.3.6-17-g389288-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)]
Hi Bastien, On Thu, 10 Sep 2020 at 02:34, Bastien wrote: Hi Gustavo, Gustavo Barros writes: As of recently, repeating tasks are no longer showing up in the agenda for future dates. Below a minimal example of the issue: Just confirming this issue, to make sure we don't forget it. Thank you for keeping track of this. But this issue is currently not affecting us any longer. If I recall correctly, the problem had emerged after a fix to another issue. Kyle was able to identify the commit, and the discussion then converged to revert that commit, thus restoring the behavior which prompted this report of mine, until a fix for the other issue which did not cause this could be found. Some of the relevant messages are: - Kyle's message stating the commit was reverted, with the corresponding commit numbers: https://orgmode.org/list/87o8rx1cmf@kyleam.com/ - The issue whose fix caused this regression is mentioned at: https://orgmode.org/list/87o8tim83q@kyleam.com/ I think (not sure) that that issue is still pending. Best, Gustavo.
Re: "text mode" org mode
Hi Emanuel, On Tue, 15 Sep 2020 at 14:27, Emanuel Berg via "General discussions about Org-mode." wrote: > Can I tell Org mode to don't change editing back and > forth, also don't collapse items in and out, i.e. > virtually text mode, only I still want the font lock > and to be able to use the mode to set keys, the > functions to compile into a PDF, and so forth. > > TIA That's probably not something most Org users would do, but I think you'd get close to what you want with: (add-hook 'org-mode-hook 'visible-mode) HTH. Best, Gustavo.
Bug: Double trailing slash for default candidate in org-refile-get-target [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hi All,
some time ago, I've reported an issue regarding duplicity of the default
candidate in `org-refile'
(https://orgmode.org/list/87lftw1k2n@gmail.com/). The problem was
that, when using `org-refile-use-outline-path' an "extra" slash was
appended at the end of every path, but candidates were stored in
`org-refile-history' without that extra slash. Bastien took care of
that and indeed changed things so as to pass the elements to
`org-refile-history' with the trailing slash as appropriate.
At the time, I reported a difference of behavior between
`completing-read-default' and `ivy-completing-read' after the mentioned
commit by Bastien. But the issue did not appear for Bastien, which does
not use Ivy, and I also was not able to diagnose the problem properly.
I felt I didn't have enough to offer as to insist, so I resorted to an
old hack of mine. But the new release this week (thank you very much!,
btw) has bitten me again on this, so I went back to some digging, and
hopefully I can do a better job this time in diagnosing the problem and
suggesting a fix.
An ECM to reproduce the issue as it currently stands is:
- Start 'emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20200921")
(add-to-list 'load-path "~/.emacs.d/elpa/ivy-20200826.955")
;; Those are the latest Org weekly build (Org 9.4) and the current up
to date
;; Ivy at Melpa
(setq org-refile-targets '(("~/org/test.org" :maxlevel . 2)))
(setq org-refile-use-outline-path 'file)
(setq org-outline-path-complete-in-steps nil)
(require 'ivy)
(ivy-mode)
;; Bear with me, the problem is not with Ivy, I'll demonstrate that.
#+end_src
- Open file "~/org/test.org", with contents:
#+begin_src org
,* Top heading 1
,* Top heading 2
,** Entry 1
,** Entry 2
#+end_src
- Go to heading "Entry 1", refile it to "Top heading 1"
- Go to heading "Entry 2", and call `org-refile'
- Observe the available candidates, and notice "test.org/Top heading 1/"
is there twice, once as the default candidate, with a *double*
trailing slash, and also on the paths list, with a single trailing
slash.
I've tried to pin down what is going on here and my understanding is
that Bastien's fix on that previous thread did indeed correct the
problem of the missing trailing slash in `org-refile-history' and this
indeed corresponds correctly to the state of the completion "collection"
(the let bound `tbl' variable in `org-refile-get-location'), as it
should. But there remained a couple of instances in
`org-refile-get-location' which added the trailing slash considering
`org-refile-history' didn't have them, so that when this is done, we get
a double trailing slash.
The two instances are: 1) when the completion function is actually
called:
#+begin_src emacs-lisp
(setq answ (funcall cfunc prompt tbl nil (not new-nodes)
nil 'org-refile-history
(or cdef (concat (car org-refile-history)
extra
#+end_src
2) And three lines bellow, on the let binding:
#+begin_src emacs-lisp
(let* ((last-refile-loc (car org-refile-history))
(last-refile-loc-path (concat last-refile-loc extra)))
...)
#+end_src
In both instances, we are getting the `car' of `org-refile-history'
which now already has `extra' (that is, the trailing slash) and adding
it again.
My suggested fix is to remove these `extra's in duplicity, they are
remnants of when `org-refile-history' didn't have them already. That
is:
#+begin_src emacs-lisp
(setq answ (funcall cfunc prompt tbl nil (not new-nodes)
nil 'org-refile-history
(or cdef (car org-refile-history
#+end_src
And:
#+begin_src emacs-lisp
(let* ((last-refile-loc (car org-refile-history))
(last-refile-loc-path last-refile-loc))
...)
#+end_src
Of course, the second opens some opportunity to simplify the code that
follows considering `last-refile-loc-path' and `last-refile-loc' are now
identical.
Why I think this is the problem and the correct way to fix it:
1) If you add inspection points at the appropriate locations for the
sexps =(concat (car org-refile-history) extra)= and =(concat
last-refile-loc extra)= you will find the double trailing slash there,
and it shouldn't be there.
2) The visual manifestation of this double trailing slash in the default
candidate with `ivy-mode' is there therefore independently of
`ivy-mode`. Indeed, `ivy-mode' basically sets
`completing-read-function' to `ivy-completing-read', which in turn calls
its main API function `ivy-read'. `ivy-completing-read' just passes
along the `def' argument without manipulating it. As far as I can see,
`ivy-read' also does not change it before calling
`read-from-minibuffer'.
Why `completing-read-default' does not show this second trailing slash
of the `def' argument it received is another matter. But it's there...
3) I've tested this sugge
Bug: Logbook drawer and org-adapt-indentation with value headline-data [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hi All,
the new release brought the interesting value `headline-data' to the
option `org-adapt-indentation'. However it introduces some issues
regarding the indentation of log entries in the `LOGBOOK' drawer, which
I describe below.
An ECM to reproduce the issue is:
- Start 'emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20200921")
;; This is the latest Org weekly build (Org 9.4)
(setq org-adapt-indentation 'headline-data)
(setq org-log-into-drawer t)
(setq org-todo-keywords '((sequence "TODO(t)" "DONE(d@)")))
#+end_src
- Open file "~/org/test.org", with contents:
#+begin_src org
,** Foo
#+end_src
- Change the todo state of "Foo" to "DONE" and add a corresponding note
with "C-c C-t d Baz C-c C-c".
- After expanding the `LOGBOOK' drawer we find:
#+begin_src org
,** DONE Foo
:LOGBOOK:
- State "DONE" from [2020-09-21 Mon 16:19] \\
Baz
:END:
#+end_src
In which we find that the drawer itself is honoring the setting in
`org-adapt-indentation' whereas the content of the drawer is not. And
it is expected that it did.
- After that, move point to the headline and demote it with ""
and examine the buffer again to find:
#+begin_src org
,*** DONE Foo
:LOGBOOK:
- State "DONE" from [2020-09-21 Mon 16:19] \\
Baz
:END:
#+end_src
We now see the demotion did bring the content of `LOGBOOK' to align
with the headline, but in doing so, broke the plain list structure of
the note, removing the indent of "Baz", which is also not expected.
Best regards,
Gustavo.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-08-11
Package: Org mode version 9.4 (9.4-7-g3eccc5-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-adapt-indentation 'headline-data
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite"
. sql))
org-occur-hook '(org-first-headline-recenter)
org-log-into-drawer t
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-todo-keywords '((sequence "TODO(t)" "DONE(d@)"))
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("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 :export org-irc-export)
("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")
("shell" :follo
Bug: org-agenda-later scrolls buffer unnecessarily [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hi All,
since some time I've been facing a small annoyance in the agenda, as
when I move point in my weekly agenda to a day which is not the first
one display and then hit "f" (`org-agenda-later') the agenda buffer is
scrolled up, hiding the top of the buffer, even though there is no lack
of space in the frame to fit the whole window.
This is not something that started after the most recent release, I had
been observing this previously. But I thought I might have missed some
fix, and waited to see if the issue was still up after the release came.
And it is. I'd say since a couple of weeks, but it is easy to be
tricked by memory in these cases, and it might be more.
I did some bisecting to be able to come up with a proper ECM, and it
turned out to boil down to the interaction between my
`scroll-conservatively' setting, and a combination in
`org-agenda-custom-commands' of two agendas with different time spans
(one weekly, the other daily).
An ECM to reproduce the issue is:
- Start 'emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20200921")
;; Latest Org weekly build (Org 9.4)
(setq scroll-conservatively 1)
;; Not essential to reproduce, but included just to emphasize there is
no lack
;; of space to trigger the scrolling.
(setq org-agenda-window-setup 'only-window)
(setq org-agenda-custom-commands
'(("w" "Agenda"
((agenda ""
((org-agenda-overriding-header "Agenda (Week)")))
(agenda ""
((org-agenda-overriding-header "Habits (Day)")
(org-agenda-span 'day)))
#+end_src
Now, open this agenda with "M-x org-agenda RET w", move point to a day
further down the first agenda block (e.g. today is Monday, go to
Saturday). Call `org-agenda-later' ("f") and observe the buffer was
scrolled up so that the day of the week you were before is now made the
first line of the buffer, and the previous ones are hidden.
As these kinds of scrolling settings interactions might be somewhat
tricky to reproduce, I attach a couple of screenshots of the resulting
situation before and after calling `org-agenda-later' as described in
the ECM.
Best regards,
Gustavo.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-08-11
Package: Org mode version 9.4 (9.4-7-g3eccc5-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all append
local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php)
("C" . c) ("C++" . c++) ("asymptote" . asy)
("bash" . sh) ("beamer" . latex) ("calc"
. fundamental)
("cpp" . c++) ("ditaa" . artist) ("dot"
. fundamental)
("elisp" . emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh)
("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-agenda-window-setup 'only-window
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open)
("eww" :follow org-eww-open :store
org-eww-store-link)
("rmail" :follow org-rmail-open :store
Re: Bug: Logbook drawer and org-adapt-indentation with value headline-data [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hi Nick, On Mon, 21 Sep 2020 at 19:06, "Nicholas Savage" wrote: > I tried reproducing this, but I am having difficulties. "Baz" and the " - > State" stayed correctly aligned as I would have expected them, and not as you > have shown them. > > I am on emacs 28.0.50 though so maybe that has made the difference, with org > compiled from master as of a day or two ago. > > Nick > thank you for looking into it. You mentioned that you could not reproduce the second issue, but could you reproduce the first? (That is, the note being inserted at the margin rather than indented with the drawer). Anyway, indeed the Emacs and Org versions might be making a difference. Let's see if anyone else can reproduce. Gustavo.
Re: Bug: Double trailing slash for default candidate in org-refile-get-target [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]
Hi stardiviner, On Wed, 23 Sep 2020 at 11:17, stardiviner wrote: I have same issue when using Ivy. But can't reproduce this by disabled ivy-mode. And only happened when I refiled once, then the target will has two slash like this: #+begin_example Tasks/kk// (file.org) Tasks/hello/ (file.org) #+end_example Thank you for checking this and for confirming you also observe this behavior with Ivy. Regarding when ivy-mode is off, as I argued in the original report, the problem is indeed *not visible* when using `completing-read-default', the double trailing slash is nevertheless there if you inspect the value being passed as default value to the completing-read-function. The tests included with ivy-mode turned off were meant to emphasize things are expected to work with the suggested fix also in this case, in other words, that this is not "just a fix for ivy-mode", which is not the problem here. Best, Gustavo.
Re: A small idea to simplify (further) time input in the date/time prompt
Hi All, Hi Bastien, if I may kindly bump this patch for review. Best regards, Gustavo. On Wed, 03 Jun 2020 at 10:14, Gustavo Barros wrote: Hi Bastien, On Tue, Jun 02 2020, Bastien wrote: Hi Gustavo, I like this idea, thanks for proposing it. We are in feature freeze for core features, so we have time to work on this for Org 9.5. [...] Would you agree? Would you like to work on this change? Well, I did give it a shot. And, as it turns out, this might be manageable within my limitations. A preliminary patch is attached, for comments. I took here the stance of following the same treatment which is given to am/pm times, and of using the letter "h" as sole main identifier. In particular, standard "HH:MM" times take precedence, as is the case for am/pm times. And duration specification with numbers only are presumed to be hours, which was already the case, the patch does not introduce any changes here. The input will match for this format for "number h 2-digit-number", where either the hour or the minutes, but not both, can be omitted and, if so, is presumed to be zero. 24h format is also presumed. With it, some example inputs/outputs for time in the date/time prompt: | input | output | |---+-| | 9h| 09:00 | | h45 | 00:45 | | 21h | 21:00 | | 9h-10h| 09:00-10:00 | | 9h--10h30 | 09:00-10:30 | | 18h30+h30 | 18:30-19:00 | | 18h30+1 | 18:30-19:30 | | 18h30+1h | 18:30-19:30 | And some sanity checks: | input | output | Observation | |---+--+---| | 10:00 9h | 10:00| by design, as for am/pm times | | 10am 9h | 10:00| expected from coming after am/pm handling | | 10:00-11h | 10:00-11:00 | | | 10h-11:00 | no match | am/pm also does not match here | | +9h | no match | | | -9h | no match | | | h | no match | | | 10h+h | no match | | | h5| no match | | | 10h70 | no match | | | 29h | 2020-06-04 Thu 05:00 | makes sense, same as for 29:00 | | 30h | no match | as per the regexp | WDYT? Best, Gustavo.
Bug: org-insert-heading-respect-content before first heading [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]
Hi All,
I just found a misbehaving of `org-insert-heading-respect-content': when
it's called before the first heading in the buffer, it breaks the
structure of that fist heading by inserting a new heading on the line
the previous heading existed.
An ECM to reproduce the issue is:
- Start 'emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20201019")
#+end_src
- Visit file =test.org= with contents:
#+begin_src org
,#+title: Title
,* Foo
#+end_src
- Place point between the title and the "Foo" heading, and call
`org-insert-heading-respect-content' with "C-RET".
- The result is:
#+begin_src org
,#+title: Title
,* !* Foo
#+end_src
where "!" represents point position.
Which clearly does not "respect content" of the following heading.
Best regards,
Gustavo.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-08-11
Package: Org mode version 9.4 (9.4-19-gb1de0c-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite"
. sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("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 :export org-irc-export)
("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")
("shell" :follow org-link--open-shell)
("news" :follow
#[514 "\301\300\302Q\"\207" ["news" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("mailto" :follow
#[514 "\301\300\302Q\"\207" ["mailto" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("https" :follow
#[514 "\301\300\302Q\"\207" ["https" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("http" :follow
#[514 "\301\300\302Q\"\207" ["http" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("ftp" :follow
#[514 "\301\300\302Q\"\207" ["ftp" browse-url
":"] 6 "\n\n(fn URL ARG)"])
("help" :follow org-link--open-help) ("file"
:complete org-link-complete-file)
("elisp" :follow org-link--open-elisp) ("doi"
:f
Bug: fill-paragraph in Org buffer [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]
Hi All,
Calling `fill-paragraph' in an Org buffer may leak paragraph boundaries,
and even heading boundaries, and break document structure.
I'm aware, of course, of `org-fill-paragraph'. Indeed, `org-mode' both
sets `fill-paragraph' function to `org-fill-paragraph' and remaps the
`fill-paragraph' binding to `org-fill-paragraph'. If I understand
correctly, this is technically redundant, but (a guess) probably the
remapping is kept for backwards compatibility reasons.
I don't know why this happens. As far as I get, `fill-paragraph' should
be calling `fill-paragraph-function', so I'd expect both to do the same
thing. But currently they don't.
Why would anyone call `fill-paragraph' instead of `org-fill-paragraph'?
Well, if you have some paragraph filling tweak you like, you might. For
example, one such instance is that widespread "fill-or-unfill" function,
which I think started with Artur Malabarba, and was eventually packaged
by Steve Purcell in https://github.com/purcell/unfill (180k+ downloads
at MELPA).
Either way, even when the binding for `fill-paragraph' is remapped to
`org-fill-paragraph' it should be at least safe (I think...) to call
`fill-paragraph' directly in an Org buffer, even when it might arguably
be better to call `org-fill-paragraph'.
An ECM to reproduce the issue is:
- Start 'emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20201019")
#+end_src
- Visit file =test.org= with contents:
#+begin_src org
,* Foo
- Boo
- Baz
,* Bar
:PROPERTIES:
:CATEGORY: home
:CUSTOM_ID: Bar
:END:
#+end_src
- Place point in the "Baz" list item under heading "Foo", and call `M-x
org-fill-paragraph'. As expected, the buffer is unchanged.
- Now call `M-x fill-paragraph'. The result is:
- The result is:
#+begin_src org
,* Foo
- Boo
- Baz
,* Bar
:PROPERTIES:
:CATEGORY: home :CUSTOM_ID: Bar
:END:
#+end_src
where `fill-paragraph' "filled" the contents of the properties drawer of
the following heading, despite three whole blank lines and a heading
along the way.
Best regards,
Gustavo.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-08-11
Package: Org mode version 9.4 (9.4-19-gb1de0c-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php"
. php) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite"
. sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("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 :export org-irc-export)
("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
Re: Force creation of org id in template
On Mon, 26 Oct 2020 at 22:33, Michael Heerdegen wrote: > I'm not sure. I see that creating an id involves slightly more than > adding the property - see the `org-id-add-location' call in > `org-id-get'. Calling the higher level `org-id-get' or the like in a > %() spec in a template fails however, since when it's called a temp > buffer not associated with a file is current. > > And then I'm also not sure if the above is always secure when something > else in the template spec wants to add a (different) property. Do you > know? Not really. `org-id' usually "just works" for me, so I never had to dig anything deeper there. But, as far as I recall, this is meant to add the new ID on the IDs file. Considering your capture template is likely to be on your agenda files, this is probably not going to be of concern (meaning here these files will eventually be scanned and the ID found). But, if it is, you could then go with `%(org-id-get nil t)`, right? It does seem to be more appropriate either way, I agree. I have stored here in my init file a message from the list describing the procedure Org uses to try to find an ID, you might find it useful: https://lists.gnu.org/archive/html/emacs-orgmode/2009-11/msg01195.html Regarding the second issue, of course, you should end up with a single properties drawer, and the template should ensure that. Best, Gustavo.
Re: Force creation of org id in template
On Mon, 26 Oct 2020 at 19:40, Gustavo Barros wrote: > On Mon, 26 Oct 2020 at 22:33, Michael Heerdegen > wrote: > >> I'm not sure. I see that creating an id involves slightly more than >> adding the property - see the `org-id-add-location' call in >> `org-id-get'. Calling the higher level `org-id-get' or the like in a >> %() spec in a template fails however, since when it's called a temp >> buffer not associated with a file is current. >> >> And then I'm also not sure if the above is always secure when something >> else in the template spec wants to add a (different) property. Do you >> know? > > Not really. `org-id' usually "just works" for me, so I never had to dig > anything deeper there. But, as far as I recall, this is meant to add > the new ID on the IDs file. Considering your capture template is likely > to be on your agenda files, this is probably not going to be of > concern (meaning here these files will eventually be scanned and the ID > found). But, if it is, you could then go with `%(org-id-get nil t)`, > right? It does seem to be more appropriate either way, I agree. > > I have stored here in my init file a message from the list describing > the procedure Org uses to try to find an ID, you might find it useful: > https://lists.gnu.org/archive/html/emacs-orgmode/2009-11/msg01195.html > > Regarding the second issue, of course, you should end up with a single > properties drawer, and the template should ensure that. Indeed, `%(org-id-get nil t)` fails. But the following works: (defun org-id-get-new-id () (interactive) (let ((id (org-id-get nil t))) id)) To my surprise, I had to make it interactive. Perhaps that's what made the previous try fail. Best, Gustavo.
Documentation suggestion: Mention async-bytecomp-package-mode in the installation section of the manual
Hi All, I've seen time and again folks get bitten by trying to install Org with `package.el' while having Org loaded. The latest, but certainly not the first and not the last: https://www.reddit.com/r/orgmode/comments/jicj1k/how_to_use_org_version_from_orgpluscontrib/ This is well known, and indeed the manual states "important" in bold to say that "You need to do this in a session where no ‘.org’ file has been visited, i.e., where no Org built-in function have been loaded." But it is not always easy to ensure that, even when you know what you are doing. And certainly not trivial to users less acquainted with the package system and how library loading works, etc. However, there is a very easy way to ensure that installation/byte-compilation is done in a clean environment in package `async', namely `async-bytecomp-package-mode'. From my experience, I have a simple: (use-package async-bytecomp :ensure async :defer t :custom (async-bytecomp-allowed-packages 'all) (async-bytecomp-package-mode t)) in my init file. My `initial-major-mode' is `org-mode' and I've never had an installation problem, even though I update `org-plus-contrib' carelessly at will on a live session. `async' is by John Wiegley, and available both at ELPA and MELPA. Wouldn't it be worth mentioning it in the manual and/or in the site/Worg? Best regards, Gustavo.
org-sort-entries sorting by top-level with first entry at bob
Hi All, `org-sort-entries' provides no easy way to sort by top-level when the first entry is at the beginning of buffer. This is true for both interactive and non-interactive uses of the function, but a little more inconvenient in the latter case. Indeed, `org-sort-entries', when deciding what to sort, first tests for `org-region-active-p', then `org-at-heading-p' (or if after a heading), failing those tests, it falls back to top-level sorting. However, if the first heading is at the beginning of buffer and we want to sort by top-level, we'll never get to the fall back case, because `org-at-heading-p' will return non-nil, and the children of the first entry will be sorted instead. Not an ECM, just an use case with the situation at hand. Consider a buffer with contents: #+begin_src org ,* B Foo ,** B Baz ,** A Foo ,* A Bar #+end_src How to sort by top-level? The currently existing alternative is to `mark-whole-buffer', and let `org-sort-entries' sort by region. While this is reasonable in the interactive case, it is less so if `org-sort-entries' is being called in code. Using `mark-whole-buffer' in your code will grant you a nice compiler warning and pretending you don't use it by doing the same thing yourself is explicitly advised against in its docstring: "it is usually a mistake for a Lisp function to use any subroutine that uses or sets the mark". Behind the scenes, Org is using `use-region-p', which means the region must not only exist but transient-mark-mode must be on and the mark must be active. It can be made to work, of course, but it is clearly less than ideal. Either way, currently the only way to ensure that sorting is done by top-level when you don't know whether there is something before the first heading (including possible narrowing) is to rely on the region case. What to do with it is somewhat tricky, though. My first thought was to test if we are actually looking at a heading regexp, and sort on the heading's level in this case. But, on second thought, I believe this is not a good idea, because it will conflict with current and expected behavior for speed-keys, in particular. Perhaps test if point is at beginning of buffer, and handle this case specially? Best regards, Gustavo.
Re: org-sort-entries sorting by top-level with first entry at bob
Hi Samuel, On Fri, 30 Oct 2020 at 17:43, Samuel Wales wrote: i always have everyting under a top level, so taht files are trees not forests and org can work treeishly even at toplevel. This would be a workaround, not a solution. Is it a formal requirement of Org that files must be kept in this form? but to not use the mark, typically you supply point-min and point-max to some function. `org-sort-entries' does not take beg/end as arguments, it uses the active region, as reported. Regards, Gustavo.
[FR] Don't hardcode checker functions prefix in org-lint
Hi All, This is a small feature request for `org-lint' not to hardcode the checker functions' prefix, as it currently does. `org-lint' is a small gem in Org, specially to those fat-fingered folks such as myself, to the point that it's been some time since I've been fancying using it to check some of my own personal conventions and structures, beyond Org syntax. It is not difficult to do so, and it is enough to define some appropriate checker functions and a personal `my-org-lints' let binding `org-lint--checkers' to my own set of checkers. It's pretty neat. However, `org-lint' hardcodes the prefix of the checker functions to its own prefix, so that to define my own personal checker functions I have to step on `org-lint's namespace, and use "org-lint-" as a prefix, to get things working. The hardcoding occurs in `org-lint--generate-reports', when each checker is called with: #+begin_src emacs-lisp (funcall (intern (format "org-lint-%s" (org-lint-checker-name c))) ast) #+end_src It would be really useful, and simple enough, if a variable was defined, such as: #+begin_src emacs-lisp (defvar org-lint-checker-prefix "org-lint") #+end_src and the call used this variable instead of hardcoding its value: #+begin_src emacs-lisp (funcall (intern (format "%s-%s" org-lint-checker-prefix (org-lint-checker-name c))) ast) #+end_src This would allow to define the mentioned `my-org-lints' function let binding `org-lint--checkers' and `org-lint-checker-prefix' to appropriate values. So that an user's checker functions could have names with other prefixes. As far as my grasp of `org-lint' goes (still learning), that would be enough for users to enjoy its infrastructure for personal lints without having to invade org-lint's namespace. If you think it's a good idea, I'd certainly appreciate it to be included. Thank you. Best regards, Gustavo.
Re: [FR] Don't hardcode checker functions prefix in org-lint
Hi All, On Tue, 10 Nov 2020 at 17:22, Gustavo Barros wrote: This is a small feature request for `org-lint' not to hardcode the checker functions' prefix, as it currently does. I've been playing with and testing this further, and I found an uncovered corner in my initial suggestion: the revert-buffer behavior in the report buffer. It is still simple to handle it, but requires a couple of extra steps: set the prefix variable as a buffer local variable in the report buffer in `org-lint--display-reports' and let-bind this value before moving to the linted buffer in `org-lint--generate-reports'. As an extra sugar, but non essential, it would also be nice to be able to set the report buffer's name. In sum, the suggestion/request then entails: #+begin_src emacs-lisp (defvar-local org-lint--checkers-prefix nil) (defvar-local org-lint--report-buffer-name nil) (defun org-lint--generate-reports (buffer checkers) (let ((checkers-prefix (or org-lint--checkers-prefix "org-lint"))) (with-current-buffer buffer ;; [...] (funcall (intern (format "%s-%s" checkers-prefix (org-lint-checker-name c))) ast) ;; [...] ))) (defun org-lint--display-reports (source checkers) ;; changed let-binding <-- (let ((buffer (get-buffer-create (or org-lint--report-buffer-name "*Org Lint*" (with-current-buffer buffer (org-lint--report-mode) (setf org-lint--source-buffer source) (setf org-lint--local-checkers checkers) ;; added variable setting <-- (setf org-lint--checkers-prefix org-lint--checkers-prefix) (org-lint--refresh-reports) (tabulated-list-print) (add-hook 'tabulated-list-revert-hook #'org-lint--refresh-reports nil t)) (pop-to-buffer buffer))) #+end_src That's about it. With it, I get a fully functional Lint report for personal lints with something like: #+begin_src emacs-lisp (defun my/org-lint (&optional arg) (interactive "P") (let ((org-lint--checkers my/org-lint-checkers) (org-lint--checkers-prefix "my/org-lint") (org-lint--report-buffer-name "*My Org Lint*")) (funcall-interactively 'org-lint arg))) #+end_src Best regards, Gustavo.
Re: Changed list indentation behavior: how to revert?
Hi Karl, On Fri, 13 Nov 2020 at 18:30, Karl Voit wrote: > Hi! > > I'm on Org mode maint git repo, currently v9.3.6. > > I recently upgraded from an older git commit version. > > Since the upgrade I do have a different behavior: > > - Consider this list itemX > A 1 > 2 > > When I press RET at the "X" above, I end up at position "1". With > another RET, cursor ends up at "2". I'd love to get back the > previous behavior where RET at "X" always ended up at "A". > > Unfortunately, there are tons of org*indent* variables out there. > I'd appreciate it very much if somebody knows what variable I need > to modify to get back to the previous behavior. > > Thanks! I'll answer, because I feel somewhat responsible for your upgrade. ;-) Since recently Org is set to respect Emacs' `eletric-indent-mode'. If I'm not mistaken, it made to the 9.4 release, I presume that's what you are getting. You can find the Org News entry, and how to get the previous behavior back in: https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS#L323 A couple of threads that might help understand the change and the reasoning behind it: https://orgmode.org/list/877dxpazbo.fsf...@gmail.com/ https://orgmode.org/list/878sfbycip@iki.fi/ HTH, Gustavo.
Re: Changed list indentation behavior: how to revert?
On Fri, 13 Nov 2020 at 18:47, Jean Louis wrote: * Gustavo Barros [2020-11-14 00:12]: I have seen discussion with very little reasoning. You are changing default for many users and large subset of those users will not read the NEWS. And now you are discovering that there are people who get messed up with it. Is it really useful? So far I remember the electric-indent-mode did work in Org mode without this anti-enhancement. [...] Introducing default that changes habits and gives more work to present users is not useful. Did you consider number of users who would now maybe need to introduce local variable just to turn that off? Sorry that I do not find this case reasonable. Oh, my! I'm not even the person you should be ranting to. I'm just an user, and someone who follows this list, and was trying to be helpful. But, as such, I do get what motivated maintainers to make the change from the linked threads. And I also got from them and the News the information needed to adjust for the change, in case I'd want to. Perhaps we read differently. Best regards, Gustavo.
Re: Changed list indentation behavior: how to revert?
Hi All, On Sun, 15 Nov 2020 at 13:37, Greg Minshall wrote: > hi, all. > > David Rogers wrote: > >> Am I crazy to say that your last example of unwanted behavior is >> easier for me to read and understand? (and to me the common >> indenting is a hopeless mess?) > > yes, in fact, the "new" way sort of has the buffer indentation match > that of the outline structure of the file (specified by asterisks). > there's a lot to be said for that. (though, obviously, it's not what > everyone would want.) > > if the new mode stays as the standard, maybe we'd want to capture an > asterisk typed immediately after a newline that would (by default), put > that line-beginning asterisk back in column one? > > otherwise, this is what one gets (without remembering to do a C-j > instead of ): > - > * i wanted a headline > * i wanted a subhead, but it's ignored by org mode > - > which is maybe not optimal? > > in most non-org modes (including in Org Src... buffers, and in org files > when writing org-mode lists), i'm a big fan of electric indent mode. > > maybe an org-specific setting, "org-file-indent-follows-structure"? if > true, it means the user wants to have a "raw" org document laid out > according to the outline structure of the document. if false, it means > one, in general, wants the org file laid out with left-alignment (or, > right, in right-to-left) languages (not including embedded lists, and > whatever else i might be ignoring). > > cheers, Greg I'm quite surprised by the reaction to this issue, because `electric-indent-mode' *does not change Org's indentation settings*, it just applies them alongside RET. Which makes me think that those who've been so bitten by it where actually manually overriding (their own) settings in this area by never applying indentation. If that's your case, you'd probably be very surprised of running `org-indent-region' in your documents (don't do it, I don't want to break them). In particular, one "surprising" result of the "new behavior" is that of indentation after a heading. That was already and continues to be controlled by the user option `org-adapt-indentation'. If you don't want your content to be indented after a heading, set it to nil. And `electric-indent-mode' should do what you expect in this regard. I'm not sure if thus overriding your own (or Org's, if you prefer) indentation settings by selectively applying indentation is a sane approach, so perhaps `electric-indent-mode' may help you discipline your editing to your benefit. And make you more conscious of Org indentation. Especially because indentation is not a "free variable" in Org, it is a syntactical aspect of an Org document and, conspicuously, is critical to the definition of a heading and of plain lists. An example from Greg: > - > * i wanted a headline > * i wanted a subhead, but it's ignored by org mode > - That's because the first one is indeed a heading, and the second is not, it is a plain list item. By definition a heading must start at the left margin. You (plural) could probably also get some juice from looking into, and incorporating to muscle memory, `M-RET', `C-RET' and `C-j'. Of course, with that said, if you really don't like `electric-indent-mode' for Org, you can disable it as described in the Org News, previously linked to in this thread. There is ground to prefer this, particularly for the list case, mentioned by Karl in the original message of this thread. But `electric-indent-mode' does not induce a new pattern of indentation for Org, it just applies your settings in this area, whose defaults have not changed of recent, as far as I recall. Finally, the "change" was not brought about by Org, but by Emacs. Org just (belatedly) tagged along. Best regards, Gustavo.
Re: Changed list indentation behavior: how to revert?
Hi Jean, On Sun, 15 Nov 2020 at 09:09, Jean Louis wrote: That is useful. I'm glad to hear that. You (plural) could probably also get some juice from looking into, and incorporating to muscle memory, `M-RET', `C-RET' and `C-j'. I do, thank you for reminder. Us in plural are sometimes teachers or mentors who educate other people who are supposed to edit Org files in most simple manner, and those people will never be able to write to this list to find out which option where, not even to know about indentation things. When default is introduced then all people following an educator has to turn off default. They will not even know why. One default introduced can cause butterfly effect. Also a fellow teacher here. As you, I'm trying to transmit this information to you and others, because I find it useful. Nobody needs to use `M-RET', `C-RET' and `C-j'. General design of user interface should not conquer their habits unless substantial amount of users have demanded it so. And how exactly would maintainers know that? Do you claim to be speaking on their (substantial amount of users) behalf? For me is now better to simple adjust: org-indent-region variable just as you said. Please, don't confuse. I said you should *not* use (the command) `org-indent-region' if you were systematically manually overriding indentation defaults. I recommended to set the user option `org-adapt-indentation' to nil, which seems to be the desired value for most of the manifestations on this thread. Best regards, Gustavo.
Re: Changed list indentation behavior: how to revert?
Hi Tim, Hi All, On Mon, 16 Nov 2020 at 18:15, Tim Cross wrote: > Tim Cross writes: > >> >> Thanks for clarifying this Kyle. >> >> So essentially, this change has been made to make org-mode consistent >> with the rest of emacs which enabled electric-indent by default in Emacs >> 24. this is a good thing. Org should be consistent with other modes. Any >> differences are likely to be the source of confusion and bug reports. >> >> I am a little confused about the purpose of org-adapt-indentation >> though. According to the org news file, to get back the old behaviour, >> it says to explicity disable electric-indent mode using org-mode-hook. >> There is no mention of org-adapt-indentation. >> >> Is this just an artefact from before and in effect, we have two methods >> to disable the indentation behaviour? Is there anything functionally >> different between disabling electric-indent by calling >> electric-indent-local-mode -1 or setting org-adapt-indent to nil or is >> the result functionally equivalent? >> > > Following up to my own question. The two are NOT functionally equivalent > in that org-adapt-indentation supports other values than t or nil. You > can use this variable to tweak how the adaptive indentation works. While > setting it to nil may be equivalent to turning of electric-indent mode, > it can be used to adjust how adaptive indentation works as well. > > Tim > > -- > Tim Cross I think I might chime in again, as perhaps I have a point to add, and Tim's formulation here is a good hook for that. Setting `org-adapt-indentation' to nil is not equivalent to disabling `electric-indent-mode' not because there are more values than t or nil for the first, but because they are conceptually different. `org-adapt-indentation' controls how the indentation should be done by Org, `electric-indent-mode' just applies this setting when you hit RET. If you have `electric-indent-mode' off, but `org-adapt-indentation' set to t, type a heading hit RET, than TAB, you will get the same indentation up to the heading stars level. But the point of interest here, is not this difference by itself, but in some of its implications, and why so many people were unaware of `org-adapt-indentation'. I think this is the case because, with `electric-indent-mode' off, it is easy to slip through the right indentation, and get to believe things are working as expected, when they are actually just doing so by coincidence. Suppose you are in the status quo before 9.4, that is `org-adapt-indentation' set to its default value of true, and `electric-indent-mode' off, and you start to type a little document. If you type it always hitting TAB after RET, you will get: #+begin_src org ,** Foo First line Second line #+end_src (Indentation appears off, but that's just the escape comma). If, instead, you just type RET, you get what many people surprised by the change in this thread expect: #+begin_src org ,** Foo First line Second line #+end_src Now, the point is that, if you just miss the TAB on the first line, even if you hit TAB to indent on the subsequent ones, they will still not indent and be kept on the left margin. So things *appear* to be working as expected, but they are not. What is happening here is that *because indentation is broken in the first line* it goes amiss in the following ones. One might argue that, if it appears to work on all accounts, it is actually working. But if you have this situation, you will then be subject to all sorts of strange things. Suppose we are in the situation of the last block, and demote the heading: #+begin_src org ,*** Foo First line Second line #+end_src Surprise! the content of the heading was moved to the right by one space which is neither indented as it should, nor at the left margin as "expected". Now you try to "fix" this "incorrect" dragging of the content, by selecting the subtree and calling `org-indent-region'. #+begin_src org ,*** Foo First line Second line #+end_src Surprise! it's even "worse". So you then undo twice, and type the star directly to "correct" it (how else?). Try to expand an org-tempo template and get surprised that you can't get a non-indented expansion right after the heading, but you can do it after some content (from a real case at https://emacs.stackexchange.com/q/55413/18951). I haven't tried further, but I wouldn't be surprised if similar "strange" behaviors would also affect killing-yanking subtrees, refiling, etc. So, keeping `org-adapt-indentation' to t, but "solving" the inconvenience by disabling `electric-indent-mode' is not a solution, because this will just hide (keep hiding?) from you the fact that you are editing a document which is different from what Org is actually expecting according to the indentation settings, and this will result in inconsistencies of behavior at a number of points. We should probably thank `electric-indent-mode' for making people more aware of this user option, and correct this setting
Bug: Can't toggle off archived tasks in agenda with "v A" [9.4 (9.4-41-g9bb930-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201116/)]
Hi All,
The toggling of Archives mode in the agenda, the one which includes
archive files, called with "v A", can be turned on, but turning it off
with "v A" does not currently work.
An ECM to reproduce the issue is:
- Start `emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20201116")
(setq org-agenda-files '("~/test/agenda.org"))
#+end_src
- We have two files in =~/test/=: =agenda.org= and =agenda.org_archive=,
which is, as you presume, the default archive file of the first one.
The contents of =agenda.org= are:
#+begin_src org
,* TODO Task
SCHEDULED: <2020-11-16 Mon>
,* TODO Archived tree
:ARCHIVE:
SCHEDULED: <2020-11-16 Mon>
#+end_src
- And those of =agenda.org_archive= are:
#+begin_src org
#-*- mode: org -*-
Archived entries from file /home/gustavo/test/agenda.org
,* TODO Archived task
SCHEDULED: <2020-11-16 Mon>
:PROPERTIES:
:ARCHIVE_TIME: 2020-11-16 Mon 11:52
:ARCHIVE_FILE: ~/test/agenda.org
:ARCHIVE_TODO: TODO
:ARCHIVE_CATEGORY: agenda
:END:
#+end_src
Which was actually produced by archiving this task from =agenda.org=.
- From this setup, lets call `org-agenda': "M-x org-agenda RET a".
- At this point, the agenda only shows "Task", which is as expected.
Call "v a" to also show "Archived tree", locally archived by tagging.
Call "v a" again to disable it, and it goes away as expected.
- Call "v A" (uppercase "A"), to enable display of archived tasks
including those of archive files. "Archived task" is also shown, as
expected. So far, so good.
- Now call "v A" again to toggle (off) the display of archived tasks.
The minibuffer echoes the message "Trees with :ARCHIVE: tag and all
active archive files are included", and the archived items are still
shown. Considering the manual describes the binding "v A" as "Toggle
Archives mode. Include all archive files as well.", this is not
expected behavior.
- Using "v a" to toggle it off does work as expected though, even when
we enabled `org-agenda-archives-mode' with "v A".
Best regards,
Gustavo.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-08-11
Package: Org mode version 9.4 (9.4-41-g9bb930-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20201116/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-agenda-files '("~/test/agenda.org")
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("redis" . redis) ("php" . php) ("arduino"
. arduino) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite"
. sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("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 :export org-irc-export)
("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
Re: Bug: Can't toggle off archived tasks in agenda with "v A" [9.4 (9.4-41-g9bb930-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201116/)]
On Tue, 17 Nov 2020 at 02:54, Kyle Meyer wrote: Gustavo Barros writes: Hi All, The toggling of Archives mode in the agenda, the one which includes archive files, called with "v A", can be turned on, but turning it off with "v A" does not currently work. An ECM to reproduce the issue is: Thanks for the report and reproducer. Should be fixed by 104d92199. Wow, that was fast! Thank you very much, Kyle.
Bug: org-toggle-link-display and org-hide-emphasis-markers [9.4 (9.4-44-g5272d9-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201123/)]
Hi All,
when using `org-hide-emphasis-markers', making links visible with
`org-toggle-link-display' also unhides the emphasis markers. I believe
this to be unexpected behavior (it certainly is to me), but I might be
wrong here, given that the emphasis markers are explicitly set to a
`org-link' invisible property (which see).
An ECM to reproduce the issue is:
- Start `emacs -Q'
- Do an initial setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20201123")
(setq org-hide-emphasis-markers t)
#+end_src
- Open an Org buffer with contents:
#+begin_src org
[[https://orgmode.org/][Org mode for Emacs]]
,*bold*
#+end_src
given the settings, both the link and emphasis markers should be
invisible.
- Call `M-x org-toggle-link-display', see that both the link and the
emphasis markers are made visible. Toggle it again, and both are
invisible.
As far as I dug, the reason for this behavior lies in
`org-do-emphasis-faces' which indeed uses the `org-link' invisible
property to hide the links (at the very end of the function):
#+begin_src emacs-lisp
(when (and org-hide-emphasis-markers
(not (org-at-comment-p)))
(add-text-properties (match-end 4) (match-beginning 5)
'(invisible org-link))
(add-text-properties (match-beginning 3) (match-end 3)
'(invisible org-link)))
#+end_src
So that `org-toggle-link-display' cannot really distinguish an emphasis
marker from an actual link when it removes `org-link' from the
invisibility-spec.
I don't know why this is done this way in `org-do-emphasis-faces', so I
might be missing something, but it does lead to this peculiar behavior
of `org-toggle-link-display'.
Best regards,
Gustavo.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-08-11
Package: Org mode version 9.4 (9.4-44-g5272d9-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20201123/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-hide-emphasis-markers t
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("redis" . redis) ("php" . php) ("arduino"
. arduino) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite"
. sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("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 :export org-irc-export)
("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")
Bug: org-link-descriptive and org-toggle-link-display [9.4 (9.4-44-g5272d9-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201123/)]
Hi All,
there is a scope mismatch in `org-toggle-link-display' between text
(visibility) properties and the setting of `org-link-descriptive'. The
text properties are set for the buffer with either
`remove-from-invisibility-spec' or `add-to-invisibility-spec', but the
value of `org-link-descriptive` is set globally with `(setq
org-link-descriptive (not org-link-descriptive))'. It is not a big
deal, but it does lead to a glitch in `org-toggle-link-display'.
It is easy to generate an ECM to trigger the glitch:
- Start `emacs -Q'
- Load the latest:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20201123")
#+end_src
- Open two Org buffers "*Buffer 1*" with contents:
#+begin_src org
[[https://orgmode.org/][Org mode for Emacs]]
#+end_src
- And "*Buffer 2*" with contents:
#+begin_src org
[[https://orgmode.org/worg/][Hello Worg, the Org-Mode Community!]]
#+end_src
- It's probably easier to visualize if you have both windows in view in
a split frame, but it should not change the result whatever you do.
- The initial state, as per defaults, is that links are invisible in
both buffers.
- Go to "*Buffer 1*" and `M-x org-toggle-link-display', and links are
made visible in that buffer, but not in "*Buffer 2*".
- Now, go to "*Buffer 2*" and call `M-x org-toggle-link-display' there.
It doesn't work. Call it again. Now it does.
What's happening is that, when we call `org-toggle-link-display' in
"*Buffer 1*" we set `org-link-descriptive' to nil globally, so that when
we move to "*Buffer 2*", Org thinks the links are visible, and when we
call `org-toggle-link-display' then, Org will try to "re-hide" the links
that are already invisible, with no apparent effect. But, in doing so,
it also sets `org-link-descriptive' to t again, also globally. And so a
second call will work.
I don't know if it's better to make `org-link-descriptive' buffer-local,
or to simply use `setq-local' in `org-toggle-link-display'. Either way,
it is a low hanging one.
Best regards,
Gustavo.
Emacs : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0)
of 2020-08-11
Package: Org mode version 9.4 (9.4-44-g5272d9-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20201123/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-link-descriptive nil
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
org-eldoc-load)
org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
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-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("redis" . redis) ("php" . php) ("arduino"
. arduino) ("C" . c) ("C++" . c++)
("asymptote" . asy) ("bash" . sh) ("beamer"
. latex) ("calc" . fundamental) ("cpp" . c++)
("ditaa" . artist) ("dot" . fundamental) ("elisp"
. emacs-lisp) ("ocaml" . tuareg)
("screen" . shell-script) ("shell" . sh) ("sqlite"
. sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete
org-attach-complete-link)
("id" :follow org-id-open) ("eww" :follow
org-eww-open :store org-eww-store-link)
("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 :export org-irc-export)
("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-bib
Re: [BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi All, On Fri, 29 Oct 2021 at 21:40, Ihor Radchenko wrote: Gustavo Barros writes: The glitch is that some repeated tasks, when marked done in the Agenda, show no visual feedback that the action has taken place, as usual, and if you refresh the Agenda, they just vanish, which demonstrates the action had indeed taken place in the agenda file, just not shown in the Agenda buffer itself. And, as far as I can tell, this happens to repeated tasks, scheduled in future. For tasks scheduled for today or in the past, they appear to be done as expected. Confirmed Best, Ihor This is a respectful bump on this one. But not to bump empty handed, I did some investigation on this, and I think I know why the problem happens. At `org-agenda-todo' when a task is a repeating one, the value of `org-agenda-headline-snapshot-before-repeat' stored at `org-todo' may or may not replace `newhead' depending on some conditions, which are: #+begin_src emacs-lisp (when (and org-agenda-headline-snapshot-before-repeat (not (equal org-agenda-headline-snapshot-before-repeat newhead)) todayp) (setq newhead org-agenda-headline-snapshot-before-repeat just-one t)) #+end_src So that `newhead' is set to `org-agenda-headline-snapshot-before-repeat' only if `todayp' is non-nil. And, indeed, this seems to be the condition which results in the missing visual feedback reported here. I've tried without it, and it works. (I'm currently using built-in 9.5.2, but I think there's no change in the function to current release 9.5.4 and also, light testing with the latter suggests no change in the reported issue). What I'm not sure is why this condition is there in the first place. That's the only place where the let-bound `todayp' is used in the function, so I may be missing why it exists and the purpose of this condition. But one side-effect of it is that, if you happen to do a repeating task ahead of schedule, you won't see the change of todo state in the agenda. Best regards, Gustavo.
Re: [BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi Ihor, On Tue, 12 Jul 2022 at 10:46, Ihor Radchenko wrote: Thanks for the detailed analysis! I thank you again for your continued interest in this little report. I dug through the old commits and found where this behaviour has been introduced: Commit 0bbf3a9bd message details the current behaviour and its caveats: Ah! this definetely clears up the intended purpose of the condition. Great dig! As you can see, the todayp condition is avoiding issues with weekly agenda when the same habit is displayed multiple times. The problem you observed is also noted and left unresolved. Ideas how to deal with the described are welcome! I can try to think this trough with you, if you'd like. Since I'm the reporter and bumper, it is fair that I start and try to build a base for it. The TL;DR for what follows is that I think `todayp' is ultimately the "wrong" condition to apply, but is a good *proxy*. Perhaps there's a chance to get to a more correct condition, but I'm not sure. But, even if not, I'd like to argue that the "occurrence at point" may be a better proxy, which would be the condition applied (as far as I can tell, which see) if the `todayp' condition were dropped. The long version: First a preliminary observation. I think the case "noted and left unresolved" in the commit message is somewhat different than the one reported here. Related, of course, but different. Let's consider a hypothetical agenda with the following characteristics: a weekly agenda starting on Monday (fixed), today is Tuesday. Unless stated otherwise, this is the scenario for the examples that follow. A daily repeating task, scheduled for today will appear in the agenda from Tuesday to Sunday. If we move point to the occurrence of that task on, say, Thursday, and mark it done then, we would have the case described in the commit message. I'm not sure it is "unlikely", but we could argue that this is "dubious user input". Now consider the case of a weekly repeating task scheduled for Thursday. This is the case reported here. And I think marking this entry done "ahead of schedule" is arguably more legitimate user input. For once, this entry only appears once in the given agenda view, there is no option to use any other. That said, let's try to be systematic. There are a number of reasons an entry may appear multiple times in an agenda view: A1) The entry is scheduled in a past date, and this past date is also visible in the agenda view. In the example agenda a task scheduled for Monday would appear both Monday, and today, Tuesday. A2) The entry has a deadline in a future date, this future date is visible in the agenda view, and the deadline warning settings are enough to be shown today as well. A task with a deadline for Thursday would appear today, Tuesday, and Thursday. B) The entry is scheduled (deadlined?) to a range of dates. For example, a task scheduled to a range from Thursday to Saturday this week would appear four times in the agenda view, once for the regular schedule and thrice for the range "(N/3)". C) The entry has a repeater whose frequency is higher than the span of the agenda view. A daily task on a weekly view, a weekly task on a monthly view, etc. Of course, a given entry may appear in the agenda multiple times for multiple of these reasons. That's all I can think of. Do you see any other cases? This is a critical question, because the soundness of the argument depends on this list being exhaustive. Anyway, pending on that, let me go on. Now, this bug only affects repeating tasks, because the problem arises only for them because their state in the underlying buffer does not correspond to the "todo change the user has just applied". Indeed, `org-agenda-headline-snapshot-before-repeat' is correspondingly just stored for them, as the name implies. Furthermore, reasons A1, A2 and B, are not specific to repeating tasks, though they affect them too, of course. Reason C is the only one specific to repeating tasks, and is really the only reason I think grants for the case considered in the commit message: Because the same line may be present in other lines in the same weekly agenda, we cannot simply update all lines related to this entry. Indeed, a non-repeating task which appears multiple times in the agenda view (A1, A2, or B), when marked done, is visually changed as such in all occurrences. The same does not happen for a repeating entry because, well, "there might be C (as well?)...". That's the nature of the problem, as far as I can see. And a real one at that. I don't know enough of the agenda machinery to know if among the metadata stored as text properties we would be able to distinguish "C" from the other reasons for a given occurrence of a given entry. It is probably fair to presume it is not possible to distinguish, otherwise Carsten might have leveraged that information. That given, `todayp' do
Re: [BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi Ihor, On Mon, 18 Jul 2022 at 14:28, Ihor Radchenko wrote: I feel that you are overcomplicating things a bit. Well, the most important objective of the analysis was to try to figure out if the `todayp' condition was too strict or not. Since your suggested fix implies removing it as well, I take I have you convinced? ;) What if we simply change all the agenda lines if and only if their date in agenda is earlier or equal to the next scheduled time (after repeater is triggered)? I think this is a good condition, better than the one I had devised (considering the span of the agenda and the repetition frequency). As far as I can tell, it will also require parsing the planning info of the entry and consider the relevant cases, but perhaps you are seeing more than I can. And I presume you refer only to repeating tasks, so that the rest of the current conditional (except `todayp') would remain in place. The only case I can think of which might trip a little this condition is a date range, but "date range with repeater" seems corner enough for us not to sweat much over it. One thing to consider is the timing of things and how it affects the conditional. You said "earlier or equal to the next scheduled time (after repeater is triggered)". We are looking at things in `org-agenda-todo' after `org-todo' has done its job, in other words, after the repeater has "stepped". `org-agenda-headline-snapshot-before-repeat' is stored in `org-todo' because there would be no longer any way to retrieve it at this point, but we don't store anything else, as far as I can tell. So, at this point, the current scheduled (dedlined, etc.) time would be "the next/first instance which is *not* done", and hence wouldn't it be "earlier, but not equal, to the next scheduled time"? Another thing for which you might have something in mind, but I don't see how to handle it is that `org-agenda-change-all-lines' can receive the `just-this' argument and that decides whether just the current line gets changed or if all entries with the same marker are looped over. So it's either "this" or "all". Perhaps the version of the conditional you suggested will require change in `org-agenda-change-all-lines' so that it can change "some, according to a given predicate". In sum, all in all, the conditional you suggested sounds very good to me, and a clear improvement relative to the current state of things. And regardless of anything else, it seems we agree that `todayp' is too strict and removing it would be the low hanging fruit in all this. Best, Gustavo.
Re: [BUG] Propertized space in Agenda's mode-name [9.5.2 (release_9.5.2-3-geb9f34 @ /usr/local/share/emacs/28.0.91/lisp/org/)]
Hi Ihor, On Sat, 22 Oct 2022 at 04:14, Ihor Radchenko wrote: > I am unable to reproduce with the latest Org. thanks for checking this report. I've retested things here and, though I can still reproduce it with Org 9.5.5, I can confirm the issue is gone on 9.6-pre with the latest commit on master. Lucky us! :-) Best regards, Gustavo.
Re: Bug: fill-paragraph in Org buffer [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]
Hi All, On Mon, 26 Oct 2020 at 14:11, Gustavo Barros wrote: > Calling `fill-paragraph' in an Org buffer may leak paragraph boundaries, > and even heading boundaries, and break document structure. Just an update on this one. I can no longer reproduce it with Emacs 28.2 and Org 9.5.5. Fixed. Best regards, Gustavo.
Re: [BUG] org-link-descriptive not honored as file-local-variable [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi All, On Fri, 29 Oct 2021 at 15:53, Gustavo Barros wrote: > Currently, trying to set `org-link-descriptive' as file-local-variable > is not honored by Org, and doing so, leads to one of mismatched states > between `org-link-descriptive' and the invisibility specs. a respectful bump. Despite the changes made to `org-link-descriptive` by Kyle in a related thread (https://list.orgmode.org/87im4ypu9v@kyleam.com/), the failing recipe in this report can still be reproduced in Org 9.5.5 and Emacs 28.2. Best regards, Gustavo.
Re: Bug: canceled capture operation results in demoted following heading when template ends with newline [9.2.4 (9.2.4-11-g1c3eae-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20190722/)]
Hi All, On Sun, 28 Jul 2019 at 16:34, Gustavo Barros wrote: > When the capture template ends with a newline character and the capture > process is canceled, the following heading gets demoted. And it > shouldn’t. a respectful bump on this one. I can still reproduce this with Emacs 28.2 and Org 9.5.5. Best regards, Gustavo.
Re: [BUG] org-link-descriptive not honored as file-local-variable [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)]
Hi Ihor, On Mon, 24 Oct 2022 at 01:52, Ihor Radchenko wrote: > This is because setting things up for links is a part of Org loading > process. And file-local variables are only loaded after major mode by > Emacs. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57003 Ah, I had presumed this one would be a load order issue, and indeed it is a general one. Agreed that this report should stay on standby until it's been decided what to do in general terms. And thank you for raising the issue in the Emacs list. Good discussion, btw. Best regards, Gustavo.
