From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: Questions about throw-on-input Date: Fri, 15 May 2020 12:47:08 -0700 Message-ID: References: <8920fe6a-8fe4-addd-c29e-2213850bf974@web.de> <83k11f7v4q.fsf@gnu.org> <4506133a-5e63-4ae7-9b5d-830359e8b673@default> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d3f43205a5b51467" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="98402"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , EMACS development team , p.stephani2@gmail.com, yyoncho@gmail.com, Arthur Miller , alexanderm@web.de, Eli Zaretskii , Drew Adams To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 15 21:48:46 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jZgK6-000PVC-Ds for ged-emacs-devel@m.gmane-mx.org; Fri, 15 May 2020 21:48:46 +0200 Original-Received: from localhost ([::1]:60952 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZgK5-0002uZ-Fg for ged-emacs-devel@m.gmane-mx.org; Fri, 15 May 2020 15:48:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32898) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZgIl-0001t5-PH for emacs-devel@gnu.org; Fri, 15 May 2020 15:47:23 -0400 Original-Received: from mail-yb1-xb41.google.com ([2607:f8b0:4864:20::b41]:42218) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jZgIk-0005i4-Rr; Fri, 15 May 2020 15:47:23 -0400 Original-Received: by mail-yb1-xb41.google.com with SMTP id i16so1706634ybq.9; Fri, 15 May 2020 12:47:21 -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=FTcjZlXzx2HULSLx78P4OZMFOPJYtPmB0Ode/bJFKv8=; b=qa31OS2Rq3EEFktOaZnKnCyO7PdnRJ1fd5X5xP6aEzrhYb5Z0OWDvkhvbFPsFkkNjN 7n8nAtbP5z2g6KN1J+mZmjbql8NrNMQ/eYGiOEWbEaWllj3vh+3fGSlcKd1hAOcVIb8D aZthSvOk5z21F2UajCj11MB2Rx5kuZtW0QHesU84wOMYmbqdtKnKYDAlTAHlWBqsCJ+/ IvwyKX/3bMDWSzTUoH56Rk1xyjtUqIhnEAANlQhqVBWTVJghuKKJ+A5jy1Xc5dXSWj4W 8YOfqAuetZ6OtDfQJpBDddp1irohyrZdAGHmA/On16rnvP45E37feNmLGMrSJzigCEkx aWMA== 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=FTcjZlXzx2HULSLx78P4OZMFOPJYtPmB0Ode/bJFKv8=; b=KaT7Y13DbF/2cFjmt+KA3IfIa7wle1gg5uLO7v2fGRUtZTWdg+Mnl7Q01V1w1yYM/z 3cubo8Jnj5bQQU7FKICnxWTo6Fe82PIn0/638wunEuxMFzcJ1XQEiFBCD1euXtwTiCbW pgOta1YY9C8XeyCAyqrXSpr1QZr6eox9hi6ze5ZrDuiO8RElLhx0xpUgydx7x6cbsYGQ Fba7Cr/dWrZWTUPgIUAE8JK8MGGzaEuaDtGCFobMUn5MHyAK6EVcFGr4AAW7qaEopXFO VUwgu3sIPQ7jANSyvNPEstsqlD2uv6h//BOvpJS4/ZtRZ6yGimF2GtZnXVlmzosNRqac OHfA== X-Gm-Message-State: AOAM532DQ8pghSKtysto0lbZqr8UQ+p8wPxd2aBtCR2D9rO3fHBcIQdg aiU3NcTeeJ/6ZOskqUPsfFZswKZ/EixTFj4pUR8= X-Google-Smtp-Source: ABdhPJxyJ50E72uugx58+huRfLeFrNgTZvntYr0kmkKW5DvZZf21n6d9u+L1K5Yf847I3GBXxglmwIAGiI9UhcEXyBo= X-Received: by 2002:a25:d84b:: with SMTP id p72mr8479978ybg.105.1589572040650; Fri, 15 May 2020 12:47:20 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::b41; envelope-from=yandros@gmail.com; helo=mail-yb1-xb41.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:250424 Archived-At: --000000000000d3f43205a5b51467 Content-Type: text/plain; charset="UTF-8" I was thinking about this recently, and, as a thought exercise, a hypothetical emacs could adopt more of the web-browser model, based around frames or windows rather than buffers. Things like completion windows would be attached to a frame/window, but that's not conceptually hard, and "better pop-up windows" is a nice-to-have anyway (people keep implementing bespoke solutions for current emacs, and I believe a good internal facility would be welcome). I say "frame or window" because most editing use cases are built around a single window with some transient extras (editing src/xdisp.c), with a few common cases where multiple buffers are semantically linked (gnus, mu4e, maybe slime/cider/gud) in a way that would be fine to share a single thread, especially if the engine allowed for "workers" that could grab (copy?) state, carry out some processing in the background, and then update and release the state, similar to package-list-packages updating the package list in the background while I look at various package-descriptions in the foreground, or git updating while I read a log/diff. By way of explanation (not endorsement), the email client I'm using right now popped up a little message in the bottom-right corner that says "New Message from Stefan Monnier _Show_ _Ignore_", letting me know that the state has been updated behind my view, and giving me the option to update the view now or leave me alone while I finish my edits. The idea here is to create potential boundaries between the giant shared-mutable soup ala Oberon, Squeak, and (from what I understand) LispM, while still allowing useful shared state. In this hypothetical world, what are the cases where making most mutable data frame/window-local and building a minimal shared arena for explict lock/mod/copy state would break down? I can imagine that a list of current buffers, for example, would need to cross that boundary. Would project-wide search, edit, and refactoring tools be too constrained if a project had to live within a single frame/window? Does the tab-bar/tab-line interface help us figure out how to present the boundaries to the user in a helpful way? Thanks, ~Chad --000000000000d3f43205a5b51467 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I was thinking about this recently, and, as a thought = exercise, a hypothetical emacs could=C2=A0adopt more of the web-browser mod= el, based around frames or windows rather than buffers. Things like complet= ion windows would be attached to a frame/window, but that's not concept= ually hard, and "better pop-up windows" is a nice-to-have anyway = (people keep implementing bespoke solutions for current emacs, and I believ= e a good internal facility would be welcome).=C2=A0

I sa= y "frame or window" because most editing use cases are built arou= nd a single window with some transient extras (editing src/xdisp.c), with a= few common cases where multiple buffers are semantically linked (gnus, mu4= e, maybe slime/cider/gud) in a way that would be fine to share a single thr= ead, especially if the engine allowed for "workers" that could gr= ab (copy?) state, carry out some processing in the background, and then upd= ate and release the state, similar to package-list-packages updating the pa= ckage list in the background while I look at various package-descriptions i= n the foreground, or git updating while I read a log/diff.=C2=A0
=
By way of explanation (not endorsement), the email client I&= #39;m using right now popped up a little message in the bottom-right corner= that says "New Message from Stefan Monnier=C2=A0 _Show_ _Ignore_"= ;, letting me know that the state has been updated behind my view, and givi= ng me the option to update the view now or leave me alone while I finish my= edits.

The idea here is to create potential bound= aries between the giant shared-mutable soup ala Oberon, Squeak, and (from w= hat I understand) LispM, while still allowing useful shared state. In this = hypothetical world, what are the cases where making most mutable data frame= /window-local and building a minimal shared arena for explict=C2=A0lock/mod= /copy state would break down? I can imagine that a list of current buffers,= for example, would need to cross that boundary. Would project-wide search,= edit, and refactoring tools be too constrained if a project had to live wi= thin a single frame/window? Does the tab-bar/tab-line interface help us fig= ure out how to present the boundaries to the user in a helpful way?

Thanks,
~Chad

--000000000000d3f43205a5b51467--