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. --
> #+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.
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
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
[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
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 > >
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
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
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
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
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
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
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
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
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
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
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
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
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
"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
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
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
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
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
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
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
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
+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
>