From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Perry E. Metzger" Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Fri, 9 Jan 2015 13:48:40 -0500 Message-ID: <20150109134840.32dd64f1@jabberwock.cb.piermont.com> References: <83bnxuzyl4.fsf@gnu.org> <87vbkovhh7.fsf@engster.org> <87387rvobr.fsf@engster.org> <83ppat84hk.fsf@gnu.org> <20150106143933.0090bc83@jabberwock.cb.piermont.com> <83r3v77ij6.fsf@gnu.org> <20150106154539.3d0752c4@jabberwock.cb.piermont.com> <87wq4ype3z.fsf@fencepost.gnu.org> <878uherlf3.fsf@wanadoo.es> <87sifkredt.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1420829344 21198 80.91.229.3 (9 Jan 2015 18:49:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Jan 2015 18:49:04 +0000 (UTC) Cc: =?ISO-8859-1?Q?=D3scar?= Fuentes , emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 09 19:48:54 2015 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 1Y9ec6-00057r-Iz for ged-emacs-devel@m.gmane.org; Fri, 09 Jan 2015 19:48:50 +0100 Original-Received: from localhost ([::1]:51811 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9ec6-0002UT-4o for ged-emacs-devel@m.gmane.org; Fri, 09 Jan 2015 13:48:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59324) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9ec1-0002Py-Vw for emacs-devel@gnu.org; Fri, 09 Jan 2015 13:48:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y9ebx-0000iI-Le for emacs-devel@gnu.org; Fri, 09 Jan 2015 13:48:45 -0500 Original-Received: from hacklheber.piermont.com ([166.84.7.14]:38162) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9ebx-0000hx-Hi; Fri, 09 Jan 2015 13:48:41 -0500 Original-Received: from snark.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id 09A9484; Fri, 9 Jan 2015 13:48:40 -0500 (EST) Original-Received: from jabberwock.cb.piermont.com (jabberwock.cb.piermont.com [10.160.2.107]) by snark.cb.piermont.com (Postfix) with ESMTP id C45682DEA20; Fri, 9 Jan 2015 13:48:40 -0500 (EST) In-Reply-To: X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; x86_64-apple-darwin14.0.0) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 166.84.7.14 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:181108 Archived-At: On Fri, 09 Jan 2015 12:39:15 -0500 Richard Stallman wrote: > > Ok, I'll try again: let's suppose an extension that highlights > > chunks of code that might have side effects, or that could use > > multi-threading features, or that could result on calls to > > certain functions, > > Those certainly don't need the statement structure. It is difficult to figure out things such as whether global variables have been assigned in a block without access to the AST. I'm sure a very specific API could be crafted to permit it, of course, but then someone else will want to check whether or not a variable is written within a block protected by a lock variable. That too can be done perhaps with a very specific API, but then someone else may want to highlight all overloaded forms of the [] operator and not the non-overloaded ones. One can keep going on. By the way, when hacking on C++, I would often *very much* like to have overloaded vs. non-overloaded operators highlighted differently. It would make "unexpected" operator behavior a lot easier to be aware of in advance -- one complaint in using the language is that one is often unaware that an operator has been overloaded, so one does not think to check what its behavioral differences from the default may be. So, this isn't a hypothetical. Again, this is something I'm sure a very specialized API could permit, but how many such very specialized APIs does one want to add? Perry -- Perry E. Metzger perry@piermont.com