M-RET and C-RET

M-RET and C-RET

[sindikat]

Hello everyone, 

M-RET works with both headings and plainlists, it's DWIM.
C-RET works only with headings. I wanted to ask, why C-RET is not DWIM? 
Wouldn't users want to add new list item respecting the content? 

Thanks in advance.

Re: M-RET and C-RET

[Tom Prince]

On Fri, 25 Nov 2011 17:49:09 +0100, "sindikat" <sindikat@mail36.net> wrote:
> Hello everyone, 
> 
> M-RET works with both headings and plainlists, it's DWIM.
> C-RET works only with headings. I wanted to ask, why C-RET is not DWIM? 
> Wouldn't users want to add new list item respecting the content? 

You can use M-RET-may-split-line, to make it respect content in lists,
more or less. I would guess the reason that they are different is to be
able to always easily start a new heading.

  Tom

M-RET and C-RET

[sindikat]

> You can use M-RET-may-split-line, to make it respect content in lists,
more or less. I would guess the reason that they are different is to be
able to always easily start a new heading. 

This is very helpful, thank you. But how to make it so M-RET will: 

1. not split line;
2. add new list item while on plain list;
AND
3. add new heading after content of the current heading? 

Maybe there should be a variable in addition to 'org-M-RET-may-split-line' 
such as 'org-M-RET-add-after-content'. 

Btw, i think it is bad to name an Emacs after keyboard combination, because 
it is ambiguous in case user remap M-RET. This is a minor issue, but still 
:)

Re: M-RET and C-RET

[Michael Brand]

Hi all

Now that I use M-RET more often when editing lists I was about trying
to make a patch to remove what seems to me an inconsistency between
headings and list items. But after I have read the docstrings of
org-insert-item and org-list-insert-item the current behavior seems so
intentional that I must have just missed some good reasons. Which are
they?

With

#+begin_src org
  ,*** abc
  ,*** def
  ,    - ghi
  ,    - jkl
#+end_src

M-RET on "e" or on "k" splits the line, ok. M-RET on the first "*"
(here also C-RET) or on "-" inserts a line above, ok. M-RET on "d"
inserts a line _below_ (and C-RET _below_ the end of the whole entry),
ok. M-RET on "j" inserts a line above but I expected it below. If I
want a line above I would move the point to "-" before doing M-RET
like I do on a heading where I move to the first "*" to get the insert
above.

Changing to the behavior expected by me would make it possible to add
a new list item below the last one in a list (a very frequent task)
without caring about configuring org-M-RET-may-split-line away from
its default. I configured it to nil for headline and item only to be
able to insert a new list item below the current with M-RET where I am
forced to be on or at right of "k" which by default splits which I
want only in very rare cases. And one should not be invited to avoid
M-RET and edit lists with "-" and TAB as illustrated in the thread
"org-list-indent-offset only works partially":
http://thread.gmane.org/gmane.emacs.orgmode/47954

Another inconsistency in my view: Since M-RET inserts above when on
"-" or before I would like to see M-RET and C-RET also insert above
when on the last "*" (or single visible "*" when hidestars) or before,
not only on the first "*" of the line.

Michael

On Sat, Nov 26, 2011 at 20:53, sindikat <sindikat@mail36.net> wrote:
>> You can use M-RET-may-split-line, to make it respect content in lists,
>
> more or less. I would guess the reason that they are different is to be
> able to always easily start a new heading.
> This is very helpful, thank you. But how to make it so M-RET will:
> 1. not split line;
> 2. add new list item while on plain list;
> AND
> 3. add new heading after content of the current heading?
> Maybe there should be a variable in addition to 'org-M-RET-may-split-line'
> such as 'org-M-RET-add-after-content'.
> [...]

Re: M-RET and C-RET

[Nicolas Goaziou]

Hello,

Michael Brand <michael.ch.brand@gmail.com> writes:

> With
>
> #+begin_src org
>   ,*** abc
>   ,*** def
>   ,    - ghi
>   ,    - jkl
> #+end_src
>
> M-RET on "j" inserts a line above but I expected it below. If I
> want a line above I would move the point to "-" before doing M-RET
> like I do on a heading where I move to the first "*" to get the insert
> above.

Point isn't on "j". It's either before or after it. In your case, point
is before "j". And using M-RET on an item before its body start will
result in creating an item before it.

This is done so to avoid splitting counters or check-boxes.

You shouldn't compare lists and headlines behaviour, they don't have the
same constraints.

> Changing to the behavior expected by me would make it possible to add
> a new list item below the last one in a list (a very frequent task)

Go to the end of the last item, and use M-RET.

If it is really frequent, the following function will do what you want:

#+begin_src emacs-lisp
(defun org-insert-item-at-end (&optional arg)
  "Insert a new list item at the end of the current list.
When optional argument ARG is non-nil, add a check-box to the
item."
  (interactive "P")
  (let ((itemp (org-in-item-p)))
    (unless itemp (error "Not in an item"))
    (goto-char (org-in-item-p))
    (let* ((struct (org-list-struct))
           (prevs (org-list-prevs-alist struct)))
      ;; Move to the end of the last item in list, before any white
      ;; space, and insert item there.
      (goto-char
       (org-list-get-item-end
        (org-list-get-last-item itemp struct prevs) struct))
      (skip-chars-backward " \r\t\n")
      ;; Repair list.
      (setq struct (org-list-insert-item (point) struct prevs arg))
      (org-list-write-struct struct (org-list-parents-alist struct))
      ;; Take care of check-boxes count, if needed.
      (when arg (org-update-checkbox-count-maybe))
      ;; Position point at body's start.
      (looking-at org-list-full-item-re)
      (goto-char (match-end 0)))))
#+end_src

> I configured it to nil for headline and item only to be able to insert
> a new list item below the current with M-RET where I am forced to be
> on or at right of "k" which by default splits which I want only in
> very rare cases. 

If you want to split lines only on very rare occasions, why is it
a problem to set `org-M-RET-may-split-line' to nil?

> And one should not be invited to avoid M-RET and edit lists with "-"
> and TAB as illustrated in the thread "org-list-indent-offset only
> works partially": http://thread.gmane.org/gmane.emacs.orgmode/47954

Which part of the thread are you referring to? I see no suggestion about
avoiding usage of M-RET.


Regards,

-- 
Nicolas Goaziou

Re: M-RET and C-RET

[Michael Brand]

Hi Nicolas

I try to argue for some supposed common Org user that likes it simple
like me, is used to the behavior of M-RET and C-RET on headings and
is about to learn to use lists and M-RET but doesn't want to know
about org-M-RET-may-split-line that he prefers to leave on its default
as typical for trying out step by step. I don't argue for myself, I
had already found out and understand how to configure and how to do.
But if M-RET with point on "j" would insert _below_:
1) it would be simpler to understand (from the user view, not
   necessarily for implementation but often there too) because also
   M-RET with point on "d" inserts already below
2) it would make possible to add a new list item below the last with
   M-RET already with the default org-M-RET-may-split-line or even
   emacs -Q
I can not see anything that could not be done with this that can be
done now. What am I missing?

On Sat, Dec 3, 2011 at 11:24, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Michael Brand <michael.ch.brand@gmail.com> writes:
>> With
>>
>> #+begin_src org
>>   ,*** abc
>>   ,*** def
>>   ,    - ghi
>>   ,    - jkl
>> #+end_src
>>
>> M-RET on "j" inserts a line above but I expected it below. If I
>> want a line above I would move the point to "-" before doing M-RET
>> like I do on a heading where I move to the first "*" to get the insert
>> above.
>
> Point isn't on "j". It's either before or after it. In your case, point
> is before "j".

When I wrote this I exactly asked myself which of these two
perspectives I want to choose:
- "point is before 'j'":
  - in some cases it leaves the question open if it means just before
    or rather between something (e. g. beginning of line) and "j"
  - sounds to me like referring to an edit cursor shape that is a bar
    between characters which is not the cursor shape of all users
- "point is on 'j'":
  - can refer to the position of point in the buffer like with "C-x ="
    or the Emacs Lisp functions "point" and some "point-*"
  - can refer to the character address or fsetpos() position in the
    corresponding file
  - can refer to an edit cursor shape that is a box on a character
    (the only possibility for some terminal emulators and the default
    for the windowed GNU Emacs on Linux, Mac OS X and Solaris)
I hope that this explains my preference for the second.

> And using M-RET on an item before its body start will
> result in creating an item before it.
>
> This is done so to avoid splitting counters or check-boxes.

I don't understand this. What would be wrong with
- point on "-": M-RET inserts above
- point on "[X]": M-RET inserts below
  (consistent with point on TODO on a line "*** TODO def")
- point on "j": M-RET inserts below
- point on "kl": M-RET splits (default config)
when considering the line "    - [X] jkl"?

> You shouldn't compare lists and headlines behaviour, they don't have the
> same constraints.

Nevertheless, wouldn't point 1) at the top add more consistency?

>> I configured it to nil for headline and item only to be able to insert
>> a new list item below the current with M-RET where I am forced to be
>> on or at right of "k" which by default splits which I want only in
>> very rare cases.
>
> If you want to split lines only on very rare occasions, why is it
> a problem to set `org-M-RET-may-split-line' to nil?

Not a problem for me, trying to simplify for others, see at the top
and also its point 2).

>> And one should not be invited to avoid M-RET and edit lists with "-"
>> and TAB as illustrated in the thread "org-list-indent-offset only
>> works partially": http://thread.gmane.org/gmane.emacs.orgmode/47954
>
> Which part of the thread are you referring to? I see no suggestion about
> avoiding usage of M-RET.

I'm sorry for the confusion and hope it becomes clearer this way:

As illustrated in the thread "org-list-indent-offset only works
partially" here
http://thread.gmane.org/gmane.emacs.orgmode/47954
one should not insert list items by editing with "-" and TAB but use
M-RET.

What I meant with the "invitation to avoid M-RET" is that until I
understood better a few weeks ago I used "-" and TAB to insert a new
item below the current line because more or less intentionally I left
org-M-RET-may-split-line at its default and because
- M-RET did not let me add a new list item below the last, and the
  relation to org-M-RET-may-split-line was not obvious for me
- when I wanted to insert a new list item below the current line I
  didn't like (maybe silly, I know) to move to the next item to be
  able to use M-RET to insert above from there

Michael

Re: M-RET and C-RET

[Nicolas Goaziou]

Hello,

Michael Brand <michael.ch.brand@gmail.com> writes:

> I try to argue for some supposed common Org user that likes it simple
> like me, is used to the behavior of M-RET and C-RET on headings and
> is about to learn to use lists and M-RET but doesn't want to know
> about org-M-RET-may-split-line that he prefers to leave on its default
> as typical for trying out step by step. I don't argue for myself, I
> had already found out and understand how to configure and how to do.
> But if M-RET with point on "j" would insert _below_:
> 1) it would be simpler to understand (from the user view, not
>    necessarily for implementation but often there too) because also
>    M-RET with point on "d" inserts already below
> 2) it would make possible to add a new list item below the last with
>    M-RET already with the default org-M-RET-may-split-line or even
>    emacs -Q
> I can not see anything that could not be done with this that can be
> done now. What am I missing?

Maybe nothing. I may be missing your point. 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.

>> Point isn't on "j". It's either before or after it. In your case, point
>> is before "j".
>
> When I wrote this I exactly asked myself which of these two
> perspectives I want to choose:
> - "point is before 'j'":
>   - in some cases it leaves the question open if it means just before
>     or rather between something (e. g. beginning of line) and "j"
>   - sounds to me like referring to an edit cursor shape that is a bar
>     between characters which is not the cursor shape of all users
> - "point is on 'j'":
>   - can refer to the position of point in the buffer like with "C-x ="
>     or the Emacs Lisp functions "point" and some "point-*"
>   - can refer to the character address or fsetpos() position in the
>     corresponding file
>   - can refer to an edit cursor shape that is a box on a character
>     (the only possibility for some terminal emulators and the default
>     for the windowed GNU Emacs on Linux, Mac OS X and Solaris)
> I hope that this explains my preference for the second.

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

>> And using M-RET on an item before its body start will
>> result in creating an item before it.
>>
>> This is done so to avoid splitting counters or check-boxes.
>
> I don't understand this. What would be wrong with
> - point on "-": M-RET inserts above
> - point on "[X]": M-RET inserts below
>   (consistent with point on TODO on a line "*** TODO def")
> - point on "j": M-RET inserts below
> - point on "kl": M-RET splits (default config)
> when considering the line "    - [X] jkl"?

I don't like it when I consider the line: " - jkl".

It means that the new behaviour you suggest (adding an item below the
current one) would only happen in one precise position on the line: just
before the "j". Calling M-RET anywhere before that would create the item
above, and anywhere after it would split the line (by default).

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.

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?

>> You shouldn't compare lists and headlines behaviour, they don't have the
>> same constraints.
>
> Nevertheless, wouldn't point 1) at the top add more consistency?

Certainly, but not with the more simple choice, despite what you claimed
at the beginning of this message.

Again:

  - Actually, M-RET before item's body creates an item before, and it
    splits body otherwise.

  - Your suggestion: M-RET before item's bullet creates and item before,
    M-RET between item's bullet and item's body (which may be reduced to
    one position only) creates an item after, and it splits body
    otherwise.

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 ;)

>>> I configured it to nil for headline and item only to be able to insert
>>> a new list item below the current with M-RET where I am forced to be
>>> on or at right of "k" which by default splits which I want only in
>>> very rare cases.
>>
>> If you want to split lines only on very rare occasions, why is it
>> a problem to set `org-M-RET-may-split-line' to nil?
>
> Not a problem for me, trying to simplify for others, see at the top
> and also its point 2).

Again, your suggestion may not be totally wrong, but it's not
simplifying anything.

> What I meant with the "invitation to avoid M-RET" is that until I
> understood better a few weeks ago I used "-" and TAB to insert a new
> item below the current line because more or less intentionally I left
> org-M-RET-may-split-line at its default and because
> - M-RET did not let me add a new list item below the last, and the
>   relation to org-M-RET-may-split-line was not obvious for me

Then the documentation with regards to that variable may be
defective. How do you think it can be improved?

> - when I wanted to insert a new list item below the current line I
>   didn't like (maybe silly, I know) to move to the next item to be
>   able to use M-RET to insert above from there

Well, even with a default `org-M-RET-may-split-line', M-RET M-DOWN
achieves the same result without requiring to move to the next
item. With a modified value, C-e M-RET will do the same.


Regards,

-- 
Nicolas Goaziou

Re: M-RET and C-RET

[Michael Brand]

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

Re: M-RET and C-RET

[Greg Troxel]

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


Please keep in mind that C-ret is not an ascii or 8-bit character (or
even a character, really), so people using emacs in an xterm (rather
than via X) do not have C-ret available.  In general I find that org
mode becomes a little awkward in a terminal due to usage of
ungeneratable characters.


[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]