23.0.60; M-( and M-) should not be bound in ESC map

23.0.60; M-( and M-) should not be bound in ESC map

[Drew Adams]

This bug is not new.  M-( and M-) are bound in `esc-map', which means
they are in effect pretty much everywhere, including the minibuffer.
 
This is is not a good idea.  `insert-parentheses' and
`move-past-close-and-reindent' should be bound only for programming
modes for which they actually make sense.  
 
It can be surprising to get an error "Unbalanced parentheses" 18,
5795" or "Containing expression ends prematurely" or some such if you
accidentally hit M-) in the minibuffer or a text file. This is the
kind of thing that can frighten users unnecessarily.

In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-04-04 on LENNART-69DE564
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include
-fno-crossjumping'
 

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> This is is not a good idea.  `insert-parentheses' and
> `move-past-close-and-reindent' should be bound only for programming
> modes for which they actually make sense.  

Inserting pairs of parentheses makes sense pretty much everywhere.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: 23.0.60; M-( and M-) should not be bound in ESC map

[Drew Adams]

> > This is is not a good idea.  `insert-parentheses' and
> > `move-past-close-and-reindent' should be bound only for programming
> > modes for which they actually make sense.  
> 
> Inserting pairs of parentheses makes sense pretty much everywhere.

Of course inserting parentheses can make sense in many contexts. These bindings
do not, however. It's about the bindings, not about inserting parens: you can
insert parentheses without these bindings.

Accidentally hitting M-( or M-) (not difficult to do) can give you inopportune
error messages. See the bug report.

Balancing parens is important for programming languages that allow nested
parens.
Any miniscule advantage gained by adding such a feature to other contexts (e.g.
ordinary text) is outweighed by the confusing error messages that users will
wonder about.

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[David Hansen]

On Wed, 9 Apr 2008 15:15:02 -0700 Drew Adams wrote:

> Balancing parens is important for programming languages that allow nested
> parens.

I have bound `(' to insert pair globally.  I don't know of any case
where I want non balanced parenthesis (except when writing a mail about
the use of (non) balanced parenthesis ;).

David

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > This is is not a good idea.  `insert-parentheses' and
>> > `move-past-close-and-reindent' should be bound only for programming
>> > modes for which they actually make sense.  
>> 
>> Inserting pairs of parentheses makes sense pretty much everywhere.
>
> Of course inserting parentheses can make sense in many contexts. These bindings
> do not, however. It's about the bindings, not about inserting parens: you can
> insert parentheses without these bindings.

But they won't be automatically balanced.  This is exactly what the
bindings are about, and why they are useful everywhere.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Reiner Steib]

On Thu, Apr 10 2008, David Hansen wrote:
> I have bound `(' to insert pair globally.  I don't know of any case
> where I want non balanced parenthesis (except when writing a mail about
> the use of (non) balanced parenthesis ;).

`case' in shell scripts.  Yes, POSIX also allow ( *.bar ), but old Bourne
shells don't.

  case $foo in *.bar ) baz;; esac

That said, I think the global bindings for M-( and M-) are the right
thing.

Drew Adams wrote:
> It can be surprising to get an error "Unbalanced parentheses" 18,
> 5795" or "Containing expression ends prematurely" or some such if you
> accidentally hit M-) in the minibuffer or a text file. This is the
> kind of thing that can frighten users unnecessarily.

I don't think such an error is very common.  More or less every
unindented key stroke can cause somewhat unexpected results, but these
cause no damage and I think its unlikely to type M-) accidentally: you
need to hit Alt+Shift+Number, at least with US or German keyboard
layout.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Richard Stallman]

    > This is is not a good idea.  `insert-parentheses' and
    > `move-past-close-and-reindent' should be bound only for programming
    > modes for which they actually make sense.  

    Inserting pairs of parentheses makes sense pretty much everywhere.

Yes.  And error messages that a beginner doesn't totally understand
can happen in many ways in Emacs.  I think this change is too much
just to eliminate a few cases of them.

Leaving well enough alone seems best to me.

People are proposing lots of changes in long-settled aspects of Emacs,
and I think this is a bad habit.  Each such proposal leads to a long
discussion, which takes up lots of people's time.  And usually it
doesn't achieve anything.

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Paul R]

