From: Carsten Dominik <dominik@science.uva.nl>
To: Bastien <bzg@altern.org>
Cc: emacs-orgmode@gnu.org
Subject: Re: Org-mode version 4.68
Date: Fri, 16 Mar 2007 18:08:33 +0100 [thread overview]
Message-ID: <b21e6a719e5c39840831e1ecd328e4a4@science.uva.nl> (raw)
In-Reply-To: <87tzwle93o.fsf@bzg.ath.cx>
Hi Bastien,
On Mar 16, 2007, at 12:11, Bastien wrote:
> * org-publish issues
>
> C-c C-e A (org-publish-all) won't save the window configuration,
> depending on what buffers are to be saved and published.
>
> Using timestamps for org-publish is *very convenient*. But forcing
> re-publication of all the pages (C-u C-c C-e a), makes emacs
> complains
> about missing directories in ~/.org-timestamps when a project has not
> been normally published first (with C-c C-e P or C-c C-e A). I think
> forced re-publication should create these directories itself.
I have forwarded this mail to David O'Toole, to find out if he still
feels responsible for changes in org-publish. Lets wait if he responds.
>
> * Table navigation / edition
>
> What about using C-c <return> to insert a plain |---- line *and* go
> down
> to a cell ? Currently, it's still bounded to org-insert-heading.
Do you mean down to a cell in the current column, or down to the first
cell in the row below the newly inserted hline?
> I was also wondering if it's possible to tell orgtbl-mode not to
> consider
> each line as a separate row. For example :
>
> |---------------------+------------------|
> | Cell#1 Row#1 | Cell#2 Row#1 |
> | (Might this belong | (...and this |
> | to the first cell?) | to the second? |
> |---------------------+------------------|
> | Cell#1 Row#2 | Cell#2 Row#2 |
> | Comment in row#2 | Comment in row#2 |
> |---------------------+------------------|
>
> would be only *two* rows when exporting to HTML. (I know i can
> narrow
> columns, but sometimes it's convenient to actually see the content
> of all
> the cells...)
No. The org-mode tables are deeply rooted on the fact that a cell
covers only a single line. Much of the easy and speed in operating the
table editor depends on it, and I don't want to compromise on that.
You have two options:
1. Make a table using the table.el package. The HTML exporter does
export such tables correctly. table.el is really good at what
it does, which is creating tables just like your example above.
But when you use it, you immediately feel the overhead that is
associated with a complex table structure like this.
2. You can spread the content of a long cell over several lines
by hand, org-mode helps with several commands like M-RET to
split a field in the middle and put the second half into the
next row, or C-c C-q which wraps a long cell over a couple
of rows. However, these commands do not change the fact that
org-mode sees each line as a new row and will export like that.
> * 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.
Hmmm, not clear to me how exactly this should be done. Should we
cast a vote for exporting text before the first heading?
> * *[[link]]* are not boldified when exported to HTML.
No it does not. Should it? What is the purpose of making
some links bold? Are you thinking about internal or
external links? Would CSS maybe be a better place to address
formatting of links?
> * .ics export bugs
>
> I'm not sure about the definition of X-WR-CALNAME: in .ics files (i
> can't
> find it in RFCs), but i assume it's the "name" of the calendar. It's
> currently set up to "OrgMode". I think it should be the actual name
> of
> the org file, or a default name for combined agendas.
Sounds resonable.
> Another tiny thing: if the descriptive part of a link (within a
> heading)
> contains a comma (`,') then the entry in the .ics file will ignore
> what
> comes before the comma.
I cannot reproduce this. Could you make an example file and show the
.ics entry you get? Thanks!
- Carsten
next prev parent reply other threads:[~2007-03-16 17:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-13 4:31 Org-mode version 4.68 Carsten Dominik
2007-03-16 11:11 ` Bastien
2007-03-16 17:08 ` Carsten Dominik [this message]
2007-03-16 18:39 ` Bastien
2007-03-18 7:00 ` Carsten Dominik
2007-03-17 11:38 ` David O'Toole
2007-03-31 21:58 ` T. V. Raman
2007-05-21 6:36 ` Carsten Dominik
2007-03-19 14:21 ` Alex Fu
2007-03-20 12:14 ` Carsten Dominik
2007-03-21 6:59 ` Carsten Dominik
2007-03-21 8:58 ` Bastien
2007-03-22 8:25 ` Leo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b21e6a719e5c39840831e1ecd328e4a4@science.uva.nl \
--to=dominik@science.uva.nl \
--cc=bzg@altern.org \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).