RFC: Revisit org-export-content-div (in the context of org-s5)

RFC: Revisit org-export-content-div (in the context of org-s5)

[Jambunathan K]

Couple of comments wrt org-export-content-div:

1. Should be renamed to org-export-html-content-div

2. If we look at org-s5.el[1], we see the following usage where
   apparently <div id="content"> is essentially replaced by "<div
   class="presentation"> with a bunch of leading and trailing stuff.

#+begin_src emacs-lisp
  (lambda ()
    (save-excursion
      (replace-regexp
       (regexp-quote "<div id=\"content\">")
       (let ((info `(("author" . ,author)
                     ("title" . ,title)
                     ("date" . ,(substring date 0 10)))))
         (join `("<div class=\"layout\">"
                 "<div id=\"controls\"><!-- no edit --></div>"
                 "<div id=\"currentSlide\"><!-- no edit --></div>"
                 "<div id=\"header\"></div>"
                 "<div id=\"footer\">"
                 ,(org-fill-template org-s5-title-string-fmt info)
                 "</div>"
                 "</div>"
                 ""
                 "<div class=\"presentation\">"
                 ,(org-fill-template org-s5-title-page-fmt info)))))))
#+end_src

3. Considering (2) above it might be worthwhile defining the
   customization as below (for a first cut)

#+begin_src emacs-lisp
  (defcustom org-export-html-content-div "%s <div %s> %s" ; note the html in prefix
    "The name of the container DIV that holds all the page contents."
    :group 'org-export-htmlize
    :type 'string)
#+end_src


With the above re-definition I believe there is an opportunity to suck

#+begin_src emacs-lisp-mode
(if (or link-up link-home)
    (concat
     (format org-export-html-home/up-format
	     (or link-up link-home)
	     (or link-home link-up))
     "\n")
  "")
#+end_src

and even the entire preamble in to

#+begin_src emacs-lisp
  (when (plist-get opt-plist :html-preamble)
    ;; etc etc etc
    )
#+end_src

the suffix %s in the above custom definition.

Or alternatively

one can suck the suffix "%s" in to preamble string.

Just a thought. WDYT.

Jambunathan K.




   

       










Footnotes: 
[1] https://github.com/eschulte/org-S5/blob/master/org-export-as-s5.el
at around line 60 or so.


-- 

Re: RFC: Revisit org-export-content-div (in the context of org-s5)

[Jambunathan K]

> #+begin_src emacs-lisp
>   (defcustom org-export-html-content-div "%s <div %s> %s" ; note the html in prefix
>     "The name of the container DIV that holds all the page contents."
>     :group 'org-export-htmlize
>     :type 'string)
> #+end_src

Btw, The :group tag seems NOT OK to me as well.

Jambunathan K.

Re: RFC: Revisit org-export-content-div (in the context of org-s5)

[Bastien]

Hi Jambunathan,

Jambunathan K <kjambunathan@gmail.com> writes:

> Couple of comments wrt org-export-content-div:
>
> 1. Should be renamed to org-export-html-content-div

Done.

> 2. If we look at org-s5.el[1], we see the following usage where
>    apparently <div id="content"> is essentially replaced by "<div
>    class="presentation"> with a bunch of leading and trailing stuff.
>
> #+begin_src emacs-lisp
>   (lambda ()
>     (save-excursion
>       (replace-regexp
>        (regexp-quote "<div id=\"content\">")
>        (let ((info `(("author" . ,author)
>                      ("title" . ,title)
>                      ("date" . ,(substring date 0 10)))))
>          (join `("<div class=\"layout\">"
>                  "<div id=\"controls\"><!-- no edit --></div>"
>                  "<div id=\"currentSlide\"><!-- no edit --></div>"
>                  "<div id=\"header\"></div>"
>                  "<div id=\"footer\">"
>                  ,(org-fill-template org-s5-title-string-fmt info)
>                  "</div>"
>                  "</div>"
>                  ""
>                  "<div class=\"presentation\">"
>                  ,(org-fill-template org-s5-title-page-fmt info)))))))
> #+end_src
>
> 3. Considering (2) above it might be worthwhile defining the
>    customization as below (for a first cut)
>
> #+begin_src emacs-lisp
>   (defcustom org-export-html-content-div "%s <div %s> %s" ; note the html in prefix
>     "The name of the container DIV that holds all the page contents."
>     :group 'org-export-htmlize
>     :type 'string)
> #+end_src

This looks to complicated to me.

I've introduced a new defcustom `org-export-html-before-content-div'
which lets the user place arbitrary HTML code before the main container.

org-s5.el could you this instead of replacing the "<div id=content>".

-- 
 Bastien

Re: RFC: Revisit org-export-content-div (in the context of org-s5)

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

>> #+begin_src emacs-lisp
>>   (defcustom org-export-html-content-div "%s <div %s> %s" ; note the html in prefix
>>     "The name of the container DIV that holds all the page contents."
>>     :group 'org-export-htmlize
>>     :type 'string)
>> #+end_src
>
> Btw, The :group tag seems NOT OK to me as well.

Fixed, thanks!

-- 
 Bastien

Using org-mode for Research and Notetaking

[Florian Beck]

[My main goal is to take research notes and write texts. I have little
interest in the todo/agenda part of org-mode, which I understand is its
main focus, so bear this in mind.]

Previously I have been using muse-mode for publishing and a home brew
system for organising my notes. Now I thought, I would give org-mode a
try. I had some 3500 short notes which I converted into a 8.5M org-file
with said 3500 heavily tagged entries. Also created a 500k org file from
my bibtex file. These two plus a couple of shorter files are my
org-agenda-files.

Speed is quite ok, surprisingly. `org-columns' in the big file is a
no-go, of course (overlays!). The agenda commands work fine (I have few
entries with todo-keywords, but they are in every file.)

So far so good. Tables, integration of latex fragments: great stuff. I
like the outlining capabilities but used most of them via
`org-struct-mode' already. Especially impressed with babel. Wow!

A couple of questions and observations, first impressions really:

 1. Publishing (I have only tested pdf) works pretty well. Obviously, or
 so I would have thought, I don't want to see todo-keywords and TAGs in
 the output. How do I get rid of them?

 2. Tags are SLOW (no doubt due to my 8.5M file). Completion takes
 minutes. I fixed that by adding all my (hundreds of) tags to
 `org-tag-alist' and restricting capture to »%g«, checking only the
 current file. `org-id-find' is slow as well and so will be property
 completions, I guess. How about caching the data and update on saving
 an org-agenda file?

 3. By default, tags cannot contain spaces or commas. I rectified that
 with an ugly hack in `org-set-tags-to', which replaces spaces with
 ?\x2008 (punctuation space), and setting it to word syntax. Also, many
 long tags display ugly. How about showing only the first twenty
 characters and show the rest via help echo?

 4. muse-mode has this nice feature that it easily allows you to define
 your own <tags> like
 <i-am-learning-kanji-so-better-display-this-big>…</…> or
 <a-citation-the-way-i-like-it>…</…>; not only for export but also for
 fontification. Can I do something similar in org-mode?

 5. According to the manual »TODO items are an integral part of the
 notes file«. I like that, but I do not find it so. TODO items are
 headings which I find somewhat confusing: My files are either articles
 to be (with the appropriate headlines) or notes where headlines usually
 formulate the topic the note is about. Todo items, on the other hand,
 would be »clarify the paragraph«, »check what X says about Y«, »add
 more sources«, etc. As it is TODOs are not integrated but stand out,
 breaking the structure of the file. How about allowing TODO items in
 comments? This would seem much more natural to me: a TODO item should
 not be part of your text but disappear when it is done.

-- 
Florian Beck

Re: Using org-mode for Research and Notetaking

[John Hendy]

On Mon, Jul 11, 2011 at 2:55 PM, Florian Beck <abstraktion@t-online.de> wrote:
> [My main goal is to take research notes and write texts. I have little
> interest in the todo/agenda part of org-mode, which I understand is its
> main focus, so bear this in mind.]

Snipped 1-4, as I don't have anything to add...

>  5. According to the manual »TODO items are an integral part of the
>  notes file«. I like that, but I do not find it so. TODO items are
>  headings which I find somewhat confusing: My files are either articles
>  to be (with the appropriate headlines) or notes where headlines usually
>  formulate the topic the note is about. Todo items, on the other hand,
>  would be »clarify the paragraph«, »check what X says about Y«, »add
>  more sources«, etc. As it is TODOs are not integrated but stand out,
>  breaking the structure of the file. How about allowing TODO items in
>  comments? This would seem much more natural to me: a TODO item should
>  not be part of your text but disappear when it is done.

I posted something similar a bit back. I do use org for todos, but
also write papers/reports, and take notes on things I'm reading. You
might want to check out that thread. [1] In particular, there were
some great comments about using inline tasks with custom export
options (one of them being the todonotes pacakge). [2] [3] Hope that
offers at least some input.

I think inline tasks can do what you want -- can be exported or not,
they stay out of the way, and don't break the flow. Good luck!

---

All from the same thread, but I skimmed it and picked these out in particular:

[1] Top level thread:
http://www.mail-archive.com/emacs-orgmode@gnu.org/msg40356.html
[2] Inline tasks suggestion:
http://www.mail-archive.com/emacs-orgmode@gnu.org/msg40359.html
[3] Todonotes variant:
http://www.mail-archive.com/emacs-orgmode@gnu.org/msg40589.html


John

>
> --
> Florian Beck
>
>

Re: Using org-mode for Research and Notetaking

[Giovanni Ridolfi]

Florian Beck <abstraktion@t-online.de> writes:

Hi, Florian,

My org version is:
Org-mode version 7.5 311b09d92644f39040087327d6a1dbeb09a9ab6e

> I don't want to see todo-keywords and TAGs in
>  the output. How do I get rid of them?
In the manual,

Export options.
#+OPTIONS:      todo: nil

manual explanation:

#+OPTIONS:      todo:   turn on/off inclusion of TODO keywords into exported text
                tags:    turn on/off inclusion of tags, may also be  `not-in-toc'

> How about caching the data and update on saving
>  an org-agenda file?

Bastien just said:
 "I've never been a big fan of caching Org files information, because Org
  files are often modified in impredictible ways.  But if we can update
  the cache quickly, then it will certainly be useful."

  However it will stress the disk.

>
>  3. By default, tags cannot contain spaces or commas. 
yes, but you can use underscore: "_"

[...]
> a TODO item should
>  not be part of your text but disappear when it is done.

you can archive the task/headline, when it is done.

cheers,
Giovanni

Re: Using org-mode for Research and Notetaking

[Bastien]

Hi Florian,

Florian Beck <abstraktion@t-online.de> writes:

> A couple of questions and observations, first impressions really:
>
>  2. Tags are SLOW (no doubt due to my 8.5M file). Completion takes
>  minutes. I fixed that by adding all my (hundreds of) tags to
>  `org-tag-alist' and restricting capture to »%g«, checking only the
>  current file. `org-id-find' is slow as well and so will be property
>  completions, I guess. How about caching the data and update on saving
>  an org-agenda file?

We might consider this.  

I doubt updating on saving is the right thing to do -- people tend to
save very often, and for solving problems like yours, it will be as slow
as the current interface.

We need to be more clever in defining the update cycle for caches, and
this depends on _what_ the cache is containing.

>  3. By default, tags cannot contain spaces or commas. I rectified that
>  with an ugly hack in `org-set-tags-to', which replaces spaces with
>  ?\x2008 (punctuation space), and setting it to word syntax. Also, many
>  long tags display ugly. How about showing only the first twenty
>  characters and show the rest via help echo?

You will need to live with it for now.

>  4. muse-mode has this nice feature that it easily allows you to define
>  your own <tags> like
>  <i-am-learning-kanji-so-better-display-this-big>…</…> or
>  <a-citation-the-way-i-like-it>…</…>; not only for export but also for
>  fontification. Can I do something similar in org-mode?

What do you mean?

What I can think of are "tag aliases": for example, the tag ":code:"
would be an alias for ":code python lisp:".

The buffer would display the alias.

Tag search would match the expanded version.

This adds a semantic layer for tags, so maybe there are complexities
I cannot think of right now, but I think it might be interesting.

What do you think?

>  5. According to the manual »TODO items are an integral part of the
>  notes file«. I like that, but I do not find it so. TODO items are
>  headings which I find somewhat confusing: My files are either articles
>  to be (with the appropriate headlines) or notes where headlines usually
>  formulate the topic the note is about. Todo items, on the other hand,
>  would be »clarify the paragraph«, »check what X says about Y«, »add
>  more sources«, etc. As it is TODOs are not integrated but stand out,
>  breaking the structure of the file. How about allowing TODO items in
>  comments? This would seem much more natural to me: a TODO item should
>  not be part of your text but disappear when it is done.

As suggested, you want to check inline tasks.

I really don't like the current syntax for inline tasks, I would much
prefer something like special TODO keywords:

* !TODO This would be an inline task, not a headline

But perhaps I'm missing something about why the current inline task
syntax is useful.  I'd be interested in hearing more by people who are
actually using them...

Thanks for your input!

-- 
 Bastien

Re: Using org-mode for Research and Notetaking

[Sebastien Vauban]

Hi Bastien,

Bastien wrote:
> As suggested, you want to check inline tasks.
>
> I really don't like the current syntax for inline tasks, I would much
> prefer something like special TODO keywords:
>
> * !TODO This would be an inline task, not a headline

I've no clear cut opinion on this right now. Maybe yes, maybe not.

> But perhaps I'm missing something about why the current inline task
> syntax is useful.  I'd be interested in hearing more by people who are
> actually using them...
>
> Thanks for your input!

Though, there are differences between inline tasks and headlines:

- inline tasks are delimited with an ****** END marker (many asterisks)

- hence, they can contain a lot of things inside them:
  + paragraphs
  + lists
  + etc.

I am sure they could somehow be improved, but I already use them a lot for the
big advantage they offer: being tasks, and not breaking the document structure
(not adding levels in your document).

Your proposition would be (very) nice when we don't have to link a note to the
task. Does that mean it should be added?  Does that mean that, then, the notes
could or should be made available thru drawers?

All such questions certainly merit more attention.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Using org-mode for Research and Notetaking

[Bastien]

Hi Sébastien,

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

>> * !TODO This would be an inline task, not a headline
>
> I've no clear cut opinion on this right now. Maybe yes, maybe not.

:)

> Though, there are differences between inline tasks and headlines:

Yep, I know the differences.

I'm talking about the way they _look_.  So many asterisks looks
cumbersome to mee, and I'd favor a non-intrusive syntax like the 
one proposed above.

My question was: what is the rationale behind using so many asterisks?

I can think of three things:

1. people want inline tasks with possibly no TODO keyword
2. people prefer to detect them *very easily*
3. changing the syntax of inline tasks from changing todos
   (like !TODO) is too complicated code-wise

My proposal is this:

- enforce the use of TODO keywords in inline tasks (wrt 1)
- make a special face for inline tasks (wrt 2)

> Your proposition would be (very) nice when we don't have to link a
> note to the task.

My change would affect the content you can add to inline tasks and 
the way they are treated by exporters.

> All such questions certainly merit more attention.

Sure -- thanks for your input!

-- 
 Bastien

Re: Using org-mode for Research and Notetaking

[Sebastien Vauban]

Hi Bastien,

Bastien wrote:
> "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>>> * !TODO This would be an inline task, not a headline
>>
>> I've no clear cut opinion on this right now. Maybe yes, maybe not.
>
> :)
>
>> Though, there are differences between inline tasks and headlines:
>
> Yep, I know the differences.

Not intended to you in particular, just to put context around my answer!

> I'm talking about the way they _look_.  So many asterisks looks
> cumbersome to mee, and I'd favor a non-intrusive syntax like the 
> one proposed above.
>
> My question was: what is the rationale behind using so many asterisks?

That's right there are a lot of them...

> I can think of three things:
>
> 1. people want inline tasks with possibly no TODO keyword

Of course, this is needed as well. Or maybe this is a wrong use of them: to
make things outstand as notes in the produced PDF (with todonotes package, in
my case, for the inline "tasks" -- or "notes" then).

> 2. people prefer to detect them *very easily*

Yes, for sure.

> 3. changing the syntax of inline tasks from changing todos
>    (like !TODO) is too complicated code-wise

Dunno.

> My proposal is this:
>
> - enforce the use of TODO keywords in inline tasks (wrt 1)

I'm divided about this, as you can see. Maybe, though, I have to respect the
fact that inline tasks are supposed to be _tasks_ which are inlined.

> - make a special face for inline tasks (wrt 2)

You see we're not far from it, and what I typically use inline tasks for...

http://i.imgur.com/rrI6Q.png

>> Your proposition would be (very) nice when we don't have to link a
>> note to the task.
>
> My change would affect the content you can add to inline tasks and 
> the way they are treated by exporters.
>
>> All such questions certainly merit more attention.
>
> Sure -- thanks for your input!

To be continued...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Using org-mode for Research and Notetaking

[Nicolas Goaziou]

Hello,

Bastien <bzg@altern.org> writes:

> I'm talking about the way they _look_.  So many asterisks looks
> cumbersome to mee, and I'd favor a non-intrusive syntax like the 
> one proposed above.
>
> My question was: what is the rationale behind using so many asterisks?
>
> I can think of three things:
>
> 1. people want inline tasks with possibly no TODO keyword
> 2. people prefer to detect them *very easily*
> 3. changing the syntax of inline tasks from changing todos
>    (like !TODO) is too complicated code-wise

4. people do not want to break the main flow of text. By default, the
   text in the inline task starts at the 15th column.
  
> My proposal is this:
>
> - enforce the use of TODO keywords in inline tasks (wrt 1)

I think it is an unnecessary restriction. I remember some people use
inline tasks without even a title (they only write the stars).

IMO, inline tasks are used in two distinct fashions. Obviously, one is
to use them as tasks. The other one is to use them as marginal notes,
like drawers with a title. Let's not forget that second category, unless
we provide an alternative solution for them, i.e. an annotation system.

> - make a special face for inline tasks (wrt 2)

I think it is a good idea.

>> Your proposition would be (very) nice when we don't have to link a
>> note to the task.
>
> My change would affect the content you can add to inline tasks and 
> the way they are treated by exporters.

For the record, there is also a degenerated version of inline tasks in
which "*************** END" is optional. Those cannot hold any contents,
though.

Regards,

-- 
Nicolas Goaziou

Re: Using org-mode for Research and Notetaking

[Florian Beck]

John Hendy <jw.hendy@gmail.com> writes:


> I posted something similar a bit back. I do use org for todos, but
> also write papers/reports, and take notes on things I'm reading. You
> might want to check out that thread. [1] In particular, there were
> some great comments about using inline tasks with custom export
> options (one of them being the todonotes pacakge). [2] [3] Hope that
> offers at least some input.
>
> I think inline tasks can do what you want -- can be exported or not,
> they stay out of the way, and don't break the flow. Good luck!

Thanks for the suggestion, I have to look into the export options.

> ---
>
> All from the same thread, but I skimmed it and picked these out in particular:
>
> [1] Top level thread:
> http://www.mail-archive.com/emacs-orgmode@gnu.org/msg40356.html
> [2] Inline tasks suggestion:
> http://www.mail-archive.com/emacs-orgmode@gnu.org/msg40359.html
> [3] Todonotes variant:
> http://www.mail-archive.com/emacs-orgmode@gnu.org/msg40589.html
>
>
> John
>
>>
>> --
>> Florian Beck
>>
>>
>
>

-- 
Florian Beck

Re: Using org-mode for Research and Notetaking

[Florian Beck]

Bastien <bzg@altern.org> writes:

>>  2. Tags are SLOW (no doubt due to my 8.5M file). Completion takes
>>  minutes. I fixed that by adding all my (hundreds of) tags to
>>  `org-tag-alist' and restricting capture to »%g«, checking only the
>>  current file. `org-id-find' is slow as well and so will be property
>>  completions, I guess. How about caching the data and update on saving
>>  an org-agenda file?
>
> We might consider this.  
>
> I doubt updating on saving is the right thing to do -- people tend to
> save very often, and for solving problems like yours, it will be as slow
> as the current interface.
>
> We need to be more clever in defining the update cycle for caches, and
> this depends on _what_ the cache is containing.

I agree, updating on saving would not work for large files. Maybe you
could use a cache on a per file basis, creating it when org first
happens to collect the data and updating it on demand. Of course, it
might be out of date, which in my case would be no problem.

> You will need to live with it for now.
>
>>  4. muse-mode has this nice feature that it easily allows you to define
>>  your own <tags> like
>>  <i-am-learning-kanji-so-better-display-this-big>…</…> or
>>  <a-citation-the-way-i-like-it>…</…>; not only for export but also for
>>  fontification. Can I do something similar in org-mode?
>
> What do you mean?
>
> What I can think of are "tag aliases": for example, the tag ":code:"
> would be an alias for ":code python lisp:".
>
> The buffer would display the alias.
>
> Tag search would match the expanded version.
>
> This adds a semantic layer for tags, so maybe there are complexities
> I cannot think of right now, but I think it might be interesting.
>
> What do you think?

Actually, I meant »tags« in the HTML sense. For <boxed>example</boxed>
would call a function during export, which returns, say, its LaTeX
interpretation, another function would be called by font lock (or
whatever you use) to determine its on screen display. That is, the user
has to provide two functions and org mode has to call them at the
appropriate place.

>
>>  5. According to the manual »TODO items are an integral part of the
>>  notes file«. I like that, but I do not find it so. TODO items are
>>  headings which I find somewhat confusing: My files are either articles
>>  to be (with the appropriate headlines) or notes where headlines usually
>>  formulate the topic the note is about. Todo items, on the other hand,
>>  would be »clarify the paragraph«, »check what X says about Y«, »add
>>  more sources«, etc. As it is TODOs are not integrated but stand out,
>>  breaking the structure of the file. How about allowing TODO items in
>>  comments? This would seem much more natural to me: a TODO item should
>>  not be part of your text but disappear when it is done.
>
> As suggested, you want to check inline tasks.

I'll look into it. Thanks for your comments!

>
> I really don't like the current syntax for inline tasks, I would much
> prefer something like special TODO keywords:
>
> * !TODO This would be an inline task, not a headline
>
> But perhaps I'm missing something about why the current inline task
> syntax is useful.  I'd be interested in hearing more by people who are
> actually using them...
>
> Thanks for your input!

-- 
Florian Beck

Re: Using org-mode for Research and Notetaking

[Thomas S. Dye]

Florian Beck <abstraktion@t-online.de> writes:

> Bastien <bzg@altern.org> writes:
>
>>>  2. Tags are SLOW (no doubt due to my 8.5M file). Completion takes
>>>  minutes. I fixed that by adding all my (hundreds of) tags to
>>>  `org-tag-alist' and restricting capture to »%g«, checking only the
>>>  current file. `org-id-find' is slow as well and so will be property
>>>  completions, I guess. How about caching the data and update on saving
>>>  an org-agenda file?
>>
>> We might consider this.  
>>
>> I doubt updating on saving is the right thing to do -- people tend to
>> save very often, and for solving problems like yours, it will be as slow
>> as the current interface.
>>
>> We need to be more clever in defining the update cycle for caches, and
>> this depends on _what_ the cache is containing.
>
> I agree, updating on saving would not work for large files. Maybe you
> could use a cache on a per file basis, creating it when org first
> happens to collect the data and updating it on demand. Of course, it
> might be out of date, which in my case would be no problem.
>
>> You will need to live with it for now.
>>
>>>  4. muse-mode has this nice feature that it easily allows you to define
>>>  your own <tags> like
>>>  <i-am-learning-kanji-so-better-display-this-big>…</…> or
>>>  <a-citation-the-way-i-like-it>…</…>; not only for export but also for
>>>  fontification. Can I do something similar in org-mode?
>>
>> What do you mean?
>>
>> What I can think of are "tag aliases": for example, the tag ":code:"
>> would be an alias for ":code python lisp:".
>>
>> The buffer would display the alias.
>>
>> Tag search would match the expanded version.
>>
>> This adds a semantic layer for tags, so maybe there are complexities
>> I cannot think of right now, but I think it might be interesting.
>>
>> What do you think?
>
> Actually, I meant »tags« in the HTML sense. For <boxed>example</boxed>
> would call a function during export, which returns, say, its LaTeX
> interpretation, another function would be called by font lock (or
> whatever you use) to determine its on screen display. That is, the user
> has to provide two functions and org mode has to call them at the
> appropriate place.

Aloha Florian,

This is partially implemented with Org-mode's link syntax.  See
http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-10-3 for
an example that defines LaTeX and HTML exports for arbitrary tags.

AFAIK, the link syntax lacks an easy way to change the function for
screen display, but this would be a useful addition to Org-mode.  Then,
it would be a relatively simple matter to provide functions that
differentiate on-screen between links used for different purposes.

There was a discussion along these lines on list some time ago under the
heading "text color + highlight".

hth,
Tom

>
>>
>>>  5. According to the manual »TODO items are an integral part of the
>>>  notes file«. I like that, but I do not find it so. TODO items are
>>>  headings which I find somewhat confusing: My files are either articles
>>>  to be (with the appropriate headlines) or notes where headlines usually
>>>  formulate the topic the note is about. Todo items, on the other hand,
>>>  would be »clarify the paragraph«, »check what X says about Y«, »add
>>>  more sources«, etc. As it is TODOs are not integrated but stand out,
>>>  breaking the structure of the file. How about allowing TODO items in
>>>  comments? This would seem much more natural to me: a TODO item should
>>>  not be part of your text but disappear when it is done.
>>
>> As suggested, you want to check inline tasks.
>
> I'll look into it. Thanks for your comments!
>
>>
>> I really don't like the current syntax for inline tasks, I would much
>> prefer something like special TODO keywords:
>>
>> * !TODO This would be an inline task, not a headline
>>
>> But perhaps I'm missing something about why the current inline task
>> syntax is useful.  I'd be interested in hearing more by people who are
>> actually using them...
>>
>> Thanks for your input!

-- 
Thomas S. Dye
http://www.tsdye.com

Re: Using org-mode for Research and Notetaking

[Bastien]

Hi all,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

>> 1. people want inline tasks with possibly no TODO keyword
>> 2. people prefer to detect them *very easily*
>> 3. changing the syntax of inline tasks from changing todos
>>    (like !TODO) is too complicated code-wise
>
> 4. people do not want to break the main flow of text. By default, the
>    text in the inline task starts at the 15th column.

Of course, you're right.

>> My proposal is this:
>>
>> - enforce the use of TODO keywords in inline tasks (wrt 1)
>
> I think it is an unnecessary restriction. I remember some people use
> inline tasks without even a title (they only write the stars).

Yes.

> IMO, inline tasks are used in two distinct fashions. Obviously, one is
> to use them as tasks. The other one is to use them as marginal notes,
> like drawers with a title. Let's not forget that second category, unless
> we provide an alternative solution for them, i.e. an annotation system.
>
>> - make a special face for inline tasks (wrt 2)
>
> I think it is a good idea.

Okay, TODO added.

Thanks,

-- 
 Bastien

Re: Using org-mode for Research and Notetaking

[Matt Lundin]

Bastien <bzg@altern.org> writes:

> "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:
>
>>> * !TODO This would be an inline task, not a headline
>>
>> I've no clear cut opinion on this right now. Maybe yes, maybe not.
>> Though, there are differences between inline tasks and headlines:
>
> I'm talking about the way they _look_.  So many asterisks looks
> cumbersome to mee, and I'd favor a non-intrusive syntax like the 
> one proposed above.

In my experience, most of the asterisks are made invisible by
org-hide-face. E.g.,

--8<---------------cut here---------------start------------->8---
*            ** TODO A task
		Some notes about the task that are not part of the text.
*            ** END
--8<---------------cut here---------------end--------------->8---

> My question was: what is the rationale behind using so many asterisks?
>
> I can think of three things:
>
> 1. people want inline tasks with possibly no TODO keyword

This is often how I use them --- to insert a "drawer" of notes that is
visible but will not be exported.

Best,
Matt

Re: Using org-mode for Research and Notetaking

[Sebastien Vauban]

Hi Matt,

Matt Lundin wrote:
> Bastien <bzg-whniv8GeeGkdnm+yROfE0A@public.gmane.org> writes:
>> "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>>
>>>> * !TODO This would be an inline task, not a headline
>>>
>>> I've no clear cut opinion on this right now. Maybe yes, maybe not.
>>> Though, there are differences between inline tasks and headlines:
>>
>> I'm talking about the way they _look_. So many asterisks looks cumbersome
>> to mee, and I'd favor a non-intrusive syntax like the one proposed above.
>
> In my experience, most of the asterisks are made invisible by
> org-hide-face. E.g.,
>
> *            ** TODO A task
> 		Some notes about the task that are not part of the text.
> *            ** END
>
>> My question was: what is the rationale behind using so many asterisks?
>>
>> I can think of three things:
>>
>> 1. people want inline tasks with possibly no TODO keyword
>
> This is often how I use them --- to insert a "drawer" of notes that is
> visible but will not be exported.

Why do you say it wouldn't be exported just because it has no TODO keyword?
At least, not in the default settings of the export, right?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Using org-mode for Research and Notetaking

[Sebastien Vauban]

Hi Matt,

Matt Lundin wrote:
> In my experience, most of the asterisks are made invisible by
> org-hide-face. E.g.,
>
> *            ** TODO A task
> 		Some notes about the task that are not part of the text.
> *            ** END

Any idea about the reason to make the first asterisk shine with face
`org-warning'? Could it be `org-hide' face as well?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Using org-mode for Research and Notetaking

[Matt Lundin]

"Sebastien Vauban"
<wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:

>>>
>>> 1. people want inline tasks with possibly no TODO keyword
>>
>> This is often how I use them --- to insert a "drawer" of notes that is
>> visible but will not be exported.
>
> Why do you say it wouldn't be exported just because it has no TODO keyword?
> At least, not in the default settings of the export, right?

Thanks for the clarification. I do indeed have set org-inlinetask-export
to nil. 

While most of my inline tasks have a TODO, some are used merely for
notes. I prefer not to export them in either case.

Best,
Matt

Re: Using org-mode for Research and Notetaking

[Bastien]

Hi Sébastien,

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> Any idea about the reason to make the first asterisk shine with face
> `org-warning'? Could it be `org-hide' face as well?

I guess using the `org-warning' face for the first asterisk of an inline
task helps distinguishing it from normal task.

I'd say it's a feature -- but I'm not an inline-task guru, feel free to
convince me otherwise.

:)

-- 
 Bastien

Re: Using org-mode for Research and Notetaking

[Bastien]

Hi Florian,

Florian Beck <abstraktion@t-online.de> writes:

> Actually, I meant »tags« in the HTML sense. For <boxed>example</boxed>
> would call a function during export, which returns, say, its LaTeX
> interpretation, another function would be called by font lock (or
> whatever you use) to determine its on screen display. 

Well, I'm not in favor of introducing <tag> -- they can be convenient,
but they degrade readability IMO.

-- 
 Bastien

Re: Using org-mode for Research and Notetaking

[Thomas S. Dye]

Bastien <bzg@altern.org> writes:

> Hi Florian,
>
> Florian Beck <abstraktion@t-online.de> writes:
>
>> Actually, I meant »tags« in the HTML sense. For <boxed>example</boxed>
>> would call a function during export, which returns, say, its LaTeX
>> interpretation, another function would be called by font lock (or
>> whatever you use) to determine its on screen display. 
>
> Well, I'm not in favor of introducing <tag> -- they can be convenient,
> but they degrade readability IMO.

Aloha all,

Perhaps they are [[tag:boxed][already]] here with org-add-link-type?  It
seems to me that all that's missing is a way to specify a function to
determine on screen display.  But, I might be missing something.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: Using org-mode for Research and Notetaking

[Florian Beck]

tsd@tsdye.com (Thomas S. Dye) writes:

> Bastien <bzg@altern.org> writes:
>
>> Hi Florian,
>>
>> Florian Beck <abstraktion@t-online.de> writes:
>>
>>> Actually, I meant »tags« in the HTML sense. For <boxed>example</boxed>
>>> would call a function during export, which returns, say, its LaTeX
>>> interpretation, another function would be called by font lock (or
>>> whatever you use) to determine its on screen display. 
>>
>> Well, I'm not in favor of introducing <tag> -- they can be convenient,
>> but they degrade readability IMO.
>
> Aloha all,
>
> Perhaps they are [[tag:boxed][already]] here with org-add-link-type?  It
> seems to me that all that's missing is a way to specify a function to
> determine on screen display.  

Exactly. I don't care about the specific implementation (and org makes a
lot of my previous uses superflous). TAGs in the above sense – however
implemented – would allow for fine grain control of the output. For
example different classes of footnotes with latex/bogfoot or specific
handling of citations.

Readability is not the issue, imo, because currently my workaround would
be to put the whole paragraph in a latex source block – which certainly
doesn't improve readability. Tagged text, on the other hand, should and
could definity allow for its own on screen display.

What is an issue is that (apart from property/source blocks and
emphasis) org text is pretty much plain. TAGs could impair that.
Currently migrating from muse to org I can certainly attest that any
»special handling« certainly impairs portability.

-- 
Florian Beck

Re: Using org-mode for Research and Notetaking

[Bastien]

Hi Tom,

tsd@tsdye.com (Thomas S. Dye) writes:

> Aloha all,
>
> Perhaps they are [[tag:boxed][already]] here with org-add-link-type?  It
> seems to me that all that's missing is a way to specify a function to
> determine on screen display.  But, I might be missing something.

just as a quick follow-up: I understand the need.  I will hack
org-link-protocols so that they can hold a custom face for each
link type.  But this won't happen for 7.7, only around mid-sept
if that's okay.

Thanks again for insisting on this, this will be quite a useful
addition!

Best,

-- 
 Bastien

Re: Using org-mode for Research and Notetaking

[Florian Beck]

Bastien <bzg@altern.org> writes:

> Hi Tom,
>
> tsd@tsdye.com (Thomas S. Dye) writes:
>
>> Aloha all,
>>
>> Perhaps they are [[tag:boxed][already]] here with org-add-link-type?  It
>> seems to me that all that's missing is a way to specify a function to
>> determine on screen display.  But, I might be missing something.
>
> just as a quick follow-up: I understand the need.  I will hack
> org-link-protocols so that they can hold a custom face for each
> link type.  But this won't happen for 7.7, only around mid-sept
> if that's okay.

IIUC, entries would be of the form (TYPE FOLLOW EXPORT FACE).

What if instead of FACE you could (alternativly) specify a function that
supplied additional text properties? Possibly a face, of course, but
also interesting are `display' and `help-echo'.

I'm not a programmer, but I got this working with quite small changes
(rather untested, I admit):

diff -c /home/flo/elisp/org-mode/lisp/org.el /home/flo/tmp/org.el
*** /home/flo/elisp/org-mode/lisp/org.el	2011-07-26 15:52:16.160581036 +0200
--- /home/flo/tmp/org.el	2011-07-26 16:16:00.022669409 +0200
***************
*** 5315,5331 ****
  (defun org-activate-bracket-links (limit)
    "Run through the buffer and add overlays to bracketed links."
    (if (re-search-forward org-bracket-link-regexp limit t)
!       (let* ((help (concat "LINK: "
! 			   (org-match-string-no-properties 1)))
  	     ;; FIXME: above we should remove the escapes.
  	     ;; but that requires another match, protecting match data,
  	     ;; a lot of overhead for font-lock.
  	     (ip (org-maybe-intangible
  		  (list 'invisible 'org-link
  			'keymap org-mouse-map 'mouse-face 'highlight
  			'font-lock-multiline t 'help-echo help)))
! 	     (vp (list 'keymap org-mouse-map 'mouse-face 'highlight
! 		       'font-lock-multiline t 'help-echo help)))
  	;; We need to remove the invisible property here.  Table narrowing
  	;; may have made some of this invisible.
  	(org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0))
--- 5315,5348 ----
  (defun org-activate-bracket-links (limit)
    "Run through the buffer and add overlays to bracketed links."
    (if (re-search-forward org-bracket-link-regexp limit t)
!       (let* ((path (org-match-string-no-properties 1))
! 	     (help (concat "LINK: " path))
! 	     (type (save-match-data
! 		     (if (string-match
! 			  "^\\(.*?\\):"
! 			  path)
! 			 (org-match-string-no-properties 1 path))))
  	     ;; FIXME: above we should remove the escapes.
  	     ;; but that requires another match, protecting match data,
  	     ;; a lot of overhead for font-lock.
+ 	     (custom-attr-1 (nth 3 (assoc type org-link-protocols)))
+ 	     ;; Check if `org-link-protocols' is a face or a function
+ 	     ;; that returns text properties.
+ 	     (custom-attr
+ 	       (if (and custom-attr-1
+ 			(facep custom-attr-1))
+ 		   `(face ,custom-attr-1)
+ 		 (funcall (or custom-attr-1 'ignore) path)))
  	     (ip (org-maybe-intangible
  		  (list 'invisible 'org-link
  			'keymap org-mouse-map 'mouse-face 'highlight
  			'font-lock-multiline t 'help-echo help)))
! 	     (vp (append
! 		  (list 'keymap org-mouse-map 'mouse-face 'highlight
! 			'face 'org-link
! 			'font-lock-multiline t 'help-echo help)
! 		  ;; Let custom settings override the default.
! 		  custom-attr)))
  	;; We need to remove the invisible property here.  Table narrowing
  	;; may have made some of this invisible.
  	(org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0))
***************
*** 5602,5608 ****
  	   (if (memq 'tag lk) '(org-activate-tags (1 'org-tag prepend)))
  	   (if (memq 'angle lk) '(org-activate-angle-links (0 'org-link t)))
  	   (if (memq 'plain lk) '(org-activate-plain-links))
! 	   (if (memq 'bracket lk) '(org-activate-bracket-links (0 'org-link t)))
  	   (if (memq 'radio lk) '(org-activate-target-links (0 'org-link t)))
  	   (if (memq 'date lk) '(org-activate-dates (0 'org-date t)))
  	   (if (memq 'footnote lk) '(org-activate-footnote-links))
--- 5619,5625 ----
  	   (if (memq 'tag lk) '(org-activate-tags (1 'org-tag prepend)))
  	   (if (memq 'angle lk) '(org-activate-angle-links (0 'org-link t)))
  	   (if (memq 'plain lk) '(org-activate-plain-links))
! 	   (if (memq 'bracket lk) 'org-activate-bracket-links)
  	   (if (memq 'radio lk) '(org-activate-target-links (0 'org-link t)))
  	   (if (memq 'date lk) '(org-activate-dates (0 'org-date t)))
  	   (if (memq 'footnote lk) '(org-activate-footnote-links))
***************
*** 8437,8444 ****
    (add-to-list 'org-link-types type t)
    (org-make-link-regexps)
    (if (assoc type org-link-protocols)
!       (setcdr (assoc type org-link-protocols) (list follow export))
!     (push (list type follow export) org-link-protocols)))
  
  (defvar org-agenda-buffer-name)
  
--- 8454,8461 ----
    (add-to-list 'org-link-types type t)
    (org-make-link-regexps)
    (if (assoc type org-link-protocols)
!       (setcdr (assoc type org-link-protocols) (list follow export face))
!     (push (list type follow export face) org-link-protocols)))
  
  (defvar org-agenda-buffer-name)
  

Diff finished.  Tue Jul 26 16:16:12 2011

-- 
Florian Beck

Re: Using org-mode for Research and Notetaking

[Thomas S. Dye]

Bastien <bzg@altern.org> writes:

> Hi Tom,
>
> tsd@tsdye.com (Thomas S. Dye) writes:
>
>> Aloha all,
>>
>> Perhaps they are [[tag:boxed][already]] here with org-add-link-type?  It
>> seems to me that all that's missing is a way to specify a function to
>> determine on screen display.  But, I might be missing something.
>
> just as a quick follow-up: I understand the need.  I will hack
> org-link-protocols so that they can hold a custom face for each
> link type.  But this won't happen for 7.7, only around mid-sept
> if that's okay.
>
> Thanks again for insisting on this, this will be quite a useful
> addition!
>
> Best,
Aloha Bastien,

That's great news.  Links are incredibly handy.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: Using org-mode for Research and Notetaking

[Christian Moe]

+1.

No hurry.

Yours,
Christian

On 7/26/11 5:15 PM, Thomas S. Dye wrote:
> Bastien<bzg@altern.org>  writes:
>
>> Hi Tom,
>>
>> tsd@tsdye.com (Thomas S. Dye) writes:
>>
>>> Aloha all,
>>>
>>> Perhaps they are [[tag:boxed][already]] here with org-add-link-type?  It
>>> seems to me that all that's missing is a way to specify a function to
>>> determine on screen display.  But, I might be missing something.
>>
>> just as a quick follow-up: I understand the need.  I will hack
>> org-link-protocols so that they can hold a custom face for each
>> link type.  But this won't happen for 7.7, only around mid-sept
>> if that's okay.
>>
>> Thanks again for insisting on this, this will be quite a useful
>> addition!
>>
>> Best,
> Aloha Bastien,
>
> That's great news.  Links are incredibly handy.
>
> All the best,
> Tom
>