Re: [O] Custom keymaps on org blocks

[Matt Price]

Necroposting here.  I was wondering if anyone has tried polymode recently,
and whether it still has the problems John described in his earlier posts.
I notice that poly-org is being actively developed but I haven't tried it
out yet...

On Sat, Jun 10, 2017 at 3:32 PM John Kitchin 
wrote:

> In case anyone would like to try this themselves, I documented what I
> tried here:
> http://kitchingroup.cheme.cmu.edu/blog/2017/06/10/Adding-keymaps-to-src-blocks-via-org-font-lock-hook/
>
> 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, Jun 10, 2017 at 9:58 AM, John Kitchin 
> wrote:
>
>>
>> Nicolas Goaziou writes:
>>
>> > Hello,
>> >
>> > John Kitchin  writes:
>> >
>> >> On the other hand, there are times when I am working on a document
>> that has
>> >> a lot of short code blocks, e.g. for lecture notes or blog posts,
>> where it
>> >> is sufficiently tedious to me to switch in and out of the special edit
>> mode
>> >> that I wanted to try this solution out, and it became clear you can't
>> >> really try it out without modifying the core org code that does the
>> >> font-locking on a block.
>> >
>> > Are you sure about it? There are two hooks related to fontification:
>> > `org-font-lock-set-keywords-hook' and `org-font-lock-hook'. I'm
>> > surprised none can help you in this case.
>>
>> You are totally right on this. I can use org-font-lock-hook to take care
>> of this. Thanks for the pointer.
>>
>> >
>> >> I don't think we have to go so far as to say we make multiple major
>> mode
>> >> keybindings available, so much as context specific keybindings
>> available
>> >> where there is value in it. We already have this in org-speed keys for
>> >> example, and even these can be context specific to do different things
>> on
>> >> headings (even different things on headings with specific properties)
>> and
>> >> blocks (
>> >>
>> http://kitchingroup.cheme.cmu.edu/blog/2016/12/22/Context-specific-org-mode-speed-keys/
>> >> ).
>> >
>> > Neat hack.
>>
>> Thanks!
>>
>> >
>> >> If there was a change to org to enable this, I wouldn't expect the
>> core to
>> >> change behavior for anyone, it would just make it possible for users to
>> >> change this if they wanted to. The same way they can customize the
>> face of
>> >> a code block for different languages.
>> >
>> > Fair enough. Would you want to provide a proper patch?
>>
>> With the hook I don't think it is necessary. Thanks for all the
>> discussion though (everyone) it was helpful to think it through.
>> >
>> > Thank you.
>> >
>> >
>> > Regards,
>>
>>
>> --
>> 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: [O] Custom keymaps on org blocks

[John Kitchin]

In case anyone would like to try this themselves, I documented what I tried
here:
http://kitchingroup.cheme.cmu.edu/blog/2017/06/10/Adding-keymaps-to-src-blocks-via-org-font-lock-hook/

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, Jun 10, 2017 at 9:58 AM, John Kitchin 
wrote:

>
> Nicolas Goaziou writes:
>
> > Hello,
> >
> > John Kitchin  writes:
> >
> >> On the other hand, there are times when I am working on a document that
> has
> >> a lot of short code blocks, e.g. for lecture notes or blog posts, where
> it
> >> is sufficiently tedious to me to switch in and out of the special edit
> mode
> >> that I wanted to try this solution out, and it became clear you can't
> >> really try it out without modifying the core org code that does the
> >> font-locking on a block.
> >
> > Are you sure about it? There are two hooks related to fontification:
> > `org-font-lock-set-keywords-hook' and `org-font-lock-hook'. I'm
> > surprised none can help you in this case.
>
> You are totally right on this. I can use org-font-lock-hook to take care
> of this. Thanks for the pointer.
>
> >
> >> I don't think we have to go so far as to say we make multiple major mode
> >> keybindings available, so much as context specific keybindings available
> >> where there is value in it. We already have this in org-speed keys for
> >> example, and even these can be context specific to do different things
> on
> >> headings (even different things on headings with specific properties)
> and
> >> blocks (
> >> http://kitchingroup.cheme.cmu.edu/blog/2016/12/22/Context-
> specific-org-mode-speed-keys/
> >> ).
> >
> > Neat hack.
>
> Thanks!
>
> >
> >> If there was a change to org to enable this, I wouldn't expect the core
> to
> >> change behavior for anyone, it would just make it possible for users to
> >> change this if they wanted to. The same way they can customize the face
> of
> >> a code block for different languages.
> >
> > Fair enough. Would you want to provide a proper patch?
>
> With the hook I don't think it is necessary. Thanks for all the
> discussion though (everyone) it was helpful to think it through.
> >
> > Thank you.
> >
> >
> > Regards,
>
>
> --
> 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: [O] Custom keymaps on org blocks

