From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Org-mode version 4.68 Date: Fri, 16 Mar 2007 18:08:33 +0100 Message-ID: References: <1c43fad8a5823dc1386f861a4984ae26@science.uva.nl> <87tzwle93o.fsf@bzg.ath.cx> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HSGXY-0007mN-6Z for emacs-orgmode@gnu.org; Fri, 16 Mar 2007 13:48:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HSGXV-0007lf-8N for emacs-orgmode@gnu.org; Fri, 16 Mar 2007 13:48:31 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HSGXV-0007lc-0N for emacs-orgmode@gnu.org; Fri, 16 Mar 2007 12:48:29 -0500 Received: from korteweg.uva.nl ([146.50.98.70]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HSGWM-0001WV-FZ for emacs-orgmode@gnu.org; Fri, 16 Mar 2007 13:47:18 -0400 In-Reply-To: <87tzwle93o.fsf@bzg.ath.cx> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien Cc: emacs-orgmode@gnu.org 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 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