RE: attachment: link type export to HTML invalid attach dir

[Gustav Wikström]

Btw, the change 20d293b4a was done after a filed bug report. Maybe should be 
mentioned as well. The change was not something I just felt like doing just for 
the fun of it.

Regards
G

> -Original Message-
> From: Kyle Meyer 
> Sent: den 14 februari 2020 03:42
> To: Gustav Wikström ; Nicolas Goaziou
> 
> Cc: Bastien Guerry ; emacs-orgmode@gnu.org
> Subject: RE: attachment: link type export to HTML invalid attach dir
> 
> Gustav Wikström  writes:
> 
> >> Gustav Wikström  writes:
> >>
> >> > Ah, you mean the reference on line 3216. No, I don't think it can
> >> > be removed. And I honestly don't think it should be either. It's
> >> > there to let attachment links mirror the peculiarities of file
> >> > links. It's needed for feature compatibility. I don't see the
> issue with that.
> >> > It's a core link type and it needs the information. That
> particular
> >> > logic doesn't affect the parse tree. It's there only to give
> >> > attachment links the same properties as file links.
> >>
> >> I disagree. This is not a core link type. The issue is that the
> >> parser should self-contained. Please use a different way to obtain
> >> the information; we already discussed it and suggested multiple
> solutions.
> >
> > Maybe time for Bastien to step in. Because I can't remove the
> > reference to attachment in org-element.el without breaking it's
> > functionality. Which, btw, was broken before adding the reference in
> > org-element.el. The thing that started this discussion in the first
> > place. We're in a better place now.
> 
> It seems unfair to say you can't remove it because it would break
> functionality.  You committed 20d293b4a (Give link parser knowledge of
> attachment link expanded path, 2020-01-18) without posting it to the
> list [0] and giving Nicolas a chance to comment, which you've agreed
> was too hasty [1].  Misjudging the situation is of course okay, but
> please don't use that as a reason to keep a change that would not have
> landed if you had submitted it for discussion.
> 
> [0]: https://lists.gnu.org/archive/html/emacs-orgmode/2020-
> 01/msg00155.html
> [1]: https://lists.gnu.org/archive/html/emacs-orgmode/2020-
> 01/msg00162.html

RE: attachment: link type export to HTML invalid attach dir

[Gustav Wikström]

Hi,

> -Original Message-
> From: Kyle Meyer 
> Sent: den 14 februari 2020 03:42
> To: Gustav Wikström ; Nicolas Goaziou
> 
> Cc: Bastien Guerry ; emacs-orgmode@gnu.org
> Subject: RE: attachment: link type export to HTML invalid attach dir
> 
> Gustav Wikström  writes:
> 
> >> Gustav Wikström  writes:
> >>
> >> > Ah, you mean the reference on line 3216. No, I don't think it can
> >> > be removed. And I honestly don't think it should be either. It's
> >> > there to let attachment links mirror the peculiarities of file
> >> > links. It's needed for feature compatibility. I don't see the
> issue with that.
> >> > It's a core link type and it needs the information. That
> particular
> >> > logic doesn't affect the parse tree. It's there only to give
> >> > attachment links the same properties as file links.
> >>
> >> I disagree. This is not a core link type. The issue is that the
> >> parser should self-contained. Please use a different way to obtain
> >> the information; we already discussed it and suggested multiple
> solutions.
> >
> > Maybe time for Bastien to step in. Because I can't remove the
> > reference to attachment in org-element.el without breaking it's
> > functionality. Which, btw, was broken before adding the reference in
> > org-element.el. The thing that started this discussion in the first
> > place. We're in a better place now.
> 
> It seems unfair to say you can't remove it because it would break
> functionality.  You committed 20d293b4a (Give link parser knowledge of
> attachment link expanded path, 2020-01-18) without posting it to the
> list [0] and giving Nicolas a chance to comment, which you've agreed
> was too hasty [1].  Misjudging the situation is of course okay, but
> please don't use that as a reason to keep a change that would not have
> landed if you had submitted it for discussion.
> 
> [0]: https://lists.gnu.org/archive/html/emacs-orgmode/2020-
> 01/msg00155.html
> [1]: https://lists.gnu.org/archive/html/emacs-orgmode/2020-
> 01/msg00162.html

Just a short note before leaving for work. I'm not trying to strong-arm 
anything here. I'm just saying I don't think it's possible to remove the 
reference without breaking functionality. The changes discussed in [0] and [1] 
are in my opinion removed already. The reference to attachment we're talking 
about here is something else. This string reference is not a change in the 
design of org-element.el for links. The other was. And that's rolled back.

I'm sorry if this is perceived as disingenuous and being done with a bad 
agenda. It's not. It's a discussion about design. Yes, we disagree about some 
things. Nothing strange there. Let's talk it out and try to find the middle 
ground. Which is what's going on. I'll respect the direction given by the 
better Org moders out there. But in this case I'm simply stating that the 
principles that needs to apply according to Nicolas will either break 
attachment link functionality (it was broken before my change in 20d293b4a) or 
require quite some thinking and/or code duplication in org-attach.el to get it 
right. And I don't have the capacity for that redesign. Rolling back the change 
to a broken state is ofc. still possible, but that is more of a regression in 
my mind than the string-reference to attachment link types in org-element.el.

Which is why I think it's a decision for the maintainer of the project to step 
in and say if it's fine to have broken attachment links, or if it's fine to let 
attachment be used the way it is on line 3216 in org-element.el, while there is 
hard-coded logic for file links the way it is on that line today.

Regards
Gustav

RE: attachment: link type export to HTML invalid attach dir

[Gustav Wikström]

Hi,

> -Original Message-
> From: Nicolas Goaziou 
> Sent: den 14 februari 2020 01:16
> To: Gustav Wikström 
> Cc: emacs-orgmode@gnu.org; Bastien Guerry 
> Subject: Re: attachment: link type export to HTML invalid attach dir
> 
> Gustav Wikström  writes:
> 
> > What makes attachment links not be a core link type?
> 
> 1. Org Attach is not loaded by default
> 2. Implementing Org syntax doesn't require to implement attachments
> 
> Attachment links are in the same category as Docview links, for
> example.
> There is no "docview" occurrence in "org-element.el". We have been
> there already.
> 
> > As I see it we have two categories here: Core = those inside Org
> mode.
> > Not core = those in external libraries. No other distinction needs to
> > be made. If a link type is inside Org mode, let it then use the
> > special properties that Org mode provides.
> 
> Sure thing, but you use the wrong ones!

I meant that Core = inside the Org mode repository of source code files. Both 
Docview and Attachment is, both are mentioned in the manual as part of the 
system. Both should be able to use :search-option inside the Org element parser.

> > Attachment links need to be treated just as file links in most
> > regards. Since file-links have special logic which attachment links
> > also needs. Thus a reference to attachment in org-element.el. Nothing
> > strange here, nothing breaking and the parser is still self-
> contained.
> 
> Attachement links should live only in "org-attach.el": like 99% of
> other links do live in their own library. They do not require a special
> treatment.
> 
> Again, the parser is not self-contained if it references org-attach.el.

