unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Dmitrii Korobeinikov <dim1212k@gmail.com>, 35419@debbugs.gnu.org
Cc: Philipp Stephani <p.stephani2@gmail.com>,
	Noam Postavsky <npostavs@gmail.com>
Subject: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
Date: Sun, 05 May 2019 14:07:07 +0800	[thread overview]
Message-ID: <87muk1fn90.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> (raw)
In-Reply-To: <CA+Yh0SQpFnsE2NZqbRjuzDyS-sQO_RTtTPBKth0F5EhnjNGtBQ@mail.gmail.com>

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 these code blocks are treated as
lenses. 

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

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

Best,
Ihor


Dmitrii Korobeinikov <dim1212k@gmail.com> writes:

> 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, local variables,
> font-lock, and indentation. It does not really take care about the minor
> modes and does not run the submode hooks either.
>
> Just to reiterate, polymode's idea is to switch between indirect buffers,
> one for each major mode.
>
> OK, detail largely disregarded, I now can draw a bird-eye view comparison
> between lenses and multi-mode modes.
>
> - Neither polymode nor mmm-mode treat a region as if it were truly on its
> own in a seperate buffer.
>
> Effects: no stuff like seperate truncation options, implied syntax checking
> and so on.
>
> - Moreover, the region must be a part of the buffer.
>
> Effects: no data sharing between buffers, no possibility of stitching
> different buffers together, etc.
>
> Now, with these out of the way.
>
> Indirect buffers give the answer to the issue of sharing some textual data
> between several buffer.
> (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.
>
> 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?

-- 
Ihor Radchenko,





  reply	other threads:[~2019-05-05  6:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CA+Yh0SQcwxm8fbDrB7eGTDU2KMRKhNkgSddSufwXvzvY=8zciA@mail.gmail.com>
     [not found] ` <87v9z2ojf8.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me>
2019-04-24 18:35   ` bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Dmitrii Korobeinikov
2019-04-25  1:37     ` Noam Postavsky
2019-04-25  8:40       ` Dmitrii Korobeinikov
2019-04-25 17:52         ` Philipp Stephani
2019-04-25 21:14           ` Dmitrii Korobeinikov
2019-04-26 12:05         ` bug#35419: [O] " Roland Everaert
2019-04-25  7:11     ` bug#35419: Fwd: Re: [O] " 'Ihor Radchenko'
2019-05-02 21:24     ` bug#35419: [O] bug#35419: " Dmitrii Korobeinikov
2019-05-03 11:03       ` Roland Everaert
     [not found]       ` <87lfzn4x61.fsf@gmail.com>
2019-05-03 12:06         ` Dmitrii Korobeinikov
2019-05-02 21:31     ` Dmitrii Korobeinikov
2019-05-05  6:07       ` Ihor Radchenko [this message]
2019-05-14 17:42         ` Dmitrii Korobeinikov
     [not found]         ` <CA+Yh0STiV-61f2NkixpTmYE8co_ZmkaNgGePP56353eMfQoY2g@mail.gmail.com>
2019-06-01 14:49           ` Ihor Radchenko
2019-06-02  9:09             ` Dmitrii Korobeinikov
2019-04-25 21:00   ` bug#35419: [O] " Dmitrii Korobeinikov
2020-04-05  1:46     ` Dmitry Gutov
2020-04-05 10:05       ` 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.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87muk1fn90.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me \
    --to=yantar92@gmail.com \
    --cc=35419@debbugs.gnu.org \
    --cc=dim1212k@gmail.com \
    --cc=npostavs@gmail.com \
    --cc=p.stephani2@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.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).