From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Subject: Re: M-RET vs C-RET Date: Tue, 25 Nov 2014 12:16:13 +0100 Message-ID: <87y4qz7coy.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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtE6l-0000Lh-41 for emacs-orgmode@gnu.org; Tue, 25 Nov 2014 06:16:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XtE6f-0004gz-15 for emacs-orgmode@gnu.org; Tue, 25 Nov 2014 06:16:35 -0500 Received: from plane.gmane.org ([80.91.229.3]:51488) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtE6e-0004gt-QW for emacs-orgmode@gnu.org; Tue, 25 Nov 2014 06:16:28 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XtE6d-0002u1-Qj for emacs-orgmode@gnu.org; Tue, 25 Nov 2014 12:16:27 +0100 Received: from 81.17.25.98 ([81.17.25.98]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Nov 2014 12:16:27 +0100 Received: from rasmus by 81.17.25.98 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Nov 2014 12:16:27 +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 Hi, Nicolas Goaziou writes: > Rasmus writes: > >> From my point of view, we can make every function tied to M-RET beyond >> `org-insert-headline' configurable and turned off by default. This may, >> however, also add confusion ("why did M-RET work in X's Org but not in >> mine..."). > > In this case, S-RET is a superior (as in less confusing) choice. I see. That's probably OK. > Anyway, I assume M-RET on keywords is just a first step. So, what's the > big picture? I think it would help to know the complete specifications > of the M-RET you envision, as it could make more sense than the sum of > its parts. You're the architect. I just submit an occasional patch or bug-fix (under much guidance). 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'. Sebastien Vauban writes: > Having such a file: > > ** TODO Research > - [...] > - Elevator pitch| > > Check out with Laura... > > Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod > [...] > > If I want to cut the task into 2 at the point of the cursor (vertical > bar, after "pitch"), I thought doing M-RET or C-RET were the way to go. Here's another of my pet-griefs - a - b | → M-RET will give me an itme | → 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. . . —Rasmus -- Need more coffee. . .