Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]

2021-06-17 Thread Gustavo Barros

Hi Jeff,

On Wed, 16 Jun 2021 at 23:22, Jeff Kowalski  
wrote:


I can confirm the same is happening here for me with Org mode version 
9.4.6

(9.4.6-4-g093c94-elpa @ /home/jeff/.emacs.d/elpa/org-20210607/) on GNU
Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, 
cairo

version 1.16.0) of 2021-06-16
The duplicate LOGBOOK entries also seem to be messing up the graphical
display of habit records in the agenda.  Deleting the duplicates 
returns
the habit display to expected output.  I'd be happy to share details 
of
that symptom, but the root cause seems to clearly be the duplicates in 
the

LOGBOOK


Thanks for confirming and for the habits info.  So that's what was 
happening with my consistency graphs.  I had indeed been noticing they 
felt "off", but I eventually reverted to 9.4.4 because of the duplicate 
entries and forgot about it.  It seems then that this got solved for me 
not by the reverting itself but by me removing the duplicate entries in 
the LOGBOOK.


Would clocking reports be affected too? (I'm not personally an user of 
clocking, so I don't really know).


Perhaps a "lint" for LOGBOOK duplicates would be a good idea alongside 
with the fix, so that people could go about fixing their data with a 
little more convenience?


Best regards,
Gustavo.



Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]

2021-06-14 Thread Gustavo Barros

Hi Bhavin,

On Mon, 14 Jun 2021 at 15:01, Bhavin Gandhi  
wrote:



On Mon, 14 Jun 2021 at 19:10, Gustavo Barros wrote:

The marking of repeated tasks as "done" is currently resulting in
duplicate entries in the "LOGBOOK" drawer, which is not expected.  I
don't know exactly when this came to be, but it does not happen in 
the

current built-in version (9.4.4), while it does in the latest release
(9.4.6).


I was able to reproduce this, and here are my findings as well as a
reproducible configuration with only a few settings.


Thank you for taking the time to try this out and for confirming you are 
able to reproduce the issue.


(I'm marking this bug confirmed.  I'd normally refrain from "self 
confirming" but, since Bhavin was able to reproduce and I consider this 
one to be particularly relevant, I made an exception.)


Best regards,
Gustavo.



Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]

2021-06-14 Thread Gustavo Barros

Hi All,

The marking of repeated tasks as "done" is currently resulting in 
duplicate entries in the "LOGBOOK" drawer, which is not expected.  I 
don't know exactly when this came to be, but it does not happen in the 
current built-in version (9.4.4), while it does in the latest release 
(9.4.6).


An ECM to reproduce the issue is the following.

Start 'emacs -Q' and do an initial setup:

#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/elpa/org-9.4.6")
(setq org-log-into-drawer t)
(setq org-log-done 'time)
(setq org-todo-keywords
 '((sequence "TODO(t)" "SOMEDAY(s)" "|" "DONE(d!)")
   (sequence "NEXT(n)" "WAIT(w@/!)" "|" "CANCELED(c@/!)")))
#+end_src

Visit file =test.org= with contents:
#+begin_src org
,* TODO Foo
SCHEDULED: <2021-06-13 Sun +1d>
#+end_src

Now call "C-c C-t" (`org-todo'), and call the key "d" for "DONE", as per 
the above settings.  The resulting buffer is:


#+begin_src org
,* TODO Foo
SCHEDULED: <2021-06-15 Tue +1d>
:PROPERTIES:
:LAST_REPEAT: [2021-06-14 Mon 10:27]
:END:
:LOGBOOK:
- State "DONE"   from "TODO"   [2021-06-14 Mon 10:27]
- State "DONE"   from "TODO"   [2021-06-14 Mon 10:27]
:END:
#+end_src


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.4.6 (9.4.6-gab9f2a @ 
/home/gustavo/.emacs.d/elpa/org-9.4.6/)


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-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-log-done 'time
org-agenda-loop-over-headlines-in-active-region nil
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)" "SOMEDAY(s)" "|" "DONE(d!)")
		 (sequence "NEXT(n)" "WAIT(w@/!)" "|" 
		 "CANCELED(c@/!)"))

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
 

[BUG] org-return does not honor delete-selection-mode [9.4.6 (release_9.4.6-551-gf70e36 @ /home/gustavo/.emacs.d/lib/org-mode/lisp/)]

2021-06-09 Thread Gustavo Barros

Hi All,

`org-return' currently does not honor `delete-selection-mode'. An ECM to 
reproduce it is the following.


Start `emacs -Q' and do some setup:
#+begin_src emacs-lisp
(add-to-list 'load-path "~/.emacs.d/lib/org-mode/lisp")
;; Org repo at commit f70e36252
(load-library "org")
(org-version); => "9.4.6"
(delete-selection-mode 1)
(org-mode)
#+end_src

Now select a region and type "RET". The newline is indeed inserted, but 
the selected region is not deleted, as would be expected. To compare, 
select some region again and type "a".


I don't know when this came to be, but the above ECM was tested on the 
current master. The issue is also present for me in the built-in version 
of Emacs 27.2, Org 9.4.4.


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.4.6 (release_9.4.6-551-gf70e36 @ 
/home/gustavo/.emacs.d/lib/org-mode/lisp/)


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 '((closure
  (org--rds reftex-docstruct-symbol
   org-element-greater-elements org-clock-history
		   org-agenda-current-date org-with-time org-defdecode 
		   org-def

   org-read-date-inactive org-ans2 org-ans1
		   org-columns-current-fmt-compiled 
		   org-clock-current-task

   org-clock-effort org-agenda-skip-function
		   org-agenda-skip-comment-trees 
		   org-agenda-archives-mode

   org-end-time-was-given org-time-was-given
   org-log-note-extra org-log-note-purpose
   org-log-post-message org-last-inserted-timestamp
   org-last-changed-timestamp
		   org-entry-property-inherited-from 
		   org-blocked-by-checkboxes

   org-state org-agenda-headline-snapshot-before-repeat
		   org-agenda-start-on-weekday 
		   org-agenda-buffer-tmp-name

   org-priority-regexp org-mode-abbrev-table
		   org-mode-syntax-table buffer-face-mode-face 
		   org-tbl-menu
		   org-org-menu org-struct-menu org-entities 
		   org-last-state
		   org-id-track-globally org-clock-start-time 
		   texmathp-why

   remember-data-file
   org-agenda-tags-todo-honor-ignore-options
   iswitchb-temp-buflist calc-embedded-open-mode
		   calc-embedded-open-formula 
		   calc-embedded-close-formula

   align-mode-rules-list org-emphasis-alist
   org-emphasis-regexp-components
   org-export-registered-backends org-modules
   org-babel-load-languages org-id-overriding-file-name
   org-indent-indentation-per-level
		   org-element-paragraph-separate 
		   org-inlinetask-min-level t)

  nil
		  (add-hook 'change-major-mode-hook 'org-show-all 
		  'append

   'local)
  )
 (closure
  (org-src-window-setup *this*
   org-babel-confirm-evaluate-answer-no
   org-babel-tangle-uncomment-comments
   org-src-preserve-indentation org-src-lang-modes
		   org-edit-src-content-indentation 
		   org-babel-library-of-babel

   t)
  nil
  (add-hook 'change-major-mode-hook
   #'org-babel-show-result-all 'append 'local)
  )
 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 '(closure
   (org-id-locations
org-agenda-search-view-always-boolean
org-agenda-overriding-header t)
   (entry) (cdr (assq :title 
   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

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/)]

2021-05-24 Thread Gustavo Barros



On Mon, 24 May 2021 at 13:34, Bhavin Gandhi  
wrote:




Yes, I have attached an updated patch.



Looks good to me. Thank you!



We are indeed aligned. The only additional thing I discovered was
the reason `org-refile--get-location' works despite having double
slashes. That was new for me.



Great!  Thanks for clearing that up too.


Best,
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/)]

