[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Nit-picking
From: |
Alan Mackenzie |
Subject: |
Re: Nit-picking |
Date: |
Sat, 12 Apr 2008 09:35:59 +0000 |
User-agent: |
Mutt/1.5.9i |
Hi, Eli!
On Sat, Apr 12, 2008 at 11:40:13AM +0300, Eli Zaretskii wrote:
> > From: Richard Stallman <address@hidden>
> > That is true, but it is also true that if we keep reopening
> > questions decided long ago, we will make our lives very difficult
> > and probably make little progress. We have to leave well enough
> > alone for the old features most of the time, in order to have time
> > to add the new features we know we want.
> Amen.
> 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.
--
Alan Mackenzie (Nuremberg, Germany).
- Re: 23.0.60; M-( and M-) should not be bound in ESC map, (continued)
- Re: 23.0.60; M-( and M-) should not be bound in ESC map, Paul R, 2008/04/11
- Re: 23.0.60; M-( and M-) should not be bound in ESC map, Juanma Barranquero, 2008/04/11
- Re: 23.0.60; M-( and M-) should not be bound in ESC map, Thomas Lord, 2008/04/10
- Re: 23.0.60; M-( and M-) should not be bound in ESC map, Paul R, 2008/04/10
- Re: 23.0.60; M-( and M-) should not be bound in ESC map, Stephen J. Turnbull, 2008/04/10
- Re: 23.0.60; M-( and M-) should not be bound in ESC map, Richard Stallman, 2008/04/11
- RE: 23.0.60; M-( and M-) should not be bound in ESC map, Drew Adams, 2008/04/10
- Re: 23.0.60; M-( and M-) should not be bound in ESC map, Richard Stallman, 2008/04/11
- Re: 23.0.60; M-( and M-) should not be bound in ESC map, Richard Stallman, 2008/04/11
- Re: Nit-picking (was: 23.0.60; M-( and M-) should not be bound in ESC map), Eli Zaretskii, 2008/04/12
- Re: Nit-picking,
Alan Mackenzie <=
- Re: Nit-picking, Eli Zaretskii, 2008/04/12
- Being constructive [Was: Nit-picking], Alan Mackenzie, 2008/04/12
- Re: Being constructive [Was: Nit-picking], Eli Zaretskii, 2008/04/12
- Re: Being constructive [Was: Nit-picking], Jason Rumney, 2008/04/12
- Re: Being constructive [Was: Nit-picking], Eli Zaretskii, 2008/04/12
- Re: Being constructive [Was: Nit-picking], Eli Zaretskii, 2008/04/12
- Re: Being constructive [Was: Nit-picking], Mike Mattie, 2008/04/12
- RE: 23.0.60; M-( and M-) should not be bound in ESC map, Drew Adams, 2008/04/12
- Re: 23.0.60; M-( and M-) should not be bound in ESC map, Richard Stallman, 2008/04/12