It doesn't referencen org-attach.el any longer. That reference is removed. What 
remains is a reference to the string "attachment". You may argue that even that 
is to much. And I can only agree with that vision if you also state that 
org-element shouldn't reference the string "file" either. Anything else is a 
subjective design that puts a sentiment on "more" or "less" importance of link 
types and how to regard if they're "important" enough to be mentioned. I don't 
think you want that in org-element any more than I do.

> > Maybe time for Bastien to step in. Because I can't remove the
> > reference to attachment in org-element.el without breaking it's
> > functionality. Which, btw, was broken before adding the reference in
> > org-element.el. The thing that started this discussion in the first
> > place. We're in a better place now.
> 
> We're not. The way it is implemented is not correct.

Functionally we are - we have working attachment links that are treated in the 
same way as file links through out Org mode. Since there is special treatment 
for file links in Org, attachment links needs the same special treatment to get 
the same behavior. You might see it as a regression in the design of 
org-element.el. To which I've already given arguments about why it's not really 
- and different ways it can be solved - by removing special file-related 
properties from org-element.el. The added string-reference to attachment links 
is there because special string-references to file links are there. If special 
file link references are removed, then clearly attachment links will/should be 
removed as well.

> For opening link, attachment links should use the :follow link
> parameter. The "following" function can extract the search option, if
> any, and the file name, then call `org-open-file' appropriately. You're
> doing it backwards and modify `org-open-file' instead. Additional links
> are not supposed to modify "ol.el".

Sure, that's a principle I can agree to. And have already mentioned that I will 
try to refactor that part by giving the :follow function the same abilities as 
org-open-file currently has. But that won't be completed quite yet.

> For exporting link, it should use the :export link parameter. The
> "exporting" function can extract the search option, if any, and the
> file name. It can then re-create a file link object, and call `org-
> export-data' on it. You're also doing it backwards here and prefer to
> modify each export back-end instead.

Which I've argued about already, saying it will be difficult without having 
file already being treated the same way. I'm not opposed to doing it that way 
in the long run. But let it be done for file links first, then attachment links 
can follow. I don't have the capacity to dig into this on my own.

> > Attachment links works as intended. It would be a pity to have to
> > change that because of your argument that attachment links aren't
> > "core" enough to be mentioned in org-element.el.
> 
> I strongly insist that it should be removed. I gave you ways to solve
> the issue. If you need anything else, let me know, but please consider
> implementing them.

In the end, I don't think I can roll back that change without breaking 
attachment links. For the reasons I've given below. I'm not trying to 
s

[SOLVED] Re: org-agenda clock table total time only for first clock time column

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Sorry for my misunderstanding. Today I re-check the org-agenda clock table. I
found It's correct. I read this style of display wrong. :)

Bastien  writes:

> stardiviner  writes:
>
>> Why the total clock time only calculated for first column clock task
>> time?
>
> I am not sure I understand the problem.
>
> If you really think there *is* a problem, can you give us an example
> file to reproduce it?


- -- 
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  
-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl5GOKgUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsMgyggAs/KWAv5U/ttkeaQQ3DQ+pNlTNrNx
Hg6+7VnLw+sTlvc/xX+HlvtMqrySEa0JROri1GGmzOpsMBcPFRpuXiV+Xfb65+Kp
PtKwv3llED7iFvMN/vcogS5n7TWPe2iMx6ZTzwOXJMOkqLeh/Z8JiV0vtNSNssVs
mxfDKXFeLztrsJUQjEVz9A4zg5IhRiTGlj2X+vNoYcqTWGKX0M6CbF/pm879K4Hz
P9xrTG/X5UjuhkbidEORi5OA5iCKX0Zi/5eZhdQ9GCnarXp8HDKDNSrHbAbfqi+U
E82ugBc7nHxckiYiLgMew+y4guOZ2BgMvl8fKBYlP4VBmeimIfEqwT4rbg==
=GrCm
-END PGP SIGNATURE-

Re: [PATCH] Re: ob-clojure.el: Add ClojureScript interface

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


About this patch, last night, I try to test ob-clojurescript eval with CIDER
connection. But no luck, the ClojureScript REPL connection always failed to
start. I have problem on CIDER. So I have a request that can you take a test.
Because on my side, ~(cider-current-connection "cljs")~ returns ~nil~ unable to
test. I think this patch should work. Just for confirm.

Thanks in advance.

Bastien  writes:

> Hi,
>
> stardiviner  writes:
>
>> And patches in attachments.
>
> Applied, thanks.
>
> I made some minor modifications:
>
> - I added the TINYCHANGE cookie in both messages
> - I replaced "ob-clojure.el: (...)" by "ob-clojure.el (...):"
>
> In general, try `C-x 4 a' on a change, either from magit or from
> the modified buffer: this will format a correct changelog entry.
>
> Also, users may need to figure out that ClojureScript src blocks
> need a proper environment to execute src blocks.  I.e. we should
> recommend users to have their .org file within a ClojureScript
> project -- I added something along these lines in the ORG-NEWS
> entry.
>
> If you want to contribute further, you'd need to sign the FSF
> papers: https://orgmode.org/request-assign-future.txt
>
> Thanks!


- -- 
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  
-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl5GLv4UHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsMkfAf/fFCfp91u8ZtK9VyVjlpf+tZ0wZzU
7d0OPcbnEtUZH/FkGyG2eFgXN/WBnf8O31ESj5EyXtnDGNZSa3Ia/cgmC7ZtCJRp
9w7YbwPnfM9EBq5qK7R+9i6fCEcua5i4Oszx4x1erWuksfGogCdKN6gwZJMYlH5y
lqdGQ0LCZMnTxDHn4mi8JuM2K0kaaIK4oJMJmCLu8+/X6lvTbLjGsTl08dew0Pbx
jMEkV/3FvtFNeS7MZIIrZedPgAhiS3o6IUj+hmngVpKdcabOZmBkV5IFgvMB77Us
SuSKs3Y9Y4hlWZyBMV2Twc4lKicnO31vGJm9MmFn4LCjI3Fd5O6LFEnL0A==
=GDMy
-END PGP SIGNATURE-

Automatic LaTeX preview toggling

[Ag Ibragimov]

I just recently discovered that this excellent code snippet that I found long 
time ago here:
http://slumpy.org/blog/2017-02-01-automatic-latex-preview-in-org-mode

which is based on even older post originally written by John Kitchin:

http://kitchingroup.cheme.cmu.edu/blog/2015/10/09/Automatic-latex-image-toggling-when-cursor-is-on-a-fragment/

unfortunately stopped working. I guess I missed it, at some point it seems 
org--list-latex-overlays function was removed.

Does anyone know if there's updated version of this thing somewhere? Or maybe 
this was extracted into some plugin or something that can be installed from 
MELPA maybe and I don't even know?

Re: [PATCH] Re: ob-clojure.el: Add ClojureScript interface

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Bastien  writes:

> Hi,
>
> stardiviner  writes:
>
>> And patches in attachments.
>
> Applied, thanks.

Great!

