Re: Prefix arguments, checklists, and lists

[Nicolas Goaziou <n.goaziou@gmail.com>]

Hello,

Robert Horn <rjhorn@alum.mit.edu> writes:

> Nicolas Goaziou writes:
>>
>> As a rule of thumb, C-c C-c on a list will operate on every top level
>> items and C-c C-c on a item will operate on the item. You are considered
>> to be on a list when calling C-c C-c from affiliated keywords or from
>> the very beginning of the first line in the first item. Note that
>> element-wise navigation (like M-{ and M-}) behaves the same.
>>
>
> This is different than your initial response, and still needs to be
> documented.

Certainly. Help is welcome, too.

> I still think it's poor user interface design.  The impact when you go
> through the documentation for each command and add "... except when on
> the first character of the first item of the list, in which case the
> behavior is ...." may make this clear.

There's no point in adding it for each command. The list and item
boundaries just need to be defined once. Then, each command that behaves
differently on a list and on an item will have a documentation along the
lines of: "When at a list, do this. When at an item, do that."

> The user has to add that into their thought processes when using
> lists. This constant side nag of "where am I on this line? which item
> am I on?" is an indication of a user interface problem.
>
> The other times that emacs and org-mode care about where you are on the
> line are situations where you are directly editing and changing the
> contents of the line.  It feels natural to pay attention to the location
> on the line when editing the text.  And, even then, the change is
> restricted to that location on the line.  It is only when using a
> prefixed commands that the changes affect other locations.

I think you are wrong. Org is all about context.

Think about speed commands: you have to be on the first character of
a headline to trigger them. Think about "M-RET": it will add a headline
before the current one if the point is at its very beginning. Think
about "C-c C-c". You hardly control it with prefixes: it acts according
to the location of point in the buffer.

I don't know if it's a user interface problem. I do like it, though. You
just have to _look_ for context, while you have to _think_ about the
right prefix to use. I must be faster at looking than at thinking,
I guess.

Anyway, to put it clearly, the syntax introduced in this situation
didn't come out of nowhere. It followed the same logic as the rest of
Org, really.

> That's why I prefer using a different prefix to mean "whole list".  That
> leaves all of the list related commands that affect the current item to
> be C-u prefixed.  If you have a different prefix that means "whole
> list", you eliminate the "where is the point?" mental effort.  It adds
> the ability to have that different prefix enable "whole list" when on
> any item in any location in the list.

To really understand where it comes from, you have to forget about lists
for a while. You even have to forget about C-c C-c. Let's talk about
`org-forward-element' ("M-}") instead.

In the following example `org-forward-element' on the first paragraph
will move point on the second paragraph. All good and logical.

--8<---------------cut here---------------start------------->8---
This is the first paragraph

This is the second paragraph
--8<---------------cut here---------------end--------------->8---

If we add attributes to the first paragraph, as in the next example,
`org-forward-element' on the first paragraph (even on its attribute)
will unsurprisingly move point on the other one.

--8<---------------cut here---------------start------------->8---
#+NAME: para1
This is the first paragraph

This is the second paragraph
--8<---------------cut here---------------end--------------->8---

Now, we replace the first paragraph with a two-row table. If we stay
consistent, `org-forward-element' on the attribute line of the table
should move point on the paragraph, and so it does.

--8<---------------cut here---------------start------------->8---
#+NAME: table1
| a | b |
| c | d |

This is the second paragraph
--8<---------------cut here---------------end--------------->8---

But what if we remove that attribute line? Assuming point is on the
table's first row, should `org-forward-element' move it onto the next
paragraph or the second row?

--8<---------------cut here---------------start------------->8---
| a | b |
| c | d |

This is the second paragraph
--8<---------------cut here---------------end--------------->8---

We can move to the next row and add a prefix to "M-{", in order to skip
the whole table, much like what you suggest for lists. But what about
the table with the attribute line? There, an un-prefixed command will
still skip a table, or it won't be compliant with the example before it.

So what we really get is a prefixed command that behaves differently
according to context. In my book, it means we lose on both sides.

Now, let's look again at the same example, with point on the paragraph
this time.

--8<---------------cut here---------------start------------->8---
| a | b |
| c | d |

This is the second paragraph
--8<---------------cut here---------------end--------------->8---

Even in a poor user interface design (!), it is not unreasonable to
imagine that `org-forward-element' and `org-backward-element' have
opposite effects. So, basically, `org-backward-element' +
`org-forward-element'[1] should keep point on the same element.

`org-backward-element' moves point to the first character in the table.
Since `org-forward-element' has to bring it back to the paragraph, this
is no rocket science to say it should skip the whole table. Question
answered. We don't have to add a prefix either, and we get the rest of
the line to operate on the row. It is also consistent if there is
a prefix line.

We can generalize a bit: a command called on the very first character of
an element is expected to operate at the container level, not at the
contents level.

What about lists? Just replace "table" with "list" and "row" with
"item". This is a global design, and lists are but a part of it.

Also you can dislike this interface. At least, you know there are
reasons for it.


Regards,

[1] If point is at the beginning of an element. Otherwise, the first
call to `org-backward-element' will move it there.

-- 
Nicolas Goaziou