From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Subject: Re: M-RET vs C-RET Date: Thu, 27 Nov 2014 01:55:02 +0100 Message-ID: <87d289ihsp.fsf@gmx.us> 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> <87lhmxo71z.fsf@nicolasgoaziou.fr> 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]:44973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtnMY-0006tE-HJ for emacs-orgmode@gnu.org; Wed, 26 Nov 2014 19:55:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XtnMT-000793-1D for emacs-orgmode@gnu.org; Wed, 26 Nov 2014 19:55:14 -0500 Received: from mout.gmx.net ([212.227.15.15]:49449) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtnMS-00074c-P1 for emacs-orgmode@gnu.org; Wed, 26 Nov 2014 19:55:08 -0500 Received: from W530 ([46.166.186.244]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MhRI2-1XX9sL2pAg-00Mefb for ; Thu, 27 Nov 2014 01:55:03 +0100 In-Reply-To: <87lhmxo71z.fsf@nicolasgoaziou.fr> (Nicolas Goaziou's message of "Thu, 27 Nov 2014 00:50:32 +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: emacs-orgmode@gnu.org Nicolas Goaziou writes: > 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". I agree. Some quick thoughts: babel-call =E2=86=92 maybe insert new call line? comment =E2=86=92 new commented line? Drawer, property-drawer =E2=86=92 insert new drawer template? fixed-width =E2=86=92 clone : headline =E2=86=92 `org-insert-headline' inlinetask =E2=86=92 insert new inlinetask?=20 item =E2=86=92 `org-insert-headline' keyword =E2=86=92 `org-insert-keyword' but doesn't cover all keywords... paragraph =E2=86=92 `org-insert-headline' plain-list =E2=86=92 `org-insert-headline' table-row =E2=86=92 what it does now No clue: center-block =E2=86=92=20 clock =E2=86=92 comment-block =E2=86=92=20 diary-sexp =E2=86=92 dynamic-block =E2=86=92=20 example-block =E2=86=92=20 export-block =E2=86=92=20 horizontal-rule =E2=86=92 latex-environment =E2=86=92 node-property =E2=86=92 planning =E2=86=92=20 quote-block =E2=86=92=20 special-block =E2=86=92 src-block =E2=86=92 table =E2=86=92 verse-block =E2=86=92=20 I agree that if there exited a "list of rights things to do", and it was implemented, it may not be optimal to put it on M-RET [I'm not sure]. . . > 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. For the two latter: I only learned about the current possibility of doing this reading the docstring of `org-insert-headline'. I haven't used it, and I don't think it's immediately helpful to me, but who knows. > 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. Would be cool. >> 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 /I/ know why it does what it does. But how about the guy who's been using Org for five minutes? Even knowing the technical/syntax reason, I do not find this to be "predictable, and meaningful"=E2=80=94especially in = my initial example, less so when separating items by two lines. Cheers, Rasmus --=20 Don't panic!!!