From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Subject: Re: Heading/item insert commands
Date: Wed, 04 Oct 2017 12:33:02 +0200
Message-ID: <871smjgq3l.fsf@nicolasgoaziou.fr>
References: <87d1649i7t.fsf@acer.localhost.com>
Mime-Version: 1.0
Content-Type: text/plain
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50315)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mail@nicolasgoaziou.fr>) id 1dzgzF-0002ke-AM
	for emacs-orgmode@gnu.org; Wed, 04 Oct 2017 06:33:10 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mail@nicolasgoaziou.fr>) id 1dzgzE-0003yi-KJ
	for emacs-orgmode@gnu.org; Wed, 04 Oct 2017 06:33:09 -0400
Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:60342)
	by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.71) (envelope-from <mail@nicolasgoaziou.fr>)
	id 1dzgzE-0003x3-EQ
	for emacs-orgmode@gnu.org; Wed, 04 Oct 2017 06:33:08 -0400
In-Reply-To: <87d1649i7t.fsf@acer.localhost.com> (Ingo Lohmar's message of
	"Tue, 03 Oct 2017 20:52:54 +0200")
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode/>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
Sender: "Emacs-orgmode"
	<emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
To: Ingo Lohmar <i.lohmar@gmail.com>
Cc: emacs-orgmode@gnu.org

Hello,

Ingo Lohmar <i.lohmar@gmail.com> writes:

> What I have in mind for starters:
>
> Add orthogonal internal functions that can handle *all* sensible
> combinations of requirements.  Then rewrite existing commands in terms
> of these, but possibly adding new ones.
>
> I would not want to break any workflows, of course.  But in the *long*
> run, we could rethink if the existing commands and their prefix-arg
> behavior are really what users want, or if we provide other ones by
> default.
>
> Does that sound reasonable, or are there any grave obstacles I did not
> consider, or any hard reasons why such changes could not be accepted?

I think, as a starter, we should discuss and agree on how the UI should
be. IMO, implementation follows, not the other way around.

WDYT?

Regards,

-- 
Nicolas Goaziou