emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Matt <matt@excalamus.com>
To: "Ihor Radchenko" <yantar92@posteo.net>
Cc: "emacs-orgmode" <emacs-orgmode@gnu.org>
Subject: Re: Comments on Summary section of Org manual (was: [PATCH] doc/org-manual.org (Summary): Clarify the Org markup is human-readable)
Date: Wed, 03 Jan 2024 21:43:52 +0100	[thread overview]
Message-ID: <18cd111777e.efad32b9285772.6378361649896083029@excalamus.com> (raw)
In-Reply-To: <87o7e2a5wf.fsf@localhost>


 ---- On Wed, 03 Jan 2024 14:41:29 +0100  Ihor Radchenko  wrote --- 

 > I do not see much benefit changing "todo list" to "to-do list". Both are
 > clear and both are grammatically correct.

I said "TODO" to "to-do".  I was reacting to it being all caps.  I'm sorry I didn't say that.

When it's all caps, TODO is a keyword.   Otherwise, it's prose.   The following are different (AFAIK):

* TODO Finish this headline
* todo Finish this headline
* to-do Finish this headline

Agreed, it's a minor detail.

 > > Regarding "markup language," that reads to me like programmer jargon.
 > > What does it mean and why should someone care?  Again, who are we
 > > writing to?  A markup language is a notation for formatting,
 > > structure, and relationships.  I think it would be best to directly
 > > say that.
 > 
 > What about "plain text file format"?

I like that it's less technical.  I worry that it's less precise.  

I still think a word like "notation," that doesn't derive from computer culture, has a greater chance of being meaningful to people from other domains, like authors, scientists, or engineers.  Of course, these same people can easily understand the idea when they see it.  It's more important to explain why it matters and that's something we're already doing.

"Markup language" is fine.  It's correct.  Org syntax is a markup language.

I'm happy to leave it rather than risk bike-shedding it more than I have.  If we learn that it caused friction for a newcomer, we can change it easily enough.

 > > I would also soften that Org "relies" on its markup.  It doesn't.  I
 > > used Org only for lists for a long time.  I believe lists to be a
 > > fundamental feature of Org (and hence a great item for the first
 > > sentence).  Lists are as simple as dashes.  It's hard to say that
 > > dashes before list items is a markup language.
 > 
 > Yet, it is. You cannot, for example, use "." as bullets in Org mode.
 > Also, indentation matters in Org lists, while it does not matter in more
 > free-style writing.

Fair points.  I concede.  :)

 > > Finally, I don't think the file extension is relevant for the first
 > > paragraph.  Technically, an extension isn't necessary.  A person can
 > > call M-x org-mode or use a file local variable.  Worse, I think the
 > > extension contradicts the point that any text editor can view an Org
 > > file.  Ever try to open a .org file in Windows?  It asks for the
 > > program.  Yes, *technically* Windows could open a .org file *if* the
 > > person opening it knew which program to use (or to change the
 > > extension to something like .txt).  Again, who are we writing to?  If
 > > it's someone who believes file extensions matter, then this would
 > > introduce unnecessary friction.  It seems best to avoid it.  Better to
 > > do as you've done and say Org is readable (which it is) rather than
 > > specify the extension (which doesn't really matter).
 > 
 > I am mostly neutral here, but I can see an argument why mentioning .org
 > extension may be useful - unlike Windows, GitHub does expect .org file
 > extension specifically to render Org mode files. The same goes for
 > non-Emacs editors that support Org markup. For example, Vim/Neovim.
 
That's a good point.

Knowing about the .org extension is useful.  I don't think it hurts anything other than taking up valuable space.  If we need to bump something from the first paragraph, this gets my vote.

--
Matt Trzcinski
Emacs Org contributor (ob-shell)
Learn more about Org mode at https://orgmode.org
Support Org development at https://liberapay.com/org-mode



  reply	other threads:[~2024-01-03 20:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-31 15:24 [PATCH] doc/org-manual.org (Summary): Clarify the Org markup is human-readable Ihor Radchenko
2024-01-02  5:24 ` Thomas S. Dye
2024-01-03  7:52   ` Jean Louis
2024-01-03 12:36     ` Bastien Guerry
2024-01-03 13:00     ` Ihor Radchenko
2024-01-02 22:47 ` Matt
2024-01-03 13:44   ` Comments on Summary section of Org manual (was: [PATCH] doc/org-manual.org (Summary): Clarify the Org markup is human-readable) Ihor Radchenko
2024-01-03 20:43     ` Matt [this message]
2024-01-05 13:17       ` Ihor Radchenko
2024-01-05 13:06 ` [PATCH v2] doc/org-manual.org (Summary): Clarify the Org markup is human-readable Ihor Radchenko
2024-01-06 10:31   ` Matt
2024-01-06 12:55     ` Ihor Radchenko
2024-01-06 12:56       ` Matt
2024-02-01 12:16   ` Ihor Radchenko

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=18cd111777e.efad32b9285772.6378361649896083029@excalamus.com \
    --to=matt@excalamus.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=yantar92@posteo.net \
    /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).