2021-05-23 Thread Gustavo Barros

Hi Bhavin,

On Sun, 23 May 2021 at 15:05, Bhavin Gandhi  
wrote:


Finally after spending a couple of hours, I was able to understand the 
code

of org-refile-get-location \o/. The detailed bug report helped me to
understand the issue. I'm attaching a patch here which should fix the
problem, it has other details as well. I have tested a few basic 
scenarios

as mentioned in the report.


Thank you very much for working on this patch.  I couldn't offer it 
myself (out of my legal bounds) and had gone as far as I was allowed to 
here, so I'm happy you took it from there.


The patch looks good to me, and corresponds to my analysis of the 
problem and suggested fix.  I have only one minor nitpick: you could go 
with a simple `let' there, instead of a `let*', since we only have one 
let-bound variable there anyway.


About:


[...] it has other details as well.


As far as I could see, we are very much aligned on the problem and fix. 
But perhaps I'm missing something, could you elaborate on that?


Thanks again.

Best,
Gustavo.



Re: 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/)]

2021-05-06 Thread Gustavo Barros

Hi Bastien,

On Thu, 06 May 2021 at 08:53, Bastien  wrote:


I fixed this in the
maint branch, please let me know if you notice any weirdness.



It's looking good here now.

Thanks again.

Best,
Gustavo.



Re: Bug: org-agenda-later scrolls buffer unnecessarily [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]

2021-05-03 Thread Gustavo Barros

Hi Bastien,

On Mon, 03 May 2021 at 19:26, Bastien  wrote:



well, clearly my mind is dull right now - I pushed another better fix,
but please report any better solution if you have one.



Thank you.

No, not really, I just happened to spot an offending case of the 
previous commit.  Unfortunately, I don't have a silver bullet here.


Gustavo.



Re: Bug: org-agenda-later scrolls buffer unnecessarily [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]

2021-05-03 Thread Gustavo Barros

Hi Bastien,

On Mon, 03 May 2021 at 17:31, Bastien  wrote:


Hi Gustavo,

Gustavo Barros  writes:

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.


Fixed in maint, thanks.


Thank you for looking into this.

But I think the commit, though indeed avoids the reported undue 
scrolling, brings other undesired side effects.  Usually, 
`org-agenda-later' will carry over the current day of the week to the 
next week.  If we call it on Thursday, point will be placed on the same 
week day of the next week.


Just calling `(set-window-start nil 1)' there breaks this regularity. 
It is easy to generate a case where this happens.  Just squeeze the 
height of your window on a "populated" agenda, and choose a day for 
which that day next week won't fit in the window if position 1 is shown, 
and call it from there.


Perhaps doing so before the call to 
`org-agenda-find-same-or-today-or-agenda' would be a possibility? 
(untested)


Best,
Gustavo.





Re: 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/)]

2021-05-02 Thread Gustavo Barros

Hi Bastien,

On Sun, 02 May 2021 at 03:54, Bastien  wrote:


Hi Gustavo,

Gustavo Barros  writes:


I just tested the fix and, indeed,
`org-insert-heading-respect-content' no longer breaks the structure 
of

the first heading.  However, if I may add a nitpick, the value of
`org-blank-before-new-entry' does not seem to be honored in this 
case.

For default values, a distance of one blank line is ensured to the
next heading.  


My understanding is that `org-blank-before-new-entry' will ensure
there is a blank line before the new entry, which is what I see.

Let me know if there is something I miss here.  Thanks!


