emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Bastien <bzg@gnu.org>
Cc: emacs-orgmode@gnu.org
Subject: Re: Survey: changing a few default settings for Org 9.4
Date: Wed, 19 Feb 2020 15:07:11 +0100	[thread overview]
Message-ID: <87ftf67jsg.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87o8tuyelh.fsf@gnu.org> (Bastien's message of "Wed, 19 Feb 2020 12:57:14 +0100")

Hello,

Bastien <bzg@gnu.org> writes:

> Well, let's agree to disagree on this one.
>
> org-tempo and C-c C- fill two different use cases: the first one for
> fast block insertion while typing, the second one for e.g. when the
> region is selected.

I don't understand. C-c C-, combination is as fast as Org Tempo:

  C-c C-, s   : 3 keys
  < s TAB     : 3 keys

I can agree to disagree, but I don't buy the "fast block insertion while
typing" argument: they are as fast. We could even add an "expert"
interface that would not display the help menu for an even faster C-c
C-, experience. And, about the "while typing" part, C-c C-, can be used
anywhere amidst a line.

One true argument in favor of Org Tempo, however, is its extensibility.
IIRC, it can also insert non-block templates, e.g., "#+include:",
whereas C-c C-, cannot. Org has built-in completion for these, tho.

> M-x customize-option RET org-modules seems okay to me.

Then you may belong to the happy few that happen to find Customize
interface "okay". :>

I was speaking about "init.el" hacking. One must be cautious when
setting Org modules: it requires to be set before Org is loaded.

>> By the way, this does not belong to the same category as other
>> defcustoms discussed. This is only tangential to "how does Org should
>> look and feel by default". It relates to: should Org provide multiple
>> snippet extensions, knowing this is not a central feature, and Org is
>> often seen as bloated by Emacs devs? I don't think so, no matter how
>> useful this feature can be for some users.
>
> I'll be more receptive to this argument when animate-birthday-present
> is not in Emacs's core anymore :)

That's true. But I think they do have a point, though.

Also, my question is still open: is there any strong reason to provide,
out of the box, two template mechanisms in Org? This is genuine
question.

In any case, I don't think it is just a matter of personal preference,
like defcustoms. There should be some clear design decision behind the
answer. Let's un-bundle this issue from the rest of the poll, and think
about it separately.

> That said, I'm receptive to the idea that Org could be more focused to
> its core functionalities.  E.g., I think we could be more minimalistic
> about the ol-* and ox-* libraries in Org.

Hmmmm. This is another topic.

"ox-" are fine, IMO, even though I'm not sure about the health of
"ox-odt" these days.

"ol-*" libraries make sense as long as the suffix is bundled with Emacs.
E.g.,"ol-eww" is fine, but "ol-w3m" could be an external module.

A real issue, however, lies within "ob-*". Many of them require
libraries external to Emacs. There's a running bug report about it,
IIRC. We may not ship them with Emacs.

But, again, this is another topic.

Regards,

-- 
Nicolas Goaziou

  reply	other threads:[~2020-02-19 14:07 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19  7:39 Survey: changing a few default settings for Org 9.4 Bastien
2020-02-19  8:57 ` Samuel Wales
2020-02-19  9:01   ` Bastien
2020-02-19 20:02   ` Samuel Wales
2020-02-19 20:15     ` Marcin Borkowski
2020-02-19 21:35       ` Bastien
2020-02-19 22:06         ` Samuel Wales
2020-02-19 11:03 ` Marco Wahl
2020-02-19 11:41   ` Bastien
2020-02-19 13:21     ` Marco Wahl
2020-02-19 13:39       ` Bastien
2020-02-19 17:57         ` Marco Wahl
2020-02-19 20:44           ` Bastien
2020-02-20  4:11       ` Adam Porter
2020-02-19 11:30 ` Nicolas Goaziou
2020-02-19 11:57   ` Bastien
2020-02-19 14:07     ` Nicolas Goaziou [this message]
2020-02-19 17:24       ` Bastien
2020-02-19 23:23         ` Vladimir Lomov
2020-02-19 23:53           ` Bastien
2020-02-20  0:20             ` Samuel Wales
2020-02-19 12:58   ` Tim Cross
2020-02-19 13:22     ` Bastien
2020-02-19 15:06       ` Tim Cross
2020-02-19 13:03   ` AW
2020-02-19 15:41 ` Matthew Lundin
2020-02-19 16:16   ` Joost Kremers
2020-02-19 17:13     ` Bastien
2020-02-19 16:50   ` Detlef Steuer
2020-02-19 17:14     ` Bastien
2020-02-20  4:07 ` Adam Porter
2020-02-20  7:10   ` Bastien
2020-02-20 14:10     ` Kaushal Modi
2020-02-21 15:49 ` Bastien
2020-02-21 19:36   ` Diego Zamboni
2020-02-21 21:28     ` Archenoth
2020-02-22  9:38       ` Bastien
2020-02-22 12:45         ` Nicolas Goaziou
2020-02-22 13:31           ` Bastien
2020-02-22 18:57           ` Archenoth
2020-03-18  2:20 ` Mark E. Shoulson
2020-03-18  8:58   ` Norman Tovey-Walsh
2020-03-18 20:47     ` Hiding emphasis markers Mark E. Shoulson
2020-05-22 16:47       ` Bastien

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=87ftf67jsg.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=bzg@gnu.org \
    --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).