emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Re: Feature request: lists with letters
@ 2017-02-03 11:37 Titus von der Malsburg
  0 siblings, 0 replies; 24+ messages in thread
From: Titus von der Malsburg @ 2017-02-03 11:37 UTC (permalink / raw)
  To: Org Mode

[-- 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 --]

^ permalink raw reply	[flat|nested] 24+ messages in thread
* Feature request: lists with letters
@ 2017-02-02 17:28 Titus von der Malsburg
  2017-02-02 17:55 ` Nicolas Goaziou
  0 siblings, 1 reply; 24+ messages in thread
From: Titus von der Malsburg @ 2017-02-02 17:28 UTC (permalink / raw)
  To: emacs-orgmode


Items in lists can start with -, +, N), or N. (with N being an
integer).  It’s currently not possible, to use letters as in the
following examples:

a. First item
b. Second item

or

a) First item
b) Second item

I believe it would make sense to allow letters in org-mode because
that’s a very common way to label items in lists.  I know that this has
been discussed previously but to my knowledge there was no
resolution.  The counter argument against letters was that we wouldn’t
know what labels to use when there are more items than letters, but I
think this shouldn’t stop us.  Reasons:

a) Most lists have fewer items and cases where more than 26 labels are
   needed are rare.
b) If a list has more than 26 items, the user is free to switch to
   bullet points or numbers.
c) The limited number of letters hasn’t stopped people from using
   letters in many other contexts.  For example, LaTeX offers letters
   and people think it’s useful.
d) Similarly, people often use Roman numerals (e.g., iv.) although
   they also quickly become impractical (999 = CMXCIX).
e) In some (academic) contexts, e.g. in linguistics, letters are
   conventionally used to label items in lists.
f) Letters worked perfectly fine in this list.

As to the question what org mode should do if a list is two long for
letters: Here are two possible solutions:

a) Label all items beyond the 26th with z, to make it visually very
   salient that there are not enough letters.
b) Start over from letter a after z.
c) Count in base 26 using letters as digits: a … z aa … az ba … bz …

Personally, I would prefer solution c because it gives each item a
unique label to which we can refer.  But solutions a and b would be ok,
too.  It doesn’t really matter because this is just an uninteresting
edge case and we shouldn’t obsess about it when the default case (<=26
items) is complete unproblematic.

Thanks for considering this proposal.

  Titus

^ permalink raw reply	[flat|nested] 24+ messages in thread
end of thread, other threads:[~2017-02-14 12:57 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [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
2017-02-03 11:37 Titus von der Malsburg
  -- 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

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).