emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Feature request: lists with letters


From: Titus von der Malsburg
Subject: Re: [O] Feature request: lists with letters
Date: Fri, 03 Feb 2017 12:37:22 +0100
User-agent: mu4e 0.9.17; emacs 25.0.93.1


Eric Abrahamsen wrote:
>> Titus von der Malsburg <address@hidden> writes:
>>
>>> Correct me if I’m wrong but there are a lot of things in Org that are
>>> just about typesetting: *bold*, /italic/, _underlined_, =verbatim= and
>>> ~code~, +strike-through+.  Would you remove these things as well?
>>
>> I could argue that emphasis is not just about typesetting. It conveys
>> a meaning. How emphasis is rendered _is_ typesetting, however. For
>> example, "latex" and "beamer" export back-ends render bold text
>> differently.
>
>It's similar to how HTML went from <i> and <b> to <emph> and <strong>.
>The former were presentation directives. The latter are semantic
>directives. They're practically the same, for reasons of backwards
>compatibility, and conceptual continuity. Org's emphasis markers are
>similar -- they *look* like presentation directives, but at this point
>they're actually used as semantic directives.

Hi Eric,

I appreciate that it makes sense to make Org more consistent and to use
abstract principles to guide its design.  However, I’m not convinced by
the analogy to HTML since there are some crucial differences between Org
and HTML.

First, HTML is not supposed to be read by humans – it is code.  In
contrast to that, Org is supposed to be human readable and hence, it has
to deal with visual presentation to some degree.  And it actually does:
when I write *bold* in Emacs, a bold font is used.  Nicholas’ point that
Org’s bold has nothing to do with bold fonts is therefore not entirely
correct.  Bold clearly means bold in Org, even if the beamer exporter
interprets this otherwise (which I always found annoying).

Secondly, HTML can afford to be purely semantic because there is CSS to
deal with visual presentation.  In the case of Org, there is no such
thing as CSS, and the only solution is to litter the Org document with
LaTeX and HTML code.  Not appealing at all in my opinion.  Here is an
example to illustrate this:

#+BEGIN_SRC org
Sensation, perception, and memory are of particular
interest to which group of contemporary psychologists?

a. psychoanalysts
b. behaviorists
c. humanistic psychologists
d. cognitive psychologists

The correct answer is d. because …
#+END_SRC

For me and many others, this is a very common use case.  I challenge you
to implement this with current Org such that it will export correctly to
HTML and PDF.  If I’m not mistaken, this is non-trivial.  If there is no
clean and simple solution for this, this strongly suggests that Org
should do the pragmatic thing and support alphabetic bullet points
in its exporters.

More generally, I’m not convinced by the philosophy that Org should be
purely semantic markup and that its syntax should be changed to enforce
this even if this breaks existing documents (Nicholas’ preferred
solution).  Org clearly has a certain WYSIWYG quality and precisely that
is one of the reasons for its success.  We should embrace the fact that
Org is differnt from HTML and not force it to be something that it
isn’t.

  Titus

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]