Indeed, that's why I said I'm not sure `org-blank-before-new-entry' is 
the culprit here.  Still, there is a difference of behavior in that 
regard if point is before or after the fist heading.  An ECM to 
reproduce it is the following.




From the situation ("|" represents point position), call `C-RET':


#+begin_src org
,#+title: Title

|
,* Foo

,* Bar

,* Baz
#+end_src

The result is:

#+begin_src org
,#+title: Title

,* |
,* Foo

,* Bar

,* Baz
#+end_src

Now move point to:

#+begin_src org
,#+title: Title

,*
,* Foo

,* Bar
|
,* Baz
#+end_src

And call `C-RET'.  The result is:

#+begin_src org
,#+title: Title

,*
,* Foo

,* Bar

,* |

,* Baz
#+end_src

Not quite sure what is the cause, and also not absolutely sure what 
would be expected behavior.  Since, if we now place point at:


#+begin_src org
,#+title: Title

,*
,* Foo
|
,* Bar

,*

,* Baz
#+end_src

And call `C-RET', we get:

#+begin_src org
,#+title: Title

,*
,* Foo
,* |

,* Bar

,*

,* Baz
#+end_src

My guess, and this is just a hunch, is that the default value of 
`org-blank-before-new-entry', which by default is `auto' for `heading' 
is somehow backward looking, and hence has somewhat of a hard time in 
making the said "intelligent decision" as to how many blank lines to 
include.  Particularly before the first heading.


Indeed, I can understand the last case in that perspective, since the 
first heading we inserted has no blank line to "Foo", so that when 
inserting a new heading between "Foo" and "Bar" if we look right above 
"no blank line" is the rule to infer.  And, if that first heading is 
removed, inserting a new one there, will behave just as it does between 
"Bar" and "Baz".


This was all tested with `emacs -Q', version 27.2, and Org commit 
3e497bec3.  No variables changed, thus out-of-the-box experience.


Anyway, as mentioned, "nitpick" level stuff, since you asked for 
testing.


Best regards,
Gustavo.



Re: 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/)]

2021-05-02 Thread Gustavo Barros

Hi Bastien,

On Sun, 02 May 2021 at 03:30, Bastien  wrote:


Gustavo Barros  writes:


This way it would be
possible to toggle the markers selectively, as it is done with the
links.  I'm not sure this is granted, but one reasonable hypothesis
why `org-link' was used there in the first place is that some degree
of selective toggling of the markers was somehow demanded.


Yes, this came to my mind too, but I will refrain from adding this
new toggling capability for emphasis markers until people convince
us it has to be implemented.


I'm fine with that.  I have no particular opinion on the matter, I was 
really just speculating why that might have ended there in the first 
place.  That said, nothing to add here, except: thanks again.


Gustavo.



Re: [Feature Request] More flexibility in org-speed-commands customization

2021-05-02 Thread Gustavo Barros



Hi Bastien,

On Sun, 02 May 2021 at 03:29, Bastien  wrote:



Indeed, I have some code ready for this in an updated version of the
patch. So the change won't be that "breaking" but let's still assess
whether it will break many configurations.



Looks good to me. Thank you.

Gustavo.



Re: 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/)]

2021-05-01 Thread Gustavo Barros

Hi Bastien,

On Sat, 01 May 2021 at 13:02, Bastien  wrote:


Hi Gustavo,

Gustavo Barros  writes:

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.


Fixed with commit fb3030188 in the maint branch, thanks a lot.

Please test it and report any problem you may encounter.


Thank you very much.

I just tested the fix and, indeed, `org-insert-heading-respect-content' 
no longer breaks the structure of the first heading.  However, if I may 
add a nitpick, the value of `org-blank-before-new-entry' does not seem 
to be honored in this case.  For default values, a distance of one blank 
line is ensured to the next heading.  In the report's ECM, after the 
fix, the new heading is inserted immediately before it.  (I'm not sure 
it is really `org-blank-before-new-entry' which is at play here, but the 
behavior is not the same before the first heading than it is after it, 
with respect to blank lines).


Best,
Gustavo.



Re: [Feature Request] More flexibility in org-speed-commands customization

2021-05-01 Thread Gustavo Barros

Hi Bastien,

On Sat, 01 May 2021 at 13:24, Bastien  wrote:


Hi Gustavo,

Gustavo Barros  writes:


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?


Well, no, I don't see a strong reason to hard-code the set of speedy
keys.  See the attached patch, which proposes to use just one option
`org-speed-commands'.

This would be a breaking change, but I don't think we do otherwise.

Would this suit your needs?  What do you think about the change?


Thank you for seeing to this.

Yes, the patch corresponds pretty much to what I had in mind.  That's 
the way I'd go there too.


And it's not about my needs here, I can verify it is safe to override 
the defconst and do so (as indeed I do).  I was thinking more of that 
kind of user which would be uncertain if they could, and might 
eventually refrain from using a nice feature for framing it an "expert 
kind of stuff".


A possible way to mitigate breakage here can be at hand, since we ended 
up with a third name (a proper one, btw).  You could mark 
`org-speed-commands-user' as obsolete but keep it, for the due time as 
usual, and append it to `org-speed-commands' somehow (no need to 
distinguish them in `org-speed-command-help' though).  Those who had 
overriden `org-speed-commands-default' are on their own, of course, as 
they shouldn't have done that in the first place.  ;-)


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/)]

2021-05-01 Thread Gustavo Barros

Hi Bastien,

On Sat, 01 May 2021 at 17:28, Bastien  wrote:


Hi Gustavo,

Gustavo Barros  writes:

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.


Fixed in the maint branch with commit ccd513a3c, thanks!


Thank you!

Gustavo.



Re: 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/)]

