emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Titus von der Malsburg <malsburg@posteo.de>
To: Org Mode <emacs-orgmode@gnu.org>
Subject: Re: Feature request: lists with letters
Date: Fri, 03 Feb 2017 12:37:22 +0100	[thread overview]
Message-ID: <87k297bj4d.fsf@posteo.de> (raw)

[-- Attachment #1: Type: text/plain, Size: 3119 bytes --]



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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

             reply	other threads:[~2017-02-03 11:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-03 11:37 Titus von der Malsburg [this message]
     [not found] <1622a63fda844eb1aa553fdcd19a5758@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
2017-02-03 12:40 ` Feature request: lists with letters Eric S Fraga
2017-02-03 13:47   ` Titus von der Malsburg
2017-02-06 15:34     ` Rasmus
2017-02-06 19:59       ` Titus von der Malsburg
2017-02-09  9:29         ` Rasmus
2017-02-10 10:58           ` Titus von der Malsburg
2017-02-11  1:20             ` Nicolas Goaziou
2017-02-13 10:51               ` Rasmus
2017-02-13 13:47                 ` Nicolas Goaziou
2017-02-13 16:55                   ` Rasmus
2017-02-13 20:39                     ` Nicolas Goaziou
2017-02-14 11:25                       ` Rasmus
2017-02-14 12:57                         ` Nicolas Goaziou
     [not found]             ` <9385a1ca2a23417399fb441d6d85795d@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
2017-02-11 12:39               ` Eric S Fraga
  -- strict thread matches above, loose matches on Subject: below --
2017-02-02 17:28 Titus von der Malsburg
2017-02-02 17:55 ` Nicolas Goaziou
2017-02-02 19:42   ` Titus von der Malsburg
2017-02-02 19:57     ` Nicolas Goaziou
2017-02-02 20:05       ` Titus von der Malsburg
2017-02-02 20:19         ` Nicolas Goaziou
2017-02-02 20:33           ` Eric Abrahamsen
2017-02-03  8:50       ` Rainer M Krug
2017-02-03 16:22         ` William Denton

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=87k297bj4d.fsf@posteo.de \
    --to=malsburg@posteo.de \
    --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).