Richard Stallman <rms@gnu.org> writes:

> (...)
> And usually it doesn't achieve anything.

This is the bad habit :)

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Juanma Barranquero]

On Thu, Apr 10, 2008 at 5:49 PM, Alan Mackenzie <acm@muc.de> wrote:

> Each such proposal leads to a long
> discussion, which takes up lots of people's time.  And usually it
> doesn't achieve anything.

Surely the fact that suggesting the slightest change usually prompts
such a long, heated discussion is a factor in not achieving anything.

 Juanma

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Alan Mackenzie]

Hi, Richard!

On Thu, Apr 10, 2008 at 08:55:06AM -0400, Richard Stallman wrote:

> People are proposing lots of changes in long-settled aspects of Emacs,
> and I think this is a bad habit.  Each such proposal leads to a long
> discussion, which takes up lots of people's time.  And usually it
> doesn't achieve anything.

Well said, that man!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Juanma Barranquero]

On Thu, Apr 10, 2008 at 6:24 PM, Alan Mackenzie <acm@muc.de> wrote:

>  Just to clarify, RMS wrote that, not me.  I just agreed with it.

I know.

>  Well, are we currently starting another long heated discussion, not even
>  talking about well established things?  I won't be carrying on with this
>  thread too long.  ;-)

I won't either.

>  A lot of the recent discussions haven't been about "the slightest
>  change"s, they've been about changing the very core features of Emacs.

I was not talking specifically about recent discussions. It was the
feeling gathered after five years of emacs-devel. All user-visible
changes cause long threads, heated comments and few decisions.

 Juanma

RE: 23.0.60; M-( and M-) should not be bound in ESC map

[Drew Adams]

>     > This is is not a good idea.  `insert-parentheses' and
>     > `move-past-close-and-reindent' should be bound only for 
>     > programming modes for which they actually make sense.  
> 
>     Inserting pairs of parentheses makes sense pretty much everywhere.
> 
> Yes.  And error messages that a beginner doesn't totally understand
> can happen in many ways in Emacs.  I think this change is too much
> just to eliminate a few cases of them.
> 
> Leaving well enough alone seems best to me.

Even leaving aside the opaque error messages and the waste of useful global
keys, this makes no more sense for non-programming modes than would
`blink-matching-paren' or `show-paren-mode'. Should we add those everywhere, as
well?

And we have `insert-pair' as well. If inserting matched parens is so appropriate
for text mode and all other modes, then surely the same must be true for {}, <>,
[], "", '', and `'. The same logic says we should bind `insert-pair'. Matching
"" is at least as important as matching ().

Don't argue only to support personal habits. If your argument makes sense, then
it makes sense also for `insert-pair', `blink-matching-paren', and
`show-paren-mode'.

It's no accident that this is defined in lisp.el. It's appropriate for
programming modes with nested parens.

> People are proposing lots of changes in long-settled aspects of Emacs,
> and I think this is a bad habit.  Each such proposal leads to a long
> discussion, which takes up lots of people's time.  And usually it
> doesn't achieve anything.

You're opening a general discussion not specific to this bug report.

Just because a decision was made long ago does not mean that it is the right
decision now or even that it was the right decision then.

I filed a bug report. The discussion is yours. Do as you like about the report.

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Alan Mackenzie]

Hi, Juanma,

On Thu, Apr 10, 2008 at 05:45:43PM +0200, Juanma Barranquero wrote:
> On Thu, Apr 10, 2008 at 5:49 PM, Alan Mackenzie <acm@muc.de> wrote:
 
> > Each such proposal leads to a long
> > discussion, which takes up lots of people's time.  And usually it
> > doesn't achieve anything.

Just to clarify, RMS wrote that, not me.  I just agreed with it.

> Surely the fact that suggesting the slightest change usually prompts
> such a long, heated discussion is a factor in not achieving anything.

Well, are we currently starting another long heated discussion, not even
talking about well established things?  I won't be carrying on with this
thread too long.  ;-)

A lot of the recent discussions haven't been about "the slightest
change"s, they've been about changing the very core features of Emacs.
Everybody on this list has strong views about these, and proposing a
changes to them is bound to trigger off long heated discussions.

Let's get back to Emacs bugs and features!

>  Juanma

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Paul R]

Thomas Lord <lord@emf.net> writes:

> And that observation ("whose got the time?") points out where the
> deeper problem is:
>
> The GNU project doesn't have enough money.
>

At least, it would surely benefit from more manpower. Hence, it would
need more people contributing on their free time. So how to get them ?
I don't have an out-of-the-box solution to sell, but as a start I
would recommend to show respect and listening to contributors, so that
they can feel they are part of the project, and not only free
manpower. Somebody wrote recently that emacs never was a democratic
project, and that masses are coming to Gnu, not the other way round.
Although I'm not sure if that was a joke or not, I highly recommand to
check that masses are still coming to Gnu Emacs. I doubt it,
sincerely. If Gnu Emacs wants more contributors, let's start to *face*
what are preventing them to come. As a start, some "long-settled
aspects of Emacs" should probably get revamped, and talking about them
here is a good start, IMO. Ignoring that will lead to a vicious
circle.

Please don't get me wrong, I really like Gnu Emacs, but being new in
emacs development, I can report all the obstacles I'm facing on this
path.

with much respect to emacs contributors, past and present,

-- Paul

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Thomas Lord]

Not to prolong discussion, but:

Alan Mackenzie wrote:
> Well, are we currently starting another long heated discussion, not even
> talking about well established things?  I won't be carrying on with this
> thread too long.  ;-)
>
> A lot of the recent discussions haven't been about "the slightest
> change"s, they've been about changing the very core features of Emacs.
> Everybody on this list has strong views about these, and proposing a
> changes to them is bound to trigger off long heated discussions.
>
> Let's get back to Emacs bugs and features!
>   

Over the years, a fairly complex program like Emacs suffers from
"entropy" in the architecture of the core.  Slight mistakes get somewhat
locked in.  Then more slight mistakes get added.   And eventually you
can wind up with an intractable program.  Some would argue
we should have faith in "cleverness" and that clever simple fixes from
time to time will counter-act the entropy, but I am pretty sure that is
just wishful thinking in a project with a 20+ year history.


That doesn't mean people should argue about these impractical
changes here -- the main point of these recent comments.  But...

The entropy problem can be directly attacked by some obvious things
like starting a side discussion, elsewhere, about the architectural issues;
working out a plan to deal with them;  then executing that plan.


That's an idea but an incomplete one, because, really, whose got the
time?

And that observation ("whose got the time?") points out where the
deeper problem is:

The GNU project doesn't have enough money.

Money alone isn't the solution.  Given money for hacking, the next
hard problem is how to spend it wisely.   So there are two sides to that
coin.  Plans for getting more money and spending that money would need
to be developed hand in hand.

Oh well.   I am pretty conservative about what goes in my .emacs.   I mostly
use Emacs in ways not too far removed from using in v18 or so.   I'm not
worried about the imminent heat death of Emacs by a long shot.   Some of
the new features (e.g., Eclipse-inspired stuff) look potentially very cool.


But as this list (hopefully) concludes (at least for now) quibbling over 
hard
architectural issues (with no results from that quibbling), I just hope 
people
will think about the larger context and why these problems are hard to cope
with.   Something to stew around in the back of your mind.

Thanks,
-t

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Stephen J. Turnbull]

Paul R writes:

 > At least, it would surely benefit from more manpower. [...] As a
 > start, some "long-settled aspects of Emacs" should probably get
 > revamped, and talking about them here is a good start, IMO.

Eric Raymond and others pushed this thread in Dec-Jan.  The conclusion
was (more or less) that Emacs is what it is, and while experienced
contributors listening to enthusiastic newbies is a good idea, so is
newcomers listening to the old hands.  What the old hands said was
"let's be careful that in turning Emacs into Eclipse we don't throw
out what makes Emacs special."

There are plenty of things that can be added to Emacs (tab controls,
for example) that do not require any changes to the habits of Ye Olde
Garde, but will be familiar/useful to newcomers.  Better to focus
there, perhaps?

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> I was not talking specifically about recent discussions. It was the
> feeling gathered after five years of emacs-devel. All user-visible
> changes cause long threads, heated comments and few decisions.

It also causes the abandonment of bad compromises.  Many of those
discussions have resulted in code and behavior that would be an overall
improvement, meaning that it retained its usefulness for its proponents
while not being a regression for its opponents.

Waxing poetical, moving from raw to cooked state might require heat at
times.

If the aim of this discussion list was to make everybody like everybody
else, it probably could be called not quite effective.  But its aim is
the development and improvement of Emacs.  And those few decisions which
caused long threads, all in all, tended to be decisions in the need of
cooking.  When the decision finally was made, it was rarely about the
same code that started the discussion.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Juanma Barranquero]

On Thu, Apr 10, 2008 at 11:09 PM, David Kastrup <dak@gnu.org> wrote:

>  And those few decisions which
>  caused long threads, all in all, tended to be decisions in the need of
>  cooking.

Obviously, we disagree in at least two points: the number (you say
"those few decisions", I've got the feeling they have been plenty) and
the final state (you [seem to] think most of them end by reaching a
decision, I think most of them just die out of participant's boredom,
to be reborn a few weeks/months/years later).

But we're out in subjective land. There's no much point discussing this, IMO.

 Juanma

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Glenn Morris]

"Juanma Barranquero" wrote:

> I was not talking specifically about recent discussions. It was the
> feeling gathered after five years of emacs-devel. All user-visible
> changes cause long threads, heated comments and few decisions.

(I find a killfile improves the signal-to-noise ratio.)

I don't like the "poisonous people" tag, but the following has some
valid points:

http://www.oreillynet.com/conferences/blog/2006/07/oscon_how_open_source_projects.html

    The premise for their talk was: Attention and focus are your
    scarce resources and you need to protect them. Poisonous people
    tend to distract communities and scatter the attention and focus
    of the people who should continue developing new features or
    fixing bugs. Communities must avoid deadlock by not letting people
    derail forward progress. For instance, people in the community can
    ask endless questions or focus on perfection (in a design or
    feature set) and bogart the attention of developers.

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Thomas Lord]

Glenn Morris wrote:
> I don't like the "poisonous people" tag, but the following has some
> valid points:
>
> http://www.oreillynet.com/conferences/blog/2006/07/oscon_how_open_source_projects.html
>
>     The premise for their talk was: Attention and focus are your
>     scarce resources and you need to protect them. Poisonous people
>     tend to distract communities and scatter the attention and focus
>     of the people who should continue developing new features or
>     fixing bugs. Communities must avoid deadlock by not letting people
>     derail forward progress. For instance, people in the community can
>     ask endless questions or focus on perfection (in a design or
>     feature set) and bogart the attention of developers.
>
>
>   



People use that rubbish as a tool of oppression.   It isn't the right 
approach.

Don't objectify others in such ways, please.

Every case is different.   You can not polarize the population that way and
then make up rule for how to treat those who you consider to be inferior.

If you are doing something in public and the rest of the public is making it
difficult, then maybe the problem lies with you.

Meanwhile, that stuff from O'Reilly is mostly about how to manage a
commercially sponsored "open source" project in such a way as to maximize
your ability to extract gratis labor from the "community".

-t

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Apr 10, 2008 at 10:03:20PM -0700, Thomas Lord wrote:
> Glenn Morris wrote:
> >I don't like the "poisonous people" tag, but the following has some
> >valid points:
> >
> >http://www.oreillynet.com/conferences/blog/2006/07/oscon_how_open_source_projects.html
> >
> >    The premise for their talk was: Attention and focus are your
> >    scarce resources and you need to protect them. Poisonous people
> >    tend to distract communities [...]

> People use that rubbish as a tool of oppression.   It isn't the right 
> approach.

[...]

Wow. Couldn't agree more. And couldn't put that in less words

thanks
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFH/xtHBcgs9XrR2kYRAoZrAJ90a8I2xaarBPBLOuW/ZRG3J9P1TACggOSB
OJq5x3brLz/OMOP+xcZrfXk=
=aVap
-----END PGP SIGNATURE-----

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Paul R]

Glenn Morris <rgm@gnu.org> writes:

> "Juanma Barranquero" wrote:
>
>> I was not talking specifically about recent discussions. It was the
>> feeling gathered after five years of emacs-devel. All user-visible
>> changes cause long threads, heated comments and few decisions.
>
> (I find a killfile improves the signal-to-noise ratio.)
>
> I don't like the "poisonous people" tag, but the following has some
> valid points:
>
> http://www.oreillynet.com/conferences/blog/2006/07/oscon_how_open_source_projects.html
>
>     The premise for their talk was: Attention and focus are your
>     scarce resources and you need to protect them. Poisonous people
>     tend to distract communities and scatter the attention and focus
>     of the people who should continue developing new features or
>     fixing bugs. Communities must avoid deadlock by not letting people
>     derail forward progress. For instance, people in the community can
>     ask endless questions or focus on perfection (in a design or
>     feature set) and bogart the attention of developers.

Wow. This is sad to read such words in a "libre", community project
newsgroup. Really sad. But you might never read this, your killfile
protecting you from other people POV.

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Juanma Barranquero]

On Fri, Apr 11, 2008 at 4:23 AM, Glenn Morris <rgm@gnu.org> wrote:

>  (I find a killfile improves the signal-to-noise ratio.)

Though I've sometimes tempted, I don't ever use a killfile. I've never
found anyone in a mailing list, newsgroup or forum so obnoxious that I
would forever reject anything he can say in the future (though I
obviously skip in fast forward over many unintersting discussions).

>  I don't like the "poisonous people" tag, but the following has some
>  valid points:

I agree with Tom, Tomás and Paul's comments.

 Juanma

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Richard Stallman]

    Even leaving aside the opaque error messages and the waste of useful global
    keys, this makes no more sense for non-programming modes than would
    `blink-matching-paren' or `show-paren-mode'. Should we add those everywhere, as
    well?

