From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Lohmar Subject: Re: Heading/item insert commands Date: Wed, 4 Oct 2017 13:27:44 +0200 Message-ID: References: <87d1649i7t.fsf@acer.localhost.com> <871smjgq3l.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113d2a288f52ee055ab6e562" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38437) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzhq7-0004s5-EC for emacs-orgmode@gnu.org; Wed, 04 Oct 2017 07:27:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzhq6-0003Bz-9b for emacs-orgmode@gnu.org; Wed, 04 Oct 2017 07:27:47 -0400 Received: from mail-vk0-x22c.google.com ([2607:f8b0:400c:c05::22c]:56811) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dzhq6-0003B4-4j for emacs-orgmode@gnu.org; Wed, 04 Oct 2017 07:27:46 -0400 Received: by mail-vk0-x22c.google.com with SMTP id q190so6100060vkd.13 for ; Wed, 04 Oct 2017 04:27:46 -0700 (PDT) In-Reply-To: <871smjgq3l.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Nicolas Goaziou Cc: emacs-orgmode@gnu.org --001a113d2a288f52ee055ab6e562 Content-Type: text/plain; charset="UTF-8" Hi Nicolas, I am not sure I understand: As I tried to make clear, I am *not* interested in changing the UI for anybody but myself. I probably should have omitted the "long-run" comment altogether. What I am interested in is refactoring: add a layer of functions that cleanly do what is now done in an ad-hoc way, eg, inside of-insert-todo-heading, or which is not done at all. Or are you talking about the parameters of such new functions? On Oct 4, 2017 12:33 PM, "Nicolas Goaziou" wrote: Hello, Ingo Lohmar 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 --001a113d2a288f52ee055ab6e562 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nicolas,

= I am not sure I understand: As I tried to make clear, I am *not* interested= in changing the UI for anybody but myself. I probably should have omitted = the "long-run" comment altogether.

What I am interested in is refactoring: add a layer of= functions that cleanly do what is now done in an ad-hoc way, eg, inside of= -insert-todo-heading, or which is not done at all.
<= br>
Or are you talking about the parameters of such = new functions?


On Oct 4, 2017 12:33 PM, "Nicolas Goaziou" &l= t;mail@nicolasgoaziou.fr> = wrote:
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.=C2=A0 Then rewrite existing commands in = terms
> of these, but possibly adding new ones.
>
> I would not want to break any workflows, of course.=C2=A0 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?<= br>
I think, as a starter, we should discuss and agree on how the UI shou= ld
be. IMO, implementation follows, not the other way around.

WDYT?

Regards,

--
Nicolas Goaziou

--001a113d2a288f52ee055ab6e562--