Re: [O] A Microsoftesque detail in org
Rasmus ras...@gmx.us writes: 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. Pushed. Let me know if it's worse than before. Rasmus -- Need more coffee. . .
Re: [O] A Microsoftesque detail in org
Hi Rasmus, On Mon, May 18, 2015 at 05:39:36PM +0200, Rasmus wrote: Suvayu Ali fatkasuvayu+li...@gmail.com writes: As for Rasmus's examples of similar behaviour in other modes, I don't like them either. Unfortunately again, I'm too short on time to fix the behaviour in my setup. So far nobody has felt strongly enough about this to supply a patch, even to org.texi or, I think, worg. Here's an untested start to get rid of those pesky Microsoftesque detail in org-mode (with-eval-after-load 'org (add-hook 'org-mode-hook (defun org-keyboard-purist () (org-defkey org-mode-map (kbd RET) nil) (mapc (lambda (key) (org-defkey org-mode-map key nil)) (list [(control return)] [(shift control return)] [(meta return)]) I didn't realise it is this simple! I'm always afraid of fiddling with Org key bindings because of all the context sensitive magic going on. Thank you. -- Suvayu Open source is the future. It sets us free.
Re: [O] A Microsoftesque detail in org
On Mon, May 18, 2015 at 06:33:51PM +1000, Brett Witty wrote: 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 vastly more things you'd care about. Similarly in tables, or drawers or timestamps or... Actually, the headline behaviour was a shock to me as a long time user! I would have reported it if only I had some time to be more involved. As for headlines being sacred, I realise they may have a lot of meta information. However the keyword is may, they are all optional. Even the most primary candidate for protection, tags, are optional! As long as we can undo, I do not think any hand holding is necessary. As for Rasmus's examples of similar behaviour in other modes, I don't like them either. Unfortunately again, I'm too short on time to fix the behaviour in my setup. That said, this is just my personal opinion. As long as there ways to get the normal behaviour back, I'm happy. If there are no easy ways to get it back, I'll live with it. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] A Microsoftesque detail in org
On 18 May 2015, Brett Witty wrote: 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 vastly more things you'd care about. I'm on this side too. I like the current behaviour. Bill -- William Denton ↔ Toronto, Canada ↔ https://www.miskatonic.org/
Re: [O] A Microsoftesque detail in org
Titus von der Malsburg malsb...@posteo.de writes: On 2015-05-17 Sun 14:15, Rasmus wrote: 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. I disagree with that last statement. I’m not aware of any Emacs mode (or any other text editor for that matter) that prevents me from producing invalid syntax. A text editor preventing invalid syntax is actually not even desirable because the path from one syntactically valid state of the document to the next often leads through invalid states. If you really want to prevent temporarily invalid documents, the result is going to be some kind of GUI application, not a text editor. While that may be a valid solution for some people, it is certainly not the Emacs way of doing things. Exactly! I would prefer that by default there is no intelligence in the return key, but more intelligence can be added as an option. (The problem with Microsoft programs is exactly the fact that too much intelligence is the default.) I leave it to the wiser men to decide. Over and out from me. Jarmo
Re: [O] A Microsoftesque detail in org
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 vastly more things you'd care about. Similarly in tables, or drawers or timestamps or... 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 ras...@gmx.us wrote: Hi Jarmo, Jarmo Hurri jarmo.hu...@iki.fi writes: Rasmus ras...@gmx.us 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 line, 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_ like 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. —Rasmus -- This is the kind of tedious nonsense up with which I will not put
Re: [O] A Microsoftesque detail in org
Suvayu Ali fatkasuvayu+li...@gmail.com writes: As for Rasmus's examples of similar behaviour in other modes, I don't like them either. Unfortunately again, I'm too short on time to fix the behaviour in my setup. So far nobody has felt strongly enough about this to supply a patch, even to org.texi or, I think, worg. Here's an untested start to get rid of those pesky Microsoftesque detail in org-mode (with-eval-after-load 'org (add-hook 'org-mode-hook (defun org-keyboard-purist () (org-defkey org-mode-map (kbd RET) nil) (mapc (lambda (key) (org-defkey org-mode-map key nil)) (list [(control return)] [(shift control return)] [(meta return)]) —Rasmus -- It was you, Jezebel, it was you
Re: [O] A Microsoftesque detail in org
Rainer M Krug rai...@krugs.de writes: 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. That is literally what my patch does IF you are in region four (more or less) of org-complex-heading-regexp. Jumping to the next line is actually counter intuitive, as this is pure movement. It's what it does in tables (most of the time). What would be better? —Rasmus -- However beautiful the theory, you should occasionally look at the evidence
Re: [O] A Microsoftesque detail in org
Brett Witty brettwi...@brettwitty.net 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 vastly more things you'd care about. Similarly in tables, or drawers or timestamps 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 ras...@gmx.us wrote: Hi Jarmo, Jarmo Hurri jarmo.hu...@iki.fi writes: Rasmus ras...@gmx.us 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 line, 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_ like 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. —Rasmus -- This is the kind of tedious nonsense up with which I will not put -- 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: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] A Microsoftesque detail in org
Rasmus ras...@gmx.us writes: Rainer M Krug rai...@krugs.de writes: 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. That is literally what my patch does IF you are in region four (more or less) of org-complex-heading-regexp. Sorry - I did not look into the patch - but that sounds perfect. Jumping to the next line is actually counter intuitive, as this is pure movement. It's what it does in tables (most of the time). What would be better? For me, tables area a slightly different story, as they can not contain line breaks. OK - you could argue headers neither. I think you got me there. But the syntax in a table is more abstract then in a straight header. Is you have priorities, tags, ... it is different, story. But as you are asking, one more consistent possibility for tables would be to *split* the cell where the cursor sits, (as in normal text) and create a new empty row below the one the cursor is in with the cell containing the remainder of the cell above. So: | test 1 | re | t | | test 2 | a | b | | test 3 | c | d | with cursor in the space in test 2 would become | test 1 | re | t | | test 2 | a | b | | 2 || | | test 3 | c | d | But I would not suggest due to the table nature. Cheers, Rainer —Rasmus -- 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: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] A Microsoftesque detail in org
Titus von der Malsburg malsb...@posteo.de writes: While that may be a valid solution for some people, it is certainly not the Emacs way of doing things. That's right. It is the Org mode way of doing things in Emacs. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] A Microsoftesque detail in org
On 2015-05-17 Sun 14:15, Rasmus wrote: Hi Jarmo, Jarmo Hurri jarmo.hu...@iki.fi writes: Rasmus ras...@gmx.us 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. I disagree with that last statement. I’m not aware of any Emacs mode (or any other text editor for that matter) that prevents me from producing invalid syntax. A text editor preventing invalid syntax is actually not even desirable because the path from one syntactically valid state of the document to the next often leads through invalid states. If you really want to prevent temporarily invalid documents, the result is going to be some kind of GUI application, not a text editor. While that may be a valid solution for some people, it is certainly not the Emacs way of doing things. Titus 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 line, 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_ like 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. —Rasmus signature.asc Description: PGP signature
Re: [O] A Microsoftesque detail in org
Rasmus ras...@gmx.us writes: Greetings Rasmus. I would suggest that the original interpretation of Enter would not be messed with. Messing with Alt-Enter and such is fine, but Enter, please no. I disagree. Consider the more complete example: * TODO [#A] foo bar:tag: 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. 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. 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. 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 line, regardless of where I was on that line (in a tag or whatever). I am a very minor player in this game, but I would really, _really_ like Org to remain as true to it's slogan as possible. Keeping it real, Jarmo
Re: [O] A Microsoftesque detail in org
Hi Jarmo, Jarmo Hurri jarmo.hu...@iki.fi writes: Rasmus ras...@gmx.us 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 line, 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_ like 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. —Rasmus -- This is the kind of tedious nonsense up with which I will not put
Re: [O] A Microsoftesque detail in org
Titus von der Malsburg malsb...@posteo.de writes:
One minor cosmetic issue:
* TODO foo bar :test:
When I RET between foo and bar, the tag moves to the left. I think it
would be nicer if it would stay where it was.
In the attached patch current column of tags is used if
org-auto-align-tags is nil. Otherwise org-tags-column is used.
I'll push this unless any other undesirable behaviors are found.
Thanks,
Rasmus
--
⠠⠵
From 112b91cdc2887b1cc4451549dd4dd0c2e6a370ac Mon Sep 17 00:00:00 2001
From: Rasmus ras...@gmx.us
Date: Fri, 15 May 2015 13:08:11 +0200
Subject: [PATCH 1/3] org.el: RET breaks headline text
* org.el (org-return): RET breaks headline text.
* test-org.el (test-org/return): Test org-return on headline text.
* ORG-NEWS: Add entry on new org-return behavior.
---
etc/ORG-NEWS | 4 +
lisp/org.el | 222 +++
testing/lisp/test-org.el | 31 ++-
3 files changed, 61 insertions(+), 196 deletions(-)
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 3803060..a3e1ae2 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -93,6 +93,10 @@ functions. The Org version of these functions skips over inline tasks
*** ~org-element-context~ no longer return objects in keywords
~org-element-context~ used to return objects on some keywords, i.e.,
=TITLE=, =DATE= and =AUTHOR=. It now returns only the keyword.
+*** Behavior of ~org-return~ changed
+If point is before or after the true headline text, insert newline
+without changing the text. If point is on headline text preserve
+tags.
** Removed functions
*** Removed function ~org-translate-time~
Use ~org-timestamp-translate~ instead.
diff --git a/lisp/org.el b/lisp/org.el
index 4b44a94..a46cb86 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19845,189 +19845,6 @@ boundaries.
(org-defkey org-mode-map \C-c|'org-table-create-or-convert-from-region)
(org-defkey org-mode-map [(control ?#)] 'org-table-rotate-recalc-marks)
(org-defkey org-mode-map \C-c~'org-table-create-with-table.el)
-(org-defkey org-mode-map \C-c\C-a 'org-attach)
-(org-defkey org-mode-map \C-c}'org-table-toggle-coordinate-overlays)
-(org-defkey org-mode-map \C-c{'org-table-toggle-formula-debugger)
-(org-defkey org-mode-map \C-c\C-e 'org-export-dispatch)
-(org-defkey org-mode-map \C-c:'org-toggle-fixed-width)
-(org-defkey org-mode-map \C-c\C-x\C-f 'org-emphasize)
-(org-defkey org-mode-map \C-c\C-xf'org-footnote-action)
-(org-defkey org-mode-map \C-c\C-x\C-mg'org-mobile-pull)
-(org-defkey org-mode-map \C-c\C-x\C-mp'org-mobile-push)
-(org-defkey org-mode-map \C-c@ 'org-mark-subtree)
-(org-defkey org-mode-map \M-h 'org-mark-element)
-(org-defkey org-mode-map [?\C-c (control ?*)] 'org-list-make-subtree)
-;;(org-defkey org-mode-map [?\C-c (control ?-)] 'org-list-make-list-from-subtree)
-
-(org-defkey org-mode-map \C-c\C-x\C-w 'org-cut-special)
-(org-defkey org-mode-map \C-c\C-x\M-w 'org-copy-special)
-(org-defkey org-mode-map \C-c\C-x\C-y 'org-paste-special)
-
-(org-defkey org-mode-map \C-c\C-x\C-t 'org-toggle-time-stamp-overlays)
-(org-defkey org-mode-map \C-c\C-x\C-i 'org-clock-in)
-(org-defkey org-mode-map \C-c\C-x\C-x 'org-clock-in-last)
-(org-defkey org-mode-map \C-c\C-x\C-z 'org-resolve-clocks)
-(org-defkey org-mode-map \C-c\C-x\C-o 'org-clock-out)
-(org-defkey org-mode-map \C-c\C-x\C-j 'org-clock-goto)
-(org-defkey org-mode-map \C-c\C-x\C-q 'org-clock-cancel)
-(org-defkey org-mode-map \C-c\C-x\C-d 'org-clock-display)
-(org-defkey org-mode-map \C-c\C-x\C-r 'org-clock-report)
-(org-defkey org-mode-map \C-c\C-x\C-u 'org-dblock-update)
-(org-defkey org-mode-map \C-c\C-x\C-l 'org-toggle-latex-fragment)
-(org-defkey org-mode-map \C-c\C-x\C-v 'org-toggle-inline-images)
-(org-defkey org-mode-map \C-c\C-x\C-\M-v 'org-redisplay-inline-images)
-(org-defkey org-mode-map \C-c\C-x\\ 'org-toggle-pretty-entities)
-(org-defkey org-mode-map \C-c\C-x\C-b 'org-toggle-checkbox)
-(org-defkey org-mode-map \C-c\C-xp'org-set-property)
-(org-defkey org-mode-map \C-c\C-xP'org-set-property-and-value)
-(org-defkey org-mode-map \C-c\C-xe'org-set-effort)
-(org-defkey org-mode-map \C-c\C-xE'org-inc-effort)
-(org-defkey org-mode-map \C-c\C-xo'org-toggle-ordered-property)
-(org-defkey org-mode-map \C-c\C-xi'org-insert-columns-dblock)
-(org-defkey org-mode-map [(control ?c) (control ?x) ?\;] 'org-timer-set-timer)
-
-(org-defkey org-mode-map \C-c\C-x.'org-timer)
-(org-defkey org-mode-map \C-c\C-x-'org-timer-item)
-(org-defkey org-mode-map \C-c\C-x0'org-timer-start)
-(org-defkey org-mode-map \C-c\C-x_'org-timer-stop)
-(org-defkey org-mode-map \C-c\C-x,'org-timer-pause-or-continue)
-
-(define-key org-mode-map \C-c\C-x\C-c 'org-columns)
-
-(define-key org-mode-map \C-c\C-x! 'org-reload)
-
-(define-key org-mode-map \C-c\C-xg 'org-feed-update-all)
-(define-key org-mode-map \C-c\C-xG 'org-feed-goto-inbox)
-
-(define-key
Re: [O] A Microsoftesque detail in org
Hi Rasmus, just tried the patch and while I still find it weird to change the meaning of RET, this solution doesn’t get in my way as much as the previous solution did. One minor cosmetic issue: * TODO foo bar :test: When I RET between foo and bar, the tag moves to the left. I think it would be nicer if it would stay where it was. Titus On 2015-05-16 Sat 08:28, Rasmus wrote: Hi, Thanks for the comments. Nicolas Goaziou m...@nicolasgoaziou.fr writes: RET breaks headline text may be more accurate. OK. + (let* ((context (if org-return-follows-link (org-element-context) + (org-element-at-point))) +(type (org-element-type context))) +(cond + ;; At a headline + ((and (eq type 'headline) (not (bolp))) You are removing an optimization here. Checking if point is on a headline/inlinetask doesn't require to use `org-element-at-point'/`org-element-context'. It is faster to simply check for `org-outline-regexp' (or derived) at bol. This optimization is less important than it used to be, now that properties drawers are at a fixed location. Nevertheless, it might be worth keeping it in mind. I did it 'cause it's easier, I think, to read a single cond than first an if and then a cond. The latter also seems easier to fix in the future. + (org-show-entry) + (let ((string )) + (unless (and (save-excursion + (beginning-of-line) + (looking-at org-complex-heading-regexp)) +(or (and (match-beginning 3) + ( (point) +(save-excursion + (goto-char (match-beginning 4)) + (skip-chars-backward \t) + (point +(and (match-beginning 5) + (= (point) (match-beginning 5) + ;; Point is on headline keywords, tags or cookies. Do not break + ;; them: add a newline after the headline instead. + (setq string (delete-and-extract-region + (point) (or (match-beginning 5) + (line-end-position The `setq' is not necessary here. Bind it within `let' instead. You are right. + (when (match-beginning 5) + (insert (make-string (length string) ?\ ?\ - ?\s If you add this feature, please augment `test-org/return' from test-org.el accordingly. Done and and attached. Anybody against pushing this? —Rasmus signature.asc Description: PGP signature
Re: [O] A Microsoftesque detail in org
Hi Titus,
Titus von der Malsburg malsb...@posteo.de writes:
just tried the patch and while I still find it weird to change the
meaning of RET, this solution doesn’t get in my way as much as the
previous solution did.
Try to:
(with-temp-buffer (org-mode) (describe-mode)).
A lot of keys have been orgified.
At the extreme of the anti-org-whatever-key line of though, how would
org-table work?
One minor cosmetic issue:
* TODO foo bar :test:
When I RET between foo and bar, the tag moves to the left. I think it
would be nicer if it would stay where it was.
Good observation. I don't even know how to make a tab character in Emacs
so I blissfully assumed them away.
Anyway, this should be fixed now, though it will religiously adhere to
org-tags-column which, at least for my setup, your example does not. I
think this is acceptable 'cause we also need to consider the example
* TODO foo \phi\delta
:test:
Which is pretty hard due to the overlays (display-width is two, but real
length is more).
Could you try this version of the patch and see if you find it more
satisfactory?
Thanks,
Rasmus
--
Governments should be afraid of their people
From 60688c52732fbbe0757c57686089c55c709f2a07 Mon Sep 17 00:00:00 2001
From: Rasmus ras...@gmx.us
Date: Fri, 15 May 2015 13:08:11 +0200
Subject: [PATCH 1/2] org.el: RET breaks headline text
* org.el (org-return): RET breaks headline text.
* test-org.el (test-org/return): Test org-return on headline text.
* ORG-NEWS: Add entry on new org-return behavior.
---
etc/ORG-NEWS | 4 +
lisp/org.el | 217 ++-
testing/lisp/test-org.el | 28 +-
3 files changed, 54 insertions(+), 195 deletions(-)
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 3803060..a3e1ae2 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -93,6 +93,10 @@ functions. The Org version of these functions skips over inline tasks
*** ~org-element-context~ no longer return objects in keywords
~org-element-context~ used to return objects on some keywords, i.e.,
=TITLE=, =DATE= and =AUTHOR=. It now returns only the keyword.
+*** Behavior of ~org-return~ changed
+If point is before or after the true headline text, insert newline
+without changing the text. If point is on headline text preserve
+tags.
** Removed functions
*** Removed function ~org-translate-time~
Use ~org-timestamp-translate~ instead.
diff --git a/lisp/org.el b/lisp/org.el
index 4b44a94..8527c2d 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -19845,189 +19845,6 @@ boundaries.
(org-defkey org-mode-map \C-c|'org-table-create-or-convert-from-region)
(org-defkey org-mode-map [(control ?#)] 'org-table-rotate-recalc-marks)
(org-defkey org-mode-map \C-c~'org-table-create-with-table.el)
-(org-defkey org-mode-map \C-c\C-a 'org-attach)
-(org-defkey org-mode-map \C-c}'org-table-toggle-coordinate-overlays)
-(org-defkey org-mode-map \C-c{'org-table-toggle-formula-debugger)
-(org-defkey org-mode-map \C-c\C-e 'org-export-dispatch)
-(org-defkey org-mode-map \C-c:'org-toggle-fixed-width)
-(org-defkey org-mode-map \C-c\C-x\C-f 'org-emphasize)
-(org-defkey org-mode-map \C-c\C-xf'org-footnote-action)
-(org-defkey org-mode-map \C-c\C-x\C-mg'org-mobile-pull)
-(org-defkey org-mode-map \C-c\C-x\C-mp'org-mobile-push)
-(org-defkey org-mode-map \C-c@ 'org-mark-subtree)
-(org-defkey org-mode-map \M-h 'org-mark-element)
-(org-defkey org-mode-map [?\C-c (control ?*)] 'org-list-make-subtree)
-;;(org-defkey org-mode-map [?\C-c (control ?-)] 'org-list-make-list-from-subtree)
-
-(org-defkey org-mode-map \C-c\C-x\C-w 'org-cut-special)
-(org-defkey org-mode-map \C-c\C-x\M-w 'org-copy-special)
-(org-defkey org-mode-map \C-c\C-x\C-y 'org-paste-special)
-
-(org-defkey org-mode-map \C-c\C-x\C-t 'org-toggle-time-stamp-overlays)
-(org-defkey org-mode-map \C-c\C-x\C-i 'org-clock-in)
-(org-defkey org-mode-map \C-c\C-x\C-x 'org-clock-in-last)
-(org-defkey org-mode-map \C-c\C-x\C-z 'org-resolve-clocks)
-(org-defkey org-mode-map \C-c\C-x\C-o 'org-clock-out)
-(org-defkey org-mode-map \C-c\C-x\C-j 'org-clock-goto)
-(org-defkey org-mode-map \C-c\C-x\C-q 'org-clock-cancel)
-(org-defkey org-mode-map \C-c\C-x\C-d 'org-clock-display)
-(org-defkey org-mode-map \C-c\C-x\C-r 'org-clock-report)
-(org-defkey org-mode-map \C-c\C-x\C-u 'org-dblock-update)
-(org-defkey org-mode-map \C-c\C-x\C-l 'org-toggle-latex-fragment)
-(org-defkey org-mode-map \C-c\C-x\C-v 'org-toggle-inline-images)
-(org-defkey org-mode-map \C-c\C-x\C-\M-v 'org-redisplay-inline-images)
-(org-defkey org-mode-map \C-c\C-x\\ 'org-toggle-pretty-entities)
-(org-defkey org-mode-map \C-c\C-x\C-b 'org-toggle-checkbox)
-(org-defkey org-mode-map \C-c\C-xp'org-set-property)
-(org-defkey org-mode-map \C-c\C-xP'org-set-property-and-value)
-(org-defkey org-mode-map \C-c\C-xe'org-set-effort)
-(org-defkey
Re: [O] A Microsoftesque detail in org
Hi, Thanks for the comments. Nicolas Goaziou m...@nicolasgoaziou.fr writes: RET breaks headline text may be more accurate. OK. + (let* ((context (if org-return-follows-link (org-element-context) +(org-element-at-point))) + (type (org-element-type context))) +(cond + ;; At a headline + ((and (eq type 'headline) (not (bolp))) You are removing an optimization here. Checking if point is on a headline/inlinetask doesn't require to use `org-element-at-point'/`org-element-context'. It is faster to simply check for `org-outline-regexp' (or derived) at bol. This optimization is less important than it used to be, now that properties drawers are at a fixed location. Nevertheless, it might be worth keeping it in mind. I did it 'cause it's easier, I think, to read a single cond than first an if and then a cond. The latter also seems easier to fix in the future. + (org-show-entry) + (let ((string )) +(unless (and (save-excursion + (beginning-of-line) + (looking-at org-complex-heading-regexp)) + (or (and (match-beginning 3) + ( (point) + (save-excursion + (goto-char (match-beginning 4)) + (skip-chars-backward \t) + (point + (and (match-beginning 5) + (= (point) (match-beginning 5) +;; Point is on headline keywords, tags or cookies. Do not break +;; them: add a newline after the headline instead. + (setq string (delete-and-extract-region +(point) (or (match-beginning 5) +(line-end-position The `setq' is not necessary here. Bind it within `let' instead. You are right. + (when (match-beginning 5) +(insert (make-string (length string) ?\ ?\ - ?\s If you add this feature, please augment `test-org/return' from test-org.el accordingly. Done and and attached. Anybody against pushing this? —Rasmus -- There are known knowns; there are things we know that we know From a7e6e6b9c96c13be9ebdc0a5c4c2f5033cefbfc7 Mon Sep 17 00:00:00 2001 From: Rasmus ras...@gmx.us Date: Fri, 15 May 2015 13:08:11 +0200 Subject: [PATCH 1/2] org.el: RET breaks headline text * org.el (org-return): RET breaks headline text. * test-org.el (test-org/return): Test org-return on headline text. * ORG-NEWS: Add entry on new org-return behavior. --- etc/ORG-NEWS | 4 lisp/org.el | 32 ++-- testing/lisp/test-org.el | 28 ++-- 3 files changed, 52 insertions(+), 12 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 3803060..a3e1ae2 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -93,6 +93,10 @@ functions. The Org version of these functions skips over inline tasks *** ~org-element-context~ no longer return objects in keywords ~org-element-context~ used to return objects on some keywords, i.e., =TITLE=, =DATE= and =AUTHOR=. It now returns only the keyword. +*** Behavior of ~org-return~ changed +If point is before or after the true headline text, insert newline +without changing the text. If point is on headline text preserve +tags. ** Removed functions *** Removed function ~org-translate-time~ Use ~org-timestamp-translate~ instead. diff --git a/lisp/org.el b/lisp/org.el index 4b44a94..93183f9 100755 --- a/lisp/org.el +++ b/lisp/org.el @@ -21185,16 +21185,28 @@ will not happen if point is in a table or on a \dead\ object (e.g., within a comment). In these case, you need to use `org-open-at-point' directly. (interactive) - (if (and (save-excursion - (beginning-of-line) - (looking-at org-todo-line-regexp)) - (match-beginning 3) - (= (point) (match-beginning 3))) - ;; Point is on headline tags. Do not break them: add a newline - ;; after the headline instead. - (progn (org-show-entry) - (end-of-line) - (if indent (newline-and-indent) (newline))) + (if (and (not (bolp)) + (save-excursion (beginning-of-line) + (looking-at org-complex-heading-regexp))) + ;; At a headline. + (let ((string (if (or ( (point) + (save-excursion + (goto-char (match-beginning 4)) + (skip-chars-backward \t) + (point))) + (and (match-beginning 5) + (= (point) (match-beginning 5 + ;; Point is on headline keywords, tags or cookies. Do not break + ;; them: add a newline after the headline instead. + + (delete-and-extract-region (point) (or (match-beginning 5) + (line-end-position)) + (when (match-beginning 5) + (insert (make-string (length string) ?\s))) + (end-of-line) + (org-show-entry) + (if indent (newline-and-indent) (newline)) + (save-excursion (insert (org-trim string (let* ((context (if
Re: [O] A Microsoftesque detail in org
On 2015-05-16 Sat 12:00, Rasmus wrote: Hi Titus, Titus von der Malsburg malsb...@posteo.de writes: just tried the patch and while I still find it weird to change the meaning of RET, this solution doesn’t get in my way as much as the previous solution did. Try to: (with-temp-buffer (org-mode) (describe-mode)). A lot of keys have been orgified. At the extreme of the anti-org-whatever-key line of though, how would org-table work? Let me first say that I think your latest patch is a good compromise and I could totally live with that solution. Having said that, I have very mixed feelings about how org behaves in tables. I’m a heavy user of org mode and feel highly comfortable with every aspect of it. Tables are the only exception. They trip me up again and again with behavior that I perceive as counter-intuitive. The problem is that org-mode is not the only citizen in the Emacs ecosystem and therefore it matters more how the rest of Emacs behaves than how Microsoft products or other outliners behave. For instance, when I put to cursor on a headline in a markdown document and press RET, I get a newline at that position. If I put the cursor on a headline in a LaTeX document and press RET, again I get a newline. The same goes for subject lines in emails (message-mode) and many other similar situations. All these things are conceptually headlines and should therefore behave the same way. Anything else would create unnecessary cognitive load for the user. Since org-mode for many years used to behave like all the other modes that I mentioned, it is not accurate to call this position anti-org. … my 5 cents. Have a nice weekend! Titus One minor cosmetic issue: * TODO foo bar :test: When I RET between foo and bar, the tag moves to the left. I think it would be nicer if it would stay where it was. Good observation. I don't even know how to make a tab character in Emacs so I blissfully assumed them away. Anyway, this should be fixed now, though it will religiously adhere to org-tags-column which, at least for my setup, your example does not. I think this is acceptable 'cause we also need to consider the example * TODO foo \phi\delta :test: Which is pretty hard due to the overlays (display-width is two, but real length is more). Could you try this version of the patch and see if you find it more satisfactory? Thanks, Rasmus signature.asc Description: PGP signature
Re: [O] A Microsoftesque detail in org
Hello, Rasmus ras...@gmx.us writes: 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. Thank you. WDYT? Some comments follow. Subject: [PATCH 2/2] org.el: RET works in headline text * org.el (org-return): RET works in headline text. RET breaks headline text may be more accurate. + (let* ((context (if org-return-follows-link (org-element-context) + (org-element-at-point))) + (type (org-element-type context))) +(cond + ;; At a headline + ((and (eq type 'headline) (not (bolp))) You are removing an optimization here. Checking if point is on a headline/inlinetask doesn't require to use `org-element-at-point'/`org-element-context'. It is faster to simply check for `org-outline-regexp' (or derived) at bol. This optimization is less important than it used to be, now that properties drawers are at a fixed location. Nevertheless, it might be worth keeping it in mind. + (org-show-entry) + (let ((string )) + (unless (and (save-excursion +(beginning-of-line) +(looking-at org-complex-heading-regexp)) + (or (and (match-beginning 3) + ( (point) + (save-excursion +(goto-char (match-beginning 4)) +(skip-chars-backward \t) +(point + (and (match-beginning 5) + (= (point) (match-beginning 5) + ;; Point is on headline keywords, tags or cookies. Do not break + ;; them: add a newline after the headline instead. + (setq string (delete-and-extract-region + (point) (or (match-beginning 5) + (line-end-position The `setq' is not necessary here. Bind it within `let' instead. + (when (match-beginning 5) + (insert (make-string (length string) ?\ ?\ - ?\s If you add this feature, please augment `test-org/return' from test-org.el accordingly. Regards, -- Nicolas Goaziou
Re: [O] A Microsoftesque detail in org
Hi Jarmo, Jarmo Hurri jarmo.hu...@iki.fi writes: I was just amazed by the following detail in org. In the example below, if my cursor is anywhere inside the word Example, and I press Enter, a new line will be inserted below, and the cursor will jump to the next line. The location of the cursor inside the heading line is ignored, and the heading line will not be broken. # * Example Some text. # This immediately reminded me of Microsoft products, where the software tries to be too intelligent, thus making it harder for the user. In this case, I needed to figure out that Ctrl-o is needed to break the line. I would suggest that the original interpretation of Enter would not be messed with. Messing with Alt-Enter and such is fine, but Enter, please no. I disagree. Consider the more complete example: * TODO [#A] foo bar:tag: 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, for one, would hate to have to readjust my tags every time I break a headline. Call me spoiled by MS if you like and if you think it's relevant. Yet, not being able to break between foo and bar is quite annoying. 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? —Rasmus -- However beautiful the theory, you should occasionally look at the evidence From 8a2477cb70770526939a6c665026802d46db21ea Mon Sep 17 00:00:00 2001 From: Rasmus ras...@gmx.us Date: Fri, 15 May 2015 13:08:11 +0200 Subject: [PATCH 2/2] org.el: RET works in headline text * org.el (org-return): RET works in headline text. --- lisp/org.el | 93 +++-- 1 file changed, 54 insertions(+), 39 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 4b44a94..8adec05 100755 --- a/lisp/org.el +++ b/lisp/org.el @@ -21185,45 +21185,60 @@ will not happen if point is in a table or on a \dead\ object (e.g., within a comment). In these case, you need to use `org-open-at-point' directly. (interactive) - (if (and (save-excursion - (beginning-of-line) - (looking-at org-todo-line-regexp)) - (match-beginning 3) - (= (point) (match-beginning 3))) - ;; Point is on headline tags. Do not break them: add a newline - ;; after the headline instead. - (progn (org-show-entry) - (end-of-line) - (if indent (newline-and-indent) (newline))) -(let* ((context (if org-return-follows-link (org-element-context) - (org-element-at-point))) - (type (org-element-type context))) - (cond - ;; In a table, call `org-table-next-row'. - ((or (and (eq type 'table) - (= (point) (org-element-property :contents-begin context)) - ( (point) (org-element-property :contents-end context))) - (org-element-lineage context '(table-row table-cell) t)) - (org-table-justify-field-maybe) - (call-interactively #'org-table-next-row)) - ;; On a link or a timestamp but not on white spaces after it, - ;; call `org-open-line' if `org-return-follows-link' allows it. - ((and org-return-follows-link - (memq type '(link timestamp)) - ( (point) - (save-excursion (goto-char (org-element-property :end context)) -(skip-chars-backward \t) -(point - (call-interactively #'org-open-at-point)) - ;; In a list, make sure indenting keeps trailing text within. - ((and indent - (not (eolp)) - (org-element-lineage context '(item))) - (let ((trailing-data - (delete-and-extract-region (point) (line-end-position - (newline-and-indent) - (save-excursion (insert trailing-data - (t (if indent (newline-and-indent) (newline))) + (let* ((context (if org-return-follows-link (org-element-context) + (org-element-at-point))) + (type (org-element-type context))) +(cond + ;; At a headline + ((and (eq type 'headline) (not (bolp))) + (org-show-entry) + (let ((string )) + (unless (and (save-excursion + (beginning-of-line) + (looking-at org-complex-heading-regexp)) + (or (and (match-beginning 3) + ( (point) + (save-excursion + (goto-char (match-beginning 4)) + (skip-chars-backward \t) + (point + (and (match-beginning 5) + (= (point) (match-beginning 5) + ;; Point is on headline keywords, tags or cookies. Do not break + ;; them: add a newline after the headline instead. + (setq string (delete-and-extract-region + (point) (or (match-beginning 5) +(line-end-position + (when (match-beginning 5) + (insert (make-string (length string) ?\ + (end-of-line) + (if indent (newline-and-indent) (newline)) + (save-excursion (insert (org-trim
Re: [O] A Microsoftesque detail in org
Jarmo Hurri jarmo.hu...@iki.fi writes: Greetings. I was just amazed by the following detail in org. In the example below, if my cursor is anywhere inside the word Example, and I press Enter, a new line will be inserted below, and the cursor will jump to the next line. The location of the cursor inside the heading line is ignored, and the heading line will not be broken. I was struggling with this as well until I somehow worked around this - fortunately I did not need this to often. # * Example Some text. # This immediately reminded me of Microsoft products, where the software tries to be too intelligent, thus making it harder for the user. In this case, I needed to figure out that Ctrl-o is needed to break the line. Thanks - did not know this. I would suggest that the original interpretation of Enter would not be messed with. Messing with Alt-Enter and such is fine, but Enter, please no. I agree - Return should be return - unless e.g. a smart return is enabled in the settings. I would definitely dis-able this. Cheers, Rainer Or? Jarmo -- 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: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] A Microsoftesque detail in org
-Original Message- On Behalf Of Jarmo Hurri Subject: [O] A Microsoftesque detail in org ...the software tries to be too intelligent, thus making it harder for the user. Well, phrased. I usually just scream, DON'T DO ME ANY FAVORS! -- ,Doug Douglas Lewan Shubert Ticketing (201) 489-8600 ext 224 or ext 4335 The human brain is the most complex thing known to man, according to the human brain.
Re: [O] A Microsoftesque detail in org
Pressing enter in a headline to make a new headline is consistent with the way many other text-mode outliners have worked in the past. Ctrl-O to open a line is an Emacs standard keybinding. I don't really have an issue with the way this works. -- Bob Newell Honolulu, Hawai`i * Sent via Ma Gnus 0.12-Emacs 24.3-Linux Mint 17 *
Re: [O] A Microsoftesque detail in org
I fully agree with this, I find this “feature” very irritating. There is a strong expectation that hitting enter inserts a line break at the position of the cursor. Can we please stick to that? When I put the cursor in the middle of a word and press enter that also “breaks” the word. Yet we would not prevent the user from doing this. Titus On 2015-05-15 Fri 02:35, Jarmo Hurri wrote: Greetings. I was just amazed by the following detail in org. In the example below, if my cursor is anywhere inside the word Example, and I press Enter, a new line will be inserted below, and the cursor will jump to the next line. The location of the cursor inside the heading line is ignored, and the heading line will not be broken. # * Example Some text. # This immediately reminded me of Microsoft products, where the software tries to be too intelligent, thus making it harder for the user. In this case, I needed to figure out that Ctrl-o is needed to break the line. I would suggest that the original interpretation of Enter would not be messed with. Messing with Alt-Enter and such is fine, but Enter, please no. Or? Jarmo signature.asc Description: PGP signature
Re: [O] A Microsoftesque detail in org
I like this feature and hope that I can keep it by setting a variable if changes are made. All the best, Tom Titus von der Malsburg malsb...@posteo.de writes: I fully agree with this, I find this “feature” very irritating. There is a strong expectation that hitting enter inserts a line break at the position of the cursor. Can we please stick to that? When I put the cursor in the middle of a word and press enter that also “breaks” the word. Yet we would not prevent the user from doing this. Titus On 2015-05-15 Fri 02:35, Jarmo Hurri wrote: Greetings. I was just amazed by the following detail in org. In the example below, if my cursor is anywhere inside the word Example, and I press Enter, a new line will be inserted below, and the cursor will jump to the next line. The location of the cursor inside the heading line is ignored, and the heading line will not be broken. # * Example Some text. # This immediately reminded me of Microsoft products, where the software tries to be too intelligent, thus making it harder for the user. In this case, I needed to figure out that Ctrl-o is needed to break the line. I would suggest that the original interpretation of Enter would not be messed with. Messing with Alt-Enter and such is fine, but Enter, please no. Or? Jarmo -- Thomas S. Dye http://www.tsdye.com
