From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Semantic parser uses c-forward-conditional Date: Tue, 22 Sep 2009 10:57:35 +0000 Message-ID: <20090922105735.GA3722@muc.de> References: <87zl8oumvl.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1253618082 3553 80.91.229.12 (22 Sep 2009 11:14:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Sep 2009 11:14:42 +0000 (UTC) Cc: "Eric M. Ludlam" , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 22 13:14:35 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Mq3KM-0000iq-FS for ged-emacs-devel@m.gmane.org; Tue, 22 Sep 2009 13:14:34 +0200 Original-Received: from localhost ([127.0.0.1]:36570 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mq3KL-0008Os-Bl for ged-emacs-devel@m.gmane.org; Tue, 22 Sep 2009 07:14:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mq30Y-0008Kb-H7 for emacs-devel@gnu.org; Tue, 22 Sep 2009 06:54:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mq30S-0008Gh-QW for emacs-devel@gnu.org; Tue, 22 Sep 2009 06:54:05 -0400 Original-Received: from [199.232.76.173] (port=52086 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mq30S-0008GR-ET for emacs-devel@gnu.org; Tue, 22 Sep 2009 06:54:00 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:1181 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mq30Q-00005o-Pi for emacs-devel@gnu.org; Tue, 22 Sep 2009 06:53:59 -0400 Original-Received: (qmail 20447 invoked by uid 3782); 22 Sep 2009 10:53:55 -0000 Original-Received: from acm.muc.de (pD9E5363E.dip.t-dialin.net [217.229.54.62]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Tue, 22 Sep 2009 12:53:53 +0200 Original-Received: (qmail 5300 invoked by uid 1000); 22 Sep 2009 10:57:35 -0000 Content-Disposition: inline In-Reply-To: <87zl8oumvl.fsf@stupidchicken.com> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:115514 Archived-At: Hi, Yidong! On Mon, Sep 21, 2009 at 03:19:10PM -0400, Chong Yidong wrote: > Hi Alan, > Semantic's C parser calls c-forward-conditional while it's parsing C > files. This happens frequently, often at idle time, if you visit a > large C file. Ah. c-forward-conditional is really intended as an interactive command rather than for use in a lisp function - a bit like beginning-of-buffer. > The trouble is that c-forward-conditional sets the mark. The call to it > is wrapped in a save-excursion, so it doesn't clobber the user's mark, > but it does lead to a stream of ugly "Mark set" messages. > Would it be possible to change c-forward-conditional so that it pushes > the mark only if called interactively? I'm not very keen on that, but how about this instead: a new defun c-forward-conditional-1 which does the same, except it doesn't push a mark, doesn't throw errors like "No following conditional at this level", and returns the final point, or nil? Then all occurances inside CEDET can be changed to (cedet-forward-c-conditional), where the following macro goes into CEDET: (require 'cc-cmds) (defmacro forward-cedet-c-conditional (count &optional target-depth with-else) .... (if (fboundp 'c-forward-conditional-1) ...) .... ) This will avoid complexifying cc-cmds.el, whilst still allowing CEDET and friends to work with older CC MODE versions. It would also be good for CC MODE to separate out the "engine" part of the command from the "wrapper". As a matter of interest, have you grepped CEDET to find other similar problems? -- Alan Mackenzie (Nuremberg, Germany).