`blink-matching-paren' is enabled globally.

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Richard Stallman]

    Just because a decision was made long ago does not mean that it is the right
    decision now or even that it was the right decision then.

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.

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Richard Stallman]

    Surely the fact that suggesting the slightest change usually prompts
    such a long, heated discussion is a factor in not achieving anything.

Many of these changes are not slight.

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Richard Stallman]

    Meanwhile, that stuff from O'Reilly is mostly about how to manage a
    commercially sponsored "open source" project in such a way as to maximize
    your ability to extract gratis labor from the "community".

Their philosophy and goals are different from ours, but the actual
work of developing software is the same.  A lot of the work of open
source supporters about how to develop software is useful for
supporters of free software.  The crucial philosophical value of
the free software movement does not concern how we develop Emacs,
but rather the freedom of the users once they get it from us.

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Thomas Lord]

Why is the FSF a union shop?

-t


Richard Stallman wrote:
>     Meanwhile, that stuff from O'Reilly is mostly about how to manage a
>     commercially sponsored "open source" project in such a way as to maximize
>     your ability to extract gratis labor from the "community".
>
> Their philosophy and goals are different from ours, but the actual
> work of developing software is the same.  A lot of the work of open
> source supporters about how to develop software is useful for
> supporters of free software.  The crucial philosophical value of
> the free software movement does not concern how we develop Emacs,
> but rather the freedom of the users once they get it from us.
>
>
>
>
>   

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[David Kastrup]

Thomas Lord <lord@emf.net> writes:

> Richard Stallman wrote:
>>     Meanwhile, that stuff from O'Reilly is mostly about how to manage a
>>     commercially sponsored "open source" project in such a way as to maximize
>>     your ability to extract gratis labor from the "community".
>>
>> Their philosophy and goals are different from ours, but the actual
>> work of developing software is the same.  A lot of the work of open
>> source supporters about how to develop software is useful for
>> supporters of free software.  The crucial philosophical value of
>> the free software movement does not concern how we develop Emacs,
>> but rather the freedom of the users once they get it from us.

> Why is the FSF a union shop?

It most certainly isn't.  It is a charity.  Its charter has never been
secret, its agenda hasn't changed.

So while your entry in the "inflammatory posts over issues solved long
ago" category gets a point for spirit, it really adds nothing new of
interest.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Alan Mackenzie]

Guten Morgen, David!

On Sat, Apr 12, 2008 at 07:49:56AM +0200, David Kastrup wrote:
> Thomas Lord <lord@emf.net> writes:

> > Richard Stallman wrote:
> >>     Meanwhile, that stuff from O'Reilly is mostly about how to manage a
> >>     commercially sponsored "open source" project in such a way as to maximize
> >>     your ability to extract gratis labor from the "community".

> >> Their philosophy and goals are different from ours, but the actual
> >> work of developing software is the same.  A lot of the work of open
> >> source supporters about how to develop software is useful for
> >> supporters of free software.  The crucial philosophical value of
> >> the free software movement does not concern how we develop Emacs,
> >> but rather the freedom of the users once they get it from us.

> > Why is the FSF a union shop?

> It most certainly isn't.  It is a charity.  Its charter has never been
> secret, its agenda hasn't changed.

> So while your entry in the "inflammatory posts over issues solved long
> ago" category gets a point for spirit, it really adds nothing new of
> interest.

Er, David, it was a joke.  Not profound, but subtle enough to raise a
smile on this miserable old hacker before breakfast.  Thanks, Thomas!

Back in the 1960s and 1970s, trade unions in Britain were _very_
insistent on regularly stopping work for a few minutes, during which
drinks made by immersing leaves from India in boiling water would be
drunk.  These intervals were known as "tea breaks".

> David Kastrup, Kriemhildstr. 15, 44793 Bochum

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Nit-picking (was: 23.0.60; M-( and M-) should not be bound in ESC map)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 11 Apr 2008 20:09:56 -0400
> Cc: schwab@suse.de, emacs-pretest-bug@gnu.org
> 
>     Just because a decision was made long ago does not mean that it is the right
>     decision now or even that it was the right decision then.
> 
> 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.

Re: Nit-picking

[Alan Mackenzie]

Hi, Eli!

On Sat, Apr 12, 2008 at 11:40:13AM +0300, Eli Zaretskii wrote:
> > From: Richard Stallman <rms@gnu.org>

> > 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: Nit-picking

[Eli Zaretskii]

[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.

Being constructive [Was: Nit-picking]

[Alan Mackenzie]

Hi, Eli!

On Sat Apr 12, 2008 at 01:30:27PM +0300, Eli Zaretskii wrote:

> [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.

[ .... ]

> > 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.

I think these are the crucial things which are missing from Emacs.
The proprietary source code I deal with seems more and more to have
degenerated into amorphous unstructured messes of, perhaps ~20,000
smallish source files in a massive, straggling directory "structure" of
~2,000 directories.  etags doesn't work well here, with M-. taking many
seconds to find what is often not the right definition.  We need much
stronger code browsing facilities.  This is where other editors score
over Emacs.

Is Klaus Berndl still maintaining ECB?  Surely this is what we need.

> 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?

I think a lot of us, like me, are quietly beavering away at important,
but less exciting things.  Unicode support, for example.  (Well, it
doesn't sound that exciting to me.  ;-)

> 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.

Yes.  I also found those discussions very negative and a waste of time,
even though I certainly contributed my share of the negativity.  I agree
there is far too much bickering on the mailing list, and far too little
positive.

I think it would be psychologically very uplifting for each of us to
post, in a constructive non contentious fashion, what we are working on,
what we are trying to achieve, and so on.  This was exactly what my
previous post was meant to be.  Eli, could you possibly respond again to
that last post with a summary of what _you_ are working on?  We could
develop a very positive constructive thread from this.  :-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Being constructive [Was: Nit-picking]

[Eli Zaretskii]

> Date: Sat, 12 Apr 2008 11:46:11 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Eli, could you possibly respond again to that last post with a
> summary of what _you_ are working on?

There's almost nothing to report, unfortunately.  There are small
improvements of the Windows port to report accurate file ownership and
group, but that's not the kind of significant improvement I had in
mind.

Continuing and perhaps even finishing my bidi display code has been a
pipe dream for several years now, so it's probably not even worth
mentioning.

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Thomas Lord]

Alan Mackenzie wrote:
> Er, David, it was a joke. 

No.  The FSF job postings used to explicitly say:

"The FSF is a union shop" or "FSF employees are unionized"
or words to that effect.   But I've asked what happened off-line
rather than perpetuate confusion here.

-t

Re: Being constructive [Was: Nit-picking]

[Jason Rumney]

Eli Zaretskii wrote:

> Continuing and perhaps even finishing my bidi display code has been a
> pipe dream for several years now, so it's probably not even worth
> mentioning.
>   

A smaller task might be to make use of the functionality of libotf/m17n 
and uniscribe (and any Mac equivalent) to provide bidi support on those 
platforms which offer underlying support.  It will only be as good as 
the support offered by the underlying platform, only available in GUI 
frames, and even then only if Emacs is compiled against those libraries, 
but it is better than the current state of no bidi support at all.  If 
work is started now, I think we can get this in to Emacs 23.  I don't 
know how far emacs-bidi is from completion, but I'm guessing it will be 
at least Emacs 24 material?

RE: 23.0.60; M-( and M-) should not be bound in ESC map

[Drew Adams]

>     Just because a decision was made long ago does not mean 
>     that it is the right decision now or even that it was
>     the right decision then.
> 
> 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.

I did not keep reopening this. I simply submitted a bug report.

You, on the other hand, have succeeded completely in hijacking this thread and
turning it into exactly what you complained about - a useless, abstract,
back-and-forth. This is _your_ discussion, not mine. You are the one wasting
time.

I have not contributed at all to your hijacked discussion (for which you didn't
even bother to change the subject line). I only presented some arguments about
the bug report, and let it go at that. Those arguments, and the bug report, have
successfully been drowned by the tumor you grafted onto the thread. Bravo -
`report-emacs-bug' now results in a flurry of crap.