2021-05-01 Thread Gustavo Barros

Hi Bastien,

On Sat, 01 May 2021 at 13:42, Bastien  wrote:


Hi Gustavo,

Gustavo Barros  writes:

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).


thanks for reporting this, I've committed 842ab092a in maint which
should fix it.



Thank you for looking into this, and for the fix.


I hope the change does not break anyone's code: perhaps some people
use custom code to hide/show emphasis markers based on the org-link
invisible property specs.  


In any case, I don't think `org-toggle-link-display' should display
emphasis markers.


I'm not sure either.  Perhaps that was the reason why `org-link' was 
used as the invisibility property there in the first place.  If you 
think that is a concern, perhaps adding something as `org-emph' to the 
invisibility specs and using it there instead of leaving the markers in 
the default group might be a good idea.  This way it would be possible 
to toggle the markers selectively, as it is done with the links.  I'm 
not sure this is granted, but one reasonable hypothesis why `org-link' 
was used there in the first place is that some degree of selective 
toggling of the markers was somehow demanded.


Best,
Gustavo.




Re: A small idea to simplify (further) time input in the date/time prompt

2021-05-01 Thread Gustavo Barros

Hi Bastien,

On Sat, 01 May 2021 at 12:40, Bastien  wrote:


Hi Gustavo,

sorry for the slow reply.

I applied this patch in master with commit e8562a332.

Thanks!


Thank you very much!
Looking forward to enjoy this one.

Best,
Gustavo.



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/)]

2021-04-27 Thread Gustavo Barros



On Tue, 27 Apr 2021 at 04:29, Bastien  wrote:


Ihor Radchenko  writes:


Maybe you can use

(eq (org-element-type (car (org-element-lineage element))) 'drawer)


Indeed, thanks for the tip!  Committed as 26d1d29cf.


Bastien and Ihor, thank you!

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/)]

2021-02-14 Thread Gustavo Barros

Hi All,

I'd like to kindly bump this report.
It is an issue which has been around for some time.  The report provides 
a clear reproduction recipe, which stardiviner was able to reproduce, 
and still affects current "org-plus-contrib-20210208".  The report also 
provides a hopefully convincing code analysis of the affected function 
`org-refile-get-location' and a suggested fix (I just don't send a 
patch, because I can't provide CA).


Best regards,
Gustavo.


On Mon, 21 Sep 2020 at 15:34, Gustavo Barros  
wrote:



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

Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht

2021-01-25 Thread Gustavo Barros

Hi Juan,

On Mon, 25 Jan 2021 at 14:46, Juan Manuel Macías 
 wrote:


By the way... I have written some code to export the citations using
make4ht. It's just a proof of concept, and not too elegant I'm afraid.
But I wanted to explore a bit more the use of make4ht in this context.



Nice! I also think make4ht has potential for this 
purpose. tex4ht/make4ht is usually a somewhat delicate tool for a 
general LaTeX document (powerful, but complex), but the typical output 
of citation and bibliography is text with emphasis/bold etc, and perhaps 
a list, if we interpret the bibliography environment strictly. This is 
much simpler (again, typically) than an arbitrary document, to the point 
I believe it could be streamlined reliably for this subset of the 
document.


The idea is to write the citations in Org as mere bibLaTeX commands, 
but

between !!- ... -!! (a provisional regexp, for convenience, and to see
if it works). It can be tested in this Org file, which includes the 
code

(you have to give a value to the variables `bib' and `preamble'):

https://gitlab.com/-/snippets/2066135



I understand using the regexp to separate the problems, provisionally, 
as you said.  If it evolves, you might wish to go with the current state 
of things in the wip-cite branch or, I reiterate the suggestion, look at 
latex-preview, which allows you to specify the commands of interest, if 
I recall correctly.


I hope you find your way trough the approach. If you do, please let me 
know. Or, if you wish to discuss a particular issue, feel free to write 
me directly.


Best regards,
Gustavo.




Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht

2021-01-24 Thread Gustavo Barros

Hi Juan,

On Sun, 24 Jan 2021 at 16:20, Juan Manuel Macías 
 wrote:



I agree with what you comment here and in your previous message. In
fact, I'm afraid this (humble) approach of mine is focused only on
creating a mere list of references in HTML from a bib file, keeping 
the
same bibliography styles that I have customized in bibLaTeX, but not 
on

everything related to citations throughout the text and on the
consistency between citations and bibliographies. I would say that my
method is not a good starting point to implement a solution. [...]

In my case, anyway, I had been using the TeX ecosystem almost
exclusively for my work in typesetting and editorial design (I do not
use DTP software, which is not intended to create books but magazines
and newspapers), and Org Mode for writing and notes. But in recent 
years
I have come to realize that a workflow based also on Org and 
Org-Publish

is tremendously productive for me to manage the typesetting of a book,
especially a complex book. Let's say now I also use Org as a 
high-level

interface for LaTeX. I'm currently working on the /Hispanic Dictionary
of Classical Tradition/ (/Diccionario Hispánico de la Tradición
Clásica/), a volume of multiple authorship and about 1200 pages. The
method I raised in this thread has to do with this scenario, where 
each

dictionary entry is accompanied by a bibliography. As the dictionary
will have an online secondary version, I wanted to keep the same
bibliography style that I had defined for bibLaTeX. I have not had the
problem of the citations here, since the entries do not contain
citations (bibliographies only). Otherwise, I think an emergency
solution could be to export from Org to *.tex, and then generate the
HTML from there using make4ht and another preamble /ad hoc/, better 
than
using a mixed csl/bibLaTeX method which, as you say, can result in 
many

inconsistencies.


