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: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Date: Sun, 2 Jun 2019 15:09:47 +0600 Message-ID: References: <87muk1fn90.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <87v9xpfjhs.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000adaa0d058a539c89" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="183502"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Philipp Stephani , 35419@debbugs.gnu.org, Noam Postavsky To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jun 02 11:11:15 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 1hXMWI-000lcF-Ah for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Jun 2019 11:11:14 +0200 Original-Received: from localhost ([127.0.0.1]:46728 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hXMWH-0002sK-BV for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Jun 2019 05:11:13 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hXMW7-0002sC-9e for bug-gnu-emacs@gnu.org; Sun, 02 Jun 2019 05:11:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hXMW6-0006gr-02 for bug-gnu-emacs@gnu.org; Sun, 02 Jun 2019 05:11:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54132) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hXMW5-0006gg-R3; Sun, 02 Jun 2019 05:11:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hXMW5-0007Wl-KY; Sun, 02 Jun 2019 05:11:01 -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: Sun, 02 Jun 2019 09:11:01 +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.155946660628870 (code B ref 35419); Sun, 02 Jun 2019 09:11:01 +0000 Original-Received: (at 35419) by debbugs.gnu.org; 2 Jun 2019 09:10:06 +0000 Original-Received: from localhost ([127.0.0.1]:39443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hXMVC-0007Va-B7 for submit@debbugs.gnu.org; Sun, 02 Jun 2019 05:10:06 -0400 Original-Received: from mail-wm1-f41.google.com ([209.85.128.41]:34748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hXMVA-0007V1-Vb for 35419@debbugs.gnu.org; Sun, 02 Jun 2019 05:10:05 -0400 Original-Received: by mail-wm1-f41.google.com with SMTP id w9so1747160wmd.1 for <35419@debbugs.gnu.org>; Sun, 02 Jun 2019 02:10:04 -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=5kEo7iGeVJvhXibPHhQI4u1BeVKZtiGsToCmK6t23HU=; b=sR7g75X3sOQQX6pRjiprOaeZ4SJyNS0Yy83UpZMUkwLASFdWB97/TvKEfFDObHC4mK Ub6yayRzTgup53mPnEn/KDyScavHaqtt06rrP8vpRwtAVJ+OPc93V8eRLULpXnLCPUKq Itj5ryQobJDQbNYre13ysd3l0i5docoH541Na2aEcgBD+aUF+exdGNYP2wsRNud4q5sB 7FqRPtN/u4RQ4Ex75eGqbDBDwtX3sQCvf+WzUCN2MI0xHKnPpQIkDLryllXt42MMpNID cTpagMhsrYm2b2gxAx8vNMm4UT/JkfyWBGMM/BN4WMRXcs4M4W+YQq+8HlX3a2fao97B 0iCg== 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=5kEo7iGeVJvhXibPHhQI4u1BeVKZtiGsToCmK6t23HU=; b=mci3eUftEZe6hL0+jZroAzD/5waQbDvGQtL3kZVvvvLWct12xbULE7CiW/m90wORb8 KsirDMl+kFM8yPQDzIa94CsaKivwAmF3cZ1FrfLr/3/fzFE1QypAA68YvF8PJTlWpNOf gjQ0V7VgQY0ma6svEF3JjueelZ047U++k6ditghiGA8DxAidvmHuk8EwaX8oWtBxR4xt KqbTlc+spzMz26vfkatAOCCPw/feUKdZHy6ZRGeU45Lf1TH2UarDLfM6njGkgOgEmxAG wwaayufX/rPvoJIgkO4eKM3wFmj9jAmEO0OggIoIGQOhxHmsBeLz+JCjYhaBa3iqdYWG QenA== X-Gm-Message-State: APjAAAU3UdHxpyvCtKr+fB9EoFPcK4CO7+0P/dXjgAHOhNDvW6eYEQQq mJwXYMAv+94VhWD4WFJ1DhjNgklsSjAF43rempE= X-Google-Smtp-Source: APXvYqx37neOVfDRYd7c4lZeLjPXTfY0JURdx93Su4AvMZ7ds17CZhbxDiMqF/3a90gOSNJCzpdGoOM/32tgWBsmDJk= X-Received: by 2002:a05:600c:2182:: with SMTP id e2mr6818049wme.55.1559466599097; Sun, 02 Jun 2019 02:09:59 -0700 (PDT) In-Reply-To: <87v9xpfjhs.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:160022 Archived-At: --000000000000adaa0d058a539c89 Content-Type: text/plain; charset="UTF-8" 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-mode, the > lense is in mingus-mode, and the key is C-d). What should be the > behaviour in such a case? run the commands in both the buffers? decide > depending on the point position? It is easy to make up similar > complicated examples if you consider some exotic major modes in the > lense buffer. It's basically a question of customization, a client-side decision. In other words, this really depends on what the user wants to happen. This customization is done through the controller of the lens. To your example. If the desirable behavior (for you, as a user) for C-d is to run in the lens, then add "C-d" to the controller of the lens. And then, whenever the point is in the area, C-d runs in the lens unconditionally. (For the sake of terminology, we can say that the keybinding is "redirected".) If you want C-d to work conditionally (sometimes do the org-mode thing and sometimes the mingus-mode thing), I am afraid there is nothing better than to update the controller yourself on the go. And that's fine, because that's what the user wants (to use the same bind for two different things in the same place at different times). (BTW, the controller could be asked to work "in reverse" and redirect all keybindings, except the ones in its black list.) But speaking of the larger picture and integration, a user can define a list of key combinations for any mode and the list will be added to the controller if the lens runs that mode. I think this should cover the vast majority of use-cases. Of course, there is no reason for the logic of key addition not to be flexible enough to cover anything more exotic. > I think that it would be more effective if someone decide on some basic > approach for the low-level implementation of the lense-mode (which > probably involves modifying emacs C-level source code) and continue the > discussion according to the benefits/limitations of that kind of > implementation. I too look forward to hearing from someone about the low-level implementation possibilities :) I especially hope the approach for the border-case issue (as described in my previous message) can work. Best regards, Dmitrii. --000000000000adaa0d058a539c89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Ihor,
=C2=A0 =C2=A0
> Regarding the question= about buffer-lens interaction. Let's take even
> more complicate= d example: =C2=A0To run the command, the user hits some key
> combina= tion, which happens to be bound to different commands in the main
> b= uffer and in the lense buffer (i.e. the main buffer is in org-mode, the
= > lense is in mingus-mode, and the key is C-d). What should be the
&g= t; behaviour in such a case? run the commands in both the buffers? decide> depending on the point position? It is easy to make up similar
&g= t; complicated examples if you consider some exotic major modes in the
&= gt; lense buffer.

