From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Prefix arguments, checklists, and lists Date: Mon, 04 Feb 2013 23:36:38 +0100 Message-ID: <87pq0f4sg9.fsf@gmail.com> References: <878v7q2o9b.fsf@gmail.com> <87ehh99xfu.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:54854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2UfB-00005J-0I for emacs-orgmode@gnu.org; Mon, 04 Feb 2013 17:37:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U2Uen-0008Gh-US for emacs-orgmode@gnu.org; Mon, 04 Feb 2013 17:36:59 -0500 Received: from mail-we0-x232.google.com ([2a00:1450:400c:c03::232]:45843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2Uen-0008GW-LI for emacs-orgmode@gnu.org; Mon, 04 Feb 2013 17:36:57 -0500 Received: by mail-we0-f178.google.com with SMTP id x48so5263062wey.37 for ; Mon, 04 Feb 2013 14:36:56 -0800 (PST) In-Reply-To: (Robert Horn's message of "Sun, 03 Feb 2013 12:24:19 -0500") 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-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Robert Horn Cc: Org-mode Hello, Robert Horn 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