Re: [O] [PATCH] contrib/lisp/ox-confluence.el: Export checkboxes; fix timestamps in headlines

[Marc Ihm]

Hi, 

Nicolas Goaziou  writes:

>
> This is a common mistake. Symbols in `cl-case' shouldn't be quoted. 'on
> is really (quote on), so you actually wrote
>
>   (cl-case (org-element-property :checkbox item)
> ((quote on) "*{{(X)}}* ")
> ((quote off) "*{{( )}}* ")
> ((quote trans) "*{{(\\-)}}* "))
>
> which is not what you want:
>
>   (cl-case 'quote ('a 1) ('quote 2) (t 3))=> 1
>
> This is why I prefer `pcase' over `cl-case'.
>

Interesting (and the docstring of `pcase') !

>>  (format "h%s. %s%s\n%s" level todo-text text
>>  (if (org-string-nw-p contents) contents ""
>>  
>> @@ -181,7 +184,7 @@ a communication channel."
>>  (defun org-confluence-timestamp (timestamp _contents _info)
>>"Transcode a TIMESTAMP object from Org to Confluence.
>>  CONTENTS and INFO are ignored."
>> -  (let ((translated (org-timestamp-translate timestamp)))
>> +  (let ((translated (org-trim (org-timestamp-translate timestamp
>
> I'm not sure what this is supposed to fix. Does
> `org-timestamp-translate' return a string with leading or trailing
> blanks?

Yes, it did return trailing blanks for me.

> Anyway, I applied the patch in master branch, with the fix suggested
> above.
>
> Regards,

Thanx !

Re: [O] Modification to `org-attach' allowing attaching from URL

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Wojciech Gac  writes:
>
>> I'm attaching a patch with a note in ORG-NEWS.
>
> Applied. Thank you.

Hey I am running org-plus-contrib from the package repos, and I still
haven't seen this patch come down. Is it in the pipeline somewhere? I'd
really like to use this!

Eric

[O] 9.0.6 and clock tables

[Eric S Fraga]

Hello all,

Just a quick note: I upgraded to v9.0.6 and my clock table reports no
longer show %age time spend on each activity.  I've not had a chance to
debug this yet but clock tables generated earlier today had percentages
where I wanted them.

I'll debug tomorrow but I thought I'd bring this up now just in case
anybody else runs into this problem.

thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50, Org release_9.0.6-404-gcbe544


signature.asc
Description: PGP signature

Re: [O] More clocktable breakage

[Achim Gratz]

Nicolas Goaziou writes:
>> I'd say anything org-element-* should exclusively return syntactical
>> things.  Context dependence needs to be dealt with elsewhere.
>
> I'm not sure to understand this. Syntactical things are all about
> context dependence in Org. Do you mean /context independance/ needs to
> be dealt with elsewhere?

No, I meant context of application, rather than context in the
syntactical sense.  Org-element-* deals with syntax, nothing else.
Whether you need strict syntactical interpretation or something else
gets decided someplace else.

> Could you provide examples about that? In particular "providing
> timestamps as arguments to any processing functions" sounds odd, in
> particular from someone who cringes when I suggest to add a second
> optional argument to a single function.

Whatever it sounds like, what you want in the clocktables example and
the properties example (and elsewhere) is something that looks, walks
and talks like a timestamp if you'd put it into the proper context.  In
each of these places the text that looks like timestamp but isn't
(org-element says so) will be fed into some machinery that emerges with
a result that is indistinguishable from what you'd get if that text
would have been a proper timestamp and then uses that result to do
whatever it wants to do with it (i.e. most certainly not build up an
agenda, although it could do that as well).  It uses a bit of Org syntax
in the improper context to achieve this (and this requires precisely to
ignore that context or at least check with something more loose than
org-element).

>> If I'd follow that road, I could edit what looks like a timestamp
>> everywhere, regardless of context.  I don't know if that's the right
>> thing to do and I don't even expect consensus among the Org user base.
>> I personally see no need to do that.
>
> I do see it, tho. This is analogous to links in comments. If you see
> something looking like a timestamp (or a link), you can expect some
> commands to operate on it. This is exactly what is biting us at the
> moment.

In a comment that timestamp-looking text doesn't have any function, so
it's in a different category, I must insist.  As I said, I can see
somebody wanting to have this text be editable like any other timestamp
also, but it's really the other uses where it's used meta-syntactically
that I'd like to focus on.  ONe of the differences to text in comments
(or generally quoted material) is that there is an expectation that this
sort of timestamp is correct, since they are intended to be input to
further processing.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [O] More clocktable breakage

[Nicolas Goaziou]

Hello,

Achim Gratz  writes:

> Well, taking a further setp back, before Org started to have a formal
> syntax anything that looked like a timestamp was treated as one.  The
> different categories of timestamps really arise from the fact that we
> now have syntactical timestamps and non-syntactical ones.

I don't pretend the contrary. I'm just talking about the current state
of timestamps.

Oh, and it is a really good thing Org now has a formal syntax.

> This in turn requires that each function dealing with timestamps needs
> to specify what exactly it wants to deal with, but as this discussion
> amply shows, that isn't quite as straightforward as one would think.

Indeed.

>> The first category is the "strict" one, which follows Org syntax
>> definition. None of the examples above belong to that category.
>> `org-element-context' should be the relative predicate, which means that
>> it probably shouldn't return a timestamp object on planning lines, as it
>> does at the moment.
>
> I'd say anything org-element-* should exclusively return syntactical
> things.  Context dependence needs to be dealt with elsewhere.

I'm not sure to understand this. Syntactical things are all about
context dependence in Org. Do you mean /context independance/ needs to
be dealt with elsewhere?

> I would call that meta-syntax or maybe quoted syntax: you are looking at
> a proper timestamp, to be used somewhere else where a timestamp is
> needed, but in a context that doesn't specify a timestamp itself.  There
> are many analogous cases elsewhere in Org, so it may be a fruitful
> endeavour to consider this in a more general fashion.  Providing
> timestamps as arguments to any processing functions (built into Org or
> otherwise) carries the requirement that they should syntactically be
> correct as a timestamp (so they can be converted into a timestamp object
> at the place of use), so all functions to insert and edit a timestamp
> need to work at those places.

Could you provide examples about that? In particular "providing
timestamps as arguments to any processing functions" sounds odd, in
particular from someone who cringes when I suggest to add a second
optional argument to a single function.

> If I'd follow that road, I could edit what looks like a timestamp
> everywhere, regardless of context.  I don't know if that's the right
> thing to do and I don't even expect consensus among the Org user base.
> I personally see no need to do that.

I do see it, tho. This is analogous to links in comments. If you see
something looking like a timestamp (or a link), you can expect some
commands to operate on it. This is exactly what is biting us at the
moment.

The real problem is that, deep into the functions calls triggered by
(org-shift*), one of them expects to operate on timestamps at least from
category 2 (i.e., it uses `org-at-timestamp-p') while we're in
category 3. The solution is not to promote current timestamp to category
2 but to relax requirements from the guilty function, so that it also
operates on category 3. Fixing it is easy: we just need to replace
`org-at-timestamp-p' with (org-in-regexp org-ts-regexp) at the
appropriate place.

IIUC, however, we are discussing higher level details, i.e., about
predicates for each category, and the developer interface we want to
provide.

> Agreed.  That's why I'm hesitant to change the org-at-timestamp-p to
> (org-in-regexp org-ts-regexp) in the edit functions.  What I don't agree
> with (if I've read you correctly) is the implied assertion that the
> clocktable example is in the last category.  Or maybe it is at the
> moment, but it ought to be in the second one.  I consider only examples
> (3) and (5) to be in the "last" category.

The second category, according to my previous message, is about agenda.
Writing

  * Entry
  #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>"
  ...
  #+END:

doesn't mean you want to display "Entry" in the agenda for today. It is
but a parameter to the clocktable that happens to use timestamp syntax.

It belongs neither to the first category nor the second one.

>> Yet, `org-at-timestamp-p' is something users are going to look after.
>> Different names may also introduce confusion (remember `org-at-regexp-p'
>> and `org-in-regexp-p'?). So, even if it looks like bad factoring to you,
>> a single predicate, or even two if we set "agenda" apart, with
>> a docstring explaining the different categories and how to select them
>> may also be a good natural choice. Hence my suggestion.
>
> Since org-at-timestamp-p already has an argument, adding a second one
> doesn't look appealing to me, especially when the first one would often
> be nil.  Maybe it's possible to change the definition of that argument
> (which would need the equivalence between t meaning 'inactive).
>
>> WDYT? Do you have any other concrete proposal?
>
> I really only need the clocktables to work again, which they'd be if
> they were in the second category, I gather.  

Re: [O] Bug: Image export with link does not support query delimiter [8.2.10 (release_8.2.10 @ /usr/local/share/emacs/25.2/lisp/org/)]

[Damien Cassou]

Nicolas Goaziou  writes:
thanks for the suggestion. I have tried several ways to specify 
a value for this variable inside the file but failed to make 
the export change in any way. 


I succeeded with 

  #+bind: org-html-inline-image-rules (("http" . "\\.foo\\'")) 

  * Test 

  [[http://orgmode.org/image.foo]] 

This assumes `org-export-allow-bind-keywords' is non-nil, which 
may not be the case within Github's Org engine. Maybe it could 
be set to a non-nil value there. 


I can't make that work on GitHub. Any other suggestion? 


--
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

[O] Org 9.0.6

[Bastien]

Hi all,

Org 9.0.6, a bugfix release, is out.  Enjoy!

http://orgmode.org

-- 
 Bastien

Re: [O] How to generate subscript followed overstriking in org-mode

[XP Chen]

Haha, good idea but of my knowledge...

Thanks.







在2017年05月02 15时01分, "Eric S Fraga"写道:

On Tuesday,  2 May 2017 at 03:19, XP Chen wrote:
> So I choose using *bold*\mbox{}_{subscripted} , then in ODT file
> replace all the \mbox{} as blank...

You could probably write an export filter for ODT export which removes
the \mbox{} bits automatically...

--
Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D)

[O] [org-caldav] including heading tags into caldav export?

[jota pin]

Dear all,
Org-caldav exports org-entries to a caldav server, but without the org-mode 
tags. How could we modify org-caldav to export also the tags?
Use case/usefulness:
using org-caldav, we can see org entries into e.g. an owncloud calendar 
/smartphone, great! However, without the org-mode heading tags, the entries in 
the caldav calendar are quite difficult to use (i.e. to know to which 
context/project do a particular event in the calendar refers to).
Cheers,Jota

Re: [O] How to generate subscript followed overstriking in org-mode

[Eric S Fraga]

On Tuesday,  2 May 2017 at 03:19, XP Chen wrote:
> So I choose using *bold*\mbox{}_{subscripted} , then in ODT file
> replace all the \mbox{} as blank...

You could probably write an export filter for ODT export which removes
the \mbox{} bits automatically...

-- 
Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D)


signature.asc
Description: PGP signature

Re: [O] [PATCH] contrib/lisp/ox-confluence.el: Export checkboxes; fix timestamps in headlines

[Nicolas Goaziou]

Hello,

Marc Ihm  writes:

> the attached patch changes ox-confluence.el:
>
> - Export checkboxes in lists to appear in the resulting
>   confluence-markup (with some minor refactoring of
>   org-confluence-item).
> - Fix spurious closing braces following timestamps in headlines.
>
>
> Please review and let me know, if you have any comments or questions.

Thank you.

> + (cl-case (org-element-property :checkbox item)
> +   ('on "*{{(X)}}* ") 
> +   ('off "*{{( )}}* ")
> +   ('trans "*{{(\\-)}}* "))

This is a common mistake. Symbols in `cl-case' shouldn't be quoted. 'on
is really (quote on), so you actually wrote

  (cl-case (org-element-property :checkbox item)
((quote on) "*{{(X)}}* ")
((quote off) "*{{( )}}* ")
((quote trans) "*{{(\\-)}}* "))

which is not what you want:

  (cl-case 'quote ('a 1) ('quote 2) (t 3))=> 1

This is why I prefer `pcase' over `cl-case'.

> + (when (eq list-type 'descriptive)
> +   (concat "*" (org-export-data (org-element-property :tag item) info) 
> "* - "))
> + (org-trim contents
>  
>  (defun org-confluence-fixed-width (fixed-width contents info)
>(org-confluence--block
> @@ -117,7 +120,7 @@
>   (string= todo ""))
>   ""
> (format "*{{%s}}* " todo
> -;; Else: Standard headline.
> +

Mind the spurious blank lines.

>  (format "h%s. %s%s\n%s" level todo-text text
>  (if (org-string-nw-p contents) contents ""
>  
> @@ -181,7 +184,7 @@ a communication channel."
>  (defun org-confluence-timestamp (timestamp _contents _info)
>"Transcode a TIMESTAMP object from Org to Confluence.
>  CONTENTS and INFO are ignored."
> -  (let ((translated (org-timestamp-translate timestamp)))
> +  (let ((translated (org-trim (org-timestamp-translate timestamp

I'm not sure what this is supposed to fix. Does
`org-timestamp-translate' return a string with leading or trailing
blanks?

Anyway, I applied the patch in master branch, with the fix suggested
above.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Incomplete header-args parsing [9.0.5 (9.0.5-elpa @ ~/.emacs.d/elpa/org-20170210/)]

[Nicolas Goaziou]

Hello,

Moritz Heidkamp  writes:

> org-babel-parse-header-arguments stops parsing arguments after an
> argument with a string value containing unbalanced parentheses. For
> example:
>
>   ELISP> (org-babel-parse-header-arguments ":foo \"(foo\" :bar 123")
>   ((:foo . "(foo"))
>
> Whereas with balanced parentheses:
>
>   ELISP> (org-babel-parse-header-arguments ":foo \"(foo)\" :bar 123")
>   ((:foo . "(foo)")
>(:bar . 123))
>
> Oddly, the same is true when wrapping the string in a progn form:
>
>   ELISP> (org-babel-parse-header-arguments ":foo (progn \"(foo\") :bar 123")
>   ((:foo . "(foo"))

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou