emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Michael Brand <michael.ch.brand@gmail.com>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: John Wiegley <jwiegley@gmail.com>,
	Org Mode <emacs-orgmode@gnu.org>, sindikat <sindikat@mail36.net>
Subject: Re: M-RET and C-RET
Date: Sun, 4 Dec 2011 22:38:23 +0100	[thread overview]
Message-ID: <CALn3zojQKdv3w9ENCku3gvFRguoe+J--HMUqOsWNyuzC3aK03A@mail.gmail.com> (raw)
In-Reply-To: <87iplwr5gp.fsf@gmail.com>

Hi Nicolas

Thank you for all the explanations.

On Sun, Dec 4, 2011 at 11:33, Nicolas Goaziou <n.goaziou@gmail.com> 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

  reply	other threads:[~2011-12-04 21:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-26 19:53 M-RET and C-RET sindikat
2011-12-02 16:13 ` Michael Brand
2011-12-03 10:24   ` Nicolas Goaziou
2011-12-03 16:58     ` Michael Brand
2011-12-04 10:33       ` Nicolas Goaziou
2011-12-04 21:38         ` Michael Brand [this message]
2011-12-05 17:23   ` Greg Troxel
  -- strict thread matches above, loose matches on Subject: below --
2011-11-25 16:49 sindikat
2011-11-26  6:08 ` Tom Prince

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALn3zojQKdv3w9ENCku3gvFRguoe+J--HMUqOsWNyuzC3aK03A@mail.gmail.com \
    --to=michael.ch.brand@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=jwiegley@gmail.com \
    --cc=n.goaziou@gmail.com \
    --cc=sindikat@mail36.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).