[John Kitchin]

Nicolas Goaziou writes:

> Hello,
>
> John Kitchin  writes:
>
>> On the other hand, there are times when I am working on a document that has
>> a lot of short code blocks, e.g. for lecture notes or blog posts, where it
>> is sufficiently tedious to me to switch in and out of the special edit mode
>> that I wanted to try this solution out, and it became clear you can't
>> really try it out without modifying the core org code that does the
>> font-locking on a block.
>
> Are you sure about it? There are two hooks related to fontification:
> `org-font-lock-set-keywords-hook' and `org-font-lock-hook'. I'm
> surprised none can help you in this case.

You are totally right on this. I can use org-font-lock-hook to take care
of this. Thanks for the pointer.

>
>> I don't think we have to go so far as to say we make multiple major mode
>> keybindings available, so much as context specific keybindings available
>> where there is value in it. We already have this in org-speed keys for
>> example, and even these can be context specific to do different things on
>> headings (even different things on headings with specific properties) and
>> blocks (
>> http://kitchingroup.cheme.cmu.edu/blog/2016/12/22/Context-specific-org-mode-speed-keys/
>> ).
>
> Neat hack.

Thanks!

>
>> If there was a change to org to enable this, I wouldn't expect the core to
>> change behavior for anyone, it would just make it possible for users to
>> change this if they wanted to. The same way they can customize the face of
>> a code block for different languages.
>
> Fair enough. Would you want to provide a proper patch?

With the hook I don't think it is necessary. Thanks for all the
discussion though (everyone) it was helpful to think it through.
>
> Thank you.
>
>
> Regards,


--
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: [O] Custom keymaps on org blocks

[Nicolas Goaziou]

Hello,

John Kitchin  writes:

> On the other hand, there are times when I am working on a document that has
> a lot of short code blocks, e.g. for lecture notes or blog posts, where it
> is sufficiently tedious to me to switch in and out of the special edit mode
> that I wanted to try this solution out, and it became clear you can't
> really try it out without modifying the core org code that does the
> font-locking on a block.

Are you sure about it? There are two hooks related to fontification:
`org-font-lock-set-keywords-hook' and `org-font-lock-hook'. I'm
surprised none can help you in this case.

> I don't think we have to go so far as to say we make multiple major mode
> keybindings available, so much as context specific keybindings available
> where there is value in it. We already have this in org-speed keys for
> example, and even these can be context specific to do different things on
> headings (even different things on headings with specific properties) and
> blocks (
> http://kitchingroup.cheme.cmu.edu/blog/2016/12/22/Context-specific-org-mode-speed-keys/
> ).

Neat hack.

> If there was a change to org to enable this, I wouldn't expect the core to
> change behavior for anyone, it would just make it possible for users to
> change this if they wanted to. The same way they can customize the face of
> a code block for different languages.

Fair enough. Would you want to provide a proper patch?

Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] Custom keymaps on org blocks

[Grant Rettke]

On Wed, Jun 7, 2017 at 8:50 AM, John Kitchin  wrote:
> On the other hand, there are times when I am working on a document that has
> a lot of short code blocks, e.g. for lecture notes or blog posts, where it
> is sufficiently tedious to me to switch in and out of the special edit mode

These bindings make source block navigation and editing really fast and fun!

(define-key org-mode-map (kbd "s-j") #'org-babel-next-src-block)
(define-key org-mode-map (kbd "s-k") #'org-babel-previous-src-block)
(define-key org-mode-map (kbd "s-l") #'org-edit-src-code)
(define-key org-src-mode-map (kbd "s-l") #'org-edit-src-exit)

Here the 'l' key binding is the most important. It makes for fast
entry and exit of the source block.

For my mind the default bindings "C-c '" interrupts my mental flow. It
is like hearing the sound of a cash register drawer sliding out, doing
some work there and then getting shoved back in every single time.
Ouch.

On the other hand, "s-l" both to enter and exit the source blocks, is
like hearing a gentle breath of air to cool a cup of tea that is a
tiny bit too warm, doing your work and then another gentle breath when
you leave the block.

That is the best way I can describe how much difference the two
bindings make. It is really a "feels" thing, and it feels a lot
better.

Seriously, these bindings might make you fall in love with source
block editing all the time.

Re: [O] Custom keymaps on org blocks

[Grant Rettke]

On Wed, Jun 7, 2017 at 7:49 AM, John Kitchin  wrote:
> Grant Rettke writes:
>
>> You want Polymode: https://github.com/vspinu/polymode
>
> I have never been able to get polymode to work. Do have an incantation
> that works?

I forgot that I set it up for R markdown files. But it did work on my
machine after manually installing the `polymode' package.

https://github.com/grettke/home/blob/master/.emacs.el#L1992-L2005

>> It is confusing alternating between the Org major a mode and the
>> source block major mode as you scroll through documents. One second
>> you are an author for humans and the other an author for the computer.
>> That is how literate programming is defined in theory, but in practice
>> I don't do it like that because it is mentally jarring.
>
> Interesting perspective. I find switching to special edit mode jarring,
> particularly when it is just for the key bindings, e.g. lispy mode, or
> getting python indentation to work.

We are both surprised!

Re: [O] Custom keymaps on org blocks

[John Kitchin]

I can see that. There are plenty of cases that certainly would not work,
e.g. in a Python block it would be a mistake to run a command that sends
the buffer to the interpreter! In the example I provided, you can see I
also had to "preserve" a few org-bindings so you could still do C-c ' to
get to the special edit. If you didn't know what was happening, it might
also appear that certain org-bindings you were used to had stopped working,
e.g. I have a lightning fast muscle memory to export a buffer, but it
doesn't work when in a src block with this modification (unless of course
it is "preserved" in the keymap). Whether this matters is up to the user,
since they get to choose how the keymap is defined. I would expect it
defaults to the org-mode-keymap.

On the other hand, there are times when I am working on a document that has
a lot of short code blocks, e.g. for lecture notes or blog posts, where it
is sufficiently tedious to me to switch in and out of the special edit mode
that I wanted to try this solution out, and it became clear you can't
really try it out without modifying the core org code that does the
font-locking on a block.

I don't think we have to go so far as to say we make multiple major mode
keybindings available, so much as context specific keybindings available
where there is value in it. We already have this in org-speed keys for
example, and even these can be context specific to do different things on
headings (even different things on headings with specific properties) and
blocks (
http://kitchingroup.cheme.cmu.edu/blog/2016/12/22/Context-specific-org-mode-speed-keys/
).

If there was a change to org to enable this, I wouldn't expect the core to
change behavior for anyone, it would just make it possible for users to
change this if they wanted to. The same way they can customize the face of
a code block for different languages.



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 Wed, Jun 7, 2017 at 7:21 AM, Nicolas Goaziou 
wrote:

> Hello,
>
> John Kitchin  writes:
>
> > For once in a while uses this works, but this isn't really a solution
> > for key-bindings that are composable, e.g. in lispy. There you can use
> > single key-presses to navigate, rearrange, insert code, etc...
> >
> > Also it adds three chords to every key-binding out of the box, it would
> > be fewer keys to just go to special edit mode unless you make a simpler
> > key definition!
>
> Sure, but I have the feeling that it isn't Org job to allow keybindings
> for multiple major modes in the same buffer. Note that we already did
> this with links, but I think that specific part of link revamp may have
> gone too far.
>
> Also, it could be troublesome because some interactive functions may
> depend on a mode specific variables, which are not initialized while in
> Org mode.
>
> As far as Org is concerned, C-c ', i.e., `org-edit-special' is the way
> to go, IMO.
>
> WDYT?
>
> Regards,
>
> --
> Nicolas Goaziou0x80A93738
>

Re: [O] Custom keymaps on org blocks

[Nicolas Goaziou]

Hello,

John Kitchin  writes:

> For once in a while uses this works, but this isn't really a solution
> for key-bindings that are composable, e.g. in lispy. There you can use
> single key-presses to navigate, rearrange, insert code, etc...
>
> Also it adds three chords to every key-binding out of the box, it would
> be fewer keys to just go to special edit mode unless you make a simpler
> key definition!

Sure, but I have the feeling that it isn't Org job to allow keybindings
for multiple major modes in the same buffer. Note that we already did
this with links, but I think that specific part of link revamp may have
gone too far.

Also, it could be troublesome because some interactive functions may
depend on a mode specific variables, which are not initialized while in
Org mode.

As far as Org is concerned, C-c ', i.e., `org-edit-special' is the way
to go, IMO.

WDYT?

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] Custom keymaps on org blocks

[John Kitchin]

Nicolas Goaziou writes:

> Hello,
>
> John Kitchin  writes:
>
>> Is there any interest in having custom keymaps on org blocks?
>>
>> The idea I had is to have the option to make the major-mode keymaps be
>> active on the src blocks.
>
> There is already `org-babel-do-key-sequence-in-edit-buffer', i.e., C-c
> C-v C-x.

For once in a while uses this works, but this isn't really a solution
for key-bindings that are composable, e.g. in lispy. There you can use
single key-presses to navigate, rearrange, insert code, etc...

Also it adds three chords to every key-binding out of the box, it would
be fewer keys to just go to special edit mode unless you make a simpler
key definition!

>
> Regards,


--
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: [O] Custom keymaps on org blocks

[John Kitchin]

Grant Rettke writes:

> On Mon, Jun 5, 2017 at 4:53 PM, John Kitchin  wrote:
>> Is there any interest in having custom keymaps on org blocks?
>>
>> The idea I had is to have the option to make the major-mode keymaps be
>> active on the src blocks.
>
> You want Polymode: https://github.com/vspinu/polymode

I have never been able to get polymode to work. Do have an incantation
that works?

>
>> I have tried this, and seems ok, and I wondered if anyone had an opinion
>> for or against this idea.
>
> It is confusing alternating between the Org major a mode and the
> source block major mode as you scroll through documents. One second
> you are an author for humans and the other an author for the computer.
> That is how literate programming is defined in theory, but in practice
> I don't do it like that because it is mentally jarring.

Interesting perspective. I find switching to special edit mode jarring,
particularly when it is just for the key bindings, e.g. lispy mode, or
getting python indentation to work.

>
> I spell check my Org-Mode Literate Documents. But the spell checker
> does not check source blocks. That is up to the major mode for that
> source block, not for the containing literate document. When you think
> about it, probably every Org-Mode literate programming has it set up
> this way, otherwise the spell checker would go crazy on typical source
> code. That is revealing. The source blocks are very different "things"
> than the containing document.
>
> For me the source block is another cognitive workspace that I enter
> consciously. I am digging deeper into the document itself. For me the
> source block is a window into that world of the source block. In the
> top level document I write literature about things, including the
> various source blocks. Then I jump into editing the source block
> itself.
>
> John you once had a discussion (or answered a (my?) question) about
> making source blocks not-editable. That is how I would like it to work
> all the time. That is why I don't fontify source blocks natively and
> that is why I wouldn't enjoy what you describe.

That is ok, the hack I made is totally optional. If you don't define an
alternative map for a block, it just gets the orgmode map. You can even
just locally redefine a few key bindings on the org-mode map that are
only valid in the block.


--
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: [O] Custom keymaps on org blocks

[Grant Rettke]

On Mon, Jun 5, 2017 at 4:53 PM, John Kitchin  wrote:
> Is there any interest in having custom keymaps on org blocks?
>
> The idea I had is to have the option to make the major-mode keymaps be
> active on the src blocks.

You want Polymode: https://github.com/vspinu/polymode

> I have tried this, and seems ok, and I wondered if anyone had an opinion
> for or against this idea.

It is confusing alternating between the Org major a mode and the
source block major mode as you scroll through documents. One second
you are an author for humans and the other an author for the computer.
That is how literate programming is defined in theory, but in practice
I don't do it like that because it is mentally jarring.

I spell check my Org-Mode Literate Documents. But the spell checker
does not check source blocks. That is up to the major mode for that
source block, not for the containing literate document. When you think
about it, probably every Org-Mode literate programming has it set up
this way, otherwise the spell checker would go crazy on typical source
code. That is revealing. The source blocks are very different "things"
than the containing document.

For me the source block is another cognitive workspace that I enter
consciously. I am digging deeper into the document itself. For me the
source block is a window into that world of the source block. In the
top level document I write literature about things, including the
various source blocks. Then I jump into editing the source block
itself.

John you once had a discussion (or answered a (my?) question) about
making source blocks not-editable. That is how I would like it to work
all the time. That is why I don't fontify source blocks natively and
that is why I wouldn't enjoy what you describe.

Re: [O] Custom keymaps on org blocks

[Nicolas Goaziou]

Hello,

John Kitchin  writes:

> Is there any interest in having custom keymaps on org blocks?
>
> The idea I had is to have the option to make the major-mode keymaps be
> active on the src blocks.

There is already `org-babel-do-key-sequence-in-edit-buffer', i.e., C-c
C-v C-x.

Regards,

-- 
Nicolas Goaziou