>
> I made some minor modifications:
>
> - I added the TINYCHANGE cookie in both messages
> - I replaced "ob-clojure.el: (...)" by "ob-clojure.el (...):"
>
> In general, try `C-x 4 a' on a change, either from magit or from
> the modified buffer: this will format a correct changelog entry.

A good advice tip. I will use it. Thanks.

>
> Also, users may need to figure out that ClojureScript src blocks
> need a proper environment to execute src blocks.  I.e. we should
> recommend users to have their .org file within a ClojureScript
> project -- I added something along these lines in the ORG-NEWS
> entry.
>
> If you want to contribute further, you'd need to sign the FSF
> papers: https://orgmode.org/request-assign-future.txt
>

I've already signed FSF papers before. Actually I contributed some patches 
already. :)

> Thanks!


- -- 
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  
-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl5GLL8UHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsOS7wf/XjDmlqgD0Us1RgDtarIXAfJDgIjy
+S8tEgeSHJSmPFSpifDyYSxAKwRGE1b5v/uUHcxECCana9k8iQ/T7VwFb6vY8XNY
NzpM1ZAErSNaOcFWOVH4yEoA8d6V/2Jir7p/SEblZid9HOC9zNpOzw4PxYr81/r5
Mof4/cQnwj1W6Z5MUqVj4rSotx3pBy1TqxCleGXj4EFsRBnJ6RMgvH+x3BYnLBAT
6zhle6hFrJtQGdiaH6YRHJ2ln52LTlozqnLCE2ROsp+ZDnS4lS5gp+2RIDnYPxq1
rszeDHWhAJcwmhPEikMzbmOGvy6X+nljVbLFJOzkFfsSkqFcam+onkLMzw==
=T3Qi
-END PGP SIGNATURE-

Re: [BUG] Infinite loop in org-agenda-show-new-time

[Andrew Hyatt]

I whittled this down to the smallest reproducible case, which I'm
attaching.  Hopefully should be clear upon viewing the file how to
reproduce.

I'm still unsure of the best solution, I'll have to think about this some
more - but at least the reproducible case will make it easier to debug into
this for anyone who wants to try.



On Tue, Feb 11, 2020 at 3:56 AM Bastien  wrote:

> Hi Matthew,
>
> not sure I replied to this one but in case I didn't, yes, my initial
> fix was wrong, I reverted it.
>
> Thanks!
>
> --
>  Bastien
>


repro.org
Description: Binary data

RE: attachment: link type export to HTML invalid attach dir

[Kyle Meyer]

Gustav Wikström  writes:

>> Gustav Wikström  writes:
>> 
>> > Ah, you mean the reference on line 3216. No, I don't think it can be
>> > removed. And I honestly don't think it should be either. It's there to
>> > let attachment links mirror the peculiarities of file links. It's
>> > needed for feature compatibility. I don't see the issue with that.
>> > It's a core link type and it needs the information. That particular
>> > logic doesn't affect the parse tree. It's there only to give
>> > attachment links the same properties as file links.
>> 
>> I disagree. This is not a core link type. The issue is that the parser
>> should self-contained. Please use a different way to obtain the
>> information; we already discussed it and suggested multiple solutions.
>
> Maybe time for Bastien to step in. Because I can't remove the
> reference to attachment in org-element.el without breaking it's
> functionality. Which, btw, was broken before adding the reference in
> org-element.el. The thing that started this discussion in the first
> place. We're in a better place now.

It seems unfair to say you can't remove it because it would break
functionality.  You committed 20d293b4a (Give link parser knowledge of
attachment link expanded path, 2020-01-18) without posting it to the
list [0] and giving Nicolas a chance to comment, which you've agreed was
too hasty [1].  Misjudging the situation is of course okay, but please
don't use that as a reason to keep a change that would not have landed
if you had submitted it for discussion.

[0]: https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00155.html
[1]: https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00162.html

Re: attachment: link type export to HTML invalid attach dir

[Nicolas Goaziou]

Gustav Wikström  writes:

> What makes attachment links not be a core link type? 

1. Org Attach is not loaded by default
2. Implementing Org syntax doesn't require to implement attachments

Attachment links are in the same category as Docview links, for example.
There is no "docview" occurrence in "org-element.el". We have been there
already.

> As I see it we have two categories here: Core = those inside Org mode.
> Not core = those in external libraries. No other distinction needs to
> be made. If a link type is inside Org mode, let it then use the
> special properties that Org mode provides.

Sure thing, but you use the wrong ones!

> Attachment links need to be treated just as file links in most
> regards. Since file-links have special logic which attachment links
> also needs. Thus a reference to attachment in org-element.el. Nothing
> strange here, nothing breaking and the parser is still self-contained.

Attachement links should live only in "org-attach.el": like 99% of other
links do live in their own library. They do not require a special
treatment.

Again, the parser is not self-contained if it references org-attach.el.

> Maybe time for Bastien to step in. Because I can't remove the
> reference to attachment in org-element.el without breaking it's
> functionality. Which, btw, was broken before adding the reference in
> org-element.el. The thing that started this discussion in the first
> place. We're in a better place now. 

We're not. The way it is implemented is not correct.

For opening link, attachment links should use the :follow link
parameter. The "following" function can extract the search option, if
any, and the file name, then call `org-open-file' appropriately. You're
doing it backwards and modify `org-open-file' instead. Additional links
are not supposed to modify "ol.el".

For exporting link, it should use the :export link parameter. The
"exporting" function can extract the search option, if any, and the file
name. It can then re-create a file link object, and call
`org-export-data' on it. You're also doing it backwards here and prefer
to modify each export back-end instead.

> Attachment links works as intended. It would be a pity to have to
> change that because of your argument that attachment links aren't
> "core" enough to be mentioned in org-element.el.

I strongly insist that it should be removed. I gave you ways to solve
the issue. If you need anything else, let me know, but please consider
implementing them.

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

[Samuel Wales]

again not sure if relevant and probably not, but it seemed to me that
the problem was related to something thinking that unix paths were
being completed, and directories were treated differently from
non-directories.  whatever i did fixed it.  took years to find and
fix.

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

