unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: Nit-picking
Date: Sat, 12 Apr 2008 13:30:27 +0300	[thread overview]
Message-ID: <uve2n8iws.fsf@gnu.org> (raw)
In-Reply-To: <20080412093559.GC1781@muc.de>


[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 <acm@muc.de>
> 
> > 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.




  reply	other threads:[~2008-04-12 10:30 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-09 21:09 23.0.60; M-( and M-) should not be bound in ESC map Drew Adams
2008-04-09 21:32 ` Andreas Schwab
2008-04-09 22:15   ` Drew Adams
2008-04-10  6:33     ` David Hansen
2008-04-10  9:20       ` Reiner Steib
2008-04-10  8:31     ` Andreas Schwab
2008-04-10 12:55   ` Richard Stallman
2008-04-10 13:45     ` Paul R
2008-04-10 15:49     ` Alan Mackenzie
2008-04-10 15:45       ` Juanma Barranquero
2008-04-10 16:24         ` Alan Mackenzie
2008-04-10 16:15           ` Juanma Barranquero
2008-04-10 21:09             ` David Kastrup
2008-04-10 22:34               ` Juanma Barranquero
2008-04-11  2:23             ` Glenn Morris
2008-04-11  5:03               ` Thomas Lord
2008-04-11  8:03                 ` tomas
2008-04-12  0:11                 ` Richard Stallman
2008-04-12  1:13                   ` Thomas Lord
2008-04-12  5:49                     ` David Kastrup
2008-04-12  7:31                       ` Alan Mackenzie
2008-04-12 14:03                         ` Thomas Lord
2008-04-12 20:07                           ` David Kastrup
2008-04-12 21:24                             ` Thomas Lord
2008-04-12 20:34                         ` Stephen J. Turnbull
2008-04-11  8:41               ` Paul R
2008-04-11  9:40               ` Juanma Barranquero
2008-04-10 17:10           ` Thomas Lord
2008-04-10 17:10             ` Paul R
2008-04-10 19:21               ` Stephen J. Turnbull
2008-04-12  0:11         ` Richard Stallman
2008-04-10 16:18     ` Drew Adams
2008-04-12  0:09       ` Richard Stallman
2008-04-12  0:09       ` Richard Stallman
2008-04-12  8:40         ` Nit-picking (was: 23.0.60; M-( and M-) should not be bound in ESC map) Eli Zaretskii
2008-04-12  9:35           ` Nit-picking Alan Mackenzie
2008-04-12 10:30             ` Eli Zaretskii [this message]
2008-04-12 11:46               ` Being constructive [Was: Nit-picking] Alan Mackenzie
2008-04-12 13:17                 ` Eli Zaretskii
2008-04-12 14:14                   ` Jason Rumney
2008-04-12 16:51                     ` Eli Zaretskii
2008-04-12 17:16                       ` Eli Zaretskii
2008-04-12 21:38                 ` Mike Mattie
2008-04-12 15:06         ` 23.0.60; M-( and M-) should not be bound in ESC map Drew Adams
2008-04-13  1:58           ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=uve2n8iws.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).