Re: Being constructive [Was: Nit-picking]

[Eli Zaretskii]

> Date: Sat, 12 Apr 2008 15:14:03 +0100
> From: Jason Rumney <jasonr@gnu.org>
> CC: Alan Mackenzie <acm@muc.de>, emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> 
> > Continuing and perhaps even finishing my bidi display code has been a
> > pipe dream for several years now, so it's probably not even worth
> > mentioning.
> >   
> 
> A smaller task might be to make use of the functionality of libotf/m17n 
> and uniscribe (and any Mac equivalent) to provide bidi support on those 
> platforms which offer underlying support.

In general, I don't believe that we can use an external library for
this, even if we only restrict ourself to displaying bidirectional
text, because bidi considerations must be applied to the basic
iterator machinery that walks Emacs buffers and prepares the glyph
matrices for display.  Too many Emacs features depend on that.

But I could be wrong, so someone should certainly study this
possibility seriously.

> If work is started now, I think we can get this in to Emacs 23.  I
> don't know how far emacs-bidi is from completion, but I'm guessing
> it will be at least Emacs 24 material?

No one is working on the emacs-bidi branch, so it's more like it's
Emacs 240 material...

Re: Being constructive [Was: Nit-picking]

[Eli Zaretskii]

> Date: Sat, 12 Apr 2008 19:51:18 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > If work is started now, I think we can get this in to Emacs 23.  I
> > don't know how far emacs-bidi is from completion, but I'm guessing
> > it will be at least Emacs 24 material?
> 
> No one is working on the emacs-bidi branch, so it's more like it's
> Emacs 240 material...

Of course ``starting work now'' would need Someone(TM) as well, and
that Someone could well try finishing up the bidirectional iterator
code in the emacs-bidi branch.

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[David Kastrup]

Thomas Lord <lord@emf.net> writes:

> Alan Mackenzie wrote:
>> Er, David, it was a joke. 
>
> No.  The FSF job postings used to explicitly say:
>
> "The FSF is a union shop" or "FSF employees are unionized"
> or words to that effect.   But I've asked what happened off-line
> rather than perpetuate confusion here.

I'd be the wrong person to ask, never having been an employee or visitor
of the FSF and frankly not too sure about the terminology, either.  So
if there is something worth asking about (and certainly my comments
don't indicate any knowledge of mine about that), you'd better ask
Richard or the FSF clerk.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Er, David, it was a joke.  Not profound, but subtle enough to raise a
 > smile on this miserable old hacker before breakfast.  Thanks, Thomas!

Ah, but IMO it is no joke, but a moderately profound insight.

Copyleft is quite analogous to union shop in *how* it protects the
folks with sweat equity from those with financial equity in an
enterprise.

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Thomas Lord]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

I suspect, then, that it is still a union shop although I wouldn't
doubt that some of the executives are at a different payscale and
not unionized (e.g., because of their role in fundraising).

Even before it was unionized (back when I was there)
we all got paid scale -- which helped make for a (mostly :-)
pleasant environment.