Well, I think your approach should work quite well for your use case, 
and certainly a number of others. It is just a matter of being aware of 
the limitations of the tool. That given, it is great. Of course, I was 
also curious how you had figured things from a more general perspective.



The
essential problem, of course, is that our customization is 
LaTeXcentric:

it resides in LaTeX/bibLaTeX and not in Org. [...]



I think it is more than just being "LaTeXcentric".  Depending on 
requirements, there is really no choice.  We don't hear this often, but 
the fact is that Org does not support citation and bibliography by 
itself.  A lot of things "work", and in many requirements scenarios that 
seems to be enough, but what does work relies on outsourcing that task 
to other tools.  As far as I know, there are only two ways out of an Org 
document with citation and bibliography: LaTeX (and its related tools: 
bibtex, biblatex, biber, etc), and pandoc (which uses CSL to process 
these features).  The first option is extremely featureful, but 
restricts us to .pdf output.  The only sufficiently general option with 
multi output is then pandoc, which in turn bypasses the whole Org export 
infrastructure, implying its own trade-offs because of that.  Besides, 
there is no real link between the LaTeX infrastructure and pandoc/CSL, 
so that if you want to reach "best results in LaTeX, and acceptable 
results in other formats", you are bound to live with differences in 
output for citation/references across formats and to remain under the 
restrictions of the least featureful backend.



Long ago I tended to be more in favor of the idea that a single
source-text should produce multiple identical or interchangeable
formats. I really still believe it with enthusiasm and I have not
completely lost faith in such a utopia ;-)


I'd also would love to see that. ;-)

And I do think Org is, by far, the best placed tool to fill this place. 
But I also think citations and bibliography are a big bottleneck in that 
regard.  Of course, there is a long ongoing effort in that area, in the 
`wip-cite' branch, and the related `org-citeproc' package.  I'm still in 
the hope this will get merged in future not too distant, as it would 
change things in that regard.  Not in the sense of "magically solving 
all of these problems", but in providing a convened base upon which 
people can than invest their time and effort, and try to figure each 
case out, with time.


Best regards,
Gustavo.



Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht

2021-01-24 Thread Gustavo Barros



On Sun, 24 Jan 2021 at 08:37, Gustavo Barros  
wrote:



It should handle two limitations of your procedure, which
are: getting the bibliography with the entries actually cited in the
document and citation callouts.  The first one is easy to handle in 
your

current approach by means of any of the multiple alternatives to
generate a bib file with only the cited entries.  The second one, much
harder, as far as I can see.


Thinking this through: there is actually a third challenge to the 
approach, which is ensuring the relation of the citation callouts and 
the bibliography is correct.  For example, if using a numeric or alpha 
style, how to be sure the labels are the same in the citation and the 
bibliography.  Even in other styles, such as author-year, if 
disambiguation rules come into play (e.g. (Smith 1987a, Smith 1987b)), 
how to be sure the same rules are being applied by pandoc/CSL (on the 
citations) and biblatex (in the bibliography).  As far as I can tell, 
this will hang on sorting, something which biblatex is known to be more 
capable than other tools, so that I would expect differences (at least 
potentially).  Styles such as verbose or author-title would probably be 
safe, I guess.  Have you given some thought about this?  If so, how are 
you handling the case?


Best,
Gustavo.



Re: [Tip] Export a bibliography to HTML with bibLaTeX and make4ht

2021-01-24 Thread Gustavo Barros


Hi Juan,

that's very interesting.  Thanks for sharing.

On Sat, 23 Jan 2021 at 12:03, Juan Manuel Macías  wrote:

