Re: [O] agenda: past due deadlines *also* showing up under today's date

2017-03-06 Thread Nicolas Goaziou
Hello,

Sébastien Delafond  writes:

> On 2017-03-05, Nicolas Goaziou  wrote:
>> I don't think so. Maybe we need to implement an equivalent to
>> `org-scheduled-past-days' for deadlines.
>
> That'd be awesome :) 

Done in master as `org-deadline-past-days'. Feedback welcome.

Regards,

-- 
Nicolas Goaziou



Re: [O] how to export to HTML using old-style numbered div ID's?

2017-03-06 Thread Nicolas Goaziou
Hello,

Nick Dokos  writes:

> Peter Salazar  writes:
>
>> Hi everyone,
>>
>> I figured out that the problem I've been having with
>> org-html-slideshow
>> (https://github.com/relevance/org-html-slideshow) is that it relies
>> on the old-style numbered anchors that org-mode used to generate for
>> div ID's in HTML export—the ones that looked like "sec-1-2".
>>
>> Example:
>>
>> 
>> 
>>
>> As you know, the new 8.x org-mode HTML exporter generates this instead:
>>
>>  
>>  
>>
>> This output confuses org-html-slideshow, preventing it from
>> correctly advancing the slides in the presenter view. 
>>
>> Does anyone know how can I direct org-mode 8.x to generate div tags
>> with the old-style numbered anchors like it used to?
>
> The LaTeX exporter *does* have such a capability, through the
> variable org-latex-prefer-user-labels,

Not exactly. The variable above allows overriding the default naming
scheme whenever the user provides additional information. However,
AFAIU, the OP wants to alter the default scheme, without any user
interaction.

This is not possible. I suggest to report it as a bug to
org-html-slideshow developers so they can update it.


Regards,

-- 
Nicolas Goaziou



Re: [O] ascii section references for id links can be inline?

2017-03-06 Thread Nicolas Goaziou
Hello,

Samuel Wales  writes:

> can ascii output for id links be inline?
>
> === org source
> Some recent test results are 
> [[id:aa8795c5-7ee7-48e2-84f7-49d26f371632][here]].
> ===
>
> === current output
> Some recent test results are [here].
>
> [here] See section 6.2.2.2
> ===
>
> === possible new output
> Some recent test results are in section 6.2.2.2
> ===
>
> i'm not sure what syntax or feature would be appropriate.

You can remove the description. Otherwise, Org will do its best to use
it.

Regards,

-- 
Nicolas Goaziou



Re: [O] limitation for macro expansion

2017-03-06 Thread Yasushi SHOJI
Hi Nicolas,

Thank you for your time.  I really appreciate it.

On Tue, 07 Mar 2017 01:41:34 +0900,
Nicolas Goaziou wrote:
>
> Yasushi SHOJI  writes:
>
> > I assume that the key phrase is "anywhere Org markup is recognized".
> > Link format doesn't allow Org markup, right?
>
> Not in the first part indeed. You can, however, use a macro in the
> description part of the link.

OK.

> > # I use file_name_with_underscore.txt more than subscripts
> > # I'd be nice, at least for me, to have '\sub' and '\super' special keywords
> > # but leave the underscores alone.
>
> I don't understand where you need this. At the export level, you can use
> `org-export-with-sub-superscripts' to `{}'. At display level, you can do
> the same with `org-use-sub-superscripts'.

I hate to waste your precious time because of my ignorant and I can
live with '\under' but I'm totally lost.

Are you saying that it's possible to generate "a_20170307.txt" from
"a_{{{timestamp}}}.txt" if I set those variables mentioned above
correctly? without using '\under'?

I know you said it's ambiguous.  So let me clarify what I said. What I
said above was to change the syntax (or lex / parser's behavior) when
some variable, let's say 'org-do-not-parse-sub-superscripts', is set
to nil.

So that a) org leaves '_' in "a_{{{somemacro}}}" as-is and the macro
parser will pickup the "{{{somemacro}}}, b) when I want to use
subscript, I can write "a\sub{someword or two}" to make a subscript.

People like me don't use subscript much (to be honest, I've never
wanted to use subscript since I started use Org, seven years?), but
use '_' many times in a doc.  Hence, (setq org-use-sub-superscripts
nil) in my init.el.  But for someone wanting to use subscripts in rare
occasion, '\sub' would serve.

I can understand if you say it's not good idea to change the _syntax_
by a variable.

> > hmm.  just checked the source.  org-use-sub-superscripts is only for 
> > display.
> > org-export-with-sub-superscripts is just for exports.
>
> See above.
>
> > I was gonna just by-pass or disable subscript parser all together when
> > org-use-sub-superscripts is nil but it doesn't seems to be a good
> > idea, does it?
>
> This is exactly what a nil `org-export-with-sub-superscripts' does.

If that's the case, why doesn't macro parser pickup the
"{{{timestamp}}}" in "a_{{{timestamp}}}"?

Maybe this is my confusing point?  The component resposible defining
the org "syntax" is different from the parser?  Even if sub/super
parser is by-passed, because the "syntax" is subscript, the macro
parser won't be called on this substring?

Is the syntax defined in org-element--object-regexp and
org-element--object-lex?

Thanks,
--
   yashi



Re: [O] how to export to HTML using old-style numbered div ID's?

2017-03-06 Thread Nick Dokos
Peter Salazar  writes:

> Hi everyone,
>
> I figured out that the problem I've been having with
> org-html-slideshow
> (https://github.com/relevance/org-html-slideshow) is that it relies
> on the old-style numbered anchors that org-mode used to generate for
> div ID's in HTML export—the ones that looked like "sec-1-2".
>
> Example:
>
> 
> 
>
> As you know, the new 8.x org-mode HTML exporter generates this instead:
>
>  
>  
>
> This output confuses org-html-slideshow, preventing it from
> correctly advancing the slides in the presenter view. 
>
> Does anyone know how can I direct org-mode 8.x to generate div tags
> with the old-style numbered anchors like it used to?
>

The LaTeX exporter *does* have such a capability, through the
variable org-latex-prefer-user-labels, but I don't think there is a
similar capability in the HTML exporter (although Nicolas has
expressed his willingness to accept a patch that implements it, IIRC -
hint, hint...)

--
Nick




[O] how to export to HTML using old-style numbered div ID's?

2017-03-06 Thread Peter Salazar
Hi everyone,

I figured out that the problem I've been having with org-html-slideshow (
https://github.com/relevance/org-html-slideshow) is that it relies on the
old-style numbered anchors that org-mode used to generate for div ID's in
HTML export—the ones that looked like "sec-1-2".

Example:




As you know, the new 8.x org-mode HTML exporter generates this instead:

 
 

This output confuses org-html-slideshow, preventing it from correctly
advancing the slides in the presenter view.

Does anyone know how can I direct org-mode 8.x to generate div tags with
the old-style numbered anchors like it used to?

Thanks!


-- Forwarded message --
From: Peter Salazar 
Date: Mon, Mar 6, 2017 at 10:04 AM
Subject: HTML presentations using org-html-slideshow?
To: org-mode 


Hi everyone,

I've been using the excellent org-html-slideshow (
https://github.com/relevance/org-html-slideshow) to generate HTML slides
from org-mode, and it's been working well for me for years.

It generates HTML slides from org-mode using the org-mode heading
hierarchy. Tag any heading with the org-tag :slide: and that heading and
its contents automatically become their own slide once you export to HTML
using org-export-dispatch.

I prefer org-html-slideshow to org-reveal since it allows me the ability to
easily customize the look and feel of slides—by creating a custom
slide—simply by adding an org-tag. So if I tag an org-heading with the tag
:fullscreenslide: for example (so that the heading looks like * Heading
:slide:fullscreenslide:), it will then export that slide to HTML with
class="fullscreenslide" — and I can then use CSS to customize the look and
feel of all slides with that class.

Org-html-slideshow also offers a great Presenter View, which opens in a
separate tab in your browser, and displays your speaker notes, the current
slide, and the next slide. Unfortunately, org-html-slideshow is no longer
being actively developed, and a recent update to org-mode has broken the
way Presenter View functions. Somehow with the new org-mode updates, the
"next slide" view in Presenter Notes mode no longer advances correctly. The
"next slide" slide gets stuck in a loop of 4-5 slides, and just repeats
those few slides. It does not reliably show you what the next slide is
going to be.

I notice that the output from example.org when I export to HTML is fairly
different from the example.html that's in the repo. Something in those
differences is breaking the ability of Presenter Notes to advance to the
next slide:
https://gist.github.com/incandescentman/dca040c750a3e9e7e687942d69ebd53f

Anyone else using org-html-slideshow? Does anyone have any thoughts on how
to get this working again? Thanks!
diff --git a/example.html b/example.html
index 2dd0b5e..49ba097 100755
--- a/example.html
+++ b/example.html
@@ -3,199 +3,73 @@
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
 http://www.w3.org/1999/xhtml; lang="en" xml:lang="en">
 
+
+
+
 Example Presentation
-
-
-
-
- 
-
+
+
 
 
 
 
-
-/*
-@licstart  The following is the entire license notice for the
-JavaScript code in this tag.
-
-Copyright (C) 2012  Free Software Foundation, Inc.
-
-The 

Re: [O] limitation for macro expansion

2017-03-06 Thread Yasushi SHOJI
Hi Nicolas,

On Mon, Mar 6, 2017 at 5:22 PM, Nicolas Goaziou  wrote:
> Yasushi SHOJI  writes:
> there are two ways to interpret it: the one you expect and
>
>   a_{CONTENTS} where CONTENTS is {{something}}.
>
> Since subscript syntax started first, it has precedence over the macro.

Yes.  That's what I understand from your response.  Thanks!

>> Doesn't seems to work.  When I export 'a_author', it
>> generates:
>>
>>   a_{Yasushi SHOJI}
>>
>> I was expecting to see:
>>
>>   a_Yasushi SHOJI
>
> This is correct if you use `ascii' back-end.

Sorry for the confusion.
I just thought that you gave me a way to use macro with underscore.

>> Would it be OK to say that it's a design decision to ignore the macro
>> expansion in the link field at export time?
>
> It is. Actually, macros are not allowed in many places, as a design
> decision. See
>
>   (info "(org) Macro replacement")
>
> for more details.

I assume that the key phrase is "anywhere Org markup is recognized".
Link format doesn't allow Org markup, right?

>> ie)
>>
>>   #+MACRO: timestamp {{{date(%Y%m%d)}}}
>>
>>   Please open log_{{{timestamp}}}.txt
>>
>> Would it be possible for org to do this?
>
> You could try
>
>   #+MACRO: timestamp {{{time(%Y%m%d)}}}
>
>   Please open log\under{}{{{timestamp()}}}.txt

Ah!  Great idea.  That's what I'm looking for. Thanks.

# I use file_name_with_underscore.txt more than subscripts
# I'd be nice, at least for me, to have '\sub' and '\super' special keywords
# but leave the underscores alone.

>> If not, would it be possible for me to modify the code to achieve this?
>> My stupid idea is to:
>>
>>   - disable sub / superscript parser when org-use-sub-superscripts is nil
>
> See `org-export-with-sub-superscripts'.

hmm.  just checked the source.  org-use-sub-superscripts is only for display.
org-export-with-sub-superscripts is just for exports.

I was gonna just by-pass or disable subscript parser all together when
org-use-sub-superscripts is nil but it doesn't seems to be a good idea, does it?

>>   - reverse the precedence order of subscript and macro
>
> This would only move the problem elsewhere.

True.
-- 
 yashi



Re: [O] limitation for macro expansion

2017-03-06 Thread Nicolas Goaziou
Hello,

Yasushi SHOJI  writes:

> Ah, you mean the parser is unable to distinguish the macro and
> subscript?

It's not the parser, but the syntax. Subscript is

  a_{...}

whereas macro is

  {{{macro(...)}}}

so, when you see

  a_{{{something}}}

there are two ways to interpret it: the one you expect and

  a_{CONTENTS} where CONTENTS is {{something}}.

Since subscript syntax started first, it has precedence over the macro.

> Doesn't seems to work.  When I export 'a_author', it
> generates:
>
>   a_{Yasushi SHOJI}
>
> I was expecting to see:
>
>   a_Yasushi SHOJI

This is correct if you use `ascii' back-end. How could you tell the
difference between

  a_{Yasushi SHOJI}

and

  a_Yasushi SHOJI

otherwise?

OTOH, `latex' back-end produces

  a\(_{\text{Yasushi SHOJI}}\)

which means the parser and the export process correctly handle it.

>> > - Link doesn't work like this: [[file:{{{input-file}}}][Bad link]]
>> 
>> Indeed. This kind of link is not supported as you cannot follow it
>> (macros are an export-only feature).
>
> Hmm, that's true that you can't follow it.
>
> Would it be OK to say that it's a design decision to ignore the macro
> expansion in the link field at export time?

It is. Actually, macros are not allowed in many places, as a design
decision. See

  (info "(org) Macro replacement")

for more details.

>> Feel free to provide a documentation patch if you think this needs to be
>> made explicit.
>
> Will do once I fully understand.
>
> Now, what I'm trying to achieve with a macro is to generate a
> filename-like string with a timestamp in it in my doc.
>
> ie)
>
>   #+MACRO: timestamp {{{date(%Y%m%d)}}}
>
>   Please open log_{{{timestamp}}}.txt
>
> Would it be possible for org to do this?

You could try

  #+MACRO: timestamp {{{time(%Y%m%d)}}}

  Please open log\under{}{{{timestamp()}}}.txt

> If not, would it be possible for me to modify the code to achieve this?
> My stupid idea is to:
>
>   - disable sub / superscript parser when org-use-sub-superscripts is nil

See `org-export-with-sub-superscripts'.

>   - reverse the precedence order of subscript and macro

This would only move the problem elsewhere.

Regards,

-- 
Nicolas Goaziou0x80A93738