Re: [O] function for inserting a block

[numbch...@gmail.com]

Ok, I see, Just I have to replace all uppercased babels and example blocks
to lowercase to keep same.
I have a lot of org files. Huge for me.
I can take with the lower-case tag.

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/

On Sat, Nov 18, 2017 at 3:14 AM, Eric Abrahamsen 
wrote:

> "numbch...@gmail.com"  writes:
>
> > Yeah, I misunderstand your code. Anyway, It should be like this:
> >
> > #+BEGIN_SRC python
> > ...
> > #+END_SRC
> >
> > #+BEGIN_EXAMPLE
> > ...
> > #+END_EXAMPLE
> >
> > etc
>
> If you look back up this (admittedly very long) thread, you'll see the
> general consensus is to move to lower-case tags. I've intentionally left
> things lowercase, and now will have to handle "example" specially, based
> on the value of `org-babel-uppercase-example-markers'.
>
>
>

Re: [O] Org emphasis markers inside src blocks causes incorrect fontification

[Nicolas Goaziou]

Hello,

Kaushal Modi  writes:

> Again it's a font-locking bug, and thankfully doesn't impact the empasis
> detection in exporters.
>
> Would you please look into fixing this?

I cannot. Fixing it would require to rewrite the whole thing to use the
parser, so that fontification matches the syntax of the document. This,
in turn, would require to repair the parser's cache so that it doesn't
freeze when the wind is north, northwest. Ah, well.

Meanwhile, I pile up ad-hoc rules to avoid mis-fontification, until the
next pathological case is reported.

IOW, I'm only mildly interested in fixing fontification bugs.

You may want to test the following rules and report if it fits your use
case.

Regards,

-- 
Nicolas Goaziou
>From 52e4c5e1e69b0aaef1795289d8cf9456e76716f1 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou 
Date: Sat, 18 Nov 2017 00:19:35 +0100
Subject: [PATCH] Small fix to emphasis fontification

* lisp/org.el (org-do-emphasis-faces): Do not span over paragraph
  separators.

Reported-by: Kaushal Modi 

---
 lisp/org.el | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index f873f1021..861ce31db 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5705,20 +5705,16 @@ This should be called after the variable `org-link-parameters' has changed."
 	  (when (save-excursion
 		  (goto-char (match-beginning 0))
 		  (and
-		   ;; Do not match headline stars.  Do not consider
-		   ;; stars of a headline as closing marker for bold
-		   ;; markup either.
-		   (not (and (equal marker "*")
-			 (save-excursion
-			   (forward-char)
-			   (skip-chars-backward "*")
-			   (looking-at-p org-outline-regexp-bol
 		   ;; Do not match table hlines.
 		   (not (and (equal marker "+")
 			 (org-match-line
-			  "^[ \t]*\\(|[-+]+|?\\|\\+[-+]+\\+\\)[ \t]*$")))
+			  "[ \t]*\\(|[-+]+|?\\|\\+[-+]+\\+\\)[ \t]*$")))
+		   ;; Match full emphasis markup regexp.
 		   (looking-at (if verbatim? org-verbatim-re org-emph-re))
-		   ;; At a table row, do not cross cell boundaries.
+		   ;; Do not span over paragraph boundaries.
+		   (not (string-match-p org-element-paragraph-separate
+	(match-string 2)))
+		   ;; Do not span over cells in table rows.
 		   (not (and (save-match-data (org-match-line "[ \t]*|"))
 			 (string-match-p "|" (match-string 4))
 	(pcase-let ((`(,_ ,face ,_) (assoc marker org-emphasis-alist)))
-- 
2.14.3

Re: [O] Bug: linum-mode + org-indent-mode cursor movement problems [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2/lisp/org/)]

[Tom Schutter]

But how long will we wait for Emacs 26?

On 11/17/2017 03:30 PM, Nicolas Goaziou wrote:

Hello,

Tom Schutter  writes:


If both linum-mode (or nlinum-mode) and org-indent-mode are enabled,
then moving the cursor to the previous line using  causes it to
jump horizontally to the right.  The jump matches the current
indentation.  I would expect the cursor to remain in the same column.

Load linum.org (contents below) with minimal config.  linum.org will
enable linum-mode and org-indent-mode:

   emacs -Q linum.org

Place your cursor on the "2" in the fourth line and press .  The
cursor will jump two columns to the right to the "4" in the third
line. Press  again and the cursor will move to the "4" in the
second line. Press  again and the cursor will jump back to the "e"
in the first line.

What is interesting is that you get different behavior when using
.  The cursor remains in the same column as you move down each
line.  So starting on the "e" in the first line, pressing  moves
the cursor to the "2" on the second line.

If you insert a second level heading in between the first and the
second line, then the jumps will be four columns instead of two.

I discovered this problem first in nlimum-mode, but it is easier to
reproduce using linum-mode when starting Emacs with -Q.

Contents of linum.org:

   * heading
   1234 line 2
   1234 line 3
   1234 line 4
   # Local Variables:
   # eval: (org-indent-mode 1)
   # eval: (linum-mode 1)
   # End:


I don't think it's worth fixing: linum.el and nlinum.el are on their way
out since Emacs 26 will ship with the same feature, implemented at the
C level.

It would be nice to know, however, if there is the same problem with
that new implementation.

Regards,

Re: [O] [PATCH] ox.el: Define subtitle macro

[Nicolas Goaziou]

Hello,

Jens Lechtenboerger  writes:

> On 2017-11-17, Rasmus wrote:
>
>> Jens Lechtenboerger  writes:
>>
>>> the attached patch adds a subtitle macro with documentation.
>>
>> AFAIK it’s already added to the backends where it makes sense.  It’s not a
>> basic keyword like "#+author".  It should be documented under the relevant
>> backends that support it.
>
> Sorry, I don't understand your suggestion.  I'm interested in
> org-reveal [1], which is based on ox-html.el.  In ox-html.el,
> subtitles are used at some hardcoded positions (preamble, postamble,
> template), but I need access to the subtitle elsewhere.
>
> What should I document where?

SUBTITLE keyword may not be supported in every back-end. As
a consequence, supporting a global {{{subtitle}}} macro sounds
presumptuous.

Anyway, it begs for generalisation. The same problem is going to arise
for CREATOR, KEYWORDS, and WHATNOT. Instead of {{{subtitle}}}, we could
implement {{{option(KWD)}}}. Basically,

  {{{option(SUBTITLE)}}}  => (org-element-interpret-data (plist-get info 
:subtitle))

Options with a `split' behaviour would need a special treatment,
however.

WDYT? Do you want to have a stab at it?

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: linum-mode + org-indent-mode cursor movement problems [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2/lisp/org/)]

[Nicolas Goaziou]

Hello,

Tom Schutter  writes:

> If both linum-mode (or nlinum-mode) and org-indent-mode are enabled,
> then moving the cursor to the previous line using  causes it to
> jump horizontally to the right.  The jump matches the current
> indentation.  I would expect the cursor to remain in the same column.
>
> Load linum.org (contents below) with minimal config.  linum.org will
> enable linum-mode and org-indent-mode:
>
>   emacs -Q linum.org
>
> Place your cursor on the "2" in the fourth line and press .  The
> cursor will jump two columns to the right to the "4" in the third
> line. Press  again and the cursor will move to the "4" in the
> second line. Press  again and the cursor will jump back to the "e"
> in the first line.
>
> What is interesting is that you get different behavior when using
> .  The cursor remains in the same column as you move down each
> line.  So starting on the "e" in the first line, pressing  moves
> the cursor to the "2" on the second line.
>
> If you insert a second level heading in between the first and the
> second line, then the jumps will be four columns instead of two.
>
> I discovered this problem first in nlimum-mode, but it is easier to
> reproduce using linum-mode when starting Emacs with -Q.
>
> Contents of linum.org:
>
>   * heading
>   1234 line 2
>   1234 line 3
>   1234 line 4
>   # Local Variables:
>   # eval: (org-indent-mode 1)
>   # eval: (linum-mode 1)
>   # End:

I don't think it's worth fixing: linum.el and nlinum.el are on their way
out since Emacs 26 will ship with the same feature, implemented at the
C level.

It would be nice to know, however, if there is the same problem with
that new implementation.

Regards,

-- 
Nicolas Goaziou

Re: [O] Stable 9.1.3 demands explicit empty string in (file) as capture target

[Nicolas Goaziou]

Hello,

Umbromancer  writes:

> This may be intended, but before it was possible (and there is a lot
> of code and examples in the wild) to have a capture template element
> such as:

I don't see this documented either in `org-capture-templates' docstring
or in the manual. It could be some glitch that disappeared during
a refactoring. AFAICT, the empty string has always been the way to go.

Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH]: Fix ob-haskell.el to work with custom ghci prompts

[Nicolas Goaziou]

Hello,

Doro Rose  writes:

> In summary, yes I'm accessing user settings but in a rather
> noninvasive way. Unfortunately I can't think of a more elegant way to
> do this.

Let's put it differently then. Isn't it the job of the user, who changed
their prompt, to configure properly "inf-haskell" library? I don't get
why it should be a task for "ob-haskell".

This is a genuine question: I don't use Haskell at all.

Regards,

-- 
Nicolas Goaziou

Re: [O] Do not inherit unnumbered property: help needed

[Nicolas Goaziou]

Hello,

Akater  writes:

> In case UNNUMBERED's inheritance could be turned off by a standard
> procedure, my other points are meaningless. So let's first figure out if
> it could.

It cannot. That's a feature intended to preserve sanity.

As suggested, you could write an export back-end that ignore UNNUMBERED
inheritance.

OOC, what is the output you expect from your initial example?

Regards,

-- 
Nicolas Goaziou

Re: [O] function for inserting a block

[Eric Abrahamsen]

"numbch...@gmail.com"  writes:

> Yeah, I misunderstand your code. Anyway, It should be like this:
>
> #+BEGIN_SRC python
> ...
> #+END_SRC
>
> #+BEGIN_EXAMPLE
> ...
> #+END_EXAMPLE
>
> etc

If you look back up this (admittedly very long) thread, you'll see the
general consensus is to move to lower-case tags. I've intentionally left
things lowercase, and now will have to handle "example" specially, based
on the value of `org-babel-uppercase-example-markers'.

Re: [O] function for inserting a block

[numbch...@gmail.com]

Yeah, I misunderstand your code. Anyway, It should be like this:

#+BEGIN_SRC python
...
#+END_SRC

#+BEGIN_EXAMPLE
...
#+END_EXAMPLE

etc

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/

On Thu, Nov 16, 2017 at 12:24 AM, Eric Abrahamsen 
wrote:

> "numbch...@gmail.com"  writes:
>
> > I think the function `org-insert-structure-template' also should
> respect the `org-babel-uppercase-example-markers'.
> > Besides, your new diff does not have a condition on
> `org-babel-uppercase-example-markers', you just use `upcase-initials` by
> default. Then the new `tempo` snippets
> > will be uppercase, but the `org-insert-structure-template` inserted
> templates will be different.
>
> I'm not entirely understanding you here -- it is
> `org-insert-structure-template' that respects
> `org-babel-uppercase-example-markers', not the tempo snippet (which was
> an omission). And none of the code is using `upcase-initials'.
>
> As far as I can see, the bug is that EXAMPLE is uppercased but the
> "begin" and "end" aren't, and also that the tempo snippet doesn't
> capitalize at all...
>

Re: [O] ob-haskell evaluation needs inf-haskell but it does not exist

[numbch...@gmail.com]

I setted `haskell-process-type` to 'ghci.
I evaluated a simple haskell src block, but it reports I need have a
`*haskell*` inferior. Then I executed command [M-x run-haskell].
Then I get error:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  expand-file-name(nil)
  locate-dominating-file(nil "cabal.sandbox.config")
  haskell-process-type()
  haskell-program-name-with-args()
  inferior-haskell-start-process()
  inferior-haskell-process()
  run-haskell()
  funcall-interactively(run-haskell)
  call-interactively(run-haskell record nil)
  command-execute(run-haskell record)
  #f(compiled-function (cmd) #)("run-haskell")
  ivy-call()
  ivy-read("M-x " [special-lispy-clone
  
  counsel-M-x()
  funcall-interactively(counsel-M-x)
  call-interactively(counsel-M-x nil nil)
  command-execute(counsel-M-x)

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/

On Wed, Nov 15, 2017 at 11:35 PM, Nick Dokos  wrote:

> "numbch...@gmail.com"  writes:
>
> > I checked out your answer, I have meet all your said requirements. GHCi,
> inf-haskell (after I installed package haskell-mode) and setting
> `haskell-program-name`, I found there is no
> > `defcustom` variable option named `haskell-program-name` at all.
>
> You probably need to set haskell-process-type to ghci. If that works,
> please let me know and I'll update the answer on SO.
>
> >
> > [stardiviner] GPG key ID: 47C32433
> > IRC(freeenode): stardiviner Twitter:  @numbchild
> > Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
> > Blog: http://stardiviner.github.io/
> >
> > On Wed, Nov 15, 2017 at 9:17 PM, numbch...@gmail.com <
> numbch...@gmail.com> wrote:
> >
> > I required `(require 'inf-haskell)` But have not found the command
> `inf-haskell` to start inferior process.
> >
> > [stardiviner] GPG key ID: 47C32433
> > IRC(freeenode): stardiviner Twitter:  @numbchild
> > Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
> > Blog: http://stardiviner.github.io/
> >
> > On Mon, Nov 13, 2017 at 11:43 PM, Nick Dokos 
> wrote:
> >
> > stardiviner  writes:
> >
> > > When I execute the following Haskell src block:
> > >
> > > ```
> > >
> > > #+BEGIN_SRC haskell :session :tangle "Data/Code/hello_world.hs"
> > > main :: IO ()
> > > main = do
> > >   putStrLn "Hello, World!"
> > > #+END_SRC
> > >
> > > ```
> > >
> > > It reports error:
> > >
> > > ```
> > >
> > > Debugger entered--Lisp error: (file-missing "Cannot open load
> file" "No
> > > such file or directory" "inf-haskell")
> > >   require(inf-haskell)
> >
> > See my answer to this SO question:
> >
> >   https://stackoverflow.com/questions/42081379/how-to-set-
> up-org-babel-for-haskell-with-stack
> >
> > for some details on setting up the environment.
> >
> > --
> > Nick
> >
>
> --
> Nick
>
>
>

Re: [O] Do not inherit unnumbered property: help needed

[Akater]

Kaushal Modi  writes:

> Have you looked at org-use-property-inheritance variable
> http://orgmode.org/manual/Property-inheritance.html -- You can set that to
> a regexp that does not match UNNUMBERED.

As this page mentions, default value is nil, which means nothing would be
inherited. UNNUMBERED does not follow this rule, even though it is not
mentioned as one “for which inheritance is hard-coded” in the manual ---
as was announced in org-news,
> *** Export unnumbered headlines

> Headlines, for which the property ~UNNUMBERED~ is non-nil, are now
> exported without section numbers irrespective of their levels.  The
> property is inherited by children.
http://orgmode.org/cgit.cgi/org-mode.git/plain/etc/ORG-NEWS

See also
Org Manual > Exporting > Export Settings
which also mentions
> Set `UNNUMBERED' property to non-`nil' to disable
>  numbering of heading and subheadings entirely.
Not a single word in the manual, or in worg, on disabling this
particular kind of inheritance.

After evaluating
(setq org-use-property-inheritance "[^\\(UNNUMBERED\\)]")
children are still exported numbered. org-reload has no additional
effect. I use Org 9.1.3 (20171116 from melpa) and Emacs 25.3.1.

In case UNNUMBERED's inheritance could be turned off by a standard
procedure, my other points are meaningless. So let's first figure out if
it could.


signature.asc
Description: PGP signature

Re: [O] Do not inherit unnumbered property: help needed

[Kaushal Modi]

On Fri, Nov 17, 2017, 7:00 AM Akater  wrote:

> I have to deal with a document that has an unfortunate vague structure
> which involves unnumbered headlines spanning a couple of numbered
> ones. I'd like to convert the document into Org and thus effectively
> need to implement a feature that would allow unnumbered property in Org
> not to be inherited by children of unnumbered items in some cases.
>
> Say, in the following toy example
>
> #+BEGIN_SRC org
> * section-one-title
> blah
> * the first two prime-numbered sections (duh)
> :properties:
> :ignore-this-outline-level: t
> :unnumbered: t
> :end:
> ** section-two-title
> blah
> ** section-three-title
> blah
> * section-four-title
> blah
> #+END_SRC
>


Have you looked at org-use-property-inheritance variable
http://orgmode.org/manual/Property-inheritance.html -- You can set that to
a regexp that does not match UNNUMBERED.

section-three and section-four would be treated as being on the same
> level as other section-x's, their children treated correspondingly.
>

That won't be possible unless you define a custom exporter with it's custom
property that doctors the level interpreted from the leading stars.

For exporting needs, I chose to format the unnumbered headline the
> same style as section-x's, only unnumbered,


I don't see why that wouldn't be possible.

 and

have section-two and
> section-three be numbered as if the unnumbered headline didn't
> exist.
>

That's the default behavior too.

First,
> I need to mark (?) parts of the parse tree that are children of
> the unnumbered item, and are not explicitly marked unnumbered
> themselves, as exportable when being passed to
> org-export--collect-headline-numbering.
>

I don't think that is needed. The numbering of the headings after the
unnumbered headings stays the same whether or not you export the unnumbered
heading.

Second,
> I will also need to redefine specialized functions like
> org-html-section, turning
> org-export-get-headline-number
> into
> org-export-get-deepest-numbered-parent-headline-number
> and so on, but this doesn't seem to be difficult. However, if I'm
> missing something and you think this could be a valuable feature, you
> are welcome to share your thoughts.


Can you explain more on what features you propose for those functions so
that people can comment?

I'm not an experienced programmer
> but hopefully I can implement this and contribute.
> n(Will sign anything FSF if needed.)
>

Signing FSF as the first step is usually a good thing. So that with the
paperwork in place, you can contribute to Org/Emacs whenever you get a
chance in future.

I admit that the whole idea to add this to Org is questionable, and
> documents structured like this better be restructured altogether.


I didn't follow that.

It is
> likely that exported versions for some backends are not going to be
> structured properly. (As far as I can see, Texinfo looks particularly
> unpromising.)
>

?

>
Nevertheless, it is possible to at least make exported versions /look/
> ok and describe possible backend-related caveats in the documentation.
> I find it reasonable to keep org files structured properly, while
> considering exported versions to be more of an eye candy. In my case,
> the document in question is an archive entry which cannot be changed
> retrospectively but me and my colleagues could still benefit from it
> being tidily marked up.
>

I didn't follow all that you mentioned in the end. It's not clear what the
document restructuring was about after the initial problem statements.
Let's start with resolving the UNNUMBERED property non-inheritance.

> --

Kaushal Modi

[O] Do not inherit unnumbered property: help needed

[Akater]

I have to deal with a document that has an unfortunate vague structure
which involves unnumbered headlines spanning a couple of numbered
ones. I'd like to convert the document into Org and thus effectively
need to implement a feature that would allow unnumbered property in Org
not to be inherited by children of unnumbered items in some cases.

Say, in the following toy example

#+BEGIN_SRC org
* section-one-title
blah
* the first two prime-numbered sections (duh)
:properties:
:ignore-this-outline-level: t
:unnumbered: t
:end:
** section-two-title
blah
** section-three-title
blah
* section-four-title
blah
#+END_SRC

section-three and section-four would be treated as being on the same
level as other section-x's, their children treated correspondingly.

For exporting needs, I chose to format the unnumbered headline the
same style as section-x's, only unnumbered, and have section-two and
section-three be numbered as if the unnumbered headline didn't
exist.

First,
I need to mark (?) parts of the parse tree that are children of
the unnumbered item, and are not explicitly marked unnumbered
themselves, as exportable when being passed to
org-export--collect-headline-numbering.

This is where I ask for help, as it's not clear to me how to do that.
My hypothesis so far was that org-export--prune-tree from ox.el filters
out unnumbered items but my attempts with debug-on-entry did not confirm
this. Could someone help?

Re: (?) maybe children are never marked as exportable in the first place
and the tree just does not get traversd too deep. Again, I don't yet see
which function is to be patched to let them through.

Second,
I will also need to redefine specialized functions like
org-html-section, turning
org-export-get-headline-number
into
org-export-get-deepest-numbered-parent-headline-number
and so on, but this doesn't seem to be difficult. However, if I'm
missing something and you think this could be a valuable feature, you
are welcome to share your thoughts. I'm not an experienced programmer
but hopefully I can implement this and contribute.
n(Will sign anything FSF if needed.)

I admit that the whole idea to add this to Org is questionable, and
documents structured like this better be restructured altogether. It is
likely that exported versions for some backends are not going to be
structured properly. (As far as I can see, Texinfo looks particularly
unpromising.)

Nevertheless, it is possible to at least make exported versions /look/
ok and describe possible backend-related caveats in the documentation.
I find it reasonable to keep org files structured properly, while
considering exported versions to be more of an eye candy. In my case,
the document in question is an archive entry which cannot be changed
retrospectively but me and my colleagues could still benefit from it
being tidily marked up.


signature.asc
Description: PGP signature

Re: [O] mentioning EXPORT_LATEX_HEADER in the latex header info node

[Kaushal Modi]

On Fri, Nov 17, 2017, 4:35 AM Alan Schmitt 
wrote:

>
> It makes sense. Reading the text there, I'm a bit surprised:
>
> For example, `DATE' and `EXPORT_FILE_NAME' keywords become,
> respectively, `EXPORT_DATE' and `EXPORT_FILE_NAME'.
>
> Is the `EXPORT_FILE_NAME' a real example (i.e., a node property that has
> a global and subtree meaning with the same name)?
>

I haven't used #+EXPORT_FILE_NAME *keyword* when exporting files because
the exported file name base name is taken from the Org file base name.

But I have used that as a :EXPORT_FILE_NAME: *property* in subtrees many
times, when doing subtree scoped exports, and it works great :) For subtree
exports, it's kind of mandatory to set that property if you want to export
different subtrees from the same Org file to different files.

> --

Kaushal Modi

Re: [O] mentioning EXPORT_LATEX_HEADER in the latex header info node

[Alan Schmitt]

On 2017-11-16 22:00, Nicolas Goaziou  writes:

> Alan Schmitt  writes:
>
>> The LaTeX header and sectioning structure info node talks about
>> LATEX_HEADER and LATEX_HEADER_EXTRA. Maybe it could mention the EXPORT
>> version as well, as is done for the LATEX_CLASS_OPTION.
>
> Since adding "EXPORT_" prefixed version of all keywords could be
> overwhelming, I'd rather do it the other way and remove
> EXPORT_LATEX_CLASS_OPTION reference. We could consider that all is said
> in the last paragraph of (info "(org)Export settings").
>
> WDYT?

It makes sense. Reading the text there, I'm a bit surprised:

For example, `DATE' and `EXPORT_FILE_NAME' keywords become,
respectively, `EXPORT_DATE' and `EXPORT_FILE_NAME'.

Is the `EXPORT_FILE_NAME' a real example (i.e., a node property that has
a global and subtree meaning with the same name)?

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-10: 403.64, 2016-10: 401.57


signature.asc
Description: PGP signature

Re: [O] Public TODO agendas

[Colin Baxter]

Dear David,
> "David" == David Arroyo Menendez  writes:

David> I would like share my public agenda and read public agendas
David> of another worgers, perhaps we can share our agendas in a git
David> repository, or from different sources linked from
David> worgers.org. Are there more people interested in this idea?

Have you looked at 'org-secretary' in ../contrib/lisp/?

Best wishes

-- 
Colin Baxter
m43...@yandex.com
-
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8
-
The sole cause of all human misery is the inability of people to sit
quietly in their rooms.  Blaise Pascal, 1670

Re: [O] [PATCH] ox.el: Define subtitle macro

[Jens Lechtenboerger]

On 2017-11-17, Rasmus wrote:

> Jens Lechtenboerger  writes:
>
>> the attached patch adds a subtitle macro with documentation.
>
> AFAIK it’s already added to the backends where it makes sense.  It’s not a
> basic keyword like "#+author".  It should be documented under the relevant
> backends that support it.

Sorry, I don't understand your suggestion.  I'm interested in
org-reveal [1], which is based on ox-html.el.  In ox-html.el,
subtitles are used at some hardcoded positions (preamble, postamble,
template), but I need access to the subtitle elsewhere.

What should I document where?

Best wishes
Jens

[1] https://github.com/lechten/org-reveal