Re: S-RET not incrementing table cell with emacs -nw
On Thu, Dec 01, 2022 at 04:50:48PM +0100, Loris Bennett wrote: > Hi, > > If I run emacs or emacsclient with the option -nw or -t, the chord S-RET > in a table cell does not create a new cell below with the incremented > value. It just creates a new empty cell. When running Emacs with a > GUI, the incrementation works. > > Is this a known problem? If so, is there a solution? Most terminals don't even know what a S-RET is (i.e. they don't have a code sequence to pass it to the application). Actually, most terms just pass 0x0a, i.e. "linefeed". So Emacs has no chance to "see" that you meant S-RET. Cheers -- t signature.asc Description: PGP signature
S-RET not incrementing table cell with emacs -nw
Hi, If I run emacs or emacsclient with the option -nw or -t, the chord S-RET in a table cell does not create a new cell below with the incremented value. It just creates a new empty cell. When running Emacs with a GUI, the incrementation works. Is this a known problem? If so, is there a solution? Cheers, Loris -- This signature is currently under constuction.
Re: S-RET
Juri Linkov writes: >> you can find a lot of functions like the ones in jupyter at >> https://github.com/jkitchin/scimax/blob/master/scimax-ob.el. I setup my >> ipython like this: >> https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L89 >> >> although I will note there are several setups in that file, e.g. this >> hydra: >> https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L271 >> … >> I don't use them all, but leave them to remind me sometimes. > > Thanks, the number of supported features is impressive! > > I see that the file name contains the word 'upstream'. This implies a set > of patches to upstream modules. Are there any plans to submit upstream > at least some of the most often used commands that correspond to > basic Jupyter shortcuts? The upstream refers to org-babel-ipython. These libraries build on and extend that. I don't have any plans to push them upstream, I think the future will be with emacs-jupyter instead, but I haven't had time to transition to it. > > For example, it would make sense to bring scimax-execute-and-next-block > under the org-babel namespace as e.g. > org-babel-execute-src-block-and-next-block > in the upstream ob-core.el. Then S-RET will be available to other ob backends > (such as ob-ruby.el that I use often too.) I alot of these make sense for general babel use I think. My time for development work has mostly vanished now, and it is not clear when it will come back. If anyone wants to push these into ob-core.el, I have no objections. -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: S-RET
>> What I miss in Org Babel is an equivalent of 'S-RET' that in Jupyter >> creates a new code block relative to the current code block. > > 'C-c C-v C-d' (org-babel-demarcate-block) splits current code block into > two with the same settings. It might be what you want. Just bind it to > something easier to access maybe :P Thanks, I tried 'C-c C-v C-d', but it's not exactly what is needed, just an approximation. When #+RESULTS: already exists after the #+END_SRC line, 'C-c C-v C-d' doesn't add a new #+BEGIN_SRC after #+RESULTS:, it adds before it (however, this could be mitigated by evaluating both blocks after splitting.)
Re: S-RET
Juri Linkov writes: > > What I miss in Org Babel is an equivalent of 'S-RET' that in Jupyter > creates a new code block relative to the current code block. 'C-c C-v C-d' (org-babel-demarcate-block) splits current code block into two with the same settings. It might be what you want. Just bind it to something easier to access maybe :P /Leo
Re: S-RET
> you can find a lot of functions like the ones in jupyter at > https://github.com/jkitchin/scimax/blob/master/scimax-ob.el. I setup my > ipython like this: > https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L89 > > although I will note there are several setups in that file, e.g. this > hydra: > https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L271 > … > I don't use them all, but leave them to remind me sometimes. Thanks, the number of supported features is impressive! I see that the file name contains the word 'upstream'. This implies a set of patches to upstream modules. Are there any plans to submit upstream at least some of the most often used commands that correspond to basic Jupyter shortcuts? For example, it would make sense to bring scimax-execute-and-next-block under the org-babel namespace as e.g. org-babel-execute-src-block-and-next-block in the upstream ob-core.el. Then S-RET will be available to other ob backends (such as ob-ruby.el that I use often too.)
Re: S-RET
you can find a lot of functions like the ones in jupyter at https://github.com/jkitchin/scimax/blob/master/scimax-ob.el. I setup my ipython like this: https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L89 although I will note there are several setups in that file, e.g. this hydra: https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L271 and these: edit: https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L271 command: https://github.com/jkitchin/scimax/blob/master/scimax-org-babel-ipython-upstream.el#L526 I don't use them all, but leave them to remind me sometimes. John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Sat, Nov 14, 2020 at 3:20 PM Juri Linkov wrote: > I've switched to Org Babel as a replacement of Jupyter Notebook since I > already > tired copying Julia program texts back and forth between Jupyter pages > in web browsers and Emacs. Fortunately, Org Babel can do everything that > Jupyter Notebook does. Except that there is a small usability feature > that I miss in Org Babel. Typing 'C-RET' in Jupyter evaluates the current > code block. In Org Babel 'C-RET' inserts a new heading at the end of > the current subtree. To evaluate the code block there is 'C-c C-c' > (org-ctrl-c-ctrl-c). Thus the equivalent of 'C-RET' is 'C-c C-c'. > So far, so good. > > What I miss in Org Babel is an equivalent of 'S-RET' that in Jupyter > creates a new code block relative to the current code block. > > Actually, in Org Babel such a command already exists and is bound to > the needed key 'S-RET', but currently it works only on tables: > the command is 'org-table-copy-down' and it copies the current field > down to the next row and moves point along with it. This is exactly > what is needed also in context of code blocks. > > Maybe like there is already the command named 'org-ctrl-c-ctrl-c', > a new general command bound to e.g. 'org-s-ret' could do this > depending on context. > > PS: another similarity is how typing RET in shell buffers > inserts a new prompt where the user can type a new command. > 'S-RET' in code blocks could work the same way: type 'S-RET' > and write code in the next code block, and type 'S-RET' again. > >
S-RET
I've switched to Org Babel as a replacement of Jupyter Notebook since I already tired copying Julia program texts back and forth between Jupyter pages in web browsers and Emacs. Fortunately, Org Babel can do everything that Jupyter Notebook does. Except that there is a small usability feature that I miss in Org Babel. Typing 'C-RET' in Jupyter evaluates the current code block. In Org Babel 'C-RET' inserts a new heading at the end of the current subtree. To evaluate the code block there is 'C-c C-c' (org-ctrl-c-ctrl-c). Thus the equivalent of 'C-RET' is 'C-c C-c'. So far, so good. What I miss in Org Babel is an equivalent of 'S-RET' that in Jupyter creates a new code block relative to the current code block. Actually, in Org Babel such a command already exists and is bound to the needed key 'S-RET', but currently it works only on tables: the command is 'org-table-copy-down' and it copies the current field down to the next row and moves point along with it. This is exactly what is needed also in context of code blocks. Maybe like there is already the command named 'org-ctrl-c-ctrl-c', a new general command bound to e.g. 'org-s-ret' could do this depending on context. PS: another similarity is how typing RET in shell buffers inserts a new prompt where the user can type a new command. 'S-RET' in code blocks could work the same way: type 'S-RET' and write code in the next code block, and type 'S-RET' again.
Re: [O] M-S-RET doesn't work anymore?
Kaushal Modi writes: > On Wed, Jan 23, 2019 at 3:54 PM Marco Wahl wrote: > > As a workaround you can evaluate the lines (that were active before the > commit) > > (org-defkey org-mode-map (kbd "S-") #'org-table-copy-down) > (org-defkey org-mode-map (kbd "M-S-") #'org-insert-todo-heading) > (org-defkey org-mode-map (kbd "ESC S-") #'org-insert-todo-heading) > > or put them into your init file AFAICS. > > Yep, that commit broke the - bindings for me too. I'll have to do the > same. > > Copying Kevin who originally requested the change of these bindings (this > switching of bindings between RET and feels like dejavu to me .. I > have seen this done before in Org repo). > > Is this a reliable fix to add these lines to the source code again? > To be honest I don't see clearly. > > May be those keys should be bound to both RET and variants? > > For Emacs GUI, I think that the variant is needed, RET does nothing. Gah! Apologies for the breakage. I assumed that in GUI frames, since is translated to RET when the former is not bound explicitly[1], *modifier*- would also be translated to *modifier*-RET, but that does not seem to be the case[2]. My previous experience with M-RET in markdown-mode[3] led me to assume I could suggest this change without breaking anything… Next time I'll know better and write those unit tests :) Thank you for catching this and again, sorry for the disruption. [1]: In fundamental-mode: C-h k ⇒ RET (translated from ) runs the command newline… [2]: In fundamental-mode: M-: (global-set-key (kbd "S-RET") (lambda () (interactive) (message "foo"))) C-h k S- ⇒ RET (translated from ) runs the command newline… M-: (global-set-key (kbd "M-S-RET") (lambda () (interactive) (message "bar"))) C-h M-S- ⇒ is undefined M-: (global-set-key (kbd "M-RET") (lambda () (interactive) (message "baz"))) C-h M- ⇒ M-RET (translated from ) runs the command (lambda…) [3]: https://github.com/jrblevin/markdown-mode/commit/c0fc52461e845baa3c55d9b6f9e67c451a9ffa8d
Re: [O] M-S-RET doesn't work anymore?
Nicolas Goaziou writes: >> May be those keys should be bound to both RET and variants? > > This is what I just did in master. Thank you. Thanks!! It works great again :) I really like the pairing of C-RET, C-S-RET which creates a TODO and M-RET and M-S-RET which creates a checkbox. Converting lists to headings with C-c * and back again with C-c - just feels natural when the key bindings work this way. Having to use C-M-S-m just felt awkward and wrong to me :) Thanks for all your excellent work on Org! Regards, Bernt
Re: [O] M-S-RET doesn't work anymore?
Helo, Kaushal Modi writes: > May be those keys should be bound to both RET and variants? This is what I just did in master. Thank you. Regards, -- Nicolas Goaziou
Re: [O] M-S-RET doesn't work anymore?
On Wed, Jan 23, 2019, 7:45 PM Amin Bandali > Also notice the left over greater sign ‘>’ on the fourth line. > Yeah, that was fixed in a later commit. I was surprised to see that too, but confirmed that the latest master doesn't have that. >
Re: [O] M-S-RET doesn't work anymore?
> #+begin_src diff > -(org-defkey org-mode-map (kbd "S-") #'org-table-copy-down) > -(org-defkey org-mode-map (kbd "M-S-") #'org-insert-todo-heading) > -(org-defkey org-mode-map (kbd "ESC S-") #'org-insert-todo-heading) > +(org-defkey org-mode-map (kbd "S-RET>") #'org-table-copy-down) > +(org-defkey org-mode-map (kbd "M-S-RET") #'org-insert-todo-heading) > +(org-defkey org-mode-map (kbd "ESC S-RET") #'org-insert-todo-heading) > #+end_src Also notice the left over greater sign ‘>’ on the fourth line.
Re: [O] M-S-RET doesn't work anymore?
On Wed, Jan 23, 2019 at 3:54 PM Marco Wahl wrote: > As a workaround you can evaluate the lines (that were active before the > commit) > > (org-defkey org-mode-map (kbd "S-") #'org-table-copy-down) > (org-defkey org-mode-map (kbd "M-S-") #'org-insert-todo-heading) > (org-defkey org-mode-map (kbd "ESC S-") #'org-insert-todo-heading) > > or put them into your init file AFAICS. > Yep, that commit broke the - bindings for me too. I'll have to do the same. Copying Kevin who originally requested the change of these bindings (this switching of bindings between RET and feels like dejavu to me .. I have seen this done before in Org repo). Is this a reliable fix to add these lines to the source code again? > To be honest I don't see clearly. > May be those keys should be bound to both RET and variants? For Emacs GUI, I think that the variant is needed, RET does nothing.
Re: [O] M-S-RET doesn't work anymore?
Hi! > I regularly create checkbox lists on the fly with > > 1. [ ] blah and M-S-RET to create the second entry > > 2. [ ] I can confirm this. > But the checkbox is missing today. Has this functionality changed? > > I am running the latest master from git on windows emacs 25.1 I guess the new behavior is due to commit 8a1957d59201940613ee90be9ed0a49e70131f37. #+begin_src diff -(org-defkey org-mode-map (kbd "S-") #'org-table-copy-down) -(org-defkey org-mode-map (kbd "M-S-") #'org-insert-todo-heading) -(org-defkey org-mode-map (kbd "ESC S-") #'org-insert-todo-heading) +(org-defkey org-mode-map (kbd "S-RET>") #'org-table-copy-down) +(org-defkey org-mode-map (kbd "M-S-RET") #'org-insert-todo-heading) +(org-defkey org-mode-map (kbd "ESC S-RET") #'org-insert-todo-heading) #+end_src I think you could use M-S-C-m with the current code. As a workaround you can evaluate the lines (that were active before the commit) (org-defkey org-mode-map (kbd "S-") #'org-table-copy-down) (org-defkey org-mode-map (kbd "M-S-") #'org-insert-todo-heading) (org-defkey org-mode-map (kbd "ESC S-") #'org-insert-todo-heading) or put them into your init file AFAICS. Is this a reliable fix to add these lines to the source code again? To be honest I don't see clearly. Ciao, Marco
Re: [O] M-S-RET doesn't work anymore?
On Wed, Jan 23, 2019 at 3:13 PM Bernt Hansen wrote: > Hi, > > I regularly create checkbox lists on the fly with > > 1. [ ] blah and M-S-RET to create the second entry > > 2. [ ] > > But the checkbox is missing today. Has this functionality changed? > > I am running the latest master from git on windows emacs 25.1 > Possible a regression caused by https://code.orgmode.org/bzg/org-mode/commit/8a1957d59201940613ee90be9ed0a49e70131f37 ?
[O] M-S-RET doesn't work anymore?
Hi, I regularly create checkbox lists on the fly with 1. [ ] blah and M-S-RET to create the second entry 2. [ ] But the checkbox is missing today. Has this functionality changed? I am running the latest master from git on windows emacs 25.1 Thanks, Bernt
Re: [O] Binding org-insert-todo-heading to M-S-RET
Hello, Kévin Le Gouguec writes: > Here is a very minor gripe I have with org-mode: is there a reason why > org-insert-todo-heading should be bound to (kbd "M-S-"), rather > than (kbd "M-S-RET")? > > AFAIU, using "" limits the key binding to the actual "⏎" > function key, while using "RET" makes any key chord that sends the > "carriage return" character ("⏎" and "C-m") work transparently. > > I admit that Alt-Shift-Control-M sounds unwieldy, but my muscle memory > has become so accustomed to using "C-m" instead of "" that I > would welcome a change allowing this alternative. > > ( > From my understanding of (emacs)Keymaps and (emacs)Named ASCII > Chars, using "RET" also has the advantage that bindings can work in > terminals; IIUC terminals translate presses to "⏎" into the "RET" > control character, so Emacs never knows that "" was pressed. > > However in this particular case I don't believe that the argument > applies, since AFAIK terminals cannot transmit "S-RET" to Emacs. > "M-RET" works though, precisely because it uses "RET" and not > "". > ) > > Thank you for your time. Fair enough. I changed a few to RET in master. Regards, -- Nicolas Goaziou
[O] Binding org-insert-todo-heading to M-S-RET
Hello! Here is a very minor gripe I have with org-mode: is there a reason why org-insert-todo-heading should be bound to (kbd "M-S-"), rather than (kbd "M-S-RET")? AFAIU, using "" limits the key binding to the actual "⏎" function key, while using "RET" makes any key chord that sends the "carriage return" character ("⏎" and "C-m") work transparently. I admit that Alt-Shift-Control-M sounds unwieldy, but my muscle memory has become so accustomed to using "C-m" instead of "" that I would welcome a change allowing this alternative. ( From my understanding of (emacs)Keymaps and (emacs)Named ASCII Chars, using "RET" also has the advantage that bindings can work in terminals; IIUC terminals translate presses to "⏎" into the "RET" control character, so Emacs never knows that "" was pressed. However in this particular case I don't believe that the argument applies, since AFAIK terminals cannot transmit "S-RET" to Emacs. "M-RET" works though, precisely because it uses "RET" and not "". ) Thank you for your time. PS: I found a relatively recent thread discussing this issue: http://lists.gnu.org/archive/html/emacs-orgmode/2017-06/msg00580.html I am happy that there exist alternative key bindings for terminal environments; however, I don't think this thread explains why org-mode uses "" rather than "RET".
Re: [O] [Bug] M-S Ret keybinding translated to M-Ret
Hello, Matt Lundin <m...@imapmail.org> writes: > Attached please find a more limited patch that fixes the issue in the > GUI without affecting TTY use. I have only changed bindings for the > M-S-RET or S-RET combinations. These combinations cannot be used in the > TTY anyway and Org Mode already defines alternative TTY bindings for > these combinations. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [Bug] M-S Ret keybinding translated to M-Ret
Thanks, your new patch looks acceptable to me. On Fri, Feb 9, 2018 at 7:02 AM Matt Lundin <m...@imapmail.org> wrote: > Allen Li <vianchielfa...@gmail.com> writes: > > > On Wed, Feb 7, 2018 at 1:47 PM Matt Lundin <m...@imapmail.org> wrote: > > > >> Matt Lundin <m...@imapmail.org> writes: > > > >> > I discovered that when trying to insert a new item with a checkbox > using > >> > M-S Return (org-insert-todo-heading), the keybinding is "translated" > to > >> > M-Return (org-meta-return). As a result, all I get is simple list item > >> > without a checkbox. > >> > > > > >> The attached patch fixes this issue. > > > > I'm pretty sure your patch would break those binding in terminal Emacs > > completely, since cannot be typed in the terminal and Emacs > > does not remap these bindings. > > Attached please find a more limited patch that fixes the issue in the > GUI without affecting TTY use. I have only changed bindings for the > M-S-RET or S-RET combinations. These combinations cannot be used in the > TTY anyway and Org Mode already defines alternative TTY bindings for > these combinations. > > Best, > Matt > >
Re: [O] [Bug] M-S Ret keybinding translated to M-Ret
Allen Li <vianchielfa...@gmail.com> writes: > On Wed, Feb 7, 2018 at 1:47 PM Matt Lundin <m...@imapmail.org> wrote: > >> Matt Lundin <m...@imapmail.org> writes: > >> > I discovered that when trying to insert a new item with a checkbox using >> > M-S Return (org-insert-todo-heading), the keybinding is "translated" to >> > M-Return (org-meta-return). As a result, all I get is simple list item >> > without a checkbox. >> > > >> The attached patch fixes this issue. > > I'm pretty sure your patch would break those binding in terminal Emacs > completely, since cannot be typed in the terminal and Emacs > does not remap these bindings. Attached please find a more limited patch that fixes the issue in the GUI without affecting TTY use. I have only changed bindings for the M-S-RET or S-RET combinations. These combinations cannot be used in the TTY anyway and Org Mode already defines alternative TTY bindings for these combinations. Best, Matt >From 3ec2e2b82ff64d708286cc9f3962acad56771dfb Mon Sep 17 00:00:00 2001 From: Matt Lundin <m...@imapmail.org> Date: Fri, 9 Feb 2018 08:52:41 -0600 Subject: [PATCH] Fix S- and M-S- keybindings for GUI This prevents these key combinations from being translated to M-RET in window systems. These bindings already have extra keys defined for TTY. --- lisp/org.el | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 688e48bcc..e47a7e0ac 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -18859,9 +18859,9 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command names." (define-key org-mode-map (kbd "") #'org-shifttab) RET key with modifiers -(org-defkey org-mode-map (kbd "S-RET") #'org-table-copy-down) -(org-defkey org-mode-map (kbd "M-S-RET") #'org-insert-todo-heading) -(org-defkey org-mode-map (kbd "ESC S-RET") #'org-insert-todo-heading) +(org-defkey org-mode-map (kbd "S-") #'org-table-copy-down) +(org-defkey org-mode-map (kbd "M-S-") #'org-insert-todo-heading) +(org-defkey org-mode-map (kbd "ESC S-") #'org-insert-todo-heading) (org-defkey org-mode-map (kbd "M-RET") #'org-meta-return) (org-defkey org-mode-map (kbd "ESC RET") #'org-meta-return) -- 2.16.1
Re: [O] [Bug] M-S Ret keybinding translated to M-Ret
Allen Li <vianchielfa...@gmail.com> writes: > On Wed, Feb 7, 2018 at 1:47 PM Matt Lundin <m...@imapmail.org> wrote: > >> Matt Lundin <m...@imapmail.org> writes: > >> > I discovered that when trying to insert a new item with a checkbox using >> > M-S Return (org-insert-todo-heading), the keybinding is "translated" to >> > M-Return (org-meta-return). As a result, all I get is simple list item >> > without a checkbox. >> > > >> The attached patch fixes this issue. > > I'm pretty sure your patch would break those binding in terminal Emacs > completely, since > cannot be typed in the terminal and Emacs does not remap these > bindings. Thanks for pointing this out. I hope someone who knows emacs keybindings better can take the lead here. I was just following the example of the following commit, which uses "". , | commit c3fffcd8d21f248f946e2d39d4bde3ce80dcf6d4 | Author: Nicolas Goaziou <m...@nicolasgoaziou.fr> | Date: Mon Jan 15 22:59:40 2018 +0100 | | Fix C- binding ` > Furthermore, I cannot reproduce your issue on Org mode version 9.1.6 > (9.1.6-33-g5b4a71-elpaplus) That is because the version in elpa not have the problematic commit yet. The elpa version you are using still uses old way of defining these keys: (org-defkey org-mode-map [(meta shift return)] 'org-insert-todo-heading) The problematic commit (6965098a5357b09575a1119074545eb708cf5944) changed that line to the following (along with several related changes): (org-defkey org-mode-map (kbd "M-S-RET") #'org-insert-todo-heading) Could you evaluate this latter line and see if you can reproduce the problem. Thanks, Matt
Re: [O] [Bug] M-S Ret keybinding translated to M-Ret
On Wed, Feb 7, 2018 at 1:47 PM Matt Lundinwrote: > Matt Lundin writes: > > I discovered that when trying to insert a new item with a checkbox using > > M-S Return (org-insert-todo-heading), the keybinding is "translated" to > > M-Return (org-meta-return). As a result, all I get is simple list item > > without a checkbox. > > > The attached patch fixes this issue. I'm pretty sure your patch would break those binding in terminal Emacs completely, since cannot be typed in the terminal and Emacs does not remap these bindings. Furthermore, I cannot reproduce your issue on Org mode version 9.1.6 (9.1.6-33-g5b4a71-elpaplus) C-h C-k M-S- runs the command org-insert-todo-heading (found in org-mode-map), which is an interactive compiled Lisp function in ‘org.el’. It is bound to . (org-insert-todo-heading ARG FORCE-HEADING)
Re: [O] [Bug] M-S Ret keybinding translated to M-Ret
Matt Lundin <m...@imapmail.org> writes: > I discovered that when trying to insert a new item with a checkbox using > M-S Return (org-insert-todo-heading), the keybinding is "translated" to > M-Return (org-meta-return). As a result, all I get is simple list item > without a checkbox. > The attached patch fixes this issue. >From 240caa630ef053a27536fe9c4725d0480dc4c570 Mon Sep 17 00:00:00 2001 From: Matt Lundin <m...@imapmail.org> Date: Wed, 7 Feb 2018 15:45:45 -0600 Subject: [PATCH] Fix return bindings --- lisp/org.el | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 688e48bcc..133bf038a 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -18859,11 +18859,11 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command names." (define-key org-mode-map (kbd "") #'org-shifttab) RET key with modifiers -(org-defkey org-mode-map (kbd "S-RET") #'org-table-copy-down) -(org-defkey org-mode-map (kbd "M-S-RET") #'org-insert-todo-heading) -(org-defkey org-mode-map (kbd "ESC S-RET") #'org-insert-todo-heading) -(org-defkey org-mode-map (kbd "M-RET") #'org-meta-return) -(org-defkey org-mode-map (kbd "ESC RET") #'org-meta-return) +(org-defkey org-mode-map (kbd "S-") #'org-table-copy-down) +(org-defkey org-mode-map (kbd "M-S-") #'org-insert-todo-heading) +(org-defkey org-mode-map (kbd "ESC S-") #'org-insert-todo-heading) +(org-defkey org-mode-map (kbd "M-") #'org-meta-return) +(org-defkey org-mode-map (kbd "ESC ") #'org-meta-return) Cursor keys with modifiers (org-defkey org-mode-map (kbd "M-") #'org-metaleft) -- 2.16.1
[O] [Bug] M-S Ret keybinding translated to M-Ret
I discovered that when trying to insert a new item with a checkbox using M-S Return (org-insert-todo-heading), the keybinding is "translated" to M-Return (org-meta-return). As a result, all I get is simple list item without a checkbox. M-x describe-key [Ret] M-S Ret ...shows the following... --8<---cut here---start->8--- M-RET (translated from ) runs the command org-meta-return (found in org-mode-map), which is an interactive compiled Lisp function in ‘org.el’. It is bound to M-RET, C-c C-x RET. (org-meta-return ARG) --8<---cut here---end--->8--- A git bisect traced the source of this problem to the following commit: --8<---cut here---start->8--- 6965098a5357b09575a1119074545eb708cf5944 is the first bad commit commit 6965098a5357b09575a1119074545eb708cf5944 Author: Nicolas Goaziou <m...@nicolasgoaziou.fr> Date: Mon Jan 15 16:13:37 2018 +0100 Use a single keybinding representation * lisp/org.el (org-replace-disputed-keys): Fix docstring. Use `kbd' macro everywhere. Also add missing "ESC" equivalents for "M-" bindings. --8<---cut here---end--->8--- Thanks, Matt
Re: [O] [babel, ess] How can I make S-RET to be multi-session friendly?
Another issue I've noticed is that if I save a buffer, that was previously associated with R session, under different name in different folder, then that association is not getting reset and/or overridden by session property of Org buffer. Namely, I had dot R file that I saved in different folder as dot org one while wrapping code in babel blocks and adding session property. I did C-c C-c. I believe there is somewhere a check whether a buffer is associated or not but no check if it is associated with a proper buffer/session. Eric Schulte writes on Fri Aug 17 2012 at 09:29 : The `org-src-in-org-buffer' macro may be used from an edit buffer to run elisp inside the code block, in the org-mode buffer of the edit buffer. e.g., the following ;; -*- emacs-lisp -*- (org-src-in-org-buffer (message --%S (org-babel-get-src-block-info))) Where is org-src-in-org-buffer macro defined. Searching all dot el files in org folder does not show anything neither does C-h f show anything similar. (describe-function 'org-src-in-org-buffer) shows that org-src-in-org-buffer can be found in org-src.el (line 679 in my version). I guess it did not propagate to bzr yet :( I've checked with rev 109760. For some reason I had problems building git version on Windows a while ago and I didn't try since then. -- Mikhail
Re: [O] [babel, ess] How can I make S-RET to be multi-session friendly?
The `org-src-in-org-buffer' macro may be used from an edit buffer to run elisp inside the code block, in the org-mode buffer of the edit buffer. e.g., the following ;; -*- emacs-lisp -*- (org-src-in-org-buffer (message --%S (org-babel-get-src-block-info))) Where is org-src-in-org-buffer macro defined. Searching all dot el files in org folder does not show anything neither does C-h f show anything similar. (describe-function 'org-src-in-org-buffer) shows that org-src-in-org-buffer can be found in org-src.el (line 679 in my version). -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [babel, ess] How can I make S-RET to be multi-session friendly?
Bastien b...@gnu.org writes: I would say that after applying changes to my-ess-eval and to org-babel-edit-prep:R as suggested by Andrew, it looks like everything is working right for me. I'v been bold and I pushed the change Andrew suggested. Thanks for reporting this and for testing around -- and thanks to Andrew for the exploration and the fix! Though not related to Org, I noticed that ess-make-buffer-current calls (update-ess-process-name-list) thus making a call for it in my-ess-eval, probably, somewhat redundant, right? Another thing that somewhat bugs me is that if R process quits (or probably dies as well) when editing source code block in a separate buffer, the subsequent S-RET will silently execute a line in a wrong buffer/process. If there are no buffers with R process, it will create the default *R* named buffer. It might be exotic but I think it is an issue. Does it mean that there is a bug in ess-make-buffer-current function somewhere? Something, probably, re-associates a buffer to another process, does it? I think it might be relevant that code editing buffer local variable ess-local-process-name is non-nil when associated process quits. This results in first ess-make-buffer-current in my-ess-eval silently launching *R*. I'm not sure if it is too much to fix. Perhaps hitting C-c ' twice to re-start editing is a reasonable workaround. Eric Schulte eric.schu...@gmx.com writes: You can find the name of the original org-mode buffer by running the following snippet of elisp within the edit buffer. ;; -*- emacs-lisp -*- (marker-buffer org-edit-src-beg-marker) The `org-src-in-org-buffer' macro may be used from an edit buffer to run elisp inside the code block, in the org-mode buffer of the edit buffer. e.g., the following ;; -*- emacs-lisp -*- (org-src-in-org-buffer (message --%S (org-babel-get-src-block-info))) Where is org-src-in-org-buffer macro defined. Searching all dot el files in org folder does not show anything neither does C-h f show anything similar. -- Mikhail
Re: [O] [babel, ess] How can I make S-RET to be multi-session friendly?
Andrew Young younga...@gmail.com writes: Hello All, Hi Andrew, Well, despite being relatively new to elisp, I've decided to take a crack at one of your problems. I'm not too sure what is causing the strange behaviour of the session property, but I have some thoughts on getting that one function working. Thanks for sending this along, unfortunately ob-R.el is currently without a core maintainer, so I'm not sure who on list would have the expertise to review your submission. Although hopefully those experiencing the problem can at least check if it works for them. Bear with me :-) It seems that for me, the inferior ess process is not being properly associated with the src edit buffer. It is being set correctly by org-babel-R-associate-session, and then being set a second time incorrectly by org-babel-edit-prep:R. Commenting out line 5 in org-babel-edit-prep:R seems to fix this issue, although I'm honestly not sure if or what it breaks. Everything seems ok for me, but ymmv. Heres the change: #+begin_src emacs-lisp (defun org-babel-edit-prep:R (info) (let ((session (cdr (assoc :session (nth 2 info) (when (and session (string-match ^\\*\\(.+?\\)\\*$ session)) (save-match-data (org-babel-R-initiate-session session nil)) ;;(setq ess-local-process-name (match-string 1 session) ))) #+end_src Perhaps replacing the commented setq ess-local-process-name line with ess-switch-process could solve this problem? Could the process name be found programatically, perhaps using the regexp solution above. Is there any one having such issues, or who can weigh in on what exactly is happening here? Without making the above change, it is possible to manually attach an ess process to the current src buffer by using the command: C-c C-s (ess-switch-process) You'll have to specify the process name, rather than the buffer name, and the session must have already been started. From here all ESS functions should work. For example, calling: C-c C-z (ess-switch-to-end-of-ESS) will open the session buffer. I've implemented a variation of the function you mentioned, which uses the inferior process discussed above. It should do something at least remotely like the function you were asking for, and will work with babel sessions, as long as the ess process is associated properly. I've made one change worth mentioning: the function now prompts for a buffer name to set up on if no ess process is associated, instead of only and always using *R*. Try it out, and let me know what you think. Of course feel free to tweak share! This is my real first dive into lisp, so if anyone has anything to share please do. #+begin_src emacs-lisp (defun my-ess-eval () (interactive) (update-ess-process-name-list) (if (not (ess-make-buffer-current)) ;; Obtain the target ess session (let ((session (read-string Use session: (let ((proc (get-process ess-current-process-name))) (if (processp proc) (buffer-name (process-buffer proc))) ;; Obtain buffer matching session (if (not (get-buffer session)) ;; If there is no buffer, create a new one (save-excursion (inferior-ess) (rename-buffer session))) (setq ess-local-process-name (process-name (get-buffer-process session) (ess-make-buffer-current) (if (and transient-mark-mode mark-active) (call-interactively 'ess-eval-region) (call-interactively 'ess-eval-line-and-step))) (add-hook 'ess-mode-hook '(lambda () (local-set-key [(shift return)] 'my-ess-eval))) (add-hook 'inferior-ess-mode-hook '(lambda () (local-set-key [C-up] 'comint-previous-input) (local-set-key [C-down] 'comint-next-input))) (add-hook 'Rnw-mode-hook '(lambda () (local-set-key [(shift return)] 'my-ess-eval))) (require 'ess-site) #+end_src This looks good to me, perhaps it should be added to the Worg page on using R with Org-mode? http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html Thanks, Sincerely, Andrew Young -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [babel, ess] How can I make S-RET to be multi-session friendly?
Eric Schulte eric.schu...@gmx.com writes: Thanks for sending this along, unfortunately ob-R.el is currently without a core maintainer Quite a sad situation, many good modules lack maintainers :( , so I'm not sure who on list would have the expertise to review your submission. Although hopefully those experiencing the problem can at least check if it works for them. I'm not an expert but I gave it a shot. It seems that for me, the inferior ess process is not being properly associated with the src edit buffer. It is being set correctly by org-babel-R-associate-session, and then being set a second time incorrectly by org-babel-edit-prep:R. Commenting out line 5 in org-babel-edit-prep:R seems to fix this issue, although I'm honestly not sure if or what it breaks. Everything seems ok for me, but ymmv. Heres the change: #+begin_src emacs-lisp (defun org-babel-edit-prep:R (info) (let ((session (cdr (assoc :session (nth 2 info) (when (and session (string-match ^\\*\\(.+?\\)\\*$ session)) (save-match-data (org-babel-R-initiate-session session nil)) ;;(setq ess-local-process-name (match-string 1 session) ))) #+end_src Perhaps replacing the commented setq ess-local-process-name line with ess-switch-process could solve this problem? Could the process name be found programatically, perhaps using the regexp solution above. Is there any one having such issues, or who can weigh in on what exactly is happening here? Without making the above change, it is possible to manually attach an ess process to the current src buffer by using the command: C-c C-s (ess-switch-process) You'll have to specify the process name, rather than the buffer name, and the session must have already been started. I would say that after applying changes to my-ess-eval and to org-babel-edit-prep:R as suggested by Andrew, it looks like everything is working right for me. Once I hit C-c ' I see properly named buffer appear with new process. Then if I hit S-RET it asks me what session to use and since I have ido mode, it already highlights proper session name, so I just hit RET. Perhaps it worth recommending to use ido? Note that I do not have to enter process name. If I quite R, while editing code in a separate buffer, and hit S-RET it is executed in the wrong one without any question being asked :( I'm running somewhat recent bzr version of Emacs with default Org in it. -- Mikhail
Re: [O] [babel, ess] How can I make S-RET to be multi-session friendly?
Hi Mikhail, Mikhail Titov m...@gmx.us writes: I would say that after applying changes to my-ess-eval and to org-babel-edit-prep:R as suggested by Andrew, it looks like everything is working right for me. I'v been bold and I pushed the change Andrew suggested. Thanks for reporting this and for testing around -- and thanks to Andrew for the exploration and the fix! -- Bastien
Re: [O] [babel, ess] How can I make S-RET to be multi-session friendly?
Hello All, Well, despite being relatively new to elisp, I've decided to take a crack at one of your problems. I'm not too sure what is causing the strange behaviour of the session property, but I have some thoughts on getting that one function working. Bear with me :-) It seems that for me, the inferior ess process is not being properly associated with the src edit buffer. It is being set correctly by org-babel-R-associate-session, and then being set a second time incorrectly by org-babel-edit-prep:R. Commenting out line 5 in org-babel-edit-prep:R seems to fix this issue, although I'm honestly not sure if or what it breaks. Everything seems ok for me, but ymmv. Heres the change: #+begin_src emacs-lisp (defun org-babel-edit-prep:R (info) (let ((session (cdr (assoc :session (nth 2 info) (when (and session (string-match ^\\*\\(.+?\\)\\*$ session)) (save-match-data (org-babel-R-initiate-session session nil)) ;;(setq ess-local-process-name (match-string 1 session) ))) #+end_src Is there any one having such issues, or who can weigh in on what exactly is happening here? Without making the above change, it is possible to manually attach an ess process to the current src buffer by using the command: C-c C-s (ess-switch-process) You'll have to specify the process name, rather than the buffer name, and the session must have already been started. From here all ESS functions should work. For example, calling: C-c C-z (ess-switch-to-end-of-ESS) will open the session buffer. I've implemented a variation of the function you mentioned, which uses the inferior process discussed above. It should do something at least remotely like the function you were asking for, and will work with babel sessions, as long as the ess process is associated properly. I've made one change worth mentioning: the function now prompts for a buffer name to set up on if no ess process is associated, instead of only and always using *R*. Try it out, and let me know what you think. Of course feel free to tweak share! This is my real first dive into lisp, so if anyone has anything to share please do. #+begin_src emacs-lisp (defun my-ess-eval () (interactive) (update-ess-process-name-list) (if (not (ess-make-buffer-current)) ;; Obtain the target ess session (let ((session (read-string Use session: (let ((proc (get-process ess-current-process-name))) (if (processp proc) (buffer-name (process-buffer proc))) ;; Obtain buffer matching session (if (not (get-buffer session)) ;; If there is no buffer, create a new one (save-excursion (inferior-ess) (rename-buffer session))) (setq ess-local-process-name (process-name (get-buffer-process session) (ess-make-buffer-current) (if (and transient-mark-mode mark-active) (call-interactively 'ess-eval-region) (call-interactively 'ess-eval-line-and-step))) (add-hook 'ess-mode-hook '(lambda () (local-set-key [(shift return)] 'my-ess-eval))) (add-hook 'inferior-ess-mode-hook '(lambda () (local-set-key [C-up] 'comint-previous-input) (local-set-key [C-down] 'comint-next-input))) (add-hook 'Rnw-mode-hook '(lambda () (local-set-key [(shift return)] 'my-ess-eval))) (require 'ess-site) #+end_src Sincerely, Andrew Young
Re: [O] [babel, ess] How can I make S-RET to be multi-session friendly?
Mikhail Titov m...@gmx.us writes: Hello! There is a wonderful post[1] on how to make S-RET to do handy things in ESS mode. However I often find myself working on several Org documents from different folders. It is quite inconvenient to change a directory in =*R*= buffer each time I work on different document. Is there a neat way to somehow reuse Org mode property =session= that I set buffer wide? I'm not sure what you mean by reuse. All of the information for how to set header arguments in available at (info (org) Using header arguments) Also for some reason #+PROPERTY: session *Rsomename* does not override session name set in =org-babel-default-header-args:R= even after =C-c C-c= on it when I re-evaluate babel code block with =C-c C-c= on code block, while explicit block header =:session *Rsomename*= makes difference. Yes, the order of precedence is system-level buffer/subtree-level language-level code-block-level ,[ snippet from dot emacs ] | (setq org-babel-default-header-args:R | '((:results . output) (:session . *R*))) ` Given that (:session . *R*) will be used by default you could simply remove it from your custom setting for org-babel-default-header-args. Best, I'm running Org-mode version 7.8.10 (release_7.8.10-658-g451191.dirty) Footnotes: [1] http://www.kieranhealy.org/blog/archives/2009/10/12/make-shift-enter-do-a-lot-in-ess/ -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [babel, ess] How can I make S-RET to be multi-session friendly?
Eric Schulte eric.schu...@gmx.com writes: There is a wonderful post[1] on how to make S-RET to do handy things in ESS mode. However I often find myself working on several Org documents from different folders. It is quite inconvenient to change a directory in =*R*= buffer each time I work on different document. Is there a neat way to somehow reuse Org mode property =session= that I set buffer wide? I'm not sure what you mean by reuse. All of the information for how to set header arguments in available at (info (org) Using header arguments) Here is the outline of what I have and what I'm doing. As I mentioned I set default :session header for R to *R*. In my file I have something like #+PROPERTY: session *Rreport* Whenever I C-c C-c on code block, I can see that *R* buffer was created instead of *Rreport* ! Now, if I edit my code block with C-c ' and hit S-RET on any line, it evaluates in *R* whereas I'd prefer it to be *Rreport* somehow. I understand that I'm trying to somewhat mix ob with plain ESS. Nevertheless I wonder if it is somehow possible. Also for some reason #+PROPERTY: session *Rsomename* does not override session name set in =org-babel-default-header-args:R= even after =C-c C-c= on it when I re-evaluate babel code block with =C-c C-c= on code block, while explicit block header =:session *Rsomename*= makes difference. Yes, the order of precedence is system-level buffer/subtree-level language-level code-block-level Then I'd say buffer level does NOT override system-level for some reason. I just re-built Emacs from bzr to make sure I'm running somewhat recent Org. Another weird thing is that when I tried to use Org from git (and not the stock one), Emacs freezes deadly on (org-clock-persistence-insinuate) unless I kill ntvdm.exe with Task Manager (I'm on Windows). But I guess it is a separate story. ,[ snippet from dot emacs ] | (setq org-babel-default-header-args:R | '((:results . output) (:session . *R*))) ` Given that (:session . *R*) will be used by default you could simply remove it from your custom setting for org-babel-default-header-args. This made a trick. Now indeed I have *Rreport* after C-c C-c on code block. However after C-c ' whenever I attempt to S-RET, yet another *R* is launched every time instead of evaluating a line. So the question perhaps is: How to alter [1] such that when I edit code block with C-c ' , S-RET executes lines in a proper session. I believe all information is in there, I just have no clue how would I extract it, e.g. to which main buffer that code editing buffer (I don't know the right name for it) belongs to, and what session header is set to in that buffer. If there is a way to fetch those, perhaps I'd be able to alter original set up in [1]. Footnotes: [1] http://www.kieranhealy.org/blog/archives/2009/10/12/make-shift-enter-do-a-lot-in-ess/ -- Mikhail
Re: [O] [babel, ess] How can I make S-RET to be multi-session friendly?
Yes, the order of precedence is system-level buffer/subtree-level language-level code-block-level Then I'd say buffer level does NOT override system-level for some reason. I believe you mean the buffer-level does not override the language-level. I just re-built Emacs from bzr to make sure I'm running somewhat recent Org. Another weird thing is that when I tried to use Org from git (and not the stock one), Emacs freezes deadly on (org-clock-persistence-insinuate) unless I kill ntvdm.exe with Task Manager (I'm on Windows). But I guess it is a separate story. I have no idea what could be causing the above, but it seems unrelated. ,[ snippet from dot emacs ] | (setq org-babel-default-header-args:R | '((:results . output) (:session . *R*))) ` Given that (:session . *R*) will be used by default you could simply remove it from your custom setting for org-babel-default-header-args. This made a trick. Now indeed I have *Rreport* after C-c C-c on code block. However after C-c ' whenever I attempt to S-RET, yet another *R* is launched every time instead of evaluating a line. So the question perhaps is: How to alter [1] such that when I edit code block with C-c ' , S-RET executes lines in a proper session. I believe all information is in there, I just have no clue how would I extract it, e.g. to which main buffer that code editing buffer (I don't know the right name for it) belongs to, and what session header is set to in that buffer. If there is a way to fetch those, perhaps I'd be able to alter original set up in [1]. You can find the name of the original org-mode buffer by running the following snippet of elisp within the edit buffer. ;; -*- emacs-lisp -*- (marker-buffer org-edit-src-beg-marker) The `org-src-in-org-buffer' macro may be used from an edit buffer to run elisp inside the code block, in the org-mode buffer of the edit buffer. e.g., the following ;; -*- emacs-lisp -*- (org-src-in-org-buffer (message --%S (org-babel-get-src-block-info))) Best, Footnotes: [1] http://www.kieranhealy.org/blog/archives/2009/10/12/make-shift-enter-do-a-lot-in-ess/ -- Eric Schulte http://cs.unm.edu/~eschulte
[O] [babel, ess] How can I make S-RET to be multi-session friendly?
Hello! There is a wonderful post[1] on how to make S-RET to do handy things in ESS mode. However I often find myself working on several Org documents from different folders. It is quite inconvenient to change a directory in =*R*= buffer each time I work on different document. Is there a neat way to somehow reuse Org mode property =session= that I set buffer wide? Also for some reason #+PROPERTY: session *Rsomename* does not override session name set in =org-babel-default-header-args:R= even after =C-c C-c= on it when I re-evaluate babel code block with =C-c C-c= on code block, while explicit block header =:session *Rsomename*= makes difference. ,[ snippet from dot emacs ] | (setq org-babel-default-header-args:R | '((:results . output) (:session . *R*))) ` I'm running Org-mode version 7.8.10 (release_7.8.10-658-g451191.dirty) Footnotes: [1] http://www.kieranhealy.org/blog/archives/2009/10/12/make-shift-enter-do-a-lot-in-ess/ -- Mikhail
Re: [O] [babel, ess] How can I make S-RET to be multi-session friendly?
Mikhail Titov writes: I'm running Org-mode version 7.8.10 (release_7.8.10-658-g451191.dirty) No you don't... please do git fetch --tags origin Can't help with your question, sorry. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [Orgmode] Bug? M-S-RET on a line
Fixed, thanks. - Carsten On Mar 9, 2009, at 10:06 PM, Wanrong Lin wrote: Hi, Suppose I have an org file with following lines: * Test1 Test2 Now if I put the cursor at the beginning of the Test2 line and press M-S-RET (Alt-Shift-Return on my machine), I got this: * Test1 * Test2TODO The TODO keyword was inserted at the end instead of the beginning of the task text. This seems a bug to me. I am using the latest release, 6.24a. Thanks for confirmation and investigation. Wanrong ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Bug? M-S-RET on a line
Hi, Suppose I have an org file with following lines: * Test1 Test2 Now if I put the cursor at the beginning of the Test2 line and press M-S-RET (Alt-Shift-Return on my machine), I got this: * Test1 * Test2TODO The TODO keyword was inserted at the end instead of the beginning of the task text. This seems a bug to me. I am using the latest release, 6.24a. Thanks for confirmation and investigation. Wanrong ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Strange behavior of C-RET and C-S-RET
Hello. I verified. The latest org-mode from git doesn't contain this bug. Thanks a lot! 2008/11/2 Carsten Dominik [EMAIL PROTECTED]: I believe this is fixed now, please verify. - Carsten On Nov 1, 2008, at 2:22 AM, Sergey A. wrote: Hello. I didn't think that the bug will be so difficult to reproduce. In my case, the bug always happens with the following file: *** foo * bar Below is the steps to reproduce that 100% works to me: 1) File is opened, headline is folded, cursor is on the second asterisk: *[*]* foo... 2) After pressing C-RET, I see the following: *** foo ... *** If instead of * bar there is bar, then the bug doesn't happen. I've deleted some tweaks to orgmode, so my config now is: (add-to-list 'auto-mode-alist '(\\.org\\' . org-mode)) (global-set-key \C-cl 'org-store-link) (global-set-key \C-ca 'org-agenda) (global-set-key \C-cb 'org-iswitchb) (add-hook 'org-mode-hook 'turn-on-font-lock) I've rebuild my emacs from CVS before testing. P.S. I use Archlinux. -- Sergey. ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Strange behavior of C-RET and C-S-RET
I believe this is fixed now, please verify. - Carsten On Nov 1, 2008, at 2:22 AM, Sergey A. wrote: Hello. I didn't think that the bug will be so difficult to reproduce. In my case, the bug always happens with the following file: *** foo * bar Below is the steps to reproduce that 100% works to me: 1) File is opened, headline is folded, cursor is on the second asterisk: *[*]* foo... 2) After pressing C-RET, I see the following: *** foo ... *** If instead of * bar there is bar, then the bug doesn't happen. I've deleted some tweaks to orgmode, so my config now is: (add-to-list 'auto-mode-alist '(\\.org\\' . org-mode)) (global-set-key \C-cl 'org-store-link) (global-set-key \C-ca 'org-agenda) (global-set-key \C-cb 'org-iswitchb) (add-hook 'org-mode-hook 'turn-on-font-lock) I've rebuild my emacs from CVS before testing. P.S. I use Archlinux. -- Sergey. ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Strange behavior of C-RET and C-S-RET
Hello. I didn't think that the bug will be so difficult to reproduce. In my case, the bug always happens with the following file: *** foo * bar Below is the steps to reproduce that 100% works to me: 1) File is opened, headline is folded, cursor is on the second asterisk: *[*]* foo... 2) After pressing C-RET, I see the following: *** foo ... *** If instead of * bar there is bar, then the bug doesn't happen. I've deleted some tweaks to orgmode, so my config now is: (add-to-list 'auto-mode-alist '(\\.org\\' . org-mode)) (global-set-key \C-cl 'org-store-link) (global-set-key \C-ca 'org-agenda) (global-set-key \C-cb 'org-iswitchb) (add-hook 'org-mode-hook 'turn-on-font-lock) I've rebuild my emacs from CVS before testing. P.S. I use Archlinux. -- Sergey. ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Strange behavior of C-RET and C-S-RET
Carsten Dominik [EMAIL PROTECTED] writes: I cannot reproduce this problem. Can anyone else? It happens to me sometimes. I'll see if I can come up with a test case that will reproduce this on demand. Then I can look into fixing it. -- Peter Jones, http://pmade.com pmade inc. Louisville, CO US ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Strange behavior of C-RET and C-S-RET
Hi, I cannot reproduce this problem. Can anyone else? - Carsten On Oct 27, 2008, at 6:50 PM, Sergey A. wrote: Hello. Firstly, thanks for org-mode! This mode is awesome! I think I've found a bug (but this bug is of little importance). For example, I have the following folded headline: *[*]* Read books... where [] indicates where cursor is. In this case the cursor is over the second asterisk (this note is important). If I want to create another headline which is of the same level as the current one I should press C-RET. Here is what happens when I do that: *** Read books ... *** [] Content of the Read books headline isn't losed, but wrong position of ... confuses me (and maybe forces some users to think that the content was losed). The same happens when using C-S-RET instead of C-RET. I use org-mode 6.10c, coming with the latest emacs from CVS. Here is part of my config file related to org-mode: ;; The following lines are always needed. Choose your own keys. (add-to-list 'auto-mode-alist '(\\.org\\' . org-mode)) (global-set-key \C-cl 'org-store-link) (global-set-key \C-ca 'org-agenda) (global-set-key \C-cb 'org-iswitchb) (add-hook 'org-mode-hook 'turn-on-font-lock) ; Org buffers only (setq org-special-ctrl-a/e t) (setq org-hide-leading-stars t) (setq org-odd-levels-only t) (setq org-cycle-separator-lines 1) (setq org-goto-auto-isearch nil) -- Sergey A. ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Strange behavior of C-RET and C-S-RET
I can't reproduce this either. -Bernt Carsten Dominik [EMAIL PROTECTED] writes: Hi, I cannot reproduce this problem. Can anyone else? - Carsten On Oct 27, 2008, at 6:50 PM, Sergey A. wrote: Hello. Firstly, thanks for org-mode! This mode is awesome! I think I've found a bug (but this bug is of little importance). For example, I have the following folded headline: *[*]* Read books... where [] indicates where cursor is. In this case the cursor is over the second asterisk (this note is important). If I want to create another headline which is of the same level as the current one I should press C-RET. Here is what happens when I do that: *** Read books ... *** [] Content of the Read books headline isn't losed, but wrong position of ... confuses me (and maybe forces some users to think that the content was losed). The same happens when using C-S-RET instead of C-RET. I use org-mode 6.10c, coming with the latest emacs from CVS. Here is part of my config file related to org-mode: ;; The following lines are always needed. Choose your own keys. (add-to-list 'auto-mode-alist '(\\.org\\' . org-mode)) (global-set-key \C-cl 'org-store-link) (global-set-key \C-ca 'org-agenda) (global-set-key \C-cb 'org-iswitchb) (add-hook 'org-mode-hook 'turn-on-font-lock) ; Org buffers only (setq org-special-ctrl-a/e t) (setq org-hide-leading-stars t) (setq org-odd-levels-only t) (setq org-cycle-separator-lines 1) (setq org-goto-auto-isearch nil) -- Sergey A. ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode