Re: S-RET not incrementing table cell with emacs -nw

[tomas]

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

[Loris Bennett]

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

[John Kitchin]

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

[Juri Linkov]

>> 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

[Leo]

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

[Juri Linkov]

> 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

[John Kitchin]

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

[Juri Linkov]

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?

[Kévin Le Gouguec]

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?

[Bernt Hansen]

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?

[Nicolas Goaziou]

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?

[Kaushal Modi]

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?

[Amin Bandali]

> #+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?

[Kaushal Modi]

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?

[Marco Wahl]

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?

[Kaushal Modi]

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?

[Bernt Hansen]

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

[Nicolas Goaziou]

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

[Kévin Le Gouguec]

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

[Nicolas Goaziou]

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

[Allen Li]

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

[Matt Lundin]

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

[Matt Lundin]

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

[Allen Li]

On Wed, Feb 7, 2018 at 1:47 PM Matt Lundin  wrote:

> 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]

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

[Matt Lundin]

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?

[Mikhail Titov]

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?

[Eric Schulte]

 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?

[Mikhail Titov]

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?

[Eric Schulte]

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?

[Mikhail Titov]

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?

[Bastien]

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?

[Andrew Young]

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?

[Eric Schulte]

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?

[Mikhail Titov]

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?

[Eric Schulte]

 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?

[Mikhail Titov]

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?

[Achim Gratz]

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

[Carsten Dominik]

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

[Wanrong Lin]

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

[Sergey A.]

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

[Carsten Dominik]

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

[Sergey A.]

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

[Peter Jones]

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

[Carsten Dominik]

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

[Bernt Hansen]

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