> When I export to LaTeX an Org document that contains a bibliography, I
> use bibLaTeX with a very custom style (i.e. quite a few lines of code
> related to bibLaTeX in the preamble). I wanted to apply all that
> bibLaTeX setting and styles when exporting to HTML too, so I came up
> with this method, using make4ht. I share it here, in case it is useful
> to someone.
>
> The idea is to compile with make4ht (see:
> https://www.ctan.org/pkg/make4ht) a simple file with *only* the
> bibliography, and "embed" the HTML output in the Org document. You need
> to create in the working directory a tex file, which will serve as a
> minimal preamble and which also includes all code related to bibLaTeX.
> We can name it preamble.tex, and it would start like this:

Indeed, when one actually needs biblatex-biber to process their
bibliography, using Org is really hard.  I have some history with this
problem, as I initially approached Emacs (once upon a time) trying to
use Org as a single source and multiple outputs (mainly pdf and odt).
However, as you, I rely on heavily customized styles, which simply won't
work with pandoc/CSL, so I got stuck.  I eventually stayed in Emacs and
use Org for a number of things, but for my more formal writing use
AUCTeX + RefTeX, which is great too (alas, no odt..., at least not
easily).

For a long time I fancied trying something about it, pretty much in the
same lines as you are doing here.  My idea was to use `preview-latex'
for this, which I still think is promising and, as far as I understand,
pretty much automates what you are doing, which is to generate a
stripped document, with a proper preamble, and run it on a piece of your
actual document.  It is used by AUCTeX and LyX (Org too, I presume) to
generate images, but I don't see why it could not be streamlined to
generate a dvi which could then be fed to tex4ht and friends, just as
you do too.  I thought that this procedure could, in principle, be used
to export to other formats, but also to Org itself, generating either a
second version of the source document with the citations and
bibliography already processed as text (sort of a
'org-biblatex-citeproc'), or as a preview, such as the ones for math.
Depending on how far you are willing to take your setup, this might be
one path.  It should handle two limitations of your procedure, which
are: getting the bibliography with the entries actually cited in the
document and citation callouts.  The first one is easy to handle in your
current approach by means of any of the multiple alternatives to
generate a bib file with only the cited entries.  The second one, much
harder, as far as I can see.

To my dismay, my own style customizations for biblatex are mainly aimed
at citations (primary/archival sources for Economic History).  But it
was quite interesting to see your approach here.  So, again, thank you.

Best,
Gustavo.



Re: org-refile and ivy

2021-01-22 Thread Gustavo Barros
Hi Eric,

On Fri, 22 Jan 2021 at 15:49, Eric S Fraga  wrote:

> Dear all org mode list readers,
>
> I have been trying to get to grips with org-refile.  For some reason,
> the completion mechanism (I use ivy generally but I have no idea what
> org-refile actually tries to do/use) only shows me the current file name
> if I have org-refile-targets set to nil.  It doesn't show any top level
> headlines to choose from which is what I would expect from the
> documentation.  Hitting RET to select the completion target given (file
> name only) refiles to the end of the file which is not what I want.
>
> This is with org updated fairly recently but not quite up to
> date.  However, I've had this problem for a long time and don't use
> org-refile as a result.
>
> Any suggestions welcome.

I use org-refile with ivy, so I might share.  If I recall correctly, the
only thing that does not play well between the two is
`org-outline-path-complete-in-steps`.   My basic setup is the following:

#+begin_src emacs-lisp
(setq org-refile-targets
  '((org-agenda-files :maxlevel . 6)
;; 'nil' means consider headings of the current buffer
(nil :maxlevel . 6)))
(setq org-refile-use-outline-path 'file)
(setq org-outline-path-complete-in-steps nil)
#+end_src

That should get you started.  I personally like org-refile for its
quickness, so I do some extra work to filter out candidates of this list
and keeping only the frequent targets (with
`org-refile-target-verify-function').  And if something atypical arises,
I just go with kill-yank.

Note however, on the relation of org-refile and ivy:
https://orgmode.org/list/87tuvrj7ww@gmail.com/

HTH,
Gustavo.



Re: underline with line breaks doesn't work

2021-01-01 Thread Gustavo Barros
Hi Enrique,

On Fri, 01 Jan 2021 at 05:22, "Blair, Erik"  wrote:

> I would like to use \ul from the soul package in Org mode for underlining with
> line breaks (and *not* underlining spaces). It’s not working well. It fails
> like \underline (spaces get underlined, and lines don’t break and run off the
> page). My LaTeX export doesn’t work if I insert \ul{abc} into the org file,
> but I can insert \ulem{abc} or \underline{abc}, as well as the typical _abc_.
>
> More information: I’m actually trying to define a new command using logic in
> the LaTeX header. This way, I can make notes with key words. I can toggle a
> Boolean variable, and it makes key words show up; or, it underlines the words,
> which are also hidden by \phantom. Also, we would like to avoid underlining
> spaces because it cues the reader to know how many words are missing.
>
> I note this previous discussion:
>https://lists.gnu.org/archive/html/emacs-orgmode/2013-06/msg00376.html
>
> It seems like the issue that was fixed at one point and \ul should work, but
> maybe it’s not now. Or, maybe I don’t have the experience to know how to apply
> the solution to my Emacs/Org mode on my computer.

`soul' was considered as a default for underline and strike-through in
that thread, but some people reported problems with Chinese characters,
so that eventually it was replaced by `ulem'.  In other words, `soul' is
not loaded by default by Org when exporting to LaTeX, `ulem' is.

Much later, I've argued in that same thread in favor of `soulutf8' as
a better default:

https://orgmode.org/list/8736iobefh@gmail.com/
https://orgmode.org/list/871ry8bdo8@gmail.com/

But my necrobumping seems to have missed the opportunity at that point.


Regarding your particular situation, you just tell us "it's not work
well / doesn't work" which is not much to go about.  And also not much
about any Org export configurations you might have in your init.
Anyway, the only guess I have with what you provided is that you are
missing to load `soul' altogether.  If that's the case, adding the
following to your document should do:

#+latex_header: \usepackage{soulutf8}

That is, it should be enough for you to use it in your `\keyTest' or to
use `\ul' directly.  For Org to export `_abc_' as `\ul{abc}' you'd also
need to configure `org-latex-text-markup-alist`.

Note, however, that the `soul' underline will underline spaces.  But
that's an issue on the LaTeX side, and has nothing to do with Org.  For
this to work as you expect, you will either have to go fancy in your
underlining (for which there is plenty of examples in
tex.stackexchange) or, which is probably the easiest, provide that this
is handled appropriately in your conditional for `\keyTest'.

HTH,
Gustavo.



[FR] Generalize org-reftex-citation

2020-12-24 Thread Gustavo Barros

Hi All,

It's been some time since included in my todos to cook something to 
insert citations in Org using RefTeX's infrastructure.  As I set this 
morning to do so, I found out it already existed: `org-reftex-citation'. 
Alas, it is not enough for me (and certainly also others), because it 
uses a simple regexp search for "#+BIBLIOGRAPHY:", thus only being able 
to find the .bib file with that specific form of declaration.  In 
particular, it does not support biblatex (as far as I can tell).


Before I found out the function existed, I had a general idea of letting 
RefTeX work in the exported .tex file.  It turns out it is easy to adapt 
`org-reftex-citation' to do precisely that.  And in so doing, being thus 
able to do anything RefTeX is able to support in its native environment, 
on top of anything Org is able to export.  The only disadvantage I see, 
and which I consider minor, is that the .tex file has to exist.


My take on this neat little idea so far is:

#+begin_src emacs-lisp
(defvar gb/org--rds nil)
(defun gb/org-reftex-citation ()
 "Use `reftex-citation' to insert a citation into the buffer.
The bibliography sources for the base Org file are found by RefTeX 
itself
parsing the corresponding exported \".tex\" file, which is required to 
exist.
Those are passed to `reftex-citation' to insert a citation into the base 
Org

buffer."
 (interactive)
 (unless (derived-mode-p 'org-mode)
   (user-error "Not an Org buffer"))
 (let ((tex-file (org-export-output-file-name ".tex")))
   (if (file-readable-p tex-file)
   (find-file-noselect tex-file)
 (user-error "TeX file not available, export first to %S" 
 tex-file))

   (let ((reftex-docstruct-symbol 'gb/org--rds)
 gb/org--rds)
 (with-current-buffer (get-file-buffer tex-file)
   (reftex-access-scan-info nil)
   (setq gb/org--rds (symbol-value reftex-docstruct-symbol)))
 (call-interactively 'reftex-citation
#+end_src

Still lightly tested, but looks good with what I tried out.

So, I thought it was a good idea to send this to the list as suggestion 
/ feature request.


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/)]

2020-12-22 Thread Gustavo Barros



On Tue, 22 Dec 2020 at 17:24, Gustavo Barros  
wrote:




Damn!  Sorry for the noise.  It *doesn't* work, and disables Org's own
remappings, of course.  Just as I sent I realized I had something else 
enabled which was doing the actual job (my previous take on this 
thread).
Back on the deadlock. 
Sorry again.


But, in the meantime I did find this: 
https://stackoverflow.com/a/13102821


I reproduce Stefan's answer verbatim, so it's kept for reference in the 
list regardless of the external link:


#+begin_src emacs-lisp
(add-hook '-hook
 (lambda ()
   (let ((oldmap (cdr (assoc ' minor-mode-map-alist)))
 (newmap (make-sparse-keymap)))
 (set-keymap-parent newmap oldmap)
 (define-key newmap [] nil)
 (make-local-variable 'minor-mode-overriding-map-alist)
 (push `( . ,newmap) 
 minor-mode-overriding-map-alist

#+end_src

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/)]

2020-12-22 Thread Gustavo Barros



On Tue, 22 Dec 2020 at 17:18, Gustavo Barros  
wrote:


Anyway, what I came up is a slight variation from Marco's approach, 
which may

be just general enough to be employed by Org.

#+begin_src emacs-lisp
(add-hook 'visual-line-mode-hook #'my/visual-line-mode-hook-for-org)

(defun my/visual-line-mode-hook-for-org ()
 (when (and (derived-mode-p 'org-mode)
visual-line-mode)
   ;; Ensure 'visual-line-mode' does not shadow Org's line commands.
   (local-set-key [remap move-beginning-of-line] nil)
   (local-set-key [remap move-end-of-line] nil)
   (local-set-key [remap kill-line] nil)))
#+end_src

I've lightly tested this here and it seems to be working.

WDYT?


Damn!  Sorry for the noise.  It *doesn't* work, and disables Org's own 
remappings, of course.  Just as I sent I realized I had something else 
enabled which was doing the actual job (my previous take on this 
thread).  Back on the deadlock. 


Sorry again.

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/)]

2020-12-22 Thread Gustavo Barros

Hi Bastien,
Hi Marco,

On Fri, 04 Sep 2020 at 14:37, Bastien  wrote:


Hi Gustavo,

Gustavo Barros  writes:


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'?


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,


I've been playing with 'mwim.el' today, and came up with something that 
might be interesting.


Btw, Bastien, I've seen the message you've sent to emacs-devel about 
this. Thank you. A pity it doesn't seem to have drawn much attention.


Anyway, what I came up is a slight variation from Marco's approach, 
which may be just general enough to be employed by Org.


#+begin_src emacs-lisp
(add-hook 'visual-line-mode-hook #'my/visual-line-mode-hook-for-org)

