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: Nit-picking Date: Sat, 12 Apr 2008 13:30:27 +0300 Message-ID: References: <003801c89a85$fcd95ad0$c2b22382@us.oracle.com> <008d01c89b26$8aacebb0$c2b22382@us.oracle.com> <20080412093559.GC1781@muc.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1207996249 25325 80.91.229.12 (12 Apr 2008 10:30:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Apr 2008 10:30:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 12 12:31:21 2008 connect(): Connection refused 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 1Jkd0u-0005sE-V0 for ged-emacs-devel@m.gmane.org; Sat, 12 Apr 2008 12:31:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jkd0H-0007ZN-2u for ged-emacs-devel@m.gmane.org; Sat, 12 Apr 2008 06:30:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jkd0C-0007V0-Lk for emacs-devel@gnu.org; Sat, 12 Apr 2008 06:30:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jkd08-0007KO-Og for emacs-devel@gnu.org; Sat, 12 Apr 2008 06:30:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jkd08-0007JM-Kf for emacs-devel@gnu.org; Sat, 12 Apr 2008 06:30:28 -0400 Original-Received: from mtaout2.012.net.il ([84.95.2.4]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jkd08-0000Dm-5B for emacs-devel@gnu.org; Sat, 12 Apr 2008 06:30:28 -0400 Original-Received: from HOME-C4E4A596F7 ([80.230.158.193]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0JZ700IS1KI34O21@i_mtaout2.012.net.il> for emacs-devel@gnu.org; Sat, 12 Apr 2008 13:44:28 +0300 (IDT) In-reply-to: <20080412093559.GC1781@muc.de> X-012-Sender: halo1@inter.net.il X-detected-kernel: by monty-python.gnu.org: Solaris 9.1 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:95035 Archived-At: [Moving this to emacs-devel, where it belongs.] > Date: Sat, 12 Apr 2008 09:35:59 +0000 > Cc: rms@gnu.org, emacs-pretest-bug@gnu.org > From: Alan Mackenzie > > > Perhaps it's just me, but there appear to be too many threads on this > > list that I need to skip entirely, due to their endless discussions of > > issues of miniscule importance. OTOH, I don't remember any > > discussions of important new features for quite some time. It almost > > looks like no important development is going on. > > Down at CC Mode, I receive a constant trickle of "little" bugs, things > that go wrong in unusual (but perfectly reasonable) source code. > Languages like C++ and Java (and even C itself) are astonishingly > complicated. > > In the medium future, I'll be concentrating on fixing long-standing, > difficult bugs: font locking going wrong in the middle of a long struct > declaration (for lack of syntactic context); inadequate handling of > template/generic bracketing (by < and >) in C++/Java. Also, somewhat > easier, things like making C-M-a go to the beginning of the real > function/class in C++, not the enclosing outermost class or namespace; > and somebody asked me for a command to switch between C-style (/* .. */) > and C++-style (// .... \n) comments. :-) > > I've got vague ideas for adding "decluttering" commands: commands to > render things like casts and "frivolous compound statements" (where a > brace block contains only a single statement) invisible. These are a > real eyesore in certain types of proprietary source code. :-( > > And there's continual refactoring to be done - software this > complicated, more than a decade old, doesn't stay cleanly implemented > all by itself. > > All in all, nothing very exciting or earth shattering - but important, > nevertheless. CC-Mode is a veteran feature. I was rather talking about something radically new, like IDE-like features in CEDET and Semantic, or function signature and C++ class member tooltips. (I'm not sure they are part of CC-Mode's scope, but just to give you an idea.) These are great usability aids, IMO, and today's programmers expect to find them in any development environment. Elsewhere, there's lot of turf to be covered in the Unicode support department, like Unicode collation and line breaking, Unicode regular expressions, script properties, etc. (See http://www.unicode.org/reports/index.html for more about these and other Unicode-related features.) These all require extensive changes in core Emacs infrastructure and its main features, so how come all these changes are never discussed here, nor worked upon? After all, Unicode support is the main new feature of Emacs 23, isn't it? If I think a bit more, I'm sure I will come up with a longer list of important developments that IMO should keep us busy for some time to come, instead of being bogged down in disagreement about how to paint the selected region.