[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: attachment: link type export to HTML invalid attach dir

[Gustav Wikström]

> -Original Message-
> From: Nicolas Goaziou 
> Sent: den 13 februari 2020 22:38
> To: Gustav Wikström 
> Cc: emacs-orgmode@gnu.org; Bastien Guerry 
> Subject: Re: attachment: link type export to HTML invalid attach dir
> 
> Gustav Wikström  writes:
> 
> > Ah, you mean the reference on line 3216. No, I don't think it can be
> > removed. And I honestly don't think it should be either. It's there to
> > let attachment links mirror the peculiarities of file links. It's
> > needed for feature compatibility. I don't see the issue with that.
> > It's a core link type and it needs the information. That particular
> > logic doesn't affect the parse tree. It's there only to give
> > attachment links the same properties as file links.
> 
> I disagree. This is not a core link type. The issue is that the parser
> should self-contained. Please use a different way to obtain the
> information; we already discussed it and suggested multiple solutions.

What makes attachment links not be a core link type? As I see it we have two 
categories here: Core = those inside Org mode. Not core = those in external 
libraries. No other distinction needs to be made. If a link type is inside Org 
mode, let it then use the special properties that Org mode provides. Attachment 
links need to be treated just as file links in most regards. Since file-links 
have special logic which attachment links also needs. Thus a reference to 
attachment in org-element.el. Nothing strange here, nothing breaking and the 
parser is still self-contained.

Maybe time for Bastien to step in. Because I can't remove the reference to 
attachment in org-element.el without breaking it's functionality. Which, btw, 
was broken before adding the reference in org-element.el. The thing that 
started this discussion in the first place. We're in a better place now. 
Attachment links works as intended. It would be a pity to have to change that 
because of your argument that attachment links aren't "core" enough to be 
mentioned in org-element.el.

Regards
Gustav

RE: [Help] Preparing for the release of Org 9.4 tomorrow

[Gustav Wikström]

Just for reference, this is answered in the parallel thread about attachment 
links.

/G

> -Original Message-
> From: Nicolas Goaziou 
> Sent: den 13 februari 2020 22:32
> To: Gustav Wikström 
> Cc: Bastien ; emacs-orgmode@gnu.org
> Subject: Re: [Help] Preparing for the release of Org 9.4 tomorrow
> 
> Hello,
> 
> Gustav Wikström  writes:
> 
> > This should be fixed since commit a24c8c481f though, no?
> >
> > https://code.orgmode.org/bzg/org-
> mode/commit/a24c8c481f63113215e66a70382d93cce82c9c7e
> 
> AFAICT, there still is an "attachment" mark in "org-element.el", at
> line 3216. Would that be an omission?
> 
> Regards,
> 
> --
> Nicolas Goaziou

RE: attachment: link type export to HTML invalid attach dir

[Gustav Wikström]

Continuation from previous answer,

> -Original Message-
> From: Nicolas Goaziou 
> Sent: den 13 februari 2020 21:41
> To: Gustav Wikström 
> Cc: emacs-orgmode@gnu.org; Bastien Guerry 
> Subject: Re: attachment: link type export to HTML invalid attach dir
> 
> [...]
> 
> > Given the above paragraph, the :path and :search-option property
> > doesn't make sense in the parser. :raw-link is enough. Less ambiguous
> > names for :path and :search-option would be :file-path
> > and :file-search-option. But that's sub-typing. We've already
> > concluded that that should not belong to the parser.
> 
> I don't have much time, I apologize if I'm not clear.
> 
> I disagree with you conclusion. Sub-typing is necessary in the parser.
> The `link' object is complex, so it needs categories or types. There are
> plain links, angle links, square links. In this last category, there are
> internal links, which include coderefs, fuzzy links, custom id, file
> links, and, "links with an explicit scheme part". For each of these
> categories, it is fine to have specific properties, like search-options.

Sure, that's not too far away from what I suggested in one of my first mails on 
the subject (except I took it a few steps too far maybe). Saying there are 
properties for categories of sub-types is fine but then this needs to be made 
much more explicit than today. 

> Note that this is sub-typing per syntax, not by meaning. This is what
> should not move, unless absolutely necessary. For example, attachment
> links belong to "square links with an explicit 'attachment' scheme
> part". That is all the parser needs to know.

That, and the way to extract the :search-options and :application from the 
link, as is done for file-links. Since attachment links would fit into your 
category of links that needs specific properties, like search-options.

> Now, it is true that [[file:...]] links are put in the same category as
> [[~/...]] links, for practical reasons, i.e., you wouldn't want them to
> differ in meaning. But this is a breach in the categories above.

Perfectly valid in my opinion. [[~/...]] is shorthand for [[file:~/...]] and, 
as long as documented as such, I see no breach. Only one such shorthand is 
possible anyways so not much ambiguity there.

> We might ignore the :search-option part in file links, but it's very
> easy to get, and, more importantly, we must extract the filename, so
> further parsing is necessary.

As you might have figured, I don't hold a very strong opinion on which design 
decision to take. I just want the choice to be based on principles and to be 
without ambiguities. If you say there are sub-types of links that require the 
:search-option, then fine, let it be so. But then we have to make it perfectly 
clear which particular types this applies to. And also make it clear that those 
special properties are only available for built-in types. I.e. to use them one 
have to get the new link-type into Org mode and into org-element.el.

> > I agree that option 1 is suboptimal. :search-option isn't obvious as
> > a property for all link types. Since option 3 is fairly trivial,
> > option 2 isn't necessary either. For attachment links to reuse
> > the :search-option semantics, without the hard-coding we're currently
> > doing, I see one option where attachment link higher order functions
> > could reuse file link higher order functions. Those file link higher
> > order functions don't exist yet as far as I know.
> 
> Higher order functions for what? `org-open-file' is such a higher order
> function for opening file links. There is no higher order function for
> exporting because each exporter handles file links differently. A higher
> order function for parsing doesn't mean much, since the consumer is not
> known yet.

Yes, each exporter handles file links differently. And I'm saying each exporter 
shouldn't handle file links at all. They should delegate that to the file 
exporter higher order function. In the same way that other link types are 
supposed to be dealt with. Principles.

> At this point, the best thing to do is to clarify what you need.
> I probably do not understand it.

I'm trying :) But it's not that /I need/ anything. It's rather the issue of how 
to solve the conundrum we're in. Where you say "attachment" links should work 
differently and not be hardcoded next to file links. And I'm saying it won't 
work unless we refactor how file-links are handled. And how we should have a 
principled approach to these kinds of things.

> > It might be seducing but I'm not sold. I'd rather have an
> > attachment-link exporter explicitly reuse functionality for exporting
> > file links than automatic translation. For that to be possible, there
> > first is a need for a file link exporter function.
> 
> I don't see how that would be possible, since it would be different for
> each back-end. Again, do you have a more precise idea about what it
> would do?

It would do exactly the same thing that o

Re: attachment: link type export to HTML invalid attach dir

[Nicolas Goaziou]

Gustav Wikström  writes:

> Ah, you mean the reference on line 3216. No, I don't think it can be
> removed. And I honestly don't think it should be either. It's there to
> let attachment links mirror the peculiarities of file links. It's
> needed for feature compatibility. I don't see the issue with that.
> It's a core link type and it needs the information. That particular
> logic doesn't affect the parse tree. It's there only to give
> attachment links the same properties as file links.

I disagree. This is not a core link type. The issue is that the parser
should self-contained. Please use a different way to obtain the
information; we already discussed it and suggested multiple solutions.

Re: [Help] Preparing for the release of Org 9.4 tomorrow

[Nicolas Goaziou]

Hello,

Gustav Wikström  writes:

> This should be fixed since commit a24c8c481f though, no?
>
> https://code.orgmode.org/bzg/org-mode/commit/a24c8c481f63113215e66a70382d93cce82c9c7e

AFAICT, there still is an "attachment" mark in "org-element.el", at
line 3216. Would that be an omission?

Regards,

-- 
Nicolas Goaziou

Custom image link types in LaTeX

[solomon theNinja]

There does not currently exist a (pretty, without huge advices) way to
create a custom link type, with a special export function, that would be
handled as an image on LaTeX exports.
By contrast, in HTML exports is possible by adding your custom link to
`org-html-inline-image-rules` - but in LaTeX, a link must either be custom
or image, and the figure-wrapping function `org-latex--inline-image`
doesn't handle custom links; its not possible without modifying these
functions
Is this the intended behavior? If so, why?

I'll be happy to implement exporting custom image links myself, given time,
if that's the issue.

- If it was not clear, in "custom links" I'm referring to links defined
with `org-link-set-parameters` that have a special export behavior.

RE: attachment: link type export to HTML invalid attach dir

[Gustav Wikström]

Hi,

Partial answer for now;

> -Original Message-
> From: Nicolas Goaziou 
> Sent: den 13 februari 2020 21:41
> To: Gustav Wikström 
> Cc: emacs-orgmode@gnu.org; Bastien Guerry 
> Subject: Re: attachment: link type export to HTML invalid attach dir
>
> [...]
>
> There is an "attachement" reference left in "org-element.el" at the
> moment. Can it be removed safely?

Ah, you mean the reference on line 3216. No, I don't think it can be removed. 
And I honestly don't think it should be either. It's there to let attachment 
links mirror the peculiarities of file links. It's needed for feature 
compatibility. I don't see the issue with that. It's a core link type and it 
needs the information. That particular logic doesn't affect the parse tree. 
It's there only to give attachment links the same properties as file links.

> I'm Cc'ing Bastien because that particular point should be solved
> before any release, IMO.
> 
> Regards,
> 
> --
> Nicolas Goaziou

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

[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: attachment: link type export to HTML invalid attach dir

[Nicolas Goaziou]

Hello,

Gustav Wikström  writes:

> Unless search-option applies as a general construct for all link types
> I don't think it should be in the parser. Given the discussion we've
> had about design of the parser from before. I.e. if the parser isn't
> supposed to know anything about the specific types themselves, all
> properties of the parsed elements have to make sense for all types of
> links. So either search-option remains but is parsed in exactly the
> same way for all link types, or it's not there at all. And if it's not
> available in the parser, the file link interpreters (that still might
> need to be constructed) gets to parse the :search-option from the
> raw-link as it wishes itself.
>
> Given the above paragraph, the :path and :search-option property
> doesn't make sense in the parser. :raw-link is enough. Less ambiguous
> names for :path and :search-option would be :file-path
> and :file-search-option. But that's sub-typing. We've already
> concluded that that should not belong to the parser.

I don't have much time, I apologize if I'm not clear.

I disagree with you conclusion. Sub-typing is necessary in the parser.
The `link' object is complex, so it needs categories or types. There are
plain links, angle links, square links. In this last category, there are
internal links, which include coderefs, fuzzy links, custom id, file
links, and, "links with an explicit scheme part". For each of these
categories, it is fine to have specific properties, like search-options.

Note that this is sub-typing per syntax, not by meaning. This is what
should not move, unless absolutely necessary. For example, attachment
links belong to "square links with an explicit 'attachment' scheme
part". That is all the parser needs to know.

Now, it is true that [[file:...]] links are put in the same category as
[[~/...]] links, for practical reasons, i.e., you wouldn't want them to
differ in meaning. But this is a breach in the categories above.

We might ignore the :search-option part in file links, but it's very
easy to get, and, more importantly, we must extract the filename, so
further parsing is necessary.

> I agree that option 1 is suboptimal. :search-option isn't obvious as
> a property for all link types. Since option 3 is fairly trivial,
> option 2 isn't necessary either. For attachment links to reuse
> the :search-option semantics, without the hard-coding we're currently
> doing, I see one option where attachment link higher order functions
> could reuse file link higher order functions. Those file link higher
> order functions don't exist yet as far as I know.

Higher order functions for what? `org-open-file' is such a higher order
function for opening file links. There is no higher order function for
exporting because each exporter handles file links differently. A higher
order function for parsing doesn't mean much, since the consumer is not
known yet.

At this point, the best thing to do is to clarify what you need.
I probably do not understand it.

> True that. There is a balance to strike. Maybe it's time to pull in
> the org element document into the manual? I vote for that at least.

I have no strong opinion on that. It may fit into an appendix, indeed,
or even as a section in first appendix: "Hacking", e.g. "Using the
Parser API".

> Ok, sure. Let the syntax be as rigid as possible, and let
> extensibility to that be dealt with in auxiliary parsing/interpreting
> functions. I guess that would be the approach, put in different words.
> Still correct?

It seems correct.

> It might be seducing but I'm not sold. I'd rather have an
> attachment-link exporter explicitly reuse functionality for exporting
> file links than automatic translation. For that to be possible, there
> first is a need for a file link exporter function.

I don't see how that would be possible, since it would be different for
each back-end. Again, do you have a more precise idea about what it
would do?

> And the current implementation (since the patch) is good enough imo,
> for now, and until anyone of us does some file link refactoring.

There is an "attachement" reference left in "org-element.el" at the
moment. Can it be removed safely?

I'm Cc'ing Bastien because that particular point should be solved before
any release, IMO.

Regards,

-- 
Nicolas Goaziou

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

[Samuel Wales]

dunno if this is useful (probably not), but i found the following was
necessary to fix ido.  i didn't really understand it, but it fixed it.

Date:   2014-05-19 19:57:44 -0700

=== remove the parens from ido completion of olpaths

Modified lisp/org.el
diff --git a/lisp/org.el b/lisp/org.el
index 69a288add..b2d8ec755 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11942,7 +11942,7 @@ this function appends the default value from
 (tbl (mapcar
   (lambda (x)
 (if (and (not (member org-refile-use-outline-path
-  '(file full-file-path)))
+  '(nil file full-file-path)))
  (not (equal filename (nth 1 x
 (cons (concat (car x) extra " ("
   (file-name-nondirectory (nth 1 x)) ")")



-- 
The Kafka Pandemic

What is misopathy?
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: Possible to exclude/include tags for agenda custom commands?

[Stig Brautaset]

Hi Bastien,

Bastien  writes:
>> I can easily do this in the list of TODOs, with a tag search. However, I
>> haven't figured out how to do this for the agenda. Is it possible? If
>> so, how?
>
> From what I understand, check `org-agenda-tag-filter' to see how to
> use it within an agenda custom command.

Thank you! That did indeed do it. 

FWIW my stanza looks like this now:

(setq org-agenda-custom-commands
 '(("w" "Work Agenda"
((agenda "" ((org-agenda-span 'day)))
 (todo "TODO"
   ((org-agenda-max-entries 5)
(org-agenda-todo-ignore-scheduled 'all)
(org-agenda-todo-ignore-deadlines 'all)
(org-agenda-todo-ignore-timestamp 'all
((org-agenda-tag-filter '("-@home" "-MAYBE"
   ("h" "Home Agenda"
((agenda "")
 (todo "TODO"
   ((org-agenda-max-entries 5)
(org-agenda-todo-ignore-scheduled 'all)
(org-agenda-todo-ignore-deadlines 'all)
(org-agenda-todo-ignore-timestamp 'all
((org-agenda-tag-filter '("-@work" "-MAYBE"
   ("m" "Maybe"
((todo "PROJ")
 (tags-todo "-PROJ/TODO"))
((org-agenda-tag-filter '("MAYBE"
   ("P" "Projects" tags-todo "-MAYBE/PROJ"
   
Stig

Re: [PATCH] Respect buffer-local value of `org-edit-src-content-indentation'

[Sebastian Miele]

Sebastian Miele  writes:

> Bastien  writes:
> >
> > Sebastian Miele  writes:
> >
> > > I am quite certain, that the content indentation conceptually and
> > > technically belongs to the buffer containing the src block.
> >
> > Sorry, I think I got confused - let's call buffer-A the one with the
> > "#+begin_src ... #+end_src" string and buffer-B the one you get when
> > C-c ' on this string (the src block).
> >
> > If "the buffer containing the src block" is buffer A, then we are on
> > the same line.  Is it the case?  Or am I still confused?
>
> Yes, we are on the same line.

Part of me feels that I should find a better explanation and spare you
the trouble of figuring out what I mean. But there seems to be no
(significantly) better explanation I can come up with without going to
greater lengths and especially investing considerable time for working
out very clear terminology for the situation.

I currently feel a tension between not wanting you to have to spend
considerable time understanding what I wrote and not wanting myself to
spend time to try to explain it better.

However, if it is necessary, I will take the time.

Please try having it in the back of your mind for some days, maybe even
without actively spending much time on trying to understand it. Then
tell me if struck or not.

All the best
Sebastian

Re: [Help] Preparing for the release of Org 9.4 tomorrow

[Gustav Wikström]

Hi,

This should be fixed since commit a24c8c481f though, no?

https://code.orgmode.org/bzg/org-mode/commit/a24c8c481f63113215e66a70382d93cce82c9c7e

Regards Gustav

Get Outlook for Android


From: Emacs-orgmode  on behalf of 
Nicolas Goaziou 
Sent: Thursday, February 13, 2020 11:46:31 AM
To: Bastien 
Cc: emacs-orgmode@gnu.org 
Subject: Re: [Help] Preparing for the release of Org 9.4 tomorrow

Hello,

Bastien  writes:

> I would like to release Org 9.4 tomorrow, during the "I love Free
> Software Day 2020" campaign: https://fsfe.org/campaigns/ilovefs/
>
> Can you all (re)submit blocking bugs and issues?

Please don't as long as "org-element.el" retain references to attachment
links.

Regards,

--
Nicolas Goaziou

Re: [PATCH] ox.el: Fix extra character deleted in org-export--update-included-link

[Adam Porter]

Dear Nicolas and Bastien,

I feel like a child whose parents are fighting.  :)  If I may speak for
other Org users: you're invaluable to us, and we look up to you.  Please
don't let the deficiencies inherent in online, textual communication
cause deterioration in your fellowship.

With gratitude for all your contributions,
Adam

Re: Provide org-insert-subitem

[Adam Porter]

Bastien  writes:

> First of all, don't be afraid, I don't have a grand plan for "cleaning
> up" things.

Don't worry, I trust you.  :)  Org wouldn't be what it is today without
your work, and I'm grateful for how much time you've been putting into
improving Org lately.

>> I'm not sure what you mean about functions mentioned as usable by the
>> user.  org-insert-subheading is an interactive command, so it's
>> explicitly usable by the user.
>
> Yes, org-insert-subheading is interactive and usable and in Org's core
> but how can a user *discover* this command?
>
> There is no keybinding for it and no mention in the manual.  Even as a
> function, it is not even used in Org codebase.
>
> The ways I can see for a user to discover this command is by trying to
> complete M-x org-insert TAB or by reading Org's code (or other code in
> the wild using it.)

I guess what happened here is that I found that command years ago,
probably from either reading someone else's config online or, as you
say, using completion (I discover so many things using Helm
completion--I'm constantly using "C-h f org-" when working on
Org-related code).  Then I bound it to S-RET in my config, and I've been
using it ever since.  To me it feels like just as much a part of Org as
any other Org command.

> So to me it's a "utility" command: something that Org does not depend
> on, something that provides a useful feature, but not useful enough to
> have a keybinding in Org's core or to be used as a function in Org's
> core.

What if we document it in the manual?  For example, in section 2.5,
"Structure editing", we have:

`M-' (`org-insert-heading')
 Insert a new heading/item with the same level as the one at point.

`C-' (`org-insert-heading-respect-content')
 Insert a new heading at the end of the current subtree.  

`M-S-' (`org-insert-todo-heading')
 Insert new TODO entry with same level as current heading.  See
 also the variable `org-treat-insert-todo-heading-as-state-change'.  

`C-S-' (`org-insert-todo-heading-respect-content')
 Insert new TODO entry with same level as current heading.  Like
 `C-', the new headline will be inserted after the current
 subtree.  

What if we add:

`S-' (`org-insert-subheading')
 Insert a new subheading and demote it.
 Works for outline headings and for plain lists alike.

Note that I also propose binding it to S-.  It seems that, by
default, that key is currently bound in Org buffers to
org-table-copy-down:

Copy the value of the current field one row below.

That's surely a useful function, but I feel like it probably isn't
widely used enough to deserve to be bound to S- in all contexts.
Of course, frequent users of this command, feel free to correct me, lest
I be a hypocrite.  ;)

If that seems agreeable, then I'd also propose renaming the command
(preserving its old name in an alias, of course) to something which
would not imply that it only works in outlines, perhaps
org-insert-subitem or org-insert-demoted.

In the longer term , perhaps we could make a new, contextual command
that would call one command in tables and another command in non-table
contexts.  If there were a clever way we could make similar, roughly
corresponding actions in both tables and tree structures use the same
bindings contextually, that might be useful.  I think it would be
reasonable, because if point is in a table, the user probably won't want
to insert a new outline heading in the middle of it.

What do you think?  Thanks.

Re: Bug: Symlink handling in org-babel-load-file

[ricky saurav]

Hey Bastien,
After this patch, org-mode loads the most updated config. A minor issue
that I have is that this patch creates config.el in my dotfiles directory,
instead of ~/.emacs.d/config.el ,since ~/.emacs.d/config.org is a symlink
to ~/dotfiles/config.org. The behaviour in org-9.1.5(emacs 26.3), was
resolution of symlinks for just fetching the file
attributes(file-modification-time). The below patch summarizes the changes
that would keep the current version in line with current version in emacs
release  org-9.1.5(emacs 26.3).
Regards,
Saurav

On Wed, 12 Feb 2020 at 17:40, Bastien  wrote:

> Hi Ricky,
>
> thanks for reporting this.
>
> Can you try this patch and confirm it solves your issue?
>
>
> --
>  Bastien
>
diff --git a/lisp/org.el b/lisp/org.el
index 1a995cc40..239e3528f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -218,12 +218,11 @@ and then loads the resulting file using `load-file'.  With
 optional prefix argument COMPILE, the tangled Emacs Lisp file is
 byte-compiled before it is loaded."
   (interactive "fFile to load: \nP")
-  (let* ((file (file-truename file))
-	 (tangled-file (concat (file-name-sans-extension file) ".el")))
+  (let* ((tangled-file (concat (file-name-sans-extension file) ".el")))
 ;; Tangle only if the Org file is newer than the Elisp file.
 (unless (org-file-newer-than-p
 	 tangled-file
-	 (file-attribute-modification-time (file-attributes file)))
+	 (file-attribute-modification-time (file-attributes (file-truename file
   (org-babel-tangle-file file tangled-file "emacs-lisp\\|elisp"))
 (if compile
 	(progn

bug#38592: 27.0.50; org mode insinuates itself into calendar

[Sam Steingold]

Hi Bastien,

If you tell me what to do, I would gladly do it.
I am afraid I am too busy to investigate it myself...
sorry

On Thu, 13 Feb 2020 at 10:41, Bastien  wrote:
>
> Hi Sam,
>
> Sam Steingold  writes:
>
> > Yes, I still have to (remove-hook 'calendar-mode-hook
> > 'org--setup-calendar-bindings) manually
>
> The hook is not added until Org is loaded -- can you track down
> why org-mode gets loaded?
>
> --
>  Bastien



-- 
Sam Steingold  

Re: [PATCH] Re: ob-clojure.el: Add ClojureScript interface

[Bastien]

Hi,

stardiviner  writes:

> And patches in attachments.

Applied, thanks.

I made some minor modifications:

- I added the TINYCHANGE cookie in both messages
- I replaced "ob-clojure.el: (...)" by "ob-clojure.el (...):"

In general, try `C-x 4 a' on a change, either from magit or from
the modified buffer: this will format a correct changelog entry.

Also, users may need to figure out that ClojureScript src blocks
need a proper environment to execute src blocks.  I.e. we should
recommend users to have their .org file within a ClojureScript
project -- I added something along these lines in the ORG-NEWS
entry.

If you want to contribute further, you'd need to sign the FSF
papers: https://orgmode.org/request-assign-future.txt

Thanks!

-- 
 Bastien

bug#38592: 27.0.50; org mode insinuates itself into calendar

[Bastien]

Hi Sam,

Sam Steingold  writes:

> Yes, I still have to (remove-hook 'calendar-mode-hook
> 'org--setup-calendar-bindings) manually

The hook is not added until Org is loaded -- can you track down
why org-mode gets loaded?

-- 
 Bastien

bug#38592: 27.0.50; org mode insinuates itself into calendar

[Sam Steingold]

Yes, I still have to (remove-hook 'calendar-mode-hook
'org--setup-calendar-bindings) manually

On Thu, 13 Feb 2020 at 03:43, Bastien  wrote:
>
> Eli Zaretskii  writes:
>
> > So I think you should report this to Org developers first, because it
> > sounds like an Org bug.
>
> I suspect org-compat.el was loaded by some lingering installation of Org.
>
> Sam, do you still get this bug?
>
> --
>  Bastien



-- 
Sam Steingold  

Re: specify time of day for org-resolve-clocks, not number of minutes

[Bastien]

Hi Dan,

Dan Drake  writes:

> I like the idea of using g/G and intelligently interpreting the
> user's response -- it's good UI / UX design. (Imagine asking a friend
> when they "got back" -- both "20 minutes ago" and "8:35" are
> unambiguous answers to the question.)

Yes.

> Now we need to decide how to distinguish the two. Would it work to
> just examine the user input for a colon and branch based on that?

You can use `read-string' and try to match either a wholenumberp (as
"[0-9]\+") or a time spec (as "[0-9]\+:[0-9]\\{2\\}").

I don't think we need to trigger the calendar: relying on (concat
(format-time-string "%F " last-valid) time) is good enough.

No need to support am/pm notation either, as long as we advertize the
need to enter HH:MM time.

We shall support this for both k/K ("keep") and g/K ("got back"),
don't you think so?

> I'll see if I can get this working.

Thanks a lot!  Since this is a new feature, I'd like to polish it
before Org 9.4 (which I initially planned for tomorrow, but I will
adapt.)

-- 
 Bastien

Re: specify time of day for org-resolve-clocks, not number of minutes

[Dan Drake]

I like the idea of using g/G and intelligently interpreting the user's
response -- it's good UI / UX design. (Imagine asking a friend when they
"got back" -- both "20 minutes ago" and "8:35" are unambiguous answers to
the question.)

Now we need to decide how to distinguish the two. Would it work to just
examine the user input for a colon and branch based on that? I'll see if I
can get this working.

On Thu, Feb 13, 2020 at 1:16 AM Bastien  wrote:

> Hi Kyle and Dan,
>
> Kyle Meyer  writes:
>
> > Thanks, though sadly Dan had already taken the time to follow up with a
> > patch:
> >
> >   https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00175.html
>
> Err, my bad, sorry Dan -- and thanks Kyle for the warning.
>
> (I too hastily assume 1 thread = 1 topic, I should have checked.)
>
> I reverted my changes and pushed Dan's commit to master.
>
> I took the liberty of inlining the function and making the message a
> bit more explicit.  Dan, let me know if that's okay.
>
> Interestingly, our (different and complementary) implementations may
> lead to a new idea: your implementation is like the `k' option while
> mine is like the `g' option (when you "got back").  I guess both can
> make sense, and what the user expect is to be able to enter a number
> of minutes *or* a HH:MM time spec in both `t' and `g'.
>
> That would also have the advantage of having less options while still
> having the possibility to use HH:MM.  (Also, using org-read-date here
> seems a bit too much here, but maybe that's okay.)
>
> Dan, what do you think?  Would you like to try implementing this or
> can I give it a try?
>
> Thanks,
>
> --
>  Bastien
>


-- 
Ceci n'est pas une .signature.

Re: [Help] Preparing for the release of Org 9.4 tomorrow

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> Please don't as long as "org-element.el" retain references to
> attachment links.

Okay.  If you have time, can you explain what is at stake here?

Is there something I can help with?

Thanks in advance!

-- 
 Bastien

Re: [PATCH] ox.el: Fix extra character deleted in org-export--update-included-link

[Bastien]

Hi Nicolas,

I'm glad I replied to your email because...

Nicolas Goaziou  writes:

> Last time we disagreed, you grossly concluded with:
>
>Future maintainers may of course interpret the recommendations of the
>FSF differently, but that's mine for now.
>
> As far as my understanding permits, this means: "I'm am the one in
> charge. I know what I'm doing. Discussion closed. Next."

... we are clearly miscommunicating here.

When I said:

 Future maintainers may of course interpret the recommendations of
 the FSF differently, but that's mine for now.

I just really meant what I said: future maintainer(s) can decide what
is the best interpretation of "15 lines of (significant) changes", but
since I'm the one responsible for handling copyright stuff for Org, I
ask you and co-maintainers to act as if my interpretation were true.

I didn't even imagine my statement could be rude, but I know see how
it can be perceived as rude, given the context.  Sorry for that.

> I find this stance dubious, whatever the subject is, or if you are right
> or wrong. To make my point go through, I'm now pushing it up to the
> absurd. My intent is to warn, not to hurt.

It did hurt, as sarcasm always does somehow.

> I also believe that lecturing others about communication on mailing
> lists, or social behaviour in general, is not helpful either. Unless, of
> course, you think being patronizing is more acceptable here than being
> ironic. I hope you don't.

I don't.

I did not want to "lecture" or to "patronize", but I wanted to express
my feelings and listen to what I may have done wrong.

On a more general topic, I hope you don't disagree with the addition
of the GNU kind communication guidelines that I recently mentioned in
the manual.

-- 
 Bastien

Re: [Help] Preparing for the release of Org 9.4 tomorrow

[Nicolas Goaziou]

Hello,

Bastien  writes:

> I would like to release Org 9.4 tomorrow, during the "I love Free
> Software Day 2020" campaign: https://fsfe.org/campaigns/ilovefs/
>
> Can you all (re)submit blocking bugs and issues?

Please don't as long as "org-element.el" retain references to attachment
links.

Regards,

-- 
Nicolas Goaziou

Re: Multiply alerts for icalendar export

[Mikhail Skorzhinskii]

Fraga, Eric  writes:
> Noting, of course, that you can have multiple time stamps (active ones
> in this case) associated with a single heading.  I do this every so
> often.

Although it would be wonderful thing to have, but it does not affect
exported icalendar file. I was expecting that multiply time stamps will
result into multiply icalendar entries with different times, but instead
I got two entries with bottom time.

I.e. this:

#+begin_example
,* some entry
SCHEDULED: <2020-02-13 Thu 07:30>
SCHEDULED: <2020-02-13 Thu 07:20>
#+end_example

Will result into two icalendar entries:

1. some entry with time 07:20
2. some entry with time 07:20

Bastien  writes:
> Perhaps adding three different appointments to get three alerts is
> good enough?
>
> 2 cents of course...

Yes, I resolved this by having sub-headings with the reminders. This way
I liked it even more then just casually having multiply reminders.

1. I can name each reminder individually. This way it takes no effort to
undetrstand what this alarm is about.

2. Every heading can carry individual notes. And since these reminders
are time dependent, notes that are really relevant right now are more
accessible.

This is especially valuable when you're in hurry and don't have much
time to go through your notes. Just tap to the calendar entry and carry
on.

3. Since calendars are stored locally, you don't need internet to have
all this information and to recieve these reminders. (This is complain
about some city commuting applications and the way how push
notifications work).

4. For events that are often recurring this function is very helpful:
~(org-clone-subtree-with-time-shift)~ (aka ~C-c C-x c~). It fixes times
not only on top-most heading but in all sub-headings as well.

And unlike recurring timestamps, this way every event can have some
slight differences for this specific day: changes in time table,
location or even complete cancelation.

Here is an example for the reference. I'm trying to show most of the
possibilties of this approach.

#+begin_example
,* Flight to Wonderland :transport:
SCHEDULED: <2020-02-13 Thu 10:00-12:30>

Terminal 2

Bookin code: AABBCC

,** Train to airport

,*** Route S9
SCHEDULED: <2020-02-13 Thu 06:50>
,*** Route S9
SCHEDULED: <2020-02-13 Thu 07:10>

,** Bus to train station

,*** Bus 512 [bus stop: Fluffy road]
SCHEDULED: <2020-02-13 Thu 06:30>

,*** Bus 1024 [bus stop: Cozy park]
SCHEDULED: <2020-02-13 Thu 06:45>

,** Taxi from airport
SCHEDULED: <2020-02-13 Thu 12:30-13:30>
;; :LOCATION: will be exported as a special field and you can later click and 
choose which app to use: maps \ taxi app \ public transport app \ etc
:PROPERTIES:
:LOCATION: Кримс, Замок Красной Королевы, 12, кв. 7
:END:

Should be around 20€ \ 1400₽

Crims, Fortress of the Red Queen, 12, apt. 7

,** Lecture
SCHEDULED: <2020-02-13 Thu 14:00-17:00>
;; Phone numbers usually can be also clicked in most apps. Helpful if you don't 
want to pollute your phone book
Prof. Fortran 

Room 404
#+end_example

Re: [PATCH] ox.el: Fix extra character deleted in org-export--update-included-link

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Nicolas Goaziou  writes:
>
>> How would I dare to have an opinion m'lord? Only yours matters.
>
> Such sarcastic remarks hurt.

Indeed! But I eventually overcame the pain. Thank you for caring! :)

Last time we disagreed, you grossly concluded with:

   Future maintainers may of course interpret the recommendations of the
   FSF differently, but that's mine for now.

As far as my understanding permits, this means: "I'm am the one in
charge. I know what I'm doing. Discussion closed. Next."

I find this stance dubious, whatever the subject is, or if you are right
or wrong. To make my point go through, I'm now pushing it up to the
absurd. My intent is to warn, not to hurt.

> I may have done something (or worse, many things!) that frustrate you
> somehow, but using irony is not a good way to communicate on mailing
> lists.  

I know that is not a good way to communicate.

I also believe that lecturing others about communication on mailing
lists, or social behaviour in general, is not helpful either. Unless, of
course, you think being patronizing is more acceptable here than being
ironic. I hope you don't.

Regards,

-- 
Nicolas Goaziou

bug#38592: 27.0.50; org mode insinuates itself into calendar

[Bastien]

Eli Zaretskii  writes:

> So I think you should report this to Org developers first, because it
> sounds like an Org bug.

I suspect org-compat.el was loaded by some lingering installation of Org.

Sam, do you still get this bug?

-- 
 Bastien

[Help] Preparing for the release of Org 9.4 tomorrow

[Bastien]

Hi all,

I would like to release Org 9.4 tomorrow, during the "I love Free
Software Day 2020" campaign: https://fsfe.org/campaigns/ilovefs/

Can you all (re)submit blocking bugs and issues?

Thanks!

-- 
 Bastien

Org 9.3.6

[Bastien]

Hi all,

I've released Org 9.3.6, a bugfix release.

Enjoy!

-- 
 Bastien

Re: [PATCH] ox.el: Fix extra character deleted in org-export--update-included-link

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> How would I dare to have an opinion m'lord? Only yours matters.

Such sarcastic remarks hurt.

I may have done something (or worse, many things!) that frustrate you
somehow, but using irony is not a good way to communicate on mailing
lists.  Simply tell me directly what wrong I've done so we can discuss
it (in private if you prefer).

But please: we're all on the same boat contributing with our free time
on sharing good stuff, no need to hurt each others.

> I pushed a fix, with a test. I let you check if the issue is resolved on
> your side, and close the bug report if appropriate.

Thanks for fixing this.

-- 
 Bastien

Re: Provide org-insert-subitem

[Bastien]

Hi Adam,

First of all, don't be afraid, I don't have a grand plan for "cleaning
up" things.

> I'm not sure what you mean about functions mentioned as usable by the
> user.  org-insert-subheading is an interactive command, so it's
> explicitly usable by the user.

Yes, org-insert-subheading is interactive and usable and in Org's core
but how can a user *discover* this command?

There is no keybinding for it and no mention in the manual.  Even as a
function, it is not even used in Org codebase.

The ways I can see for a user to discover this command is by trying to
complete M-x org-insert TAB or by reading Org's code (or other code in
the wild using it.)

So to me it's a "utility" command: something that Org does not depend
on, something that provides a useful feature, but not useful enough to
have a keybinding in Org's core or to be used as a function in Org's
core.

> And it's in org.el, so it's in Org's
> "core", right?  I guess we're thinking in different terms.

Well, my thinking is not about core vs not-core, it is more on how to
advertize such commands and functions.  I would recommand putting them
in org-utils.el but I'm not sure.  And yes, I'm not entirely convinced
such a library, if it existed, should live in Org's core :)

Best,

-- 
 Bastien