(defun my/visual-line-mode-hook-for-org ()
 (when (and (derived-mode-p 'org-mode)
visual-line-mode)
   ;; Ensure 'visual-line-mode' does not shadow Org's line commands.
   (local-set-key [remap move-beginning-of-line] nil)
   (local-set-key [remap move-end-of-line] nil)
   (local-set-key [remap kill-line] nil)))
#+end_src

I've lightly tested this here and it seems to be working.

WDYT?

Best regards,
Gustavo.



Re: did behaviour of RET change again?

2020-12-20 Thread Gustavo Barros
Hi All,

On Sun, 20 Dec 2020 at 18:25, Bastien  wrote:

>
> Also, I'm thinking of using headline-data as the new default for the
> org-adapt-indentation option.  WDYT?
>
> I know Kevin as a good overview of the whole topic, maybe he can also
> advise about what should be done here.

I cannot but raise a friendly flag here.

I've reported the following behavior I've found for `headline-data'
some time ago: https://orgmode.org/list/87r1qukjjs@gmail.com/

Nicholas Savage did try and could not reproduce.  Last time I've tried
it, not long ago, I still found the behavior.  I would thus suggest that
at least some more people try it and check their end before going that
route.  I'll be happy if it's just me.

That said, I do think `headline-data' is a great default value for
`org-adapt-indentation', despite the fuss that is bound to ensue for
*any* change there.

Best regards,
Gustavo.



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/)]

2020-11-24 Thread Gustavo Barros

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 

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/)]

2020-11-23 Thread Gustavo Barros

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")

   

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/)]

2020-11-17 Thread Gustavo Barros



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: 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/)]

2020-11-16 Thread Gustavo Barros

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 
		   

Re: Changed list indentation behavior: how to revert?

2020-11-16 Thread Gustavo Barros
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 

Re: Changed list indentation behavior: how to revert?

2020-11-15 Thread Gustavo Barros

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?

2020-11-15 Thread Gustavo Barros
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?

2020-11-13 Thread Gustavo Barros



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?

2020-11-13 Thread Gustavo Barros
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: [FR] Don't hardcode checker functions prefix in org-lint

2020-11-12 Thread Gustavo Barros

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 ( 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.



[FR] Don't hardcode checker functions prefix in org-lint

2020-11-10 Thread Gustavo Barros

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: org-sort-entries sorting by top-level with first entry at bob

2020-10-30 Thread Gustavo Barros

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.







org-sort-entries sorting by top-level with first entry at bob

2020-10-30 Thread Gustavo Barros

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.



Documentation suggestion: Mention async-bytecomp-package-mode in the installation section of the manual

2020-10-26 Thread Gustavo Barros

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.



Re: Force creation of org id in template

2020-10-26 Thread Gustavo Barros


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.



Re: Force creation of org id in template

2020-10-26 Thread Gustavo Barros


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.



Bug: fill-paragraph in Org buffer [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]

2020-10-26 Thread Gustavo Barros

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


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/)]

2020-10-21 Thread Gustavo Barros

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" 
		   

Re: A small idea to simplify (further) time input in the date/time prompt

2020-10-06 Thread Gustavo Barros

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.





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/)]

2020-09-23 Thread Gustavo Barros

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: 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/)]

2020-09-21 Thread Gustavo Barros
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.




Bug: org-agenda-later scrolls buffer unnecessarily [9.4 (9.4-7-g3eccc5-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200921/)]

2020-09-21 Thread Gustavo Barros

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
 

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/)]

2020-09-21 Thread Gustavo Barros

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" 

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/)]

2020-09-21 Thread Gustavo Barros

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 

Re: "text mode" org mode

2020-09-15 Thread Gustavo Barros


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.



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/)]

2020-09-10 Thread Gustavo Barros

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: [Feature Request] More flexibility in org-speed-commands customization

2020-09-04 Thread Gustavo Barros

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: 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/)]

2020-09-04 Thread Gustavo Barros

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: 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/)]

2020-09-04 Thread Gustavo Barros
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: [Feature Request] More flexibility in org-speed-commands customization

2020-08-17 Thread Gustavo Barros

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.




[Feature Request] More flexibility in org-speed-commands customization

2020-08-03 Thread Gustavo Barros

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.



Bug: Org sentence commands and emphasis markers [9.3 (release_9.3 @ /usr/local/share/emacs/27.1/lisp/org/)]

2020-08-02 Thread Gustavo Barros

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 

Re: Repeating task hourly

2020-07-29 Thread Gustavo Barros



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.



Re: Repeating task hourly

2020-07-29 Thread Gustavo Barros

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

2020-07-29 Thread Gustavo Barros


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: 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/)]

2020-07-28 Thread Gustavo Barros
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.



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/)]

2020-07-27 Thread Gustavo Barros

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 

Re: [PATCH] Add mode for automatically unhiding emphasis markers in the current region

2020-07-06 Thread Gustavo Barros

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.




Re: [PATCH] Add mode for automatically unhiding emphasis markers in the current region

2020-07-05 Thread Gustavo Barros

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 

Re: [FR] Add check for attachments in org-lint

2020-06-28 Thread Gustavo Barros

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] ox: Prevent dispatcher from starting in scrolled window

2020-06-26 Thread Gustavo Barros

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: [PATCH] Add mode for automatically unhiding emphasis markers in the current region

2020-06-24 Thread Gustavo Barros

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] Add mode for automatically unhiding emphasis markers in the current region

2020-06-24 Thread Gustavo Barros

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

2020-06-22 Thread Gustavo Barros


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.



[FR] Add check for attachments in org-lint

2020-06-19 Thread Gustavo Barros

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: org-lint and org-attach DIR property

2020-06-12 Thread Gustavo Barros

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.



org-lint and org-attach DIR property

2020-06-12 Thread Gustavo Barros

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: A small idea to simplify (further) time input in the date/time prompt

2020-06-03 Thread Gustavo Barros

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



Re: A small idea to simplify (further) time input in the date/time prompt

2020-06-02 Thread Gustavo Barros



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

2020-06-02 Thread Gustavo Barros

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: 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/)]

2020-06-02 Thread Gustavo Barros

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-link :complete
org-attach-complete-link)
   ("id" :follow org-id-op

Re: A small idea to simplify (further) time input in the date/time prompt

2020-05-21 Thread Gustavo Barros

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: A small idea to simplify (further) time input in the date/time prompt

2020-05-21 Thread Gustavo Barros



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.



A small idea to simplify (further) time input in the date/time prompt

2020-05-21 Thread Gustavo Barros

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: 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/)]

2020-04-12 Thread Gustavo Barros

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.



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/)]

2020-04-09 Thread Gustavo Barros

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





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/)]

2020-02-28 Thread Gustavo Barros

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: 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/)]

2020-02-28 Thread Gustavo Barros

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 
":"]


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/)]

2020-02-16 Thread Gustavo Barros

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.



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/)]

2020-02-14 Thread Gustavo Barros

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/)]

2020-02-14 Thread Gustavo Barros

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/)]

2020-02-14 Thread Gustavo Barros

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/)]

2020-02-13 Thread Gustavo Barros

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/)]

2020-02-13 Thread Gustavo Barros

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/)]

2020-02-12 Thread Gustavo Barros

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/)]

2020-02-12 Thread Gustavo Barros

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: 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/)]

2020-02-05 Thread Gustavo Barros

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: 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/)]

2020-02-04 Thread Gustavo Barros

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: org-refile-target-verify-function - use inherited tag & todo

2019-11-02 Thread Gustavo Barros

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: org-refile-target-verify-function - use inherited tag & todo

2019-10-27 Thread Gustavo Barros
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  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.



  1   2   >