Dear Ihor,
> Regarding the question about buffer-lens interaction. Let's take even
> more complicated example: To run the command, the user hits some key
> combination, which happens to be bound to different commands in the main
> buffer and in the lense buffer (i.e. the main buffer is in org-mod
Dear Dmitrii,
Regarding the question about buffer-lens interaction. Let's take even
more complicated example: To run the command, the user hits some key
combination, which happens to be bound to different commands in the main
buffer and in the lense buffer (i.e. the main buffer is in org-mode, th
Dear Ihor,
> Note that indirect buffers always share *all* the contents with the master
> buffer. As a result, it may not be easy to make things like flyspell
> work on code blocks in org-mode, if these code blocks are treated as
> lenses.
I tried flyspell w/ different dictionaries on 2 buffers.
Dear Dmitrii,
> Indirect buffers give the answer to the issue of sharing some textual data
> between several buffer.
Note that indirect buffers always share *all* the contents with the master
buffer. As a result, it may not be easy to make things like flyspell
work on code blocks in org-mode, if
I found a clarification on how mmm-mode works.
https://github.com/polymode/polymode/issues/187
> mmm-mode also allows having multiple major modes depending on cursor
position in the buffer. However, it does not fully replace major mode
locally. This mode is only taking care about keymap, menu, loc
Am Do., 25. Apr. 2019 um 10:41 Uhr schrieb Dmitrii Korobeinikov
:
> I have imagined that at the low level there is an actual data structure that
> keeps the raw textual data and it could be directly shared by multiple
> buffers.
That's what indirect buffers do. Maybe the indirect buffer
function
I see lens to be useful for the eev mode, too.
Roland.
Dmitrii Korobeinikov writes:
>> Have you looked at Phil Lord's lentic package? I think it implements a
>> lot of what you're talking about.
>
>> https://github.com/phillord/lentic
>
> This is nice to see!
> Indeed, except for embedding, the
чт, 25 апр. 2019 г. в 23:52, Philipp Stephani :
> Am Do., 25. Apr. 2019 um 10:41 Uhr schrieb Dmitrii Korobeinikov
> :
> > I have imagined that at the low level there is an actual data structure
> that keeps the raw textual data and it could be directly shared by multiple
> buffers.
>
> That's what
Dear Ihor,
> Another use case for me is to speed up agenda creation.
> I usually do not like to split my org files into too many. However, it
> results in very large and slow org buffers later. If I can store some
> parts of the org files externally and only show them if some condition
> is met (s
> Have you looked at Phil Lord's lentic package? I think it implements a
> lot of what you're talking about.
> https://github.com/phillord/lentic
This is nice to see!
Indeed, except for embedding, there is a large overlap with what I
described as buffer lenses.
BTW, judging by this description:
Dmitrii Korobeinikov writes:
> * Implementation
>
> I am not familiar with Emacs internals to say what's feasible of the
> proposed structure.
Have you looked at Phil Lord's lentic package? I think it implements a
lot of what you're talking about.
https://github.com/phillord/lentic
11 matches
Mail list logo