It's basically a question of customization, a = client-side decision.
In other words, this really depends on what the us= er wants to happen.

This customization is done through the controlle= r of the lens.

To your example.
If the desirable behavior=C2=A0(f= or you, as a user)=C2=A0for C-d is to run in the lens, then add "C-d&q= uot; to the controller of the lens.
And then, whenever the point is in t= he area, C-d runs in the lens unconditionally.
(For the sake of terminol= ogy, we can say that the keybinding is "redirected".)

If y= ou want C-d to work conditionally (sometimes do the org-mode thing and some= times the mingus-mode thing), I am afraid there is nothing better than to u= pdate the controller yourself on the go.
And that's fine, because th= at's what the user wants (to use the same bind for two different things= in the same place at different times).

(BTW, the controller could b= e asked to work "in reverse" and redirect all keybindings, except= the ones in its black list.)

But speaking of the larger picture and= integration, a user can define a list of key combinations for any mode and= the list will be added to the controller if the lens runs that mode.
I = think this should cover the vast majority of use-cases.
Of course, there= is no reason for the logic of key addition not to be flexible enough to co= ver anything more exotic.

> I think that it would be more effecti= ve if someone decide on some basic
> approach for the low-level imple= mentation of the lense-mode (which
> probably involves modifying emac= s C-level source code) and continue the
> discussion according to the= benefits/limitations of that kind of
> implementation.

I too = look forward to hearing from someone about the low-level implementation pos= sibilities :)
I especially hope the approach for the border-case issue= =C2=A0(as described in my previous message)=C2=A0can work.

Best rega= rds,
Dmitrii.
--000000000000adaa0d058a539c89--