Re: [O] Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]
Ivy Foster joyfulg...@archlinux.us writes: On 09 Mar 2012, at 3:09 am +0100, Bastien wrote: Mathias Bauer mba...@gmx.org writes: As default, all level 1 headlines are underlined by - characters and level 2 headlines with =. Wouldn't it be more logical the other way round Unless many users think this is illogical, I won't change the default. Personally, I tend to agree with Mathias here. Maybe it's just because I like Markdown, but the `=' underline just feels like stronger emphasis to me. (Of course, I keep meaning to write a Markdown exporter, but also keep putting it off, so there you go.) This is what is now in the master branch (org-ascii.el): (defcustom org-export-ascii-underline '(?\= ?\- ?\~ ?\^ ?\. ?\# ?\$) Thanks to all for the feedback, and to Mathias for the initial suggestion! -- Bastien
Re: [O] Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]
Hello, Carsten Dominik carsten.domi...@gmail.com writes: For what it is worth, I do agree that this looks wrong now and changing it would make it better. I do not remember why I chose the sequence that we have now. Looking at it now, I would also insert ... after ^^, and hope that # and $ never get any use :) For the record, `e-ascii' back-end currently uses the following default set-up: #+begin_src emacs-lisp (defcustom org-e-ascii-underline '((ascii ?= ?~ ?-) (latin1 ?= ?~ ?-) (utf-8 ?═ ?─ ?╌ ?┄ ?┈)) Characters for underlining headings in ASCII export. Alist whose key is a symbol among `ascii', `latin1' and `utf-8' and whose value is a list of characters. For each supported charset, this variable associates a sequence of underline characters. In a sequence, the characters will be used in order for headlines level 1, 2, ... If no character is available for a given level, the headline won't be underlined. :group 'org-export-e-ascii :type '(list (cons :tag Underline characters sequence (const :tag ASCII charset ascii) (repeat character)) (cons :tag Underline characters sequence (const :tag Latin-1 charset latin1) (repeat character)) (cons :tag Underline characters sequence (const :tag UTF-8 charset utf-8) (repeat character #+end_src IMO, , ^, #, $$ are just ugly and should require user's approval (i.e. customization). Regards, -- Nicolas Goaziou
Re: [O] Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]
For me, it makes a lot of sense to invert both, as Mathias is suggesting it. +1 It would conform more to a sort of standard that way, (see http://en.wikipedia.org/wiki/Lightweight_markup_language#Section_headers) Best regards, Seb -- Sebastien Vauban /Gustav
Re: [O] Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]
Hi Gustav, * Gustav Wikström gustav.e...@gmail.com [09. Mar. 2012]: For me, it makes a lot of sense to invert both, as Mathias is suggesting it. +1 +1 It would conform more to a sort of standard that way, (see http://en.wikipedia.org/wiki/Lightweight_markup_language#Section_headers) We did it this way on mechanical typewriters. Fred Flintstone
Re: [O] Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]
On 09 Mar 2012, at 3:09 am +0100, Bastien wrote: Mathias Bauer mba...@gmx.org writes: As default, all level 1 headlines are underlined by - characters and level 2 headlines with =. Wouldn't it be more logical the other way round Unless many users think this is illogical, I won't change the default. Personally, I tend to agree with Mathias here. Maybe it's just because I like Markdown, but the `=' underline just feels like stronger emphasis to me. (Of course, I keep meaning to write a Markdown exporter, but also keep putting it off, so there you go.) Ivy
Re: [O] Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]
On 9.3.2012, at 11:12, Sebastien Vauban wrote: Hi Bastien and Mathias, Bastien wrote: As default, all level 1 headlines are underlined by - characters and level 2 headlines with =. Wouldn't it be more logical the other way round: the lower the level, the more important the headline and hence the bigger its underlining? (Of course the user can change the variable org-export-ascii-underline.) Unless many users think this is illogical, I won't change the default. To be honest, fixing this was on my (huge) todo list: I've always found it disturbing to have more imposing level-2 titles than the level-1 titles. For me, it makes a lot of sense to invert both, as Mathias is suggesting it. For what it is worth, I do agree that this looks wrong now and changing it would make it better. I do not remember why I chose the sequence that we have now. Looking at it now, I would also insert ... after ^^, and hope that # and $ never get any use :) Also I do not remember to consciously make the underlining one character too long but I also agree with Bastien that it does not look bad. Maybe another variable. - Carsten Best regards, Seb -- Sebastien Vauban
Re: [O] Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]
Hi Mathias, Mathias Bauer mba...@gmx.org writes: I just played with org's export functionality and following minimal org file. This results in three minor bugs and two proposals/questions on org's behavior. Thanks for this report -- next time, please consider sending one mail per bug/request, it makes issues easier to track. ** Bug 1: Underlining the headlines Headlines without tags are underlined in a wrong manner. It's one character too long. It's a matter of taste. I like this additionnal character and I think Carsten added it intentionally. ** Question/Proposal As default, all level 1 headlines are underlined by - characters and level 2 headlines with =. Wouldn't it be more logical the other way round: the lower the level, the more important the headline and hence the bigger its underlining? (Of course the user can change the variable org-export-ascii-underline.) Unless many users think this is illogical, I won't change the default. * HTML export ** Question/Proposal --snip-- h2...Some section with TAG at the end nbsp;nbsp;nbsp;span class=tagspan class=some_tagsome_tag... --snip-- Isn't a single space enough for separating the heading's text and the tag? Beside their number, the additional three (why not five or n?) nbsp; seem a little bit freaky to me... They _are_ freaky :) But they are also needed. Even if the tags display is taken care of by the CSS, we must prevent collapsing the tags with the previous strings in case the CSS is not available -- just think of what the HTML page should look like with w3m/lynx. ** Bug 2: Exporting the tag into the toc Adding #+OPTIONS: tags:t results in the following exported toc: --snip-- li...Some section with TAG at the endnbsp;nbsp;nbsp;span class=tag some_tag/span/a/li --snip-- There is a space inside the span.../span just before the tag name which should not be there. Fixed, thanks. ** Bug 3: Exporting the TODO keywords --snip-- h2...span class=todo TODO TODO/span Some section with a TODO keyword/h2 --snip-- There is a space inside the span.../span just before the TODO keyword which should not be there. Fixed, thanks. -- Bastien
Re: [O] Bug: 3 bugs and 2 proposals on ascii/html export [7.8.03]
Hi Bastien, * Bastien wrote on 2012-03-09 at 03:09 (+0100): Mathias Bauer mba...@gmx.org writes: Thanks for this report -- next time, please consider sending one mail per bug/request, it makes issues easier to track. ok, I'll do so - even for small bugs. Promised :-) Headlines without tags are underlined in a wrong manner. It's one character too long. It's a matter of taste. I like this additionnal character and I think Carsten added it intentionally. Hm, yes it is. I just wondered because the strings of the title and the toc headline have a different underlining. --snip-- h2...Some section with TAG at the end nbsp;nbsp;nbsp;span class=tagspan class=some_tagsome_tag... --snip-- Isn't a single space enough for separating the heading's text and the tag? Beside their number, the additional three (why not five or n?) nbsp; seem a little bit freaky to me... They _are_ freaky :) But they are also needed. Even if the tags display is taken care of by the CSS, we must prevent collapsing the tags with the previous strings in case the CSS is not available -- just think of what the HTML page should look like with w3m/lynx. Thanks for your explanation. I completely missed text based browsers. And ordinary spaces are _really_ not enough for them? Concerning CSS I'm digging into the docs ... but tomorrow :-) Regards, Mathias
