emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

* M-RET and C-RET
@ 2011-11-26 19:53 sindikat
  2011-12-02 16:13 ` Michael Brand
  0 siblings, 1 reply; 9+ messages in thread
From: sindikat @ 2011-11-26 19:53 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

• * Re: M-RET and C-RET
    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-05 17:23   ` Greg Troxel
    0 siblings, 2 replies; 9+ messages in thread
  From: Michael Brand @ 2011-12-02 16:13 UTC (permalink / raw)
    To: Org Mode; +Cc: sindikat
  
  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'.
  > [...]
  
  ^ permalink raw reply	[flat|nested] 9+ messages in thread

• • * Re: M-RET and C-RET
      2011-12-02 16:13 ` Michael Brand
    @ 2011-12-03 10:24   ` Nicolas Goaziou
      2011-12-03 16:58     ` Michael Brand
      2011-12-05 17:23   ` Greg Troxel
      1 sibling, 1 reply; 9+ messages in thread
    From: Nicolas Goaziou @ 2011-12-03 10:24 UTC (permalink / raw)
      To: Michael Brand; +Cc: sindikat, Org Mode
    
    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
    
    ^ permalink raw reply	[flat|nested] 9+ messages in thread

  • • * Re: M-RET and C-RET
        2011-12-03 10:24   ` Nicolas Goaziou
      @ 2011-12-03 16:58     ` Michael Brand
        2011-12-04 10:33       ` Nicolas Goaziou
        0 siblings, 1 reply; 9+ messages in thread
      From: Michael Brand @ 2011-12-03 16:58 UTC (permalink / raw)
        To: Nicolas Goaziou; +Cc: sindikat, Org Mode
      
      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
      
      ^ permalink raw reply	[flat|nested] 9+ messages in thread

    • • * Re: M-RET and C-RET
          2011-12-03 16:58     ` Michael Brand
        @ 2011-12-04 10:33       ` Nicolas Goaziou
          2011-12-04 21:38         ` Michael Brand
          0 siblings, 1 reply; 9+ messages in thread
        From: Nicolas Goaziou @ 2011-12-04 10:33 UTC (permalink / raw)
          To: Michael Brand; +Cc: sindikat, Org Mode
        
        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
        
        ^ permalink raw reply	[flat|nested] 9+ messages in thread

      • • * Re: M-RET and C-RET
            2011-12-04 10:33       ` Nicolas Goaziou
          @ 2011-12-04 21:38         ` Michael Brand
            0 siblings, 0 replies; 9+ messages in thread
          From: Michael Brand @ 2011-12-04 21:38 UTC (permalink / raw)
            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 <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
          
          ^ permalink raw reply	[flat|nested] 9+ messages in thread

  • * Re: M-RET and C-RET
      2011-12-02 16:13 ` Michael Brand
      2011-12-03 10:24   ` Nicolas Goaziou
    @ 2011-12-05 17:23   ` Greg Troxel
      1 sibling, 0 replies; 9+ messages in thread
    From: Greg Troxel @ 2011-12-05 17:23 UTC (permalink / raw)
      To: Michael Brand; +Cc: sindikat, Org Mode
    
    [-- 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 --]
    
    ^ permalink raw reply	[flat|nested] 9+ messages in thread

* M-RET and C-RET
@ 2011-11-25 16:49 sindikat
  2011-11-26  6:08 ` Tom Prince
  0 siblings, 1 reply; 9+ messages in thread
From: sindikat @ 2011-11-25 16:49 UTC (permalink / raw)
  To: emacs-orgmode

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

• * Re: M-RET and C-RET
    2011-11-25 16:49 sindikat
  @ 2011-11-26  6:08 ` Tom Prince
    0 siblings, 0 replies; 9+ messages in thread
  From: Tom Prince @ 2011-11-26  6:08 UTC (permalink / raw)
    To: sindikat, emacs-orgmode
  
  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
  
  ^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2011-12-05 17:24 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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