From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: A Microsoftesque detail in org Date: Mon, 18 May 2015 11:02:05 +0200 Message-ID: References: <87382yji8z.fsf@iki.fi> <87lhgqxeq0.fsf@gmx.us> <87k2w754vk.fsf@iki.fi> <874mnaykh0.fsf@gmx.us> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YuGwL-00019B-Va for emacs-orgmode@gnu.org; Mon, 18 May 2015 05:02:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YuGwF-0006Z3-IB for emacs-orgmode@gnu.org; Mon, 18 May 2015 05:02:25 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:38651) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YuGwF-0006X9-9x for emacs-orgmode@gnu.org; Mon, 18 May 2015 05:02:19 -0400 Received: by wicnf17 with SMTP id nf17so61358719wic.1 for ; Mon, 18 May 2015 02:02:18 -0700 (PDT) In-Reply-To: (Brett Witty's message of "Mon, 18 May 2015 18:33:51 +1000") 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: Brett Witty Cc: Org mailing list , Rasmus --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brett Witty writes: > I agree with Rasmus' position. Just because the org format is plain text, > doesn't mean the Emacs keybindings have to act identically to, say, > Notepad. Otherwise, what's Emacs for? Similarly, I don't expect TAB to > insert tabs into an org-mode document. > > While there can be a bit of a culture shock getting used to org's "do the > useful thing" as opposed to "do the literal thing", I think it's an > advantage of the system, not a disadvantage. Headers are sacred in > org-mode, so breaking headers with RET seems suboptimal when there's vast= ly > more things you'd care about. Similarly in tables, or drawers or timestam= ps > or... OK - this makes sense. But instead of jumping to the next line, a splitting of the header into two would make more sense, keeping the correct syntax. Jumping to the next line is actually counter intuitive, as this is pure movement. Cheers, Rainer > > That said, it would be nice to have some sort of customization variable to > allow the literal behaviour, but set by default to the current behaviour > (similar to org-support-shift-select). > > BrettW > > On Mon, May 18, 2015 at 7:15 AM, Rasmus wrote: > >> Hi Jarmo, >> >> Jarmo Hurri writes: >> >> > Rasmus writes: >> >> >> With your behavior you can (i) break the TODO tag; (ii) break the >> cookie; >> >> (iii) break the tag. At least (i) and (ii) are quite destructive. >> > >> > I am not sure what you mean, since a single undo will always heal the >> > line again, regardless of where you break it. >> >> Sure. But that seems orthogonal to the problem at hand. Re (i): Assume >> TODO is keyword. We don't know that TO is. Re (ii): [#B] is a cookie. >> [#B is not. (iii) iii :tag: is a tag :ta is not. The editor should not >> easily produce invalid syntax. >> >> In any case it's very easy to rebind keys in a hook. If you write a >> org.texi patch on how to get purist keybindings we can add it. >> >> > I am a BIG fan of the Org mode slogan "Your life in plain text." The >> > power of plain text has been demonstrated over and over again. You can >> > run text manipulating commands on it, you can process it with a large >> > array of different programming languages. >> >> Nobody is disputing that. >> >> > An undo is a basic text editing feature that everyone should >> > know. Reassigning non-standard behaviour to the return key is - in my >> > opinion - against the ideology. >> >> I see that you use Gnus. Did you by any change use RET to open the >> article? It's bound to gnus-summary-scroll-up. >> >> In Emacs25, or maybe even before, RET in at least lisp mode started to >> indent automatically via electric-indent-mode. Are you against this? >> >> What I will agree on is that it would be better if Org used more >> "standard" mechanism and e.g. cleverly hooked newline. However, Org >> targets a number of versions of Emacs (ATM: 23-25), making this hard. >> >> >> The attached patch re-enables breaks in region four of >> >> org-complex-heading-regexp, i.e. from the cookie up to tags. A quick >> >> test suggests it works nicely. >> >> >> >> WDYT? >> > >> > Given enough time, I could come up with a situation where I would run a >> > keyboard macro in which I would expect the return key to break the lin= e, >> > regardless of where I was on that line (in a tag or whatever). >> >> In that case there's C-o C-e or M-x newline... >> >> > I am a very minor player in this game, but I would really, _really_ li= ke >> > Org to remain as true to it's slogan as possible. >> >> I'm still don't see this point. There's Org, "the format", which should >> ideally be easy to use in any editor (I wrote a basic syntax parser for >> texworks). It's plaintext. Then there's org-mode, the principal editor >> of Org. It supposed to be a nice environment for composing text. >> >> =E2=80=94Rasmus >> >> -- >> This is the kind of tedious nonsense up with which I will not put >> >> >> =2D-=20 Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,= UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D): +49 - (0)3 21 21 25 22 44 email: Rainer@krugs.de Skype: RMkrug PGP: 0x0F52F982 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBAgAGBQJVWaqXAAoJENvXNx4PUvmCzKMIAMEgqgaXhHZ2B8V3H5H9bQhR ew0AW2XvThZMw+Yx7INGFdvIeBZ9fmE0gB2YQnPwpAmXOcv7CXO+wMIU+pHGkOnw vzikTl/bPrjRtoO79bqMaeI9mZana0yfYbYg+QjBx4t4ShMzSiSjAMlhjqEqih0H Q07m6WwtZ/0iLvki/KMGevD0SXLBgpTxOVU6VE239rsNJFrVp9xVD7uaNMr/07u7 xmnFucQBW7KEeI+Sh176YHcoQT6NucUlvICAXjmSzPBJkdFP027G/ctdXnSTHbJx IBaO8x1SiNj4X8gHD5SWNHoU708S9MASR4C2gicVSL0JVgA6MQjAron6HUJFH10= =mT4/ -----END PGP SIGNATURE----- --=-=-=--