From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Welsh Duggan 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 00:52:58 -0500 Message-ID: <87k3cw53d1.fsf@maru2.md5i.com> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1392443591 15261 80.91.229.3 (15 Feb 2014 05:53:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Feb 2014 05:53:11 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 15 06:53:19 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 1WEYBh-0006Ok-4I for ged-emacs-devel@m.gmane.org; Sat, 15 Feb 2014 06:53:17 +0100 Original-Received: from localhost ([::1]:54962 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEYBg-00050q-73 for ged-emacs-devel@m.gmane.org; Sat, 15 Feb 2014 00:53:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEYBZ-00050a-3Y for emacs-devel@gnu.org; Sat, 15 Feb 2014 00:53:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WEYBU-0007A4-MC for emacs-devel@gnu.org; Sat, 15 Feb 2014 00:53:09 -0500 Original-Received: from md5i.com ([75.151.244.229]:35703 helo=maru2.md5i.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEYBU-00078w-HK for emacs-devel@gnu.org; Sat, 15 Feb 2014 00:53:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=md5i.com; s=dkim; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:To:From; bh=tVq7qdHRevJ8YZKt4FE+UbyVhZMgExklyXPSHCfB6lU=; b=Z8V1FpDp3L4oOkibosdosprvIfsIYMoCVID0gd47yGYqLJQxldbAMQByhZrxrTmk4ytqcoods+VKgW0lG9tP7GC5IqFfrVWKuIUZBTzc+DyL92b62x9wVjbIFZib+gHK; Original-Received: from md5i by maru2.md5i.com with local (Exim 4.82) (envelope-from ) id 1WEYBO-0005cy-Ol for emacs-devel@gnu.org; Sat, 15 Feb 2014 00:52:58 -0500 In-Reply-To: <834n41db0d.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 Feb 2014 16:28:18 +0200") User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 75.151.244.229 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:169634 Archived-At: 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. Moreover, when the cursor is in this region, all events go to the subsidiary buffer rather than the displayed one. Changes are actually happening in another buffer, with full mode and font-lock support, but those changes are visibly mirrored in the "display" buffer. Write hooks (and copy hooks) can replace the dislpay regions with the actual contents of the subsidiary buffers. Now, I am certain there are a lot of potential problems with this idea (I can think of several off the top of my head), but this is, once again, an example of a proposed feature that might be able to solve this type of problem. -- Michael Welsh Duggan (md5i@md5i.com)