Re: [O] agenda: past due deadlines *also* showing up under today's date
Hello, Sébastien Delafondwrites: > 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?
Hello, Nick Dokoswrites: > 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?
Hello, Samuel Waleswrites: > 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
Hi Nicolas, Thank you for your time. I really appreciate it. On Tue, 07 Mar 2017 01:41:34 +0900, Nicolas Goaziou wrote: > > Yasushi SHOJIwrites: > > > 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?
Peter Salazarwrites: > 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?
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 SalazarDate: 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
Hi Nicolas, On Mon, Mar 6, 2017 at 5:22 PM, Nicolas Goaziouwrote: > 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
Hello, Yasushi SHOJIwrites: > 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