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: Thu, 13 Feb 2014 18:07:11 +0200 Message-ID: <8338jnro7k.fsf@gnu.org> References: <87r47bi1e5.fsf@yandex.ru> <52F96284.50507@yandex.ru> <52FAE12B.6060101@yandex.ru> <52FC3BEE.60604@yandex.ru> <87bnyb6s7w.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1392307655 7939 80.91.229.3 (13 Feb 2014 16:07:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Feb 2014 16:07:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 13 17:07:41 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 1WDyp9-0004EC-Ur for ged-emacs-devel@m.gmane.org; Thu, 13 Feb 2014 17:07:40 +0100 Original-Received: from localhost ([::1]:47308 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDyp9-00088Q-Fu for ged-emacs-devel@m.gmane.org; Thu, 13 Feb 2014 11:07:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDyp1-00087k-Gn for emacs-devel@gnu.org; Thu, 13 Feb 2014 11:07:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WDyov-0003WI-Mh for emacs-devel@gnu.org; Thu, 13 Feb 2014 11:07:31 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:51744) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDyop-0003TN-B1; Thu, 13 Feb 2014 11:07:19 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0N0X00D00Z6AKO00@mtaout28.012.net.il>; Thu, 13 Feb 2014 18:08:13 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0X009QLZHPWQ50@mtaout28.012.net.il>; Thu, 13 Feb 2014 18:08:13 +0200 (IST) In-reply-to: <87bnyb6s7w.fsf@fencepost.gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 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:169587 Archived-At: > From: David Kastrup > Date: Thu, 13 Feb 2014 14:46:11 +0100 > > Using different modes on a buffer would seem like a rather canonical use > case for indirect buffers. If they don't work well for that, one needs > to think about _what_ would work better. That may mean improving > indirect buffers or creating something different. In which case one > should recheck whether indirect buffers work well for _anything_. The problem, AFAIU, is that different use cases expect different things from indirect buffers. E.g., some expect them to share text properties, while others want them not to. Since indirect buffers share text with their base buffer, such conflicting requirements are impossible to implement. IOW, this is business as usual: a feature is invented having a certain use case in mind, but then it gets used for entirely different use cases, and everybody expects the new toy to do exactly what they want.