From: Dmitrii Korobeinikov <firstname.lastname@example.org>
To: Ihor Radchenko <email@example.com>
Subject: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter)
Date: Fri, 26 Apr 2019 03:00:12 +0600 [thread overview]
Message-ID: <CA+Yh0ST+u0s6L-hR2=rs3O_46FqXn8utGotORx+FMDb7Jn0Rfw__10245.firstname.lastname@example.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 3017 bytes --]
> 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 (say, for certain todo state of the parent entry), it would speed
> up my agenda and the buffer navigation quite significantly.
That's a good one!
> Let me put some historical context to this proposal.
> There was a discussion of similar feature in emacs-dev last year.
> The idea was to implement nested buffers:
An interesting read, provides another use-case (collect external data in
one place to easily view/edit):
> There are also several projects, which implement part of the
> functionality you described:
> - mmm-mode: https://github.com/purcell/mmm-mode
> - polymode: https://github.com/polymode/polymode
Pretty cool stuff. For thoroughness, let's discuss how these work.
I found a comment which mentions polymode's working principle.
>> Polymode doesn't keep its modes in a single emacs buffer but in several
indirect buffers, as many as different modes are there in a file.
Consequently, polymode is as fast as switching emacs buffers because it
never re-installs major modes like other multi-modes do. Dave Love's
multi-mode.el gets full credit for this idea.
> It looks like it slows emacs to a crawl in my main org config file. It
seems to work fairly well in some of my notes files (though with some weird
Basically, simplicity is in place but at the cost of duplication.
Lenses could avoid duplication, while yielding increased functionality and
(e.g. in polymode, a syntax checker couldn't yield correct results unless
narrowing was constantly used, which is inefficient)
Now, to MMM-mode. According to the info file:
> Within the file, MMM-mode creates /submode regions/ within which other
major modes are in effect.
> While the point is in a submode region, the following changes occur:
> <...> keymap <...> local variables <...> syntax table and indentation
> The submode regions are represented internally by Emacs Lisp objects
known as /overlays/.
> A lot of the functionality of MMM Mode---that which makes the major mode
> appear to change---is implemented by saving and restoring the values of
> local variables, or pseudo-variables.
What I don't understand is where the modes of the submode region run and
when they are turned on.
Are necessary modes just allowed to run at the right time for the whole
buffer? But then, how are they limited in their effect to just the
necessary region? Narrowing?
Could, for example, syntax checking be done efficiently that way?
Could someone, please, explain?
[-- Attachment #2: Type: text/html, Size: 4175 bytes --]
next prev parent reply other threads:[~2019-04-25 21:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-24 19:20 [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Dmitrii Korobeinikov
2019-04-25 3:25 ` Ihor Radchenko
2019-04-25 21:00 ` Dmitrii Korobeinikov [this message]
[not found] ` <CA+Yh0SQ7yWQBjXhKbJPrCroriNpwhyFyQWAfHsUvxwmojsjKuw@mail.gmail.com>
2019-04-25 1:37 ` bug#35419: " Noam Postavsky
2019-04-25 7:11 ` bug#35419: Fwd: " 'Ihor Radchenko'
[not found] ` <email@example.com>
2019-04-25 8:40 ` bug#35419: " 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:24 ` bug#35419: " Dmitrii Korobeinikov
2019-05-02 21:31 ` Dmitrii Korobeinikov
[not found] ` <CA+Yh0ST+u0s6L-hR2=rs3O_46FqXn8utGotORx+FMDb7Jn0Rfw@mail.gmail.com>
2020-04-05 1:46 ` bug#35419: [O] " Dmitry Gutov
2020-04-05 10:05 ` Dmitrii Korobeinikov
[not found] <CA+Yh0SQpFnsE2NZqbRjuzDyS-sQO_RTtTPBKth0F5EhnjNGtBQ@mail.gmail.com>
2019-05-05 6:07 ` bug#35419: " Ihor Radchenko
[not found] ` <firstname.lastname@example.org>
2019-05-14 17:42 ` Dmitrii Korobeinikov
2019-06-01 14:49 ` Ihor Radchenko
[not found] ` <email@example.com>
2019-06-02 9:09 ` Dmitrii Korobeinikov
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).