From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch Date: Sat, 15 Feb 2014 09:28:29 +0200 Message-ID: <83lhxcbzs2.fsf@gnu.org> References: <87r47bi1e5.fsf@yandex.ru> <52F96284.50507@yandex.ru> <52FAE12B.6060101@yandex.ru> <52FC3BEE.60604@yandex.ru> <52FCD2B4.5080006@yandex.ru> <52FD9F1D.50205@yandex.ru> <83mwhucg1h.fsf@gnu.org> <878ute589i.fsf@fencepost.gnu.org> <83d2iqc84m.fsf@gnu.org> <87wqgxkcr9.fsf@yandex.ru> <834n41db0d.fsf@gnu.org> <87k3cw53d1.fsf@maru2.md5i.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1392449318 31785 80.91.229.3 (15 Feb 2014 07:28:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Feb 2014 07:28:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Michael Welsh Duggan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 15 08:28:46 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WEZg5-0004I3-AS for ged-emacs-devel@m.gmane.org; Sat, 15 Feb 2014 08:28:45 +0100 Original-Received: from localhost ([::1]:55150 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEZg4-0008KO-QN for ged-emacs-devel@m.gmane.org; Sat, 15 Feb 2014 02:28:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEZfx-0008KG-KK for emacs-devel@gnu.org; Sat, 15 Feb 2014 02:28:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WEZfs-0004yT-B3 for emacs-devel@gnu.org; Sat, 15 Feb 2014 02:28:37 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:60272) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEZfs-0004y9-2r for emacs-devel@gnu.org; Sat, 15 Feb 2014 02:28:32 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N1100C000NWV400@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sat, 15 Feb 2014 09:28:30 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N1100C720RIR140@a-mtaout20.012.net.il>; Sat, 15 Feb 2014 09:28:30 +0200 (IST) In-reply-to: <87k3cw53d1.fsf@maru2.md5i.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169635 Archived-At: > From: Michael Welsh Duggan > Date: Sat, 15 Feb 2014 00:52:58 -0500 > > Eli Zaretskii writes: > > > My point is that we should come up with a list of the requirements, > > and then design and implement the infrastructure which will support > > them, instead of implementing multi-mode buffers by piggybacking > > existing infrastructure, which was never designed to support such > > features. > > Although I might be setting the cat among the pigeons, I thought I'd > throw out an example of a possible infrastructure change along these > lines. > > What if we could have a display property (or something like a display > property) that, rather than displaying a string or an image, displays > (a portion of?) another buffer. That's implementation, not requirements (I'm sure you know that). While it is possible that it will allow what is needed, specifying implementation first does not allow to come up with alternative implementation ideas that satisfy the same requirements. E.g., what you suggest would require a serious surgery on the design of the display engine, and the question remains whether such a surgery is indeed the best or the only way to go. (Personally, I hope not.) So I really think we should define the requirements first.