From: Jambunathan K <kjambunathan@gmail.com>
To: "T.F. Torrey" <tftorrey@tftorrey.com>
Cc: emacs-orgmode@gnu.org, n.goaziou@gmail.com
Subject: Re: [new exporter] [html] Tables of Contents
Date: Wed, 06 Mar 2013 15:40:08 +0530 [thread overview]
Message-ID: <87wqtk96v3.fsf@gmail.com> (raw)
In-Reply-To: <87r4jszwj6.fsf@lapcat.tftorrey.com> (T. F. Torrey's message of "Wed, 06 Mar 2013 02:51:09 -0700")
tftorrey@tftorrey.com (T.F. Torrey) writes:
>>> This gives a significant advantage in that authors can link to the
>>> various instances just by knowing their own usage. For instance, if
>>> they provided a top-level toc at the beginning of their book, and a
>>> deeper-level toc later on, they could link to each separately by id by
>>> knowing this plan.
>>
>> This seems like a valid use-case.
>>
>> I would recommend that you just specify just the use-case and leave out
>> the "how"s of implementation.
>>
>> Put your user hat and set aside the developer's hat.
>
> What a strange, semi-insulting thing to say.
There is nothing strange in what I said. I wasn't insulting.
> And misguided, too, as I was suggesting a design, not its
> implementation. As someone with all my own documents in Org and
> extensive experience developing XSLT and lisp to process the XHTML
> output of Org, I appreciate when the design of the HTML output is
> logical and useful.
When you were suggesting
#+toc: :a b :b c :c d
that is implementation specifics and you were arguing from a HTML
standpoint. If you were in fact designing, you would have articulated
your case for other backends and how your suggested changes would impact
ox.el.
> I would rather see a good design implemented in hacks than a poor design
> implemented in beautiful code.
If you have better ideas, show us the patch.
Otherwise, I suggest that you wear your user hat and place the use-case
before use while others can take care of the details.
next prev parent reply other threads:[~2013-03-06 10:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-04 19:57 [new exporter] [html] Tables of Contents T.F. Torrey
2013-03-04 20:30 ` Nicolas Goaziou
2013-03-04 23:10 ` T.F. Torrey
2013-03-05 7:53 ` Nicolas Goaziou
2013-03-05 20:21 ` T.F. Torrey
2013-03-06 4:17 ` Jambunathan K
2013-03-06 4:36 ` Jambunathan K
2013-03-06 12:04 ` Jambunathan K
2013-03-06 21:37 ` T.F. Torrey
2013-03-07 7:57 ` Jambunathan K
2013-03-06 9:51 ` T.F. Torrey
2013-03-06 10:10 ` Jambunathan K [this message]
2013-03-06 20:59 ` T.F. Torrey
2013-03-06 22:42 ` Bastien
2013-03-07 0:27 ` Jambunathan K
2013-03-07 9:10 ` Bastien
2013-03-07 9:24 ` Jambunathan K
2013-03-10 5:20 ` Samuel Wales
2013-03-10 5:42 ` Jambunathan K
2013-03-10 9:35 ` Bastien
2013-03-07 0:33 ` Jambunathan K
2013-03-06 10:35 ` Jambunathan K
2013-03-06 21:21 ` T.F. Torrey
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=87wqtk96v3.fsf@gmail.com \
--to=kjambunathan@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=n.goaziou@gmail.com \
--cc=tftorrey@tftorrey.com \
/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).