From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Brand Subject: Re: M-RET and C-RET Date: Sun, 4 Dec 2011 22:38:23 +0100 Message-ID: References: <20111126195304.61776.qmail@rage.so36.net> <87mxbaq7f2.fsf@gmail.com> <87iplwr5gp.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from eggs.gnu.org ([140.186.70.92]:60946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXJlR-000613-Up for emacs-orgmode@gnu.org; Sun, 04 Dec 2011 16:38:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXJlQ-0004jv-St for emacs-orgmode@gnu.org; Sun, 04 Dec 2011 16:38:25 -0500 Received: from mail-ww0-f49.google.com ([74.125.82.49]:58337) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXJlQ-0004f6-OJ for emacs-orgmode@gnu.org; Sun, 04 Dec 2011 16:38:24 -0500 Received: by wgbdt11 with SMTP id dt11so5228810wgb.30 for ; Sun, 04 Dec 2011 13:38:23 -0800 (PST) In-Reply-To: <87iplwr5gp.fsf@gmail.com> 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: Nicolas Goaziou Cc: John Wiegley , Org Mode , sindikat Hi Nicolas Thank you for all the explanations. On Sun, Dec 4, 2011 at 11:33, Nicolas Goaziou wrote: > Though, from what I read, > I think that you really mean to argue for a change of the default value > of `org-M-RET-may-split-line' (to, i.e. '((default . t) (item))) not for > a change of code. With my better understanding of the "insert anchor" (see below): Yes. > I'm not talking about your cursor shape, but about Emacs' point > representation. Point is never on "j" in Emacs, whatever you want to > prefer. To convince yourself, you can experiment with: > > M-: (char-to-string (char-after (point))) Interesting. At least when referring with the word "point" I better switch... > I fail to see any logic here: point is still before the contents of the > item, but M-RET adds a new item below nonetheless. I would call that > a convenient hack. But it's just me. Finally I got it and this lets me readjust my opinion too. Before I could only think of the list item bullet as the "insert anchor" for the decision whether to insert above or below. Now I realize that there is also the different and also valid perspective to have just the first character of the item text as this "insert anchor". > Moreover, with `org-M-RET-may-split-line' set to nil (at least for > items), this hack is totally useless, as there's plenty of room to call > M-RET from (like the end of _line_) when one wants to add an item below. > > So again, aren't you arguing for a change of `org-M-RET-may-split-line' > value instead? With my better understanding of the "insert anchor": Yes. > I can see the consistency with headlines, but not the simplicity. Also, > from my obviously biased point of view, I could argue that you may > modify headlines' behaviour to be more consistent with plain lists > instead ;) Indeed. Seriously, for me this would now be the better way to go to increase consistency, if this is of a broader interest than only mine. > Then the documentation with regards to that variable may be > defective. How do you think it can be improved? I don't see a problem with the doc itself. More with me not reading and remembering the right thing at the right time. But your suggestion to change the default of org-M-RET-may-split-line seems the right thing to me. My vote for the _default_ is (defcustom org-M-RET-may-split-line '((default . t) (item)) Who is interested to vote for a default? The Org-mode customization survey from January 2009 on Worg showed only one user differing from the default still in use: nil for headline (John Wiegley, CCed). The other 35 had the default (I claim that some of them don't care). With a default of nil for item I would not have followed the wrong path of using "-" and TAB to insert list items and not have made the noise related to this and more. Michael