-t


David Kastrup wrote:
> Thomas Lord <lord@emf.net> writes:
>
>   
>> Alan Mackenzie wrote:
>>     
>>> Er, David, it was a joke. 
>>>       
>> No.  The FSF job postings used to explicitly say:
>>
>> "The FSF is a union shop" or "FSF employees are unionized"
>> or words to that effect.   But I've asked what happened off-line
>> rather than perpetuate confusion here.
>>     
>
> I'd be the wrong person to ask, never having been an employee or visitor
> of the FSF and frankly not too sure about the terminology, either.  So
> if there is something worth asking about (and certainly my comments
> don't indicate any knowledge of mine about that), you'd better ask
> Richard or the FSF clerk.
>
>   


[-- Attachment #2: Type: text/html, Size: 1610 bytes --]

Re: Being constructive [Was: Nit-picking]

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]

On Sat, 12 Apr 2008 11:46:11 +0000
Alan Mackenzie <acm@muc.de> wrote:

> Hi, Eli!
> 
> On Sat Apr 12, 2008 at 01:30:27PM +0300, Eli Zaretskii wrote:
> 
> > [Moving this to emacs-devel, where it belongs.]
> 

[snip]

> I think it would be psychologically very uplifting for each of us to
> post, in a constructive non contentious fashion, what we are working
> on, what we are trying to achieve, and so on.  This was exactly what
> my previous post was meant to be.  Eli, could you possibly respond
> again to that last post with a summary of what _you_ are working on?
> We could develop a very positive constructive thread from this.  :-)
> 

