From: Dmitrii Korobeinikov <dim1212k@gmail.com>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: Philipp Stephani <p.stephani2@gmail.com>,
35419@debbugs.gnu.org, Noam Postavsky <npostavs@gmail.com>
Subject: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
Date: Tue, 14 May 2019 23:42:53 +0600 [thread overview]
Message-ID: <CA+Yh0STiV-61f2NkixpTmYE8co_ZmkaNgGePP56353eMfQoY2g@mail.gmail.com> (raw)
In-Reply-To: <87muk1fn90.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me>
[-- Attachment #1: Type: text/plain, Size: 5107 bytes --]
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.
The dictionary is switched every time I switch into one of the buffers.
You are right, ispell and the like working w/ a file directly would have to
learn to work w/ indirect buffers by managing multiple simultaneous
processes.
Fortunately, that doesn't seem like a big hurdle.
>> (1) A question: when an indirect buffer is created and some region is
>> narrowed to, is the rest of the buffer duplicated in memory somewhere? If
>> this is so, there could be a useful efficiency-related modification to
>> indirect buffers, which would allow "hard-narrowing": not duplicating the
>> rest of the base buffer.
>
> There is no duplication of the buffer content in indirect buffers.
> Internally, indirect buffer's content is a pointer to the main buffer
> content. If you modify text in any of the indirect buffers or in the
> main buffer, the text is modified in all of them and in the main buffer.
> Only the buffer-local variables are duplicated.
> You can refer to "27.11 Indirect Buffers" in the elisp manual for
> details.
Bad choice of wording on my side, I didn't mean duplication, but rather
keeping unnecessary info, like text properties in the newly created
indirect buffer, in the regions which were "permanently" chosen to be
narrowed-out.
Anyway, this is a premature optimization for now.
> > The next immediately outstanding question is:
> > (2) how can "embedding" (of a buffer as a part of another buffer as an
> > area) be done efficiently? This could possibly be approached as two
> > problems: (i) displaying the area and (ii) interacting with it.
> > Any ideas?
>
> These issues have been discussed in
> https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html.
> As I remember, the discussion stopped without a clear conclusion. It was
> not clear how to separate the main buffer contents from the nested
> buffer (I treat them as analogue of the buffer lenses). Another issue
> was how the keymaps and buffer-local variables would interact when the
> point is within a lense. It was not clear what should be the priority.
The short answer is probably that lens-mode looks at the changes to the
buffer and decides what's what.
Here is my vision for this.
Say, you have an indirect buffer, call it A, it's base has contents:
> line 1
> line 2
> line 3
Also, there is a buffer, call it B, where we want to embed A, with contents:
> word 1
> instruction: lens that displays A
> word 2
Lens-mode decides to identify the second line as a lens and constructs
layout of the file.
> [text]
> [lens#A]
> [text]
Now, construct and display the final buffer as:
> word 1
> line 1
> line 2
> line 3
> word 2
The core question: how is this "displaying" done.
In part, somewhat like how indirect buffers function.
A displayed piece of text is a pointer/reference to the text in the
indirect buffer.
Of course, this should be done in a way so that the modes running in B
don't change the properties of the text (following the layout constructed
by lens-mode as in the example above). Though, this might better&easier be
done at the display unit level.
What about interaction?
Well, when the cursor is inside the lens, the controller decides what to do
w/ each keybinding, whether to redirect it to the indirect buffer or not.
And what about the case when borders are crossed?
As I see it, any code that executes - does so as is.
For instance, consider a buffer with a lens (contents: "lens"), which looks
like this: "word1 lens word2".
Place the cursor on the first word, run a command to remove 2 words.
Now there are to possibilities here, depending on the implementation of the
function which does the removal:
1. Implementation identifies the boundaries of deletion and removes the
words as contents of the main buffer. Lens-mode identifies the removal and
deletes the lens altogether.
2. Delete "word1" -> the cursor is on "lens" -> next deletion command is
redirected to the indirect buffer, which does the removal. Lens-mode
identifies the lens as empty and removes it.
The second way might not be always desirable, so whenever a function is
called with the cursor outside a lens, as an option, decide to never
redirect the input to a lens while the function runs.
For another case, consider the first example with lines and, cursor being
in the beginning of the file, remove three lines.
To make this interesting, assume the first kind of implementation runs,
identifying the bounds, never redirecting a command to the lens.
Well, if the implementation of the lens is inspired by how indirect buffers
work, I imagine, the necessary changes in the embedded buffer take place
directly, in which case everything works as desirable.
Afterwards, lens-mode processes the changes and decides if some lens was
removed or added, updating the file layout.
Best regards,
Dmitrii.
[-- Attachment #2: Type: text/html, Size: 7251 bytes --]
next prev parent reply other threads:[~2019-05-14 17:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CA+Yh0SQpFnsE2NZqbRjuzDyS-sQO_RTtTPBKth0F5EhnjNGtBQ@mail.gmail.com>
2019-05-05 6:07 ` bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Ihor Radchenko
[not found] ` <87muk1fn90.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me>
2019-05-14 17:42 ` Dmitrii Korobeinikov [this message]
2019-06-01 14:49 ` Ihor Radchenko
[not found] ` <87v9xpfjhs.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me>
2019-06-02 9:09 ` Dmitrii Korobeinikov
[not found] <CA+Yh0SQ7yWQBjXhKbJPrCroriNpwhyFyQWAfHsUvxwmojsjKuw@mail.gmail.com>
2019-04-25 1:37 ` Noam Postavsky
[not found] ` <87sgu6rhkt.fsf@gmail.com>
2019-04-25 8:40 ` Dmitrii Korobeinikov
[not found] ` <CA+Yh0SSvQMucaC1EJR9GBxpKeP6haGiHN+Lf2QYo8csNoy0Waw@mail.gmail.com>
2019-04-25 17:52 ` Philipp Stephani
[not found] ` <CAArVCkQcwnjeMyRU6rpiuvGsOCUOsnQTQwQSGdDFKwQz_Sbi3g@mail.gmail.com>
2019-04-25 21:14 ` Dmitrii Korobeinikov
2019-04-26 12:05 ` Roland Everaert
2019-05-02 21:31 ` Dmitrii Korobeinikov
2019-04-24 19:20 Dmitrii Korobeinikov
2019-04-25 3:25 ` Ihor Radchenko
2019-04-25 21:00 ` bug#35419: " Dmitrii Korobeinikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+Yh0STiV-61f2NkixpTmYE8co_ZmkaNgGePP56353eMfQoY2g@mail.gmail.com \
--to=dim1212k@gmail.com \
--cc=35419@debbugs.gnu.org \
--cc=npostavs@gmail.com \
--cc=p.stephani2@gmail.com \
--cc=yantar92@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).