Hello all,
When using the #+TEXT:, #+HTML:, or #BEGIN_HTML...#END_HTML directives to
output literal html fragments, the resulting markup is enclosed in a
paragraph with and tags. Whenever I need something else, I am
forced to inhibit their generation in clumsy ways, "cancelling out" the
opening and closing paragraph tags like this:
#+TEXT: @@@Back to
main@@@
or
#+HTML: Back to
main
Thus, I think it would be a good idea *not* to enclose literal html
fragments in a paragraph (...), given that the markup is already
being controlled through these directives.
* * *
Possible bug:
#+BEGIN_HTML...#+END_HTML blocks are not correctly interpreted if they
consist of multiline text. Only 1 line --the one exactly above
#+END_HTML-- is exported literally.
For example:
#+BEGIN_HTML
#+END_HTML
does right thing (well, almost, because of having to cancel out tags),
producing:
However,
#+BEGIN_HTML
#+END_HTML
produces:
Tested on org 4.68, GNU Emacs 22.0.92.1.
Kind regards.
--
Alex Fu
___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Dear all,
On Fri, 16 Mar 2007 13:08:33 -0400, Carsten Dominik
<[EMAIL PROTECTED]> wrote:
* Exporting text before the first heading ?
It seems that text before the first heading is not exported. Using
#+TEXT: might help, but #+TEXT: does not understand links. Is that
intentional ?
I guess this is not very well though-out, and maybe it would be good
to simply export the text before the first heading.
That TEXT is not HTML processed I would also consider as
a bug, but I know that some have made clever use of this bug
to insert custom HTML into a file. This is now no loger
necessary since you can embed protected HTML with special commands.
Note that the #+HTML: and #+BEGIN_HTML...#+END_HTML directives are not
(yet) a replacement for inserting literal html as it can be done using
#+TEXT:. As far as I've noticed, #+TEXT: inserts html (or any other text)
before the first heading (before the in the resulting html file),
something the #+HTML directives can't do, since the effect of placing it
before the first heading is null, as it is not exported.
I don't expect to use Org as a full-featured publishing engine. Still,
the following example represents a very specific use of #+TEXT: that I
need for implementing file-specific site navigation (as opposed to
project-specific, which in this case is configured using :preamble in
`org-publish-project-alist'). These are the relevant lines in the org
file:
-
#+TEXT: @@@Return to
introduction@@
* Sonata for Unaccompanied Achilles
^ will be exported as after ...
-
AFAIK, I can't use #+HTML: to insert that snippet before the , or
first level 'org' heading, which is what I need.
Hmmm, not clear to me how exactly this should be done. Should we
cast a vote for exporting text before the first heading?
This is my idea: if the text before the first heading were exported and
that included the #+HTML: directives, it would be one way (out of perhaps
a handful) to avoid having to use the #+HTML: and #+TEXT: directives for
the same purpose -- exporting literal html. In the end, for literal html
we'd just use #+HTML: anywhere in the file, while #+TEXT: could be
reserved for a different purpose.
Vote: +1
But the final decision should consider other (broader) aspects...
Kind regards.
--
Alex Fu
___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
On 2007-03-18, Carsten Dominik said:
> On Mar 16, 2007, at 18:38, Leo wrote:
>
>> Dear all,
>>
>> Put the following line in a buffer:
>> [[http://www.google.com][Musick is wrong]]
>>
>> then enable org-mode and flyspell-mode. Now right click on the word
>> "Musick" and you can see the behavior of mouse1 has be changed to yank
>> instead of opening the link.
>
> That will teach you!
> Don't misspell your links! :-)
>
>
> Well, competing overlays with competing keymaps, I really would
> not know how to fix this on my side. I know that ispell (and
> therefore flyspell) has some ways to not check TeX command names,
> for example. But I am not sure if this is extensible so that
> we could use it for org-mode, making it skip links. And I am
> not even sure if this is what you would want, because it is
> actually nice to have the description part of a link spell-checked!
>
> Summary:
>
> If you use flyspell, do actually use it to correct your typos :-)
>
> Cheers.
>
> - Carsten
For example, if I have an internal link [[* MFE][MFE]], mouse1 won't
bring it to the right place. This is when it is rather inconvenient.
--
Leo (GPG Key: 9283AA3F)
___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Carsten Dominik wrote:
No, this does not work. Could be done, of course, but adds complexity,
and I am sure once it is there, people will want to switch
TODO keywords constantly, filling the entire file with new #+TODO
statements. Does not feel right.
How about the following alternative:
Just make a long sequence containing all the subsequences,
like
#+SEQ_TODO: REPORT BUG KNOWNCAUSE RESOLVED TODO WAITING VERIFY DONE
You can then use command like `M-5 C-c C-t'
(or `5 t' in the agenda) to jump to
TODO in this sequence. Basically, you need to remember where
in your list the different sequences start, put items onto
the right starting point, and then work through your states.
Hmmm, looking at this it might actually be useful to
allow additional DONE states in the middle of the sequence, but
this will at least currently lead to problems, both when cycling
from DONE to nothing to TODO, and also in the highlighting
of TODO keywords in the agenda. I'll check if I can fix these
small issues.
I can see that my suggestion would add complexity in both code and org
files. Supporting multiple DONE states would be a nice, especially if
they integrate properly with the agenda.
R.
___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Hey, folks:
I've also been using org-mode with longlines-mode, and had noticed
that the two occasionally conflict. I've just developed workarounds
for the bugs that affect me, mostly inserting extra carriage returns
here and there to ensure the right line breaks for org-mode. Carsten,
if you have the option of minimizing these conflicts, that would be
great. Otherwise, I'll just keep doing it manually - these two modes
are both essential for my work now, so I'll do what it takes to make
them get along locally.
--Alan
--
Alan Dove, Ph.D.
[EMAIL PROTECTED]
917.273.0544
http://dovdox.com
Gizmo or Skype: alandove
___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
On Mar 19, 2007, at 4:22, Eddward DeVilla wrote:
Once again, it hit reply instead of reply-all.
Edd
-- Forwarded message --
From: Eddward DeVilla <[EMAIL PROTECTED]>
Date: Mar 18, 2007 10:04 PM
Subject: Re: [Orgmode] Feature in org-move-item-down
To: Mike Newman <[EMAIL PROTECTED]>
I sometimes have blank lines in list items. I have lists do
visibility cycling like headings and use them as light weight
headings. One thing I've found is that empty lines seem to be after
an item and not a part. Blank lines, with whitespace characters in
them seem to be a part of the item.
If at all, this may make a difference in visibility cycling (and
then only in Emacs 21), certainly not in the items.
- Carsten
___
Emacs-orgmode mailing list
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
