Bastien <[EMAIL PROTECTED]> writes: > Michael Olson <[EMAIL PROTECTED]> writes: > >> Bastien <[EMAIL PROTECTED]> writes: > >>> Timestamps? >> >> I'm not convinced that this is a useful feature. Surely there's a >> minor mode for simple insertion of timestamps. > > I should have said timestamps manipulation. For example, behing able > to quickly insert something like <2007-09-29 sam 13:00>, to update it, > to make it a active/scheduled/deadline timestamp. The way Org lets you > go through the calendar, pick up a date in the future, add "13:00" for > making this date an appointment... all this is at the very heart of > Org's daily use.
Planner has deadline timestamps that automatically update themselves
whenever you do M-x plan to open up the latest daypage. I can't imagine
a need for "active" or "scheduled" timestamps, whatever those are.
>> Using task IDs, Planner can update changes made to a task on one page
>> to instances of the same task on different pages. It's really nifty,
>> and it is one of the things that really makes Planner work well.
>
> Right. But Org's people don't have the same tasks on different files.
> So they don't need such a workaround :)
What about tasks that might relate to two different projects? Planner
can treat parenthesized project names at the end of a task as if they
were "tags", and updates the instance of the task on each "tag" whenever
it gets edited (and then saved) on the page.
Example (all on one line):
#B _ Make IPMI/SNMP/database stuff {{Tasks:136}} (TaskPool
DbProject IpmiProject)
> Honestly, I cannot think of a single feature that should not be
> considered "core" feature for Org. Even features that might be
> considered minor (e.g. the possibility to use abbrevs for links) are
> so closely related to the general links approach that it wouldn't make
> sense to put them in some modular file.
>
> This is entirely personal, but one thing that let me progressively
> slip away from planner was the maintainability of its configuration. I
> tried to keep it very minimal, but I always had to add/remove
> requirements...
Maybe Planner and Muse should go farther with the modular idea and make
it possible to edit just a variable (`planner-modules' for Planner and
`muse-modules' for Muse), which would (1) cause the files to be loaded
(via require) whenever a Muse or Planner file would be viewed, (2)
enable the functionality of that module, so no insinuation function
needs to be called. What do people think of this idea?
>> That's not the same thing. The Elisp in those Org links don't get
>> evaluated at display time -- they get evaluated when you click on
>> them.
>
> Right. But isn't this a bit dangerous? I mean: just like local
> variables and evals might be dangerous. Org lets you add local
> variables and lisp code will be executed from here.
Not really. It's not like each Planner instance is a publicly
accessible wiki, where anyone can edit the files. And that feature
(eval elisp in <lisp> tags at display time) can be disabled, if people
are really worried, by modifying muse-colors-evaluate-lisp-tags.
> For dynamic parts of the page, Org has dynamic blocks:
>
> http://orgmode.org/org.html#Dynamic-blocks
>
> The cool thing about them is that you can share them. I don't know
> any such repository, but it would be useful.
You can share the contents of <lisp> tags as well, so I don't see what
the point is. Most often people add custom Lisp functions to their
config, and share their entire config. Some add-ons that are now
included with Planner probably began existence that way.
Additionally, you have to hit extra keystrokes in order to evaluate the
code. That's bad if you have code that you want to be updated
constantly (like a report), because then the output is stale unless you
remember to hit those keystrokes periodically.
> I've been coding org-export-latex.el so I know a bit about what a
> nightmare it could be to handle escaped characters/strings. And this
> issue is very complicated in Org, especially because it can handle so
> many LaTeX constructs natively.
>
> So, yes, Org knows about escaping chars, at least both in the HTML and
> LaTeX exports.
Ah, I didn't realize that LaTeX publishing was implemented in a separate
file. Some notes follow, in order to be helpful:
Characters escaped by Muse but not org-export-latex.el (for normal text,
presented in form of a mapping of char to its escaped variant):
(?\< . "\\textless{}") ; possibly done for look rather than
(?\> . "\\textgreater{}") ; necessity
(?\~ . "\\~{}") ; not mentioned in org notes, but escaped by org
(?\@ . "\\@") ; not escaped, AFAICT
Characters escaped differently by Muse:
(?\\ . "\\textbackslash{}")
(?\_ . "\\textunderscore{}")
> By the way, Org has #+HTML lines and #+BEGIN_HTML/#+END_HTML to let
> you insert HTML-export-only code. I guess do you have something
> similar, is it documented somewhere?
Yep.
<literal style="html">
Only published in HTML output.
</literal>
This has the advantage of being generic -- it can apply to any output
style, just by changing the "style" argument.
<literal style="latex">
Only published in LaTeX output.
</literal>
Documentation: (info "(muse)Paragraphs")
(The DNS for my website is currently messed up, otherwise I'd give you
an HTML link.)
>> Additionally, Planner can do inline LaTeX: just
>>
>> (require 'muse-latex2png)
>
> Can you use this infile? Org do this with dvipng, and lets you see
> LaTeX formulas in the Org buffer directly.
Yes. They can be published inline -- that's the behavior of both
<latex> and <math>, though it is also possible to center the <math> tag
on its own line (at least 6 spaces in front), which makes it use "$$"
instead of "$".
Short example:
<math>r = \frac{-1}{5} \pm \frac{\sqrt{34}}{5}i</math>
Longer example:
<math>u=2 e^{-t/5}\cos{\left( \frac{\sqrt{34}t}{5} \right)}
+ \frac{7}{\sqrt{34}} e^{-t/5}\sin{\left( \frac{\sqrt{34}t}{5} \right)}
</math>
By "see LaTeX formulas", do you mean "generate a PNG file, and then view
the PNG file from inside of Emacs"? If so, Muse does not yet have that,
but it sounds useful; might have to add it in a subsequent release.
>> I imagine that people would probably trip over the Org syntax if they
>> were writing a lot of monetary amounts ("$100, $200", etc.), but I
>> could be wrong.
>
> Regexps are safe on this. No complaints so far! Thanks for your answer
> and time. I think I'm done with a decent comparison table, unless you
> say I forgot something of importance.
I don't agree with Planner getting a "no" on embedded LaTeX. If it is
indeed the case that Org can preview LaTeX regions while editing an Org
file, it would be best to put that in a separate "preview LaTeX" entry.
--
Michael Olson -- FSF Associate Member #652 |
http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net | /` |\ | | |
Sysadmin -- Hobbies: Lisp, GP2X, HCoop | |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
pgpJKaUPDmD6S.pgp
Description: PGP signature
_______________________________________________ Planner-el-discuss mailing list [email protected] https://mail.gna.org/listinfo/planner-el-discuss