I am working on a Parser Compiler that generates pure elisp parsers from
a macro DSL.

http://www.emacswiki.org/cgi-bin/emacs-en/ParserCompiler

There are many times when a regex has turned into a ad-hoc parser. My
goal is to make those small to medium size parsers compact and declarative.

I think it is very useful considering the Emacs design of using co-processes
for everything external. That's alot of small parsing jobs to hook up
some simple and not so simple tools. 

The architecture of the design is unique: the compiler itself is
programmable reducing the need for call-outs to handle the parts
of the grammar beyond the scope of the usual meta-operators.

There is often a claim that open-source chases head-lights but
this design for better or worse is unique. It's baking on
EmacsWiki while I evaluate it's properties.

For example if PEG and CFG are called grammar "classes" in the logical
sense it will be possible to mix those classes along with a grammar
specific class (user defined) with well defined behavior. That is
unique AFAIK (please cite related works if you know where this has
been done before).

When it is completed I will likely port it to mzScheme to compare
it against the performance of standard designs, and evaluate how
the design is expressed when I don't have to kludge abstraction 
facilities such as co-routines. I will always maintain the elisp 
version though because Emacs is always with me :)

It won't hit 0.1.0 until left-recursion is solved eliminating the
possibility of user defined infinite loops.

Currently it works well with right-recursive grammars, builds canonical
AST trees, and the code emitted looks like I wrote it by hand - the back-end
folds emitted elisp to take advantage of special forms that can be shared.

When it hit's 0.1.0 I'll post a mention again and submit it to ELPA.

It's my thank-you note to the Emacs community. If some-one wants to write
a counter thank-you note Elisp TCO is at the top of my elisp wish-list.

Cheers,
Mike Mattie

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 23.0.60; M-( and M-) should not be bound in ESC map

[Richard Stallman]

    > 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.

    I did not keep reopening this.

I didn't say that you did.

				   I simply submitted a bug report.

Your bug report reopened a question about Emacs's interface that we
decided many years ago.  That one message, reopening one question,
would not be a problem.  But people have tried to reopen many
different questions that were decided long ago, and that adds up to a
big time drain.