From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitrii Korobeinikov Newsgroups: gmane.emacs.bugs Subject: bug#35419: [O] [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Date: Fri, 26 Apr 2019 03:00:12 +0600 Message-ID: References: <87v9z2ojf8.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006420f00587611b81" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="51756"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35419@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Apr 25 23:01:17 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hJlUb-000DFr-63 for geb-bug-gnu-emacs@m.gmane.org; Thu, 25 Apr 2019 23:01:17 +0200 Original-Received: from localhost ([127.0.0.1]:35055 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJlUa-0006IG-1a for geb-bug-gnu-emacs@m.gmane.org; Thu, 25 Apr 2019 17:01:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJlUP-0006G5-0X for bug-gnu-emacs@gnu.org; Thu, 25 Apr 2019 17:01:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJlUM-00042r-V9 for bug-gnu-emacs@gnu.org; Thu, 25 Apr 2019 17:01:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45915) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hJlUM-00042j-LA; Thu, 25 Apr 2019 17:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hJlUM-0007xr-HL; Thu, 25 Apr 2019 17:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitrii Korobeinikov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, emacs-orgmode@gnu.org Resent-Date: Thu, 25 Apr 2019 21:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35419 X-GNU-PR-Package: emacs,org-mode Original-Received: via spool by 35419-submit@debbugs.gnu.org id=B35419.155622603530571 (code B ref 35419); Thu, 25 Apr 2019 21:01:02 +0000 Original-Received: (at 35419) by debbugs.gnu.org; 25 Apr 2019 21:00:35 +0000 Original-Received: from localhost ([127.0.0.1]:59459 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hJlTu-0007wy-B2 for submit@debbugs.gnu.org; Thu, 25 Apr 2019 17:00:35 -0400 Original-Received: from mail-wr1-f68.google.com ([209.85.221.68]:34123) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hJlTr-0007we-LY for 35419@debbugs.gnu.org; Thu, 25 Apr 2019 17:00:32 -0400 Original-Received: by mail-wr1-f68.google.com with SMTP id c6so1318365wrm.1 for <35419@debbugs.gnu.org>; Thu, 25 Apr 2019 14:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jFQ2xdWpA9Banxr7zjaj5jyVmUkXBho2HziSlw35aYs=; b=UKhTppIXmydn5iqQodyzftfj1d1hbv7iZzi5NaXdor9APNFETMVInkDIB9DdXy3EWk WT2UdUSIbZt3esenMkzfRMWdT07OKQxYmvaFfVhrk3t8M31Zh5eERYpjZ6a7+H/M8c3f 1qEJn4vRfDLLfECTYESeW1awruuBepQcZcR9CLYttebz8uSnm4TCv5DW+cy5xlawswvO b6KGu8Tx6t5CBzOsPs9OaOfXwLnxAOSIHB90qix62QHbJBTIOpWZrtu3b4ZRAs3ukmDP LFRfDBs8IsEE/eXNFCYNwx+p9HaDMPQM6ck6DaM72LarvDgqV9v6owiSho9WRNwV8IJN Zw4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jFQ2xdWpA9Banxr7zjaj5jyVmUkXBho2HziSlw35aYs=; b=n/YmUGbtg1z4HUnAMypHlKS58GEC13s3FgHMLSMoksKJMNHAgysEGJ07GfAnas/cok NnAwc7I/cczNyiB8T+V3c9csKy08KshcnQZUnSX0qLv5f055Q1vXBnr0n66xJr71DcrU DqbVm8AC7wdBgno3+7uZfH8AH3NJtEpJJ4MLDkazytTSADPJ/Nvo/QvfFseKozC/rjRs gTryPem+UbJdKWWXTLHEJ80ONE/6v2GBvkdw8m8nvpx8FKcTI3PdnIkkKoXmQgQqawNr eVwmggRqSZa0FldsdcyTSApoM9Dt0Xd3aZwu9T+IkbM4vmxNGWynz0Fm2Nk/ZcAICV5e jEBA== X-Gm-Message-State: APjAAAVYSZBZ5vnuEBOvYDw1ZSj+8fE2TAJZwAL1fCseQ/m6i+rgpVXE PjPZrzWvnpX6DMKHmYTvxy7R6vPYzNCxnYnmddk= X-Google-Smtp-Source: APXvYqyk6je2ZF00sYqhqp4m+BQdn44064VOKN2Vkw2gEKUy0nSK2B7/aD6OUWDkZ69gRhiuyB6ZQZ4YDOiyZcrn+i8= X-Received: by 2002:a5d:550b:: with SMTP id b11mr12692708wrv.81.1556226024676; Thu, 25 Apr 2019 14:00:24 -0700 (PDT) In-Reply-To: <87v9z2ojf8.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:158263 Archived-At: --0000000000006420f00587611b81 Content-Type: text/plain; charset="UTF-8" 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 (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: > https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00863.html An interesting read, provides another use-case (collect external data in one place to easily view/edit): https://lists.gnu.org/archive/html/emacs-devel/2018-07/msg00890.html > 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. https://www.reddit.com/r/emacs/comments/50p34n/polymode_is_awesome/?depth=1 >> 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 indenting behavior). Basically, simplicity is in place but at the cost of duplication. Lenses could avoid duplication, while yielding increased functionality and speed. (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 <...> font-lock > 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? Best regards, Dmitrii. --0000000000006420f00587611b81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Ihor,

> Another use case for me is to speed up agenda creatio= n.
> I usually do not like to split my org files into too many= . However, it
> results in very large and slow org buffers lat= er. If I can store some
> parts of the org files externally an= d 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.

Th= at's a good one!

> Let me put some historic= al context to this proposal.
> There was a discussion of simil= ar feature in emacs-dev last year.
> The idea was to implement= nested buffers:

An inter= esting 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
> function= ality you described:

Pretty cool stuff. For= thoroughness, let's discuss how these work.

I= found a comment which mentions polymode's working principle.
https://www.reddit.com/r/emacs/comments/50p34n/polymode_is_= awesome/?depth=3D1
>> Polymode doesn't keep its mod= es in a single emacs buffer but in several indirect buffers, as many as dif= ferent modes are there in a file. Consequently, polymode is as fast as swit= ching emacs buffers because it never re-installs major modes like other mul= ti-modes do. Dave Love's multi-mode.el gets full credit for this idea.<= /div>
> It looks like it slows emacs to a crawl in my main org confi= g file. It seems to work fairly well in some of my notes files (though with= some weird indenting behavior).

Basically, simpli= city is in place but at the cost of duplication.
Lenses could avo= id duplication, while yielding increased functionality and speed.
(e.g. in polymode, a syntax checker couldn't yield correct results unl= ess 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 ot= her major modes are in effect.

> While the poin= t is in a submode region, the following changes occur:
> <.= ..> keymap <...> local variables <...> syntax table and inde= ntation <...> font-lock

> The submode reg= ions are represented internally by Emacs Lisp objects known as /overlays/.<= /div>

> A lot of the functionality of MMM Mode---that= which makes the major mode
> appear to change---is implemente= d by saving and restoring the values of
> local variables, or = pseudo-variables.

What I don't understand is w= here 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 whol= e buffer? But then, how are they limited in their effect to just the necess= ary region? Narrowing?
Could, for example, syntax checking be don= e efficiently that way?
Could someone, please, explain?

Best regards,
Dmitrii.
--0000000000006420f00587611b81--