Heading/item insert commands

Heading/item insert commands

[Ingo Lohmar]

Dear All,

I have been heavily and happily using orgmode for more than 6 years now.
During this time, I have returned 4 or 5 times to changing, tweaking and
generally being puzzled by the code and commands used to insert headings
and list items.  Now, for the first time, I have tried to systematically
write down for myself the different dimensions of the problem, what kind
of combinations I want, and I have written small wrapper commands that
make it happen the way I want.

But that has basically confirmed my gut feeling that the code dealing
with these tasks is fairly convoluted.  There is no symmetry between
todo/non-todo elements, nor between headings and plain list items
(inasmuch as possible), arguments are used inconsistently, heading
insertion may or may not fallback to list items etc.

Thankfully, we are not talking about a lot of code, and it seems to be
amenable to refactoring.  Is there any interest in me trying that (no
promises as to the success)?  I could not find any previous discussions
about this topic, but wanted to get some feedback before spending my
time on this.

To me, there are a few dimensions of requirements:
- insert a heading or an item, or decide based on context?
- insert a todo or a non-todo something?
- insert right here (possibly splitting a line), after the current
  something, or at the end of current's something parent?

Plus some specialties of the current code: For a todo heading, which
keyword to use?  Override the heading level by an argument?

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?

Thanks,
Ingo

Re: Heading/item insert commands

[Nicolas Goaziou]

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

Re: Heading/item insert commands

[Ingo Lohmar]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2059 bytes --]

Re: Heading/item insert commands

[Nicolas Goaziou]

Hello,

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

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

OK. I misunderstood your message. However, I'm not against also
discussing the UI, if needed.

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

Fair enough. There are also quite a few tests in test-org.el. You may
want to extend these while rewriting the functions.


Regards,

-- 
Nicolas Goaziou                                                0x80A93738