From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: M-RET vs C-RET Date: Thu, 27 Nov 2014 00:50:32 +0100 Message-ID: <87lhmxo71z.fsf@nicolasgoaziou.fr> References: <87egszw8ui.fsf@gmx.us> <87wq6o3u57.fsf@gmx.us> <87fvdb4l6c.fsf@nicolasgoaziou.fr> <87sihb4ede.fsf@pank.eu> <87lhn36nq1.fsf@gmx.us> <87bnny4ybq.fsf@nicolasgoaziou.fr> <5471C038.4080102@free.fr> <873899503j.fsf@nicolasgoaziou.fr> <8738997sa2.fsf@gmx.us> <87ppcd3iqj.fsf@nicolasgoaziou.fr> <87vbm56b2q.fsf@gmx.us> <878uj139k1.fsf@nicolasgoaziou.fr> <87a93h60s3.fsf@gmx.us> <87ioi3ods1.fsf@selenimh.mobile.lan> <86bnnvfv1l.fsf_-_@example.com> <87y4qz7coy.fsf@gmx.us> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtmLE-0000C7-Ah for emacs-orgmode@gnu.org; Wed, 26 Nov 2014 18:49:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XtmL6-0004BT-87 for emacs-orgmode@gnu.org; Wed, 26 Nov 2014 18:49:48 -0500 Received: from relay3-d.mail.gandi.net ([2001:4b98:c:538::195]:38887) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtmL6-0004BL-1q for emacs-orgmode@gnu.org; Wed, 26 Nov 2014 18:49:40 -0500 In-Reply-To: <87y4qz7coy.fsf@gmx.us> (rasmus@gmx.us's message of "Tue, 25 Nov 2014 12:16:13 +0100") 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: Rasmus Cc: emacs-orgmode@gnu.org Rasmus writes: > I don't have a grand vision, but, ideally, I'd want M-RET to "do the > right thing", which is my book is often create an element similar to > element at point, and is certainly not but my #+begin_src emacs-lisp > code on a headline. I agree the logical action is to the eye of the > beholder. To me, some elements have a very clear-cut "next logical > thing" (item, headline, white space (headline), some keywords, maybe > tables), others don't (e.g. src-blocks and export blocks.). IMO, we can > disable most of element-actions (literately keywords and tables) out of > the box, much like e.g. `scroll-left'. It would be nice to have complete specifications of "do the right thing". Also, it is important to have a way to insert a headline whatever is around, and one to insert a headline at the end of the current section or even great-parent. Currently C-RET is sub-optimal since it is equivalent to C-u M-RET. It might be possible to re-define both M-RET and C-RET so they can cover all use-cases in a predictable, and meaningful, fashion. > Here's another of my pet-griefs > - a > - b > > | =E2=86=92 M-RET will give me an itme=20 > | =E2=86=92 M-RET will give me a headline > > Why is the behavior a function of amount of whitespace/newlines to > nearest element? This makes not sense to me and goes against what I > want, namely act in accordance to element at point. . . Blank lines belong to the element at point above. In particular, number of blank lines is meaningful in plain lists and footnote definitions (2 blank lines mark the end of the element). In the first line, you're still in the list, in the next one, you're not anymore, hence the behaviour. Think about - a - b | Regards,