position on changing defaults?

position on changing defaults?

[Dan Nicolaescu]

Hi,

It would be interesting to know the new maintainers opinion on changing
some of the current default settings.

One type of changes would be to make emacs more similar to other current
desktop applications.

Another type would be to provide more functionality by default.

It seems that doing the above two things would make emacs more easy to
use for a larger number of people.  Emacs has a lot of functionality
available, but it's hard to find out about it.  Making it easier to use
some of the available functionality helps a log of users.

One reason to ask if there's a policy in this direction is that
absolutely ANY change will make someone scream bloody murder.  (just
remember that there was resistance even to turning on
global-font-lock-mode by default, which is something that the vast
majority of users want).  And people that oppose change tend to be
extremely vocal.

Obviously any change request has to be judged on it's own merit, but
knowing if there's a clear direction would help.

Here are some examples of changes that could be made:
- transient-mark, selection with Shift-arrow keys

- show-paren-mode on by default
- iswitchb-mode on by default
- bind ibuffer to C-x C-b
- hide-ifdef-mode on by default for C/C++/objc
- flyspell-mode on by default for text-mode

Note that the above are just examples of things that can be done, they
are not given now in order to start discussing doing them.  That can be
done later in separate threads (unless the maintainers want to approve
any of them on the spot :-)

Can you (Stefan and Yidong) please state your opinion about this?

Thanks

        --dan

Re: position on changing defaults?

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> Here are some examples of changes that could be made:
> - transient-mark, selection with Shift-arrow keys
>
> - show-paren-mode on by default
> - iswitchb-mode on by default
> - bind ibuffer to C-x C-b
> - hide-ifdef-mode on by default for C/C++/objc
> - flyspell-mode on by default for text-mode

I think most of those are fairly innocuous, but iswitchb-mode is not --
it changes a familiar and simple interface to something radically
different that will very likely confuse newcomers and annoy old-timers.
Making that the default would be a mistake.

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: position on changing defaults?

[Miles Bader]

BTW, the one of those which I consider a no-brainer is `ibuffer' --
though it has many more useful features than `list-buffers', the
interface seems almost 100% compatible, so I don't think it would cause
any problems (in fact I suspect many people would not even realize it
had replace list-buffers if nobody told them).

There are a few random interface tweaks that might be done to ibuffer,
e.g. using a header-line for the column headings, but I suspect they're
almost trivial.

-Miles

-- 
Dictionary, n.  A malevolent literary device for cramping the growth of
a language and making it hard and inelastic. This dictionary, however,
is a most useful work.

Re: position on changing defaults?

[Juanma Barranquero]

>  There are a few random interface tweaks that might be done to ibuffer,
>  e.g. using a header-line for the column headings, but I suspect they're
>  almost trivial.

ibuffer already uses the header line to show the active filters; try

  M-x ibuffer <RET> / m <RET>

(though I agree it would make more sense to use it for column headings).

             Juanma

RE: position on changing defaults?

[Drew Adams]

> BTW, the one of those which I consider a no-brainer is `ibuffer' --
> though it has many more useful features than `list-buffers', the
> interface seems almost 100% compatible, so I don't think it 
> would cause any problems (in fact I suspect many people would
> not even realize it had replace list-buffers if nobody told them).
> 
> There are a few random interface tweaks that might be done to ibuffer,
> e.g. using a header-line for the column headings, but I suspect
> they're almost trivial.

I don't agree that ibuffer subsumes list-buffers, and I don't want ibuffer
to replace list-buffers as the binding of C-x C-b.

I would prefer that we discuss some of the features that you or others like
from ibuffer, and we then adapt list-buffers to include those features that
we agree on. list-buffers has a better UI, IMO. If we want some of the
ibuffer features, then list-buffers is the place to add them. I'm not
against merging the two, keeping the best of each.

And this is not the thread for such a discussion.

Re: position on changing defaults?

[Stefan Monnier]

> I don't agree that ibuffer subsumes list-buffers, and I don't want ibuffer
> to replace list-buffers as the binding of C-x C-b.

I added many months ago the following entry in etc/TODO

** Merge ibuffer.el and buff-menu.el.
   More specifically do what's needed to make ibuffer.el the default,
   or just an extension of buff-menu.el.


-- Stefan

RE: position on changing defaults?

[Drew Adams]

> > I don't agree that ibuffer [currently] subsumes list-buffers,
> > and I don't want ibuffer to replace list-buffers as the
> > binding of C-x C-b.
> 
> I added many months ago the following entry in etc/TODO
> 
> ** Merge ibuffer.el and buff-menu.el.
>    More specifically do what's needed to make ibuffer.el the default,
>    or just an extension of buff-menu.el.

FWIW, I'm OK with the last part, "just an extention of buff-menu.el",
assuming that buff-menu.el features are not lost in the process.

Re: position on changing defaults?

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
>> There are a few random interface tweaks that might be done to ibuffer,
>> e.g. using a header-line for the column headings, but I suspect
>> they're almost trivial.
>
> I don't agree that ibuffer subsumes list-buffers.

Please give details; AFAICS, they're pretty darn-near identical.

-Miles

-- 
`The suburb is an obsolete and contradictory form of human settlement'

RE: position on changing defaults?

[Drew Adams]

> > Here are some examples of changes that could be made:
> > - transient-mark, selection with Shift-arrow keys
> >
> > - show-paren-mode on by default
> > - iswitchb-mode on by default
> > - bind ibuffer to C-x C-b
> > - hide-ifdef-mode on by default for C/C++/objc
> > - flyspell-mode on by default for text-mode
> 
> I think most of those are fairly innocuous, but iswitchb-mode 
> is not --
> it changes a familiar and simple interface to something radically
> different that will very likely confuse newcomers and annoy 
> old-timers.
> Making that the default would be a mistake.

So are we discussing these now? Dan said no - and I agree.

If we were discussing them, then my vote would be `no' to iswitchb-mode and
ibuffer as C-x C-b.

Re: position on changing defaults?

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> One reason to ask if there's a policy in this direction is that
> absolutely ANY change will make someone scream bloody murder.  (just
> remember that there was resistance even to turning on
> global-font-lock-mode by default, which is something that the vast
> majority of users want).  And people that oppose change tend to be
> extremely vocal.

You certainly sport a selective memory.  The reason
global-font-lock-mode was not turned on by default was that there were
large performance problems in a number of cases.  Those were addressed
by and by, and when global-font-lock-mode was in a shape where it would
not obliterate the usability of Emacs for large pretty standard use
cases, then it was finally adopted.

It would not have been an improvement if global-font-lock-mode would
have been made the default before this had been tackled satisfactorily.
Having the font-lock proponents actually work hard on making the code
acceptable to those who don't crave font-lock-mode that much but need
tolerable performance for large cases: this has been very important and
contributed to the quality of Emacs code.

We don't want to get into the situation where the editor gets bogged
down by a legacy of great half-baked and partly unmaintained features.
This is to some degree what I perceive as having happened with XEmacs.
Getting features to a full-quality state before enabling them is only
sane.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: position on changing defaults?

[Richard Stallman]

    It would not have been an improvement if global-font-lock-mode would
    have been made the default before this had been tackled satisfactorily.
    Having the font-lock proponents actually work hard on making the code
    acceptable to those who don't crave font-lock-mode that much but need
    tolerable performance for large cases: this has been very important and
    contributed to the quality of Emacs code.

Well said.

Re: position on changing defaults?

[Bastien]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Obviously any change request has to be judged on it's own merit, but
> knowing if there's a clear direction would help.
>
> Here are some examples of changes that could be made:
> 
> - flyspell-mode on by default for text-mode

I think this shouldn't be on by default and I doubt most users are
turning it on anyway.

This would slow the typing process in text-mode, which is a very common
mode.  It would also lead to configuration problems: what would be the
reasonable default for `ispell-dictionary' and `ispell-program-name'?

-- 
Bastien

Re: position on changing defaults?

[Stefan Monnier]

> It would be interesting to know the new maintainers opinion on changing
> some of the current default settings.

I don't necessarily have the same preferences as Richard, so there might
be some defaults which I may be willing to consider changing, but I tend
to agree with David that many of the features provided in Emacs are not
turned on by default mostly because they're not polished enough.

> - transient-mark,

I'd like to make transient-mark-mode enabled by default, although the
details of how to do it aren't clear yet.  The way I see it happen:
provide a new setting of transient-mark-mode which makes all mark-*
commands enable temporary-transient-mark-mode.  In most cases, the only
difference between this and plain old transient-mark-mode will be the
need to use C-SPC C-SPC rather than C-SPC, and C-u C-x C-x rather than
C-x C-x.

>   selection with Shift-arrow keys

Not sure about this one.  I've been using cua-selection-mode (well,
enabling rather than using, really) for a little while now and
I basically don't notice it, so it looks like it might be worth
enabling.  But I think for it to be enabled by default, we may want to
integrate it more tightly so that it doesn't need post-command-hook,
for example.

> - show-paren-mode on by default

Never liked it.  Is it really that popular?

> - iswitchb-mode on by default

I'd rather improve the general completion mechanism, than only improve
it for buffer selection.

> - bind ibuffer to C-x C-b

See other email.

> - hide-ifdef-mode on by default for C/C++/objc

What does it provide by default (other than hiding #if 0...#endif)?
Last I checked I got the impression that this package requires
configuration to be useful, so enabling it by default doesn't help much.
Did I miss something?

> - flyspell-mode on by default for text-mode

I indeed have it on in text-mode (and programming modes as well, as
a matter of fact), but I haven't given any thought to enabling it
by default.  I think it might be a bit too brittle currently to be
enabled by default: it usually works just fine, but I've had problems
with it every once in a while.


        Stefan

Re: position on changing defaults?

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >   selection with Shift-arrow keys
  > 
  > Not sure about this one.  I've been using cua-selection-mode (well,
  > enabling rather than using, really) for a little while now and
  > I basically don't notice it, so it looks like it might be worth
  > enabling.  But I think for it to be enabled by default, we may want to
  > integrate it more tightly so that it doesn't need post-command-hook,
  > for example.

That's why I said "selection with Shift-arrow keys", not
cua-selection-mode... 

  > > - show-paren-mode on by default
  > 
  > Never liked it.  Is it really that popular?

That's hard to measure, isn't it?  In _my_ experience it is.
Or more likely: blink-matching-open is unpopular, and in general
blinking cursor is downright hated by many people. 


  > > - iswitchb-mode on by default
  > 
  > I'd rather improve the general completion mechanism, than only improve
  > it for buffer selection.

That would be great too.  But we also need to consider the fact iswitch
is here now, it works and is useful, improvements to completion are not
available yet (or even in the works?).

  > > - hide-ifdef-mode on by default for C/C++/objc
  > 
  > What does it provide by default (other than hiding #if 0...#endif)?
  > Last I checked I got the impression that this package requires
  > configuration to be useful, so enabling it by default doesn't help much.
  > Did I miss something?

It is useful without configuration too, it can be used to hide/show
ifdef blocks.  It is even more useful if you tell it what variables are #defined.
It does not get in the way if not used.

  > > - flyspell-mode on by default for text-mode
  > 
  > I indeed have it on in text-mode (and programming modes as well, as
  > a matter of fact), 

Same here.

Another related point: flyspell-prog-mode is even more obscure than
flyspell.  How do we make it's availability more obvious to programmers?

  > but I haven't given any thought to enabling it by default.  I think
  > it might be a bit too brittle currently to be enabled by default: it
  > usually works just fine, but I've had problems with it every once in
  > a while.

I don't share that experience... How about we try it on and see if any
problems show up? There's plenty of time to disable it again until the
next release. 

Re: position on changing defaults?

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > I'd rather improve the general completion mechanism, than only improve
>   > it for buffer selection.
>
> That would be great too.  But we also need to consider the fact iswitch
> is here now, it works and is useful

.... and is a completely and utterly different interface, one which is
hated by many, and arguably is extremely confusing for newbies.  You
can't just drop in such a radical and controversial change by saying
"oh, but it's here now, and it works..."

I think a rather more evolutionary approach to improving to the general
completion interface is much better, and safer.

-Miles

-- 
Come now, if we were really planning to harm you, would we be waiting here,
 beside the path, in the very darkest part of the forest?

Re: position on changing defaults?

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > I'd rather improve the general completion mechanism, than only improve
  > >   > it for buffer selection.
  > >
  > > That would be great too.  But we also need to consider the fact iswitch
  > > is here now, it works and is useful
  > 
  > .... and is a completely and utterly different interface, one which is
  > hated by many, and arguably is extremely confusing for newbies.  

We must have different experiences: all the newbies that I've shown
iswitchb loved it.  That's the main reason to propose this.

Re: position on changing defaults?

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > .... and is a completely and utterly different interface, one which is
>   > hated by many, and arguably is extremely confusing for newbies.  
>
> We must have different experiences: all the newbies that I've shown
> iswitchb loved it.  That's the main reason to propose this.

I'm not saying that many people don't find it useful, simply that at
first glance, if you aren't expecting it, it can be rather ... daunting.
Of course, I suppose it's somewhat less so when one is given a personal
introduction...

There are many great features in Emacs which we probably don't want to
spring on the unprepared.

-Miles

-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: position on changing defaults?

[Dan Nicolaescu]

Miles Bader <miles.bader@necel.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > .... and is a completely and utterly different interface, one which is
  > >   > hated by many, and arguably is extremely confusing for newbies.  
  > >
  > > We must have different experiences: all the newbies that I've shown
  > > iswitchb loved it.  That's the main reason to propose this.
  > 
  > I'm not saying that many people don't find it useful, simply that at
  > first glance, if you aren't expecting it, it can be rather ... daunting.
  > Of course, I suppose it's somewhat less so when one is given a personal
  > introduction...

In this case the personal introduction was limited to: 
"Do M-x iswitchb-mode RET and now try C-x b".

Can we generalize based on this? Maybe, maybe not, but it might be worth
a try.

Re: position on changing defaults?

[Richard Stallman]

ibuffer's UI was never subjected to the scrutiny appropriate for
changes in standard Emacs interfaces.  Someone said he wanted to
install it as a powerful optional alternative, and since (from the
description) it did seem powerful, I said ok without paying much
attention.  I never tried using it, and I didn't try to learn
just what it did.

As an optional alternative, it did not need any more scrutiny than
that.  Some people use it and like it, and it can't bother anyone
else.

Whenever people wanted to enhance ibuffer, I didn't really look at
what was being proposed.  If the people who used ibuffer were happy
with the enhancements, that was good enough.  I wasn't one of them,
and I was busy.

A proposal to change the way the buffer list works by default is
another matter.  Each detail of that should receive careful thought.
Just because ibuffer does X and Y and Z, that doesn't mean that if we
make X the default then we should make Y and Z the default too.  We
might want X with Y' instead of Y, and not Z at all.

*Buffer List* is described in the Emacs Manual.  We have no Texinfo
documentation for ibuffer.  Part of making any ibuffer features the
default would be writing them up for the manual.  Writing a clear
description may not be easy, and not everyone here has the skill to
write good documentation in English.  Having good text to put in the
manual should be a prerequisite for making it the default (if we want
to).

Trying to write a clear description of these features could a crucial
test of whether they would be a good default.  If the proposed new
documentation is harder to understand than the current documentation
of the current featrues, that suggests the change should not be mde.

Perhaps it would be good to adopt the general policy that proposals
for changes in parts of the Emacs UI that are documented in the Emacs
Manual should come with the corresponding change in the manual.

Re: position on changing defaults?

[Richard Stallman]

    .... and is a completely and utterly different interface, one which is
    hated by many, and arguably is extremely confusing for newbies.  You
    can't just drop in such a radical and controversial change by saying
    "oh, but it's here now, and it works..."

That is right.

Re: position on changing defaults?

[Juri Linkov]

>   > > - show-paren-mode on by default
>   >
>   > Never liked it.  Is it really that popular?
>
> That's hard to measure, isn't it?  In _my_ experience it is.
> Or more likely: blink-matching-open is unpopular, and in general
> blinking cursor is downright hated by many people.

I always use M-( to insert a balanced pair of open and close
parentheses, so I never see that blink-matching-open jumping cursor.

When there is a need to see a matching parenthesis, this is possible by
using commands that move point on balanced expressions like forward-sexp.
Even though show-paren-mode doesn't require such point movements, it is
annoying when a matching parenthesis is highlighted in inappropriate
places like e.g. when displaying a group of completions in parenthesis
in the minibuffer, etc.

>   > > - iswitchb-mode on by default
>   >
>   > I'd rather improve the general completion mechanism, than only improve
>   > it for buffer selection.
>
> That would be great too.  But we also need to consider the fact iswitch
> is here now, it works and is useful, improvements to completion are not
> available yet (or even in the works?).

I agree with Stefan that the general completion mechanism should be
uniform among all minibuffer types, not only for switching between
buffers, and we should make such improvements to the general mechanism.

>   > > - flyspell-mode on by default for text-mode
>   >
>   > I indeed have it on in text-mode (and programming modes as well, as
>   > a matter of fact),
>
> Same here.
>
> Another related point: flyspell-prog-mode is even more obscure than
> flyspell.  How do we make it's availability more obvious to programmers?

Like all other features, to make them more available to users, we should
add more commands to the main menu.  Most newbies tend using this menu
where they can discover hidden features.

>   > but I haven't given any thought to enabling it by default.  I think
>   > it might be a bit too brittle currently to be enabled by default: it
>   > usually works just fine, but I've had problems with it every once in
>   > a while.
>
> I don't share that experience... How about we try it on and see if any
> problems show up? There's plenty of time to disable it again until the
> next release.

I think that before enabling flyspell-mode by default we should improve
the language detection mechanism, so it will set the correct ispell
dictionary in every buffer where flyspell-mode will be enabled.
Otherwise, it would be annoying to see most words in buffers
highlighted in red.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: position on changing defaults?

[Dan Nicolaescu]

Juri Linkov <juri@jurta.org> writes:

  > >   > > - show-paren-mode on by default
  > >   >
  > >   > Never liked it.  Is it really that popular?
  > >
  > > That's hard to measure, isn't it?  In _my_ experience it is.
  > > Or more likely: blink-matching-open is unpopular, and in general
  > > blinking cursor is downright hated by many people.
  > 
  > I always use M-( to insert a balanced pair of open and close
  > parentheses, so I never see that blink-matching-open jumping cursor.
  >
  > When there is a need to see a matching parenthesis, this is possible by
  > using commands that move point on balanced expressions like forward-sexp.
  > Even though show-paren-mode doesn't require such point movements, it is
  > annoying when a matching parenthesis is highlighted in inappropriate
  > places like e.g. when displaying a group of completions in parenthesis
  > in the minibuffer, etc.

That's a minor disadvantage to the big advantage of easily finding the
matching parenthesis. 

  > >   > > - flyspell-mode on by default for text-mode
  > >   >
  > >   > I indeed have it on in text-mode (and programming modes as well, as
  > >   > a matter of fact),
  > >
  > > Same here.
  > >
  > > Another related point: flyspell-prog-mode is even more obscure than
  > > flyspell.  How do we make it's availability more obvious to programmers?
  > 
  > Like all other features, to make them more available to users, we should
  > add more commands to the main menu.  Most newbies tend using this menu
  > where they can discover hidden features.

Flyspell is pretty well hidden in the Tools / Spell Checking menu.
Where would flyspell-prog-mode go? Maybe in the major mode menu? We'd
have to add it by hand to all the relevant major modes.  
Which is doable.  But what if a user wants to turn on flyspell-prog-mode
by default for all programming languages? The only way to do that now is
to add a bunch of `add-hook's in .emacs
It would be nice to have a generic solution for all these (no idea what
that might be...)

Re: position on changing defaults?

[Juri Linkov]

>   > >   > > - flyspell-mode on by default for text-mode
>   > >   >
>   > >   > I indeed have it on in text-mode (and programming modes as well, as
>   > >   > a matter of fact),
>   > >
>   > > Same here.
>   > >
>   > > Another related point: flyspell-prog-mode is even more obscure than
>   > > flyspell.  How do we make it's availability more obvious to programmers?
>   >
>   > Like all other features, to make them more available to users, we should
>   > add more commands to the main menu.  Most newbies tend using this menu
>   > where they can discover hidden features.
>
> Flyspell is pretty well hidden in the Tools / Spell Checking menu.

In some programs the menu item to turn on/off an analogy of flyspell is
in the context menu invoked by mouse-3.

> Where would flyspell-prog-mode go? Maybe in the major mode menu? We'd
> have to add it by hand to all the relevant major modes.
> Which is doable.  But what if a user wants to turn on flyspell-prog-mode
> by default for all programming languages? The only way to do that now is
> to add a bunch of `add-hook's in .emacs
> It would be nice to have a generic solution for all these (no idea what
> that might be...)

Maybe the global flyspell-prog-mode should have an user option with
a list of modes where it is on?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: position on changing defaults?

[René Kyllingstad]

* Juri Linkov:
> >   > >   > > - flyspell-mode on by default for text-mode
> >   > >   >
> >   > >   > I indeed have it on in text-mode (and programming modes as
> >   > >   > well, as a matter of fact),
> >   > >
> >   > > Same here.
> >   > >
> >   > > Another related point: flyspell-prog-mode is even more obscure
> >   > > than flyspell.  How do we make it's availability more obvious to
> >   > > programmers?
> >   >
> >   > Like all other features, to make them more available to users, we
> >   > should add more commands to the main menu.  Most newbies tend using
> >   > this menu where they can discover hidden features.
> >
> > Flyspell is pretty well hidden in the Tools / Spell Checking menu.
>  
>  In some programs the menu item to turn on/off an analogy of flyspell is
>  in the context menu invoked by mouse-3.

Having that on the context menu for the misspelled word would be great!

If that menu offered to disable it for good all the better (with a "Use
Tools -> Spell Checking to enable" message in the echo area when chosen).

I'd love if there were mouse-3 context menu's for all visual indications in
Emacs, to help with learning features, and as the main way access features
I use rarely.  I'm getting older and less interested in remembering key
bindings for everything.

For example, it would be great if outline-minor-mode offered a mouse-3
menu to Show Entry and Show All on the "...".  (I would also love to have
mouse-1 invoke Show Entry, but I guess that is a separate can of worms.)


-- René 

Re: position on changing defaults?

[Stefan Monnier]

> Which is doable.  But what if a user wants to turn on flyspell-prog-mode
> by default for all programming languages? The only way to do that now is
> to add a bunch of `add-hook's in .emacs
> It would be nice to have a generic solution for all these (no idea what
> that might be...)

One solution is to introduce a new major mode `prog-mode' and then
make all other programming modes inherit from it.


        Stefan

Re: position on changing defaults?

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > Which is doable.  But what if a user wants to turn on flyspell-prog-mode
  > > by default for all programming languages? The only way to do that now is
  > > to add a bunch of `add-hook's in .emacs
  > > It would be nice to have a generic solution for all these (no idea what
  > > that might be...)
  > 
  > One solution is to introduce a new major mode `prog-mode' and then
  > make all other programming modes inherit from it.

Sounds good.  Just wondering if we could get all modes to do that, some
still want to be compatible with emacs-20... 

Re: position on changing defaults?

[Stefan Monnier]

>> > Which is doable.  But what if a user wants to turn on flyspell-prog-mode
>> > by default for all programming languages? The only way to do that now is
>> > to add a bunch of `add-hook's in .emacs
>> > It would be nice to have a generic solution for all these (no idea what
>> > that might be...)
>> 
>> One solution is to introduce a new major mode `prog-mode' and then
>> make all other programming modes inherit from it.

> Sounds good.  Just wondering if we could get all modes to do that, some
> still want to be compatible with emacs-20... 

We could get al the modes bundled with Emacs to do that.  For the rest,
clearly we have no control over them,


        Stefan

Re: position on changing defaults?

[Xavier Maillard]

   > Which is doable.  But what if a user wants to turn on flyspell-prog-mode
   > by default for all programming languages? The only way to do that now is
   > to add a bunch of `add-hook's in .emacs
   > It would be nice to have a generic solution for all these (no idea what
   > that might be...)

   One solution is to introduce a new major mode `prog-mode' and then
   make all other programming modes inherit from it.

I like this solution.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: position on changing defaults?

[Stefan Monnier]

> Even though show-paren-mode doesn't require such point movements, it is
> annoying when a matching parenthesis is highlighted in inappropriate
> places like e.g. when displaying a group of completions in parenthesis
> in the minibuffer, etc.

Sounds like a bug.


        Stefan

Re: position on changing defaults?

[Juri Linkov]

>> Even though show-paren-mode doesn't require such point movements, it is
>> annoying when a matching parenthesis is highlighted in inappropriate
>> places like e.g. when displaying a group of completions in parenthesis
>> in the minibuffer, etc.
>
> Sounds like a bug.

I know no good way to configure contexts where matching parens should be
highlighted and where not.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: position on changing defaults?

[Stefan Monnier]

>>> Even though show-paren-mode doesn't require such point movements, it is
>>> annoying when a matching parenthesis is highlighted in inappropriate
>>> places like e.g. when displaying a group of completions in parenthesis
>>> in the minibuffer, etc.
>> 
>> Sounds like a bug.

> I know no good way to configure contexts where matching parens should be
> highlighted and where not.

IIUC the circumstance you're talking about, the highlighted
parenthesized text is not really part of the (mini)buffer, so it's
a bug.  That doesn't mean that the fix is easy.


        Stefan

Re: position on changing defaults?

[Juri Linkov]

>>>> Even though show-paren-mode doesn't require such point movements, it is
>>>> annoying when a matching parenthesis is highlighted in inappropriate
>>>> places like e.g. when displaying a group of completions in parenthesis
>>>> in the minibuffer, etc.
>>>
>>> Sounds like a bug.
>
>> I know no good way to configure contexts where matching parens should be
>> highlighted and where not.
>
> IIUC the circumstance you're talking about, the highlighted
> parenthesized text is not really part of the (mini)buffer, so it's
> a bug.  That doesn't mean that the fix is easy.

For instance, when both `show-paren-mode' and `iswitchb' are enabled,
then `C-x b' displays the minibuffer

iswitch {*scratch*,*Messages*}

where both curly brackets get highlighted.  iswitchb.el implements
displaying this text by inserting it to the minibuffer, so in this sense
this text is part of the minibuffer, and I see no way not to highlight
matching brackets in this case.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: position on changing defaults?

[Richard Stallman]

Maybe we should poll the users about show-paren-mode.

Polling the users does not mean asking them to "vote" and counting the
votes.  Instead we ask them to explain why they like or dislike about
the various options.  That way we learn how they affect people, and
with that, we can make a good decision.

Re: position on changing defaults?

[Xavier Maillard]

   Maybe we should poll the users about show-paren-mode.

I am not in favor of the show-paren-mode: I do not like all that
"bling bling" features.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: position on changing defaults?

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > Maybe we should poll the users about show-paren-mode.
  > 
  > Polling the users does not mean asking them to "vote" and counting the
  > votes.  Instead we ask them to explain why they like or dislike about
  > the various options.  That way we learn how they affect people, and
  > with that, we can make a good decision.


Please do that.  How many questions can we ask in a single poll?

Re: position on changing defaults?

[Richard Stallman]

    Please do that.  How many questions can we ask in a single poll?

A poll can ask several related questions if that seems useful, but it
should stick to one issue.  If there is more than one issue it is
better to do more than one poll.

Re: position on changing defaults?

[Stefan Monnier]

>> Never liked it.  Is it really that popular?
> That's hard to measure, isn't it?  In _my_ experience it is.
> Or more likely: blink-matching-open is unpopular, and in general
> blinking cursor is downright hated by many people. 

Never heard anyone complain about blink-matching-open.  I myself find it
great: it's very lightweight yet effective.  I find show-paren-mode too
much in-your-face.

> improvements to completion are not available yet (or even in the works?).

I've been using such a thing for years ;-)
[ But admittedly, it's not quite ready for installation. ]


        Stefan

RE: position on changing defaults?

[Drew Adams]

> >> Never liked it.  Is it really that popular?
> > That's hard to measure, isn't it?  In _my_ experience it is.
> 
> Never heard anyone complain about blink-matching-open.  I 
> myself find it great: it's very lightweight yet effective.
> I find show-paren-mode too much in-your-face.

I like both show-paren-mode and blink-matching-open. Show-paren-mode shows
the matching paren all the time; blink-matching-open shows it only when you
add a closing paren.

But I use a subtle face for show-paren-mode, so it's not at all in-my-face.
When a face background is only slightly highlighted wrt the frame, it's
noticeable only if you look for it, which you do only when you want it. Find
a face that is noticeable, but not too noticeable, wrt your default
background etc. YMMV.

FWIW, I see no need to change any defaults in this regard. Someone who
programs in Lisp (where paren matching is important) will have no trouble
finding and customizing these things.

Re: position on changing defaults?

[Dan Nicolaescu]

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

  > FWIW, I see no need to change any defaults in this regard. Someone who
  > programs in Lisp (where paren matching is important) will have no trouble
  > finding and customizing these things.

Huh?  AFAIR many languages other than lisp use parens quite a bit... 

RE: position on changing defaults?

[Drew Adams]

>   > FWIW, I see no need to change any defaults in this 
>   > regard. Someone who programs in Lisp (where paren matching
>   > is important) will have no trouble finding and customizing
>   > these things.
> 
> Huh?  AFAIR many languages other than lisp use parens quite a bit... 

"Huh?"  (What is that, the latest way to put people down? HUH? Whaddaya,
stupid? Nuts? HUH? ;-))

Dan, I don't care whether you change the default or not. As I said, I use
show-parent-mode, personally. I see no need to change the default, but I
don't care if you do change it. Fiddle away.

But yes, paren matching is more important to Lisp than to most other
languages. And yes, paren matching can also be important to other languages,
besides Lisp.

There is nevertheless a qualitative difference between Lisp and most other
languages in this regard, in particular because its data and program
syntaxes are the same (and use parens).

Try editing Lisp code without automatic indenting or paren matching. It's no
accident that those features were developed first for Lisp. It's a nightmare
to edit Lisp without some such aids. The same is not true to the same degree
for most other languages. 

I programmed in Fortran for years without paren matching, and I never would
have dreamed that such a feature could be important to coding. If you had
proposed to me back then that Fortran code have its matching parens
highlighted I would have said, "Huh?".

Re: position on changing defaults?

[Alan Mackenzie]

On Thu, Mar 06, 2008 at 09:35:43AM -0800, Drew Adams wrote:

> Dan, I don't care whether you change the default or not. As I said, I
> use show-parent-mode, personally. I see no need to change the default,
> but I don't care if you do change it. Fiddle away.

Uhu<rot13>?  Remember, Drew, some Emacs users are ophans.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: position on changing defaults?

[Drew Adams]

> Uhu<rot13>?  Remember, Drew, some Emacs users are ophans.  ;-)

V qba'g trg vg.

uggc://ra.jvxvcrqvn.bet/jvxv/Bcuna? Rfgvzngrq Cebcurg?

Re: position on changing defaults?

[Alan Mackenzie]

On Thu, Mar 06, 2008 at 12:40:22PM -0800, Drew Adams wrote:
> > Uhu<rot13>?  Remember, Drew, some Emacs users are ophans.  ;-)

> V qba'g trg vg.

The said orphans might be unable to use the full functionality of
show-parent-mode.

> uggc://ra.jvxvcrqvn.bet/jvxv/Bcuna? Rfgvzngrq Cebcurg?

Tngrshy Qrnq?

-- 
Alan.

RE: position on changing defaults?

[Drew Adams]

> The said orphans might be unable to use the full functionality of
> show-parent-mode.

OK, I get it. Mea culpa typo.

Re: position on changing defaults?

[Xavier Maillard]

   FWIW, I see no need to change any defaults in this regard. Someone who
   programs in Lisp (where paren matching is important) will have no trouble
   finding and customizing these things.

I agree with that statement, it is really easy to totally disable
a feature that one dislikes ;)

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: position on changing defaults?

[Johan Bockgård]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Never heard anyone complain about blink-matching-open.  I myself find
> it great: it's very lightweight yet effective.  I find show-paren-mode
> too much in-your-face.

I find blink-matching-open quite annoying.  OTOH, show-paren-mode is
among the very first things I turn on in an uncustomized Emacs.
(Actually I normally use mic-paren.el; the feature I miss in paren.el is
that when point is directly between two parens, it can highlight both
the preceding and following matching parens.)

-- 
Johan Bockgård

Re: position on changing defaults?

[Mathias Dahl]

>  I find blink-matching-open quite annoying.  OTOH, show-paren-mode is
>  among the very first things I turn on in an uncustomized Emacs.
>  (Actually I normally use mic-paren.el; the feature I miss in paren.el is
>  that when point is directly between two parens, it can highlight both
>  the preceding and following matching parens.)

I agree. I have recently started to use show-paren-mode and like it
better than blink-matching-open. Previously I always removed a parent
and then added it again, just to see where the matching one blinked.

Re: position on changing defaults?

[Juri Linkov]

>>  I find blink-matching-open quite annoying.  OTOH, show-paren-mode is
>>  among the very first things I turn on in an uncustomized Emacs.
>>  (Actually I normally use mic-paren.el; the feature I miss in paren.el is
>>  that when point is directly between two parens, it can highlight both
>>  the preceding and following matching parens.)
>
> I agree. I have recently started to use show-paren-mode and like it
> better than blink-matching-open. Previously I always removed a parent
> and then added it again, just to see where the matching one blinked.

I use C-left and C-right to quickly find the matching paren when necessary,
and can do this faster than automatic highlighting by show-paren-mode :)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: position on changing defaults?

[Xavier Maillard]

   >> Never liked it.  Is it really that popular?
   > That's hard to measure, isn't it?  In _my_ experience it is.
   > Or more likely: blink-matching-open is unpopular, and in general
   > blinking cursor is downright hated by many people. 

   Never heard anyone complain about blink-matching-open.  I myself find it
   great: it's very lightweight yet effective.  I find show-paren-mode too
   much in-your-face.

This is exactly the reason why I also prefer using
blink-matching-open rather than the show-paren-mode. What's more,
I usually insert paired parenthesis and with the help of paredit,
writing *lisp code is really a pleasure.

By the way, are there plans to put paredit-el into the official
GNU Emacs distribution at some point ?

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: position on changing defaults?

[Richard Stallman]

    That would be great too.  But we also need to consider the fact iswitch
    is here now, it works and is useful, improvements to completion are not
    available yet (or even in the works?).

I have never tried iswitchb.  What incompatible changes would I notice
if this change were made?

Re: position on changing defaults?

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> I have never tried iswitchb.  What incompatible changes would I notice
> if this change were made?

Hmm, first thing I noticed was that when I did "C-x b", the minibuffer
expanded to half my screen size, and was filled with what initially
appeared to be line-noise...

-Miles

-- 
Justice, n. A commodity which in a more or less adulterated condition the
State sells to the citizen as a reward for his allegiance, taxes and personal
service.

Re: position on changing defaults?

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     That would be great too.  But we also need to consider the fact iswitch
  >     is here now, it works and is useful, improvements to completion are not
  >     available yet (or even in the works?).
  > 
  > I have never tried iswitchb.  What incompatible changes would I notice
  > if this change were made?

Nothing fundamentally incompatible, but there are differences in which
C-x b  works.  The essence is that you don't have to press TAB to get
completions, they happen as you type.

When doing C-x b it will start by showing in the minibuffer a list of
the buffers.  When typing something the list will shrink to the buffers
that match the substring already typed (or grow when you delete
something that you typed).  You can go forward/backward in the list with C-s/C-r. 
TAB still works.
These are the basics.  Please give it a try.

Re: position on changing defaults?

[Richard Stallman]

    When doing C-x b it will start by showing in the minibuffer a list of
    the buffers.

I think I would find that very annoying.  I tend to have 50 buffers or
more.

I don't think this should be the default, not just for C-x b,
and not for anything else either.

Re: position on changing defaults?

[Gregory Collins]

Richard Stallman <rms@gnu.org> writes:

>     When doing C-x b it will start by showing in the minibuffer a list of
>     the buffers.
>
> I think I would find that very annoying.  I tend to have 50 buffers or
> more.
>
> I don't think this should be the default, not just for C-x b,
> and not for anything else either.

I think you should try the function out before being so eager to dismiss
it. Iswitchb-mode (and the very similar ido-mode, which I prefer) can
save a lot of keystrokes; e.g. I can call up my "*haskell*" buffer more
quickly by typing "C-x b ask RET", or my "*Summary list.emacs*" buffer
by typing "C-x b .e RET". Stock switch-to-buffer will only do completion
on prefixes, and then only when you hit "TAB".

The reason that it displays a (partial, btw) list of the buffers is so
that you can interactively see how the list is being narrowed by your
keystroke input. Usually you can uniquely identify the buffer you want
within three or four keystrokes. I also keep a large number of buffers
open (hundreds, sometimes), and I don't think I could ever go back to
the stock behaviour.

You can make an argument that this kind of thing is a "power user"
feature that shouldn't be made default, but that decision shouldn't be
made by a snap judgment based on a prima facie reading of a one-sentence
description of its behaviour.

G.

Re: position on changing defaults?

[Miles Bader]

Gregory Collins <greg@maptuit.com> writes:
>> I don't think this should be the default, not just for C-x b,
>> and not for anything else either.
>
> I think you should try the function out before being so eager to dismiss
> it. Iswitchb-mode (and the very similar ido-mode, which I prefer) can
> save a lot of keystrokes

I agree that it's good to try stuff out before making a judgement (it's
not hard after all), but I think Richard's spot on.

I _have_ tried iswitchb (many times actually), and it can be pretty
annoying and confusing, especially when there are tons of buffers.

I'm sure it does save some keystrokes, but there are other important
issues for a default command.  iswitchb is, as you say, a "power user"
tool.

-Miles

-- 
Faith, n. Belief without evidence in what is told by one who speaks without
knowledge, of things without parallel.

Re: position on changing defaults?

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > Gregory Collins <greg@maptuit.com> writes:
  > >> I don't think this should be the default, not just for C-x b,
  > >> and not for anything else either.
  > >
  > > I think you should try the function out before being so eager to dismiss
  > > it. Iswitchb-mode (and the very similar ido-mode, which I prefer) can
  > > save a lot of keystrokes
  > 
  > I agree that it's good to try stuff out before making a judgement (it's
  > not hard after all), but I think Richard's spot on.
  > 
  > I _have_ tried iswitchb (many times actually), and it can be pretty
  > annoying and confusing, especially when there are tons of buffers.
  > 
  > I'm sure it does save some keystrokes, but there are other important
  > issues for a default command.  iswitchb is, as you say, a "power user"
  > tool.

I don't buy that "power user" argument.  It is not dissimilar to the UI
that you get nowadays when typing a URL in a browser.  Users seem to do
just fine with that.  Maybe it's time to reconsider what a user knows
and does not know nowadays.

Re: position on changing defaults?

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> I don't buy that "power user" argument.

That seems clear

> It is not dissimilar to the UI that you get nowadays when typing a URL
> in a browser.  Users seem to do just fine with that.  Maybe it's time
> to reconsider what a user knows and does not know nowadays.

The difference is that such browser interfaces are designed to fairly
readable and clear.  iswitchb is not.

Morever, typing a URL into a browser address bar is a relatively
uncommon action (compared to other browser activities), but switching
buffers is an _extremely_ common action in emacs, and deserves a
lightweight and unintrusive interface.

-Miles

-- 
Un-American, adj. Wicked, intolerable, heathenish.

Re: position on changing defaults?

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:

  > > It is not dissimilar to the UI that you get nowadays when typing a URL
  > > in a browser.  Users seem to do just fine with that.  Maybe it's time
  > > to reconsider what a user knows and does not know nowadays.
  > 
  > The difference is that such browser interfaces are designed to fairly
  > readable and clear.  iswitchb is not.

Perhaps if you say what is unclear, then it can be improved, or
something better can be developed.  Just making statements like that is
not helpful.

Re: position on changing defaults?

[Mathias Dahl]

>  The difference is that such browser interfaces are designed to fairly
>  readable and clear.  iswitchb is not.

I have to agree on this one although I have used iswitchb a lot (I use
`anything' most of the time now). When taking time to look at what
iswitchb displays I almost get scared :) A jumble of buffer names and
commas (it's compact though.) Maybe something can be done with the
display of buffer names, using a list, at least for beginners? I never
look at the list myself until I have typed a few chars, to see what
matches I get.

I find iswitchb and anything very convenient as they both match
anywhere inside a string. I hate needing to type that leading `*' when
going to buffers which such names.

Re: position on changing defaults?

[Xavier Maillard]

   I find iswitchb and anything very convenient as they both match
   anywhere inside a string. I hate needing to type that leading `*' when
   going to buffers which such names.

I find it counter intuitive too. Ideally, one would just have to
type sorted _but_ not consecutive letters to reach the buffer of
choice.

For example, typing fb would automatically restrict the buffer
list to candidates such as *foobar*, fb, fabrice, ...

As for anything, I gave up using it since it was moving too fast
at some time, I will have to try it again since things have
calmed down :)

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

RE: position on changing defaults?

[Drew Adams]

>    I find iswitchb and anything very convenient as they both match
>    anywhere inside a string. I hate needing to type that 
>    leading `*' when going to buffers which such names.
> 
> I find it counter intuitive too. Ideally, one would just have to
> type sorted _but_ not consecutive letters to reach the buffer of
> choice.
> 
> For example, typing fb would automatically restrict the buffer
> list to candidates such as *foobar*, fb, fabrice, ...

FWIW, you can do that using either Icicles or Ido. Icicles calls it
"scatter" matching. Ido calls it "flex" matching.

http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Fuzzy_Completion#toc2

Re: position on changing defaults?

[Juri Linkov]

> I don't buy that "power user" argument.  It is not dissimilar to the UI
> that you get nowadays when typing a URL in a browser.  Users seem to do
> just fine with that.  Maybe it's time to reconsider what a user knows
> and does not know nowadays.

When you type a URL in a browser, you get a pull-down list of matches.
In Emacs, an analogy to this is displaying the *Completions* buffer.
I'm sure Drew will say how Icicles is superior to this.  Yes, it is
powerful, but like suggested packages radically changes the default
behavior that most Emacs users are accustomed to.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: position on changing defaults?

[Drew Adams]

> When you type a URL in a browser, you get a pull-down list of matches.
> In Emacs, an analogy to this is displaying the *Completions* buffer.
> I'm sure Drew will say how Icicles is superior to this.

No, I won't say it. ;-)

Superior to what, BTW? Icicles just uses the *Completions* buffer, so it
can't be superior to displaying the *Completions* buffer. Sorry, I don't
understand.

IMO, Emacs (and so Icicles) completion is superior to picking something from
a pull-down list. And in Emacs (and Icicles) you can anyway use the mouse to
make your choice if you want - just like using a pull-down list.

Some pull-down lists also let you use completion, BTW. In my mail client,
for example, hitting C-k completes an address, or you can pick from a
pull-down list of matches. A pull-down list with completion is pretty much
the same as using *Completions* in Emacs (and Icicles).

> Yes, it is powerful, but like suggested packages radically
> changes the default behavior that most Emacs users are accustomed to.

Sorry, I can't follow. What is powerful? What suggested packages?... What's
the point/question?

Re: position on changing defaults?

[Juri Linkov]

>> Yes, it is powerful, but like suggested packages radically
>> changes the default behavior that most Emacs users are accustomed to.
>
> Sorry, I can't follow. What is powerful? What suggested packages?... What's
> the point/question?

I was referring to the similarities between the *Completions* buffer
and pull-down lists that allow completions, and just like Icicles is the
superstructure over the *Completions* buffer, ido is the superstructure
over the minibuffer, and iswitchb is the superstructure just over the
C-x b minibuffer with buffer names.  Though all they significantly
change the underlying default user interface.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: position on changing defaults?

[Drew Adams]

> >> Yes, it is powerful, but like suggested packages radically
> >> changes the default behavior that most Emacs users are 
> >> accustomed to.
> >
> > Sorry, I can't follow. What is powerful? What suggested 
> > packages?... What's the point/question?
> 
> I was referring to the similarities between the *Completions* buffer
> and pull-down lists that allow completions, and just like 
> Icicles is the superstructure over the *Completions* buffer, ido
> is the superstructure over the minibuffer, and iswitchb is the 
> superstructure just over the C-x b minibuffer with buffer names.
> Though all they significantly
> change the underlying default user interface.

Well, I still don't understand, but thanks for trying. ;-)

I don't agree, BTW, with your characterization of the various
"superstructures", except the part about them all changing the default UI.

Icicles, for example, is not about the *Completions* buffer - you need never
even show it. It is about completion, which is about minibuffer behavior
more than anything else. I'd just say that all three libraries you mentioned
change or extend the completion behavior from the default one, in different
ways.

Re: position on changing defaults?

[Xavier Maillard]

     > I'm sure it does save some keystrokes, but there are other important
     > issues for a default command.  iswitchb is, as you say, a "power user"
     > tool.

   I don't buy that "power user" argument.  It is not dissimilar to the UI
   that you get nowadays when typing a URL in a browser.  Users seem to do
   just fine with that.  Maybe it's time to reconsider what a user knows
   and does not know nowadays.

Agree. Another good example is SMS typing; inaccessible for me
but so easy for the "new generations" :)

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: position on changing defaults?

[Xavier Maillard]

   I'm sure it does save some keystrokes, but there are other important
   issues for a default command.  iswitchb is, as you say, a "power user"
   tool.

Ahem, in what typing a buffer name is targeted to « power users »
exactly ? Default working way of iswitchb (and ido for what I
have seen) is really not more difficult than using default emacs
buffer switching method.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: position on changing defaults?

[Richard Stallman]

    You can make an argument that this kind of thing is a "power user"
    feature that shouldn't be made default, but that decision shouldn't be
    made by a snap judgment based on a prima facie reading of a one-sentence
    description of its behaviour.

The recommendation is valid, but the accusation is wide of the mark,
since my message was not the final decision in any case.

I am trying iswitchb mode now, and I find that the displayed list of
buffers does not bother me.  But I find that I use it the same way I
used the ordinary minibuffer completion (and I get very surprised when
TAB enters the buffer name immediately instead of completing).  So far
I have never paid enough attention to my buffer switching to even
start to think about whether iswitchb might actually help.

I think the list of buffers in iswitchb will be confusing for
beginners, and I think it should not be enabled by default.

Re: position on changing defaults?

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     When doing C-x b it will start by showing in the minibuffer a list of
  >     the buffers.
  > 
  > I think I would find that very annoying.  I tend to have 50 buffers or
  > more.

The size of the list displayed in the minibuffer is limited by default
max-mini-window-height.  We can easily add an extra limitation to make
it smaller, if that is desirable.

Please don't dismiss this before even looking at it.

Re: position on changing defaults?

[Juri Linkov]

>     When doing C-x b it will start by showing in the minibuffer a list of
>     the buffers.
>
> I think I would find that very annoying.  I tend to have 50 buffers or
> more.
>
> I don't think this should be the default, not just for C-x b,
> and not for anything else either.

I have a patch that implements the best part of iswitchb functionality
without changing the default minibuffer user interface.  It provides
the following benefits:

1. After typing C-x b: each M-n (or down-arrow) key will put the
next buffer name to the minibuffer, starting with the most recent
buffer and going in the order buffers are stored in the buffer list.

2. After typing C-x b: C-s or C-M-s will incrementally search the
buffer list for the buffer name that matches the search string or
regexp. So to switch to the buffer, the users can simply type any
unique part of the buffer name or to repeatedly type C-s until seeing
the needed buffer name, e.g.: `C-x b C-s [substring] C-s ... RET'

This is implemented by putting the buffer list to the list of default
values of the minibuffer created by the `interactive' code character `B':

Index: src/callint.c
===================================================================
RCS file: /sources/emacs/emacs/src/callint.c,v
retrieving revision 1.161
diff -c -r1.161 callint.c
*** src/callint.c	19 Feb 2008 04:03:01 -0000	1.161
--- src/callint.c	8 Mar 2008 21:09:16 -0000
***************
*** 520,528 ****
  	  break;
  
  	case 'B':		/* Name of buffer, possibly nonexistent */
! 	  args[i] = Fread_buffer (callint_message,
! 				  Fother_buffer (Fcurrent_buffer (), Qnil, Qnil),
! 				  Qnil);
  	  break;
  
          case 'c':		/* Character */
--- 524,552 ----
  	  break;
  
  	case 'B':		/* Name of buffer, possibly nonexistent */
! 	  {
! 	    Lisp_Object tema, temb, temc;
! 
! 	    /* Get a list of buffer names (except the current buffer and
! 	       internal buffers), and use this list for default values.  */
! 	    tema = Qnil;
! 	    temc = Fcurrent_buffer ();
! 	    teml = Fbuffer_list (selected_frame);
! 	    for (; CONSP (teml); teml = XCDR (teml))
! 	      {
! 		temb = XCAR (teml);
! 		if (EQ (temb, temc))
! 		  continue;
! 		if (NILP (temb))
! 		  continue;
! 		if (NILP (XBUFFER (temb)->name))
! 		  continue;
! 		if (SREF (XBUFFER (temb)->name, 0) == ' ')
! 		  continue;
! 		tema = Fcons (XBUFFER (temb)->name, tema);
! 	      }
! 	    args[i] = Fread_buffer (callint_message, Fnreverse (tema), Qnil);
! 	  }
  	  break;
  
          case 'c':		/* Character */

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: position on changing defaults?

[Richard Stallman]

    1. After typing C-x b: each M-n (or down-arrow) key will put the
    next buffer name to the minibuffer, starting with the most recent
    buffer and going in the order buffers are stored in the buffer list.

That sounds nice -- and hurts nothing.

    2. After typing C-x b: C-s or C-M-s will incrementally search the
    buffer list for the buffer name that matches the search string or
    regexp. So to switch to the buffer, the users can simply type any
    unique part of the buffer name or to repeatedly type C-s until seeing
    the needed buffer name, e.g.: `C-x b C-s [substring] C-s ... RET'

Does this mean it works like C-s except that it searches through
text that is bigger than just what is in the minibuffer?
Or is it an incompatible change in C-s?

If it is incompatible, we should change C-s for all minibuffers, or
for none.  And I think changing it for all minibuffers would cause
problems in some.

If the change in C-s is compatible, then I think it could be ok to do
it in just buffer reading, but it might be good to make it more
general if possible.

Re: position on changing defaults?

[Juri Linkov]

>     2. After typing C-x b: C-s or C-M-s will incrementally search the
>     buffer list for the buffer name that matches the search string or
>     regexp. So to switch to the buffer, the users can simply type any
>     unique part of the buffer name or to repeatedly type C-s until seeing
>     the needed buffer name, e.g.: `C-x b C-s [substring] C-s ... RET'
>
> Does this mean it works like C-s except that it searches through
> text that is bigger than just what is in the minibuffer?
> Or is it an incompatible change in C-s?
>
> If it is incompatible, we should change C-s for all minibuffers, or
> for none.  And I think changing it for all minibuffers would cause
> problems in some.
>
> If the change in C-s is compatible, then I think it could be ok to do
> it in just buffer reading, but it might be good to make it more
> general if possible.

Nothing special is done for buffer reading.  It is the same functionality
that allows isearch to search the minibuffer history: C-r starts searching
the history list backwards, and C-s starts searching the "future" history.

This already works in all minibuffers, and this patch just puts the buffer
list to the "future" history of C-x b.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: position on changing defaults?

[Stefan Monnier]

>> 2. After typing C-x b: C-s or C-M-s will incrementally search the
>> buffer list for the buffer name that matches the search string or
>> regexp. So to switch to the buffer, the users can simply type any
>> unique part of the buffer name or to repeatedly type C-s until seeing
>> the needed buffer name, e.g.: `C-x b C-s [substring] C-s ... RET'
>> 
>> Does this mean it works like C-s except that it searches through
>> text that is bigger than just what is in the minibuffer?
>> Or is it an incompatible change in C-s?
>> 
>> If it is incompatible, we should change C-s for all minibuffers, or
>> for none.  And I think changing it for all minibuffers would cause
>> problems in some.
>> 
>> If the change in C-s is compatible, then I think it could be ok to do
>> it in just buffer reading, but it might be good to make it more
>> general if possible.

> Nothing special is done for buffer reading.  It is the same functionality
> that allows isearch to search the minibuffer history: C-r starts searching
> the history list backwards, and C-s starts searching the "future" history.

> This already works in all minibuffers, and this patch just puts the buffer
> list to the "future" history of C-x b.

Maybe C-s should be changed to also search the completion table?


        Stefan

Re: position on changing defaults?

[Juri Linkov]

>> Nothing special is done for buffer reading.  It is the same functionality
>> that allows isearch to search the minibuffer history: C-r starts searching
>> the history list backwards, and C-s starts searching the "future" history.
>
>> This already works in all minibuffers, and this patch just puts the buffer
>> list to the "future" history of C-x b.
>
> Maybe C-s should be changed to also search the completion table?

This is already easy to do with `C-x b PageUp C-s ... RET'.

But there is a problem that buffers in the opened *Completions* buffer
are sorted alphabetically while it would be more preferable to keep
the order of the buffer list where they are sorted by recency.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: position on changing defaults?

[Juri Linkov]

>     1. After typing C-x b: each M-n (or down-arrow) key will put the
>     next buffer name to the minibuffer, starting with the most recent
>     buffer and going in the order buffers are stored in the buffer list.
>
> That sounds nice -- and hurts nothing.

Below is a patch this implements the same to the small letter "b"
in the interactive specification.  It keeps the original logic
of processing of "B" and "b", and doesn't skip the current buffer
in the buffer list for "b" if not in the minibuffer.

Index: src/callint.c
===================================================================
RCS file: /sources/emacs/emacs/src/callint.c,v
retrieving revision 1.161
diff -c -r1.161 callint.c
*** src/callint.c	19 Feb 2008 04:03:01 -0000	1.161
--- src/callint.c	10 Mar 2008 22:27:46 -0000
***************
*** 513,528 ****
  	  break;
  
  	case 'b':   		/* Name of existing buffer */
- 	  args[i] = Fcurrent_buffer ();
- 	  if (EQ (selected_window, minibuf_window))
- 	    args[i] = Fother_buffer (args[i], Qnil, Qnil);
- 	  args[i] = Fread_buffer (callint_message, args[i], Qt);
- 	  break;
- 
  	case 'B':		/* Name of buffer, possibly nonexistent */
! 	  args[i] = Fread_buffer (callint_message,
! 				  Fother_buffer (Fcurrent_buffer (), Qnil, Qnil),
! 				  Qnil);
  	  break;
  
          case 'c':		/* Character */
--- 517,551 ----
  	  break;
  
  	case 'b':   		/* Name of existing buffer */
  	case 'B':		/* Name of buffer, possibly nonexistent */
! 	  {
! 	    Lisp_Object tema, temb, temc;
! 	    int skip_current = 1;
! 
! 	    if (*tem == 'b' && !EQ (selected_window, minibuf_window))
! 	      skip_current = 0;
! 
! 	    /* Get a list of buffer names (except the current buffer and
! 	       internal buffers), and use this list for default values.  */
! 	    tema = Qnil;
! 	    temc = Fcurrent_buffer ();
! 	    teml = Fbuffer_list (selected_frame);
! 	    for (; CONSP (teml); teml = XCDR (teml))
! 	      {
! 		temb = XCAR (teml);
! 		if (skip_current && EQ (temb, temc))
! 		  continue;
! 		if (NILP (temb))
! 		  continue;
! 		if (NILP (XBUFFER (temb)->name))
! 		  continue;
! 		if (SREF (XBUFFER (temb)->name, 0) == ' ')
! 		  continue;
! 		tema = Fcons (XBUFFER (temb)->name, tema);
! 	      }
! 	    args[i] = Fread_buffer (callint_message, Fnreverse (tema),
! 				    *tem == 'b' ? Qt : Qnil);
! 	  }
  	  break;
  
          case 'c':		/* Character */

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: position on changing defaults?

[Andreas Schwab]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> These are the basics.  Please give it a try.

It does not allow creating a new buffer, it does not switch the buffer
in the current window if it is shown in another frame.  That makes it
completely unacceptable for me.

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: position on changing defaults?

[Dan Nicolaescu]

[Stephen this discussion is about turning on iswitchb by default]

Andreas Schwab <schwab@suse.de> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > These are the basics.  Please give it a try.
  > 
  > It does not allow creating a new buffer, 

C-x b blahblah RET y 
works just fine for me.

  > it does not switch the buffer in the current window if it is shown
  > in another frame.

You might want to customize the value of iswitchb-default-method.
Is a different default preferable?

Re: position on changing defaults?

[Andreas Schwab]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> [Stephen this discussion is about turning on iswitchb by default]
>
> Andreas Schwab <schwab@suse.de> writes:
>
>   > Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > 
>   > > These are the basics.  Please give it a try.
>   > 
>   > It does not allow creating a new buffer, 
>
> C-x b blahblah RET y 
> works just fine for me.

It always switches to some random buffer.

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: position on changing defaults?

[Dan Nicolaescu]

Andreas Schwab <schwab@suse.de> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > [Stephen this discussion is about turning on iswitchb by default]
  > >
  > > Andreas Schwab <schwab@suse.de> writes:
  > >
  > >   > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > 
  > >   > > These are the basics.  Please give it a try.
  > >   > 
  > >   > It does not allow creating a new buffer, 
  > >
  > > C-x b blahblah RET y 
  > > works just fine for me.
  > 
  > It always switches to some random buffer.

That's only if blahblah matches an existing buffer, if it does not, it
will create a new buffer.

Re: position on changing defaults?

[Andreas Schwab]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> That's only if blahblah matches an existing buffer, if it does not, it
> will create a new buffer.

One more reason not to use it.

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: position on changing defaults?

[Kim F. Storm]

Andreas Schwab <schwab@suse.de> writes:

> Dan Nicolaescu <dann@ics.uci.edu> writes:
>
>> That's only if blahblah matches an existing buffer, if it does not, it
>> will create a new buffer.
>
> One more reason not to use it.

With ido-mode, you type C-x b blablabla C-j y RET to create a new buffer.
I guess it's the same with iswitchb.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Andreas Schwab]

storm@cua.dk (Kim F. Storm) writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> Dan Nicolaescu <dann@ics.uci.edu> writes:
>>
>>> That's only if blahblah matches an existing buffer, if it does not, it
>>> will create a new buffer.
>>
>> One more reason not to use it.
>
> With ido-mode, you type C-x b blablabla C-j y RET to create a new buffer.
> I guess it's the same with iswitchb.

I use scratch buffers quite often, anything that requires more than C-x
b x RET to go to buffer x would not be acceptable for me.

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: position on changing defaults?

[Stephen Eglen]

Thanks to Dan for alerting me to this thread.

>> With ido-mode, you type C-x b blablabla C-j y RET to create a new buffer.
>> I guess it's the same with iswitchb.

yes, thanks Kim, C-j will create the buffer of exactly that name.  

> I use scratch buffers quite often, anything that requires more than C-x
> b x RET to go to buffer x would not be acceptable for me.

Its behaviour when you hit RET will be to go to the most recent buffer
that contains `x' in its buffer name.  It should not go to some RANDOM
buffer (as you earlier reported) when you hit RET; if you think there
is a bug, please report it to me.

To get the behaviour you want, C-x b x C-j will do one of two things:

1. If a buffer by the name of 'x' already exists, it will go that
buffer. (As pointed out by Dan, if that buffer is already visible in
another frame, the default behaviour is to raise that frame -- see
iswitchb-default-method -- maybe you'd prefer 'samewindow.)

2. If no buffer by the name 'x' exists, then you are asked if you want
to create a new one by that name.

These small issues aside, I'd be honoured if iswitchb became the
default buffer switching mechanism, but perhaps it may be too
specialised to be intuitive for a new user to work with.  (Probably a
new user would want something interactive, but more like how window
managers switch between applications with Alt+TAB and such like?)
There are many alternative buffer switching methods, of which mine is
just one {that I hope Richard might one day try!}.

Best wishes, Stephen

Re: position on changing defaults?

[Xavier Maillard]

   There are many alternative buffer switching methods, of which mine is
   just one {that I hope Richard might one day try!}.

Just a quick question, I just saw ido-mode mentionned on another
post. I am not an expert but it seems pretty closed to iswitchb.
The question is then simply: why ido-mode and iswitchb and not a
merge of these two packages ? In what do they differ exactly ?

Regards

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: position on changing defaults?

[Kim F. Storm]

Xavier Maillard <xma@gnu.org> writes:

>    There are many alternative buffer switching methods, of which mine is
>    just one {that I hope Richard might one day try!}.
>
> Just a quick question, I just saw ido-mode mentionned on another
> post. I am not an expert but it seems pretty closed to iswitchb.
> The question is then simply: why ido-mode and iswitchb and not a
> merge of these two packages ? In what do they differ exactly ?

Good question - when I wrote ido, I started hacking on the iswitchb
code, but i found it akward to use the iswitchb prefix - I tried to
use an ifindf- prefix for the new functions, but things were so glued
together (in particular in the minibuffer hooks) that I chose a
completely new prefix ido- for everything.

When I was done, things had moved quite far away from iswitchb
(in the internals and in the names of functions and options),
that I didn't see a way to synchronize with iswitchb.

I guess iswitchb is still there for those who don't want to use the
same interface for find-file (why not?) -- in that case, it is more
lightweight than the full ido.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Tassilo Horn]

storm@cua.dk (Kim F. Storm) writes:

Hi Kim,

> I guess iswitchb is still there for those who don't want to use the
> same interface for find-file (why not?)

I like and use ido, but one drawback of ido's find-file behavior is that
it doesn't work with TRAMP.  If you don't know about
`ido-fallback-command' that disqualifies ido.

BTW, I'd suggest to bind `ido-fallback-command' to `C-x b' in addition
to `C-x C-b' in `ido-buffer-completion-map'.  That's easier to remember,
because then typing a key twice will always switch to the non-ido
version, e.g. `C-x C-f' twice opens the normal find-file interface and
`C-x b' twice would switch to the default buffer switching interface.

Bye,
Tassilo

ido-mode (was Re: position on changing defaults?)

[Kim F. Storm]

Tassilo Horn <tassilo@member.fsf.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
> Hi Kim,
>
>> I guess iswitchb is still there for those who don't want to use the
>> same interface for find-file (why not?)
>
> I like and use ido, but one drawback of ido's find-file behavior is that
> it doesn't work with TRAMP.  If you don't know about
> `ido-fallback-command' that disqualifies ido.

It has worked with tramp before - can you give a recipe...

> BTW, I'd suggest to bind `ido-fallback-command' to `C-x b' in addition
> to `C-x C-b' in `ido-buffer-completion-map'.  That's easier to remember,
> because then typing a key twice will always switch to the non-ido
> version, e.g. `C-x C-f' twice opens the normal find-file interface and
> `C-x b' twice would switch to the default buffer switching interface.

I'll do that.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: ido-mode

[Tassilo Horn]

storm@cua.dk (Kim F. Storm) writes:

>>> I guess iswitchb is still there for those who don't want to use the
>>> same interface for find-file (why not?)
>>
>> I like and use ido, but one drawback of ido's find-file behavior is
>> that it doesn't work with TRAMP.  If you don't know about
>> `ido-fallback-command' that disqualifies ido.
>
> It has worked with tramp before - can you give a recipe...

No, it works like a charm.  I remember I had problems with it in the
past, so I always used the fallback method.  ;-)

Bye,
Tassilo

Re: position on changing defaults?

[Dan Nicolaescu]

Andreas Schwab <schwab@suse.de> writes:

  > storm@cua.dk (Kim F. Storm) writes:
  > 
  > > Andreas Schwab <schwab@suse.de> writes:
  > >
  > >> Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >>
  > >>> That's only if blahblah matches an existing buffer, if it does not, it
  > >>> will create a new buffer.
  > >>
  > >> One more reason not to use it.
  > >
  > > With ido-mode, you type C-x b blablabla C-j y RET to create a new buffer.
  > > I guess it's the same with iswitchb.
  > 
  > I use scratch buffers quite often, anything that requires more than C-x
  > b x RET to go to buffer x would not be acceptable for me.

The fact that you need to type C-j instead of RET when creating a buffer
does not seem such a huge imposition, it if makes selecting buffers much
easier for everyone else (assuming we don't find a better solution).
Creating non-file backed buffers is not something that is that frequent
for most users, and frankly probably not so desirable for newbies
(There's so much trouble with the *scratch* buffer anyway...)

Re: position on changing defaults?

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> Creating non-file backed buffers is not something that is that frequent
> for most users

You're kidding, right?

-Miles

-- 
80% of success is just showing up.  --Woody Allen

Re: position on changing defaults?

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> The fact that you need to type C-j instead of RET when creating a
> buffer does not seem such a huge imposition, it if makes selecting
> buffers much easier for everyone else (assuming we don't find a better
> solution).

I don't think we need more idiosyncratic interfaces in Emacs by default.
If we can clad the functionality into something not requiring special
keystrokes and learning, everyone is better off.  Special modes with
non-essential functionality requiring additional learning should remain
off by default, I think.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: position on changing defaults?

[Richard Stallman]

    The fact that you need to type C-j instead of RET when creating a buffer
    does not seem such a huge imposition, it if makes selecting buffers much
    easier for everyone else (assuming we don't find a better solution).

I agree that typing C-j instead of RET for this case is not hard.
It is, however, a complication.  If you know how to use the minibuffer,
you can use the ordinary C-x b command to do whatever you like.
The iswitchb interface doesn't show you that you should use C-j for this.

    I don't buy that "power user" argument.  It is not dissimilar to the UI
    that you get nowadays when typing a URL in a browser.

It doesn't look anything like a file browser window.  iswitchb output
is cryptic and short.  That is convenient for the people who like it,
but does not help beginners understand, as a file browser window does.

    Perhaps if you say what is unclear, then it can be improved, or
    something better can be developed.

The problem is fundamental, and I don't think it can be fixed
without making iswitchb inconvenient for the people who like it.

Re: position on changing defaults?

[Xavier Maillard]

   Creating non-file backed buffers is not something that is that frequent
   for most users, and frankly probably not so desirable for newbies
   (There's so much trouble with the *scratch* buffer anyway...)

Huh ? I am using this feature all day long. Not having this would
kill my "productivity" :)

We need this feature.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: position on changing defaults?

[Xavier Maillard]

   Richard Stallman <rms@gnu.org> writes:

     >     That would be great too.  But we also need to consider the fact iswitch
     >     is here now, it works and is useful, improvements to completion are not
     >     available yet (or even in the works?).
     > 
     > I have never tried iswitchb.  What incompatible changes would I notice
     > if this change were made?

   Nothing fundamentally incompatible, but there are differences in which
   C-x b  works.  The essence is that you don't have to press TAB to get
   completions, they happen as you type.

<snip>

   These are the basics.  Please give it a try.

I second this request, this is a real enhancement in my opinion.



	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: position on changing defaults?

[paul r]

2008/3/7, Richard Stallman <rms@gnu.org>:

> I have never tried iswitchb.  What incompatible changes would I notice
>  if this change were made?

You will be able to chose the buffer you want to go to in a
find-as-you-type way. I find the benefit of it real, because :
 - there is no need to hit the * to go to *Message*
 - there is no need to hit S-M for the capital M in *Message*
 - you might want to go to a buffer that you can not remember
precisely how its name begins, but know a slice of its name : enter
the slice until you see the correct name appear

Basically, it makes one need buffer-list less often, therefore
"increase productivity".
But as Stefan said, all that is a matter of improving the completion
mechanism of switch-to-buffer.

What will maybe annoy you using it is how to choose, in the list of
buffers matching your entry, the one you really want. In a purely
incremental search like in switch-to-buffer, there is no need of such
a mechanism because names are completed up to ambiguity, and
desambiguity is made be entering a few more caracters. In iswichb, if
you have opened buffers "first-foobar" and "second-foobar" and you
enter "foobar", there is ambiguity. Iswitchb provides C-s and C-r to
move forward and backward in the list of matching buffers. I personaly
find this last design choice counter-intuitive, and I think it could
be improved. But all the rest is very valuable.

Re: position on changing defaults?

[Xavier Maillard]

   2008/3/7, Richard Stallman <rms@gnu.org>:

   > I have never tried iswitchb.  What incompatible changes would I notice
   >  if this change were made?

   You will be able to chose the buffer you want to go to in a
   find-as-you-type way. I find the benefit of it real, because :
    - there is no need to hit the * to go to *Message*
    - there is no need to hit S-M for the capital M in *Message*
    - you might want to go to a buffer that you can not remember
   precisely how its name begins, but know a slice of its name : enter
   the slice until you see the correct name appear

   Basically, it makes one need buffer-list less often, therefore
   "increase productivity".
   But as Stefan said, all that is a matter of improving the completion
   mechanism of switch-to-buffer.

   What will maybe annoy you using it is how to choose, in the list of
   buffers matching your entry, the one you really want. In a purely
   incremental search like in switch-to-buffer, there is no need of such
   a mechanism because names are completed up to ambiguity, and
   desambiguity is made be entering a few more caracters. In iswichb, if
   you have opened buffers "first-foobar" and "second-foobar" and you
   enter "foobar", there is ambiguity. Iswitchb provides C-s and C-r to
   move forward and backward in the list of matching buffers. I personaly
   find this last design choice counter-intuitive, and I think it could
   be improved. But all the rest is very valuable.

Well sumed up Paul. Why not put this as an entry into the manual
as a first "shoot" ? I am speaking about the first paragraph and
the part on C-r and C-s.

Regards,

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: position on changing defaults?

[Richard Stallman]

    > - flyspell-mode on by default for text-mode

    I indeed have it on in text-mode (and programming modes as well, as
    a matter of fact), but I haven't given any thought to enabling it
    by default.  I think it might be a bit too brittle currently to be
    enabled by default: it usually works just fine, but I've had problems
    with it every once in a while.

How about posting the problems you occasionally have?
That will help get them fixed.

Re: position on changing defaults?

[Chong Yidong]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> - transient-mark

Like Stefan, I am in favor of this change.

My thinking on this, however, is a little different.  I'm not in favor
of creating a new setting for transient-mark-mode if it involves
cumbersome keystrokes (e.g. C-SPC C-SPC instead of C-SPC).  The
reasoning is that transient-mark-mode is already easily accessible in
the Options menu on the menu-bar, so it's trivial for users to go back
to the old behavior.  So the question is whether complete newbies, who
haven't even tinkered with the Options menu, would be more comfortable
with the invisible mark or transient-mark-mode.

My feeling is that transient-mark-mode is more intuitive to use, since
you can see exactly what is going on.  The invisible mark is a more
"advanced" mode of editing: it allows you to have an active mark while
editing, but the mark is not displayed and you have to remember where
it is.  Thus, transient-mark-mode is more suitable for newbies.

> - selection with Shift-arrow keys

I think this would be a good default.  If someone is willing to make a
patch that refactors this code from cua-mode into simple.el, it would
be worth considering.

> - show-paren-mode on by default

I don't think this should be done.  I think the default blink-paren
behavior is a good default; show-paren-mode can be annoying.  For
those who like it, it's already easily accessible in the Options menu
on the menu-bar.

> - iswitchb-mode on by default
> - bind ibuffer to C-x C-b
> - hide-ifdef-mode on by default for C/C++/objc
> - flyspell-mode on by default for text-mode

I don't see a need for these, but am open to discussion.

Re: position on changing defaults?

[Juri Linkov]

>> - selection with Shift-arrow keys
>
> I think this would be a good default.  If someone is willing to make a
> patch that refactors this code from cua-mode into simple.el, it would
> be worth considering.

Unfortunately, I see no way of implementing this in simple.el without
using pre-command-hook and post-command-hook.  It seems this can be
implemented only in C in the function that reads characters.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: position on changing defaults?

[Bastien]

Juri Linkov <juri@jurta.org> writes:

>>> - selection with Shift-arrow keys
>>
>> I think this would be a good default.  If someone is willing to make a
>> patch that refactors this code from cua-mode into simple.el, it would
>> be worth considering.
>
> Unfortunately, I see no way of implementing this in simple.el without
> using pre-command-hook and post-command-hook.  It seems this can be
> implemented only in C in the function that reads characters.

On top of this, Shift-arrow keys are already in use in org-mode.

--8<---------------cut here---------------start------------->8---
(defun org-shiftup (&optional arg)
  "Increase item in timestamp or increase priority of current headline.
  ...

(defun org-shiftdown (&optional arg)
  "Decrease item in timestamp or decrease priority of current headline.
Calls `org-timestamp-down' or `org-priority-down', or `org-next-item'
depending on context.  See the individual commands for more information."
  ...
          
(defun org-shiftright ()
  "Next TODO keyword or timestamp one day later, depending on context."
  ...

(defun org-shiftleft ()
  "Previous TODO keyword or timestamp one day earlier, depending on context."
  ...
--8<---------------cut here---------------end--------------->8---

-- 
Bastien

Re: position on changing defaults?

[Juri Linkov]

>>>> - selection with Shift-arrow keys
>>>
>>> I think this would be a good default.  If someone is willing to make a
>>> patch that refactors this code from cua-mode into simple.el, it would
>>> be worth considering.
>>
>> Unfortunately, I see no way of implementing this in simple.el without
>> using pre-command-hook and post-command-hook.  It seems this can be
>> implemented only in C in the function that reads characters.
>
> On top of this, Shift-arrow keys are already in use in org-mode.

This is not a reason to make Emacs unfriendly to newbies that expect
Shift-arrow keys to work like in other programs.  Could you change
these keys in org-mode to e.g. Meta-arrows or something?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: position on changing defaults?

[Lennart Borgman (gmail)]

Juri Linkov wrote:
>>>>> - selection with Shift-arrow keys
>>>> I think this would be a good default.  If someone is willing to make a
>>>> patch that refactors this code from cua-mode into simple.el, it would
>>>> be worth considering.
>>> Unfortunately, I see no way of implementing this in simple.el without
>>> using pre-command-hook and post-command-hook.  It seems this can be
>>> implemented only in C in the function that reads characters.
>> On top of this, Shift-arrow keys are already in use in org-mode.
> 
> This is not a reason to make Emacs unfriendly to newbies that expect
> Shift-arrow keys to work like in other programs.  Could you change
> these keys in org-mode to e.g. Meta-arrows or something?

org-mode has already support for changing this, see the variable

   `org-replace-disputed-keys'

Re: position on changing defaults?

[Bastien]

Juri Linkov <juri@jurta.org> writes:

>>>>> - selection with Shift-arrow keys
>>>>
>>>> I think this would be a good default.  If someone is willing to make a
>>>> patch that refactors this code from cua-mode into simple.el, it would
>>>> be worth considering.
>>>
>>> Unfortunately, I see no way of implementing this in simple.el without
>>> using pre-command-hook and post-command-hook.  It seems this can be
>>> implemented only in C in the function that reads characters.
>>
>> On top of this, Shift-arrow keys are already in use in org-mode.
>
> This is not a reason to make Emacs unfriendly to newbies that expect
> Shift-arrow keys to work like in other programs.  Could you change
> these keys in org-mode to e.g. Meta-arrows or something?

Meta-arrows are also quite busy.  

But there is a mechanism in Org to handle conflicts with keybindings of
cua-mode.el or windmove.el:

,----[ org-replace-disputed-keys ]
| Non-nil means use alternative key bindings for some keys.
| Org-mode uses S-<cursor> keys for changing timestamps and priorities.
| These keys are also used by other packages like `CUA-mode' or `windmove.el'.
| If you want to use Org-mode together with one of these other modes,
| or more generally if you would like to move some Org-mode commands to
| other keys, set this variable and configure the keys with the variable
| `org-disputed-keys'.
| 
| This option is only relevant at load-time of Org-mode, and must be set
| *before* org.el is loaded.  Changing it requires a restart of Emacs to
| become effective.
`----

We could change the default value for this (and `org-disputed-keys')
when required.  But I guess many org-ers will revert the change to get
the Shift-arrow keys have their original behavior.  The paradox here is
that it seems many org-ers are also Emacs newbies.

-- 
Bastien

Re: position on changing defaults?

[Richard Stallman]

    On top of this, Shift-arrow keys are already in use in org-mode.

That doesn't necessarily mean we should not give them a global meaning.
Org mode is not crucial enough to determine global Emacs key decisions.

If we do that, Org mode can still bind those keys as it does now, if
that is the best thing for it to do.  However, it might be desirable
to change Org mode to use other keys for this.

Re: position on changing defaults?

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>>> - selection with Shift-arrow keys
>>
>> I think this would be a good default.  If someone is willing to make a
>> patch that refactors this code from cua-mode into simple.el, it would
>> be worth considering.
>
> Unfortunately, I see no way of implementing this in simple.el without
> using pre-command-hook and post-command-hook.  It seems this can be
> implemented only in C in the function that reads characters.

I was thinking about we might do this in a better and more general way
(in C, obviously).

How about adding a new type of binding, a "modifier binding", which
could serve to implement CUA movement, and replace the current automatic
S-foo => foo remapping.

Basically, these would be bindings that represent event-modifiers only.
If normal key lookup fails, the keymapping mechanism would then look up
and invoke the modifier binding corresponding to the modifiers on the
key, and invoke it instead; the invoked function could then, if it
wished (e.g. for CUA), set some variables or frob some state and
re-invoke the event with the modifiers removed.

[Presumably there would be some fallback mechanism for dealing with
multiple modifiers where there was no binding for the entire modifier
set; e.g., if the event was "S-M-x", and there was no "S-M-x" binding,
nor a "S-M-" binding, it would then lookup say "S-" and "M-" in turn,
and invoke the first one found.]

Whadaya think?

-Miles

-- 
Bride, n. A woman with a fine prospect of happiness behind her.

Re: position on changing defaults?

[Juri Linkov]

>> Unfortunately, I see no way of implementing this in simple.el without
>> using pre-command-hook and post-command-hook.  It seems this can be
>> implemented only in C in the function that reads characters.
>
> I was thinking about we might do this in a better and more general way
> (in C, obviously).
>
> How about adding a new type of binding, a "modifier binding", which
> could serve to implement CUA movement, and replace the current automatic
> S-foo => foo remapping.
>
> Basically, these would be bindings that represent event-modifiers only.
> If normal key lookup fails, the keymapping mechanism would then look up
> and invoke the modifier binding corresponding to the modifiers on the
> key, and invoke it instead; the invoked function could then, if it
> wished (e.g. for CUA), set some variables or frob some state and
> re-invoke the event with the modifiers removed.
>
> [Presumably there would be some fallback mechanism for dealing with
> multiple modifiers where there was no binding for the entire modifier
> set; e.g., if the event was "S-M-x", and there was no "S-M-x" binding,
> nor a "S-M-" binding, it would then lookup say "S-" and "M-" in turn,
> and invoke the first one found.]
>
> Whadaya think?

In general, I agree with the idea of exposing the translation of unbound
event-modified keys to Lisp functions that can process untranslated keys.
Maybe it would be possible to implement the following interface to define
such bindings?

(define-key global-map [(shift untranslated)]
  (lambda ()
    (interactive)
    (when (and transient-mark-mode (not mark-active))
       (push-mark-command nil nil))))

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: position on changing defaults?

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> Basically, these would be bindings that represent event-modifiers only.
> If normal key lookup fails, the keymapping mechanism would then look up
> and invoke the modifier binding corresponding to the modifiers on the
> key, and invoke it instead; the invoked function could then, if it
> wished (e.g. for CUA), set some variables or frob some state and
> re-invoke the event with the modifiers removed.

That's a nice idea, but it only solves half the problem.

You also need to handle the case where you have use shifted arrow
to mark the region, and then use an unshifted arrow ... which should
deactivate the mark.

It seems like a simpler solution would be to have special events 
like <shift-down> <shift-up> <meta-down> <meta-up> etc....

A third possibility would be a "point moved" hook (at C level)
which was called with the original value of point - and the
original event modifiers.

BTW, cua-mode has some special code to detect the shift modifier on
a tty (something about looking for "S-" in the key symbol).
A solution should work equally well on all platforms!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Richard Stallman]

    You also need to handle the case where you have use shifted arrow
    to mark the region, and then use an unshifted arrow ... which should
    deactivate the mark.

    It seems like a simpler solution would be to have special events 
    like <shift-down> <shift-up> <meta-down> <meta-up> etc....

Why not just bind the shifted and unshifted arrow keys to new commands?
We only need 8 of them.

Re: position on changing defaults?

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     You also need to handle the case where you have use shifted arrow
>     to mark the region, and then use an unshifted arrow ... which should
>     deactivate the mark.
>
>     It seems like a simpler solution would be to have special events 
>     like <shift-down> <shift-up> <meta-down> <meta-up> etc....
>
> Why not just bind the shifted and unshifted arrow keys to new commands?
> We only need 8 of them.

Actually in usual practice, this feature is used with many other
movement commands too, not just the arrow keys -- for instance, S-C-home
will highlight to the beginning of the buffer in typical MS-type apps
(so in emacs, that should work, and so should S-M-<), and S-M-right will
highlight the next word (so in emacs S-M-f should do so as well).

Emacs could just exhaustively bind the shifted versions of all common
movement commands, but of course this is a bit brittle (user rebindings
won't be automatically handled).

There's also the "_non_-shifted movement should _deactivate_ the region"
issue which Kim mentioned earlier; it occurs to me that perhaps that
could be handled simply by having "shift activation" (activating the
region by using a shifted movement command) add a _temporary_
post-command hook, which would take care of deactivating the mark
appropriately, and would then remove itself from the post-command-hook
list.  While it would still be using post-command-hook, I think this
would be much better than the current cua mechanism, because it limits
the use of post-command-hook to only those periods when this feature is
actually actively in use.

[This "temporary post-command-hook" method should work with the
"modifier bindings" method (i.e., allowing bindings of modifier keys
which would match all otherwise-unbound events having those modifiers) I
suggested earlier as well.]

-Miles

-- 
Sabbath, n. A weekly festival having its origin in the fact that God made the
world in six days and was arrested on the seventh.

Re: position on changing defaults?

[Lennart Borgman (gmail)]

Miles Bader wrote:
> Richard Stallman <rms@gnu.org> writes:
>>     You also need to handle the case where you have use shifted arrow
>>     to mark the region, and then use an unshifted arrow ... which should
>>     deactivate the mark.
>>
>>     It seems like a simpler solution would be to have special events 
>>     like <shift-down> <shift-up> <meta-down> <meta-up> etc....
>>
>> Why not just bind the shifted and unshifted arrow keys to new commands?
>> We only need 8 of them.
> 
> Actually in usual practice, this feature is used with many other
> movement commands too, not just the arrow keys -- for instance, S-C-home
> will highlight to the beginning of the buffer in typical MS-type apps
> (so in emacs, that should work, and so should S-M-<), and S-M-right will
> highlight the next word (so in emacs S-M-f should do so as well).
> 
> Emacs could just exhaustively bind the shifted versions of all common
> movement commands, but of course this is a bit brittle (user rebindings
> won't be automatically handled).

Maybe a much more radical surgery would be easier. How about having the 
convention that whenever a movement is bound to a shifted key then this 
should activate the region? If the movement is bound to a non-shifted 
key then it should deactivate the region.

Could not something like this be handled in the command loop?

Of course such a radical change would need a defcustom to remove it. And 
some cases would have to be exceptions.

> There's also the "_non_-shifted movement should _deactivate_ the region"
> issue which Kim mentioned earlier; it occurs to me that perhaps that
> could be handled simply by having "shift activation" (activating the
> region by using a shifted movement command) add a _temporary_
> post-command hook, which would take care of deactivating the mark
> appropriately, and would then remove itself from the post-command-hook
> list.  While it would still be using post-command-hook, I think this
> would be much better than the current cua mechanism, because it limits
> the use of post-command-hook to only those periods when this feature is
> actually actively in use.
> 
> [This "temporary post-command-hook" method should work with the
> "modifier bindings" method (i.e., allowing bindings of modifier keys
> which would match all otherwise-unbound events having those modifiers) I
> suggested earlier as well.]
> 
> -Miles
> 

Re: position on changing defaults?

[Richard Stallman]

    Maybe a much more radical surgery would be easier. How about having the 
    convention that whenever a movement is bound to a shifted key then this 
    should activate the region? If the movement is bound to a non-shifted 
    key then it should deactivate the region.

It is better to have the keymaps control what keys do.  Let's not
hard-wire any keys or modifiers if we can avoid it.

deactivation in "shift-select" mode

[Miles Bader]

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

Johan Bockgård pointed out (on the #emacs irc channel) that
transient-mark-mode actually _already_ has enough functionality to
allow implementing the desired "deactivation" behavior for
shift-select (where non-shifted movement keys automatically deactivate
any mark which was activated by shifted movement keys), without using
post-command-hook at all!

Basically his idea is to use the "only mode" feature of
transient-mark-mode (setting the transient-mark-mode variable to 'only
instead of t).

I've attached a proof-of-concept that shows how it works; this code
only implements shift-select for the basic cursor movement keys plus
forward/backward-word, but it's obviously trivial to extend to any
other commands desired.

This implementation only works if transient-mark-mode is disabled,
because of the way the transient-mark-mode "only mode" works; my guess
is that this restriction would probably be pretty easy to remove by
simply having a separate variable to enable "only mode" instead of
overloading the meaning of the basic transient-mark-mode variable.

Anyway, here's the example code, which is very simple and seems to
work quite nicely; check it!

-Miles



[-- Attachment #2: proof-of-concept for \"shift-select\" without post-command-hook --]
[-- Type: application/emacs-lisp, Size: 1773 bytes --]

[-- Attachment #3: Type: text/plain, Size: 114 bytes --]




-- 
Genealogy, n. An account of one's descent from an ancestor who did not
particularly care to trace his own.

Re: deactivation in "shift-select" mode

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

> Johan Bockgård pointed out (on the #emacs irc channel) that
> transient-mark-mode actually _already_ has enough functionality to
> allow implementing the desired "deactivation" behavior for
> shift-select (where non-shifted movement keys automatically deactivate
> any mark which was activated by shifted movement keys), without using
> post-command-hook at all!
>
> Basically his idea is to use the "only mode" feature of
> transient-mark-mode (setting the transient-mark-mode variable to 'only
> instead of t).
>
> I've attached a proof-of-concept that shows how it works; this code
> only implements shift-select for the basic cursor movement keys plus
> forward/backward-word, but it's obviously trivial to extend to any
> other commands desired.

Bit confused.

AFAICT, the function region-active-p which you use isn't defined, and
the "only mode" feature transient-mark-mode doesn't exist/isn't
documented.  Is this a feature from XEmacs?

Re: deactivation in "shift-select" mode

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
> Bit confused.
>
> AFAICT, the function region-active-p which you use isn't defined, and
> the "only mode" feature transient-mark-mode doesn't exist/isn't
> documented.  Is this a feature from XEmacs?

Er, no.

`region-active-p' is defined in simple.el (unless someone's undefined it
in the last week or so).

transient-mark-mode "only mode" is used by `mouse-set-region-1'.

Johan mentioned that "only mode" was documented in the Emacs (or Elisp?)
manual, though I haven't looked it up.

-Miles

-- 
Generous, adj. Originally this word meant noble by birth and was rightly
applied to a great multitude of persons. It now means noble by nature and is
taking a bit of a rest.

Re: deactivation in "shift-select" mode

[Miles Bader]

Just to followup:

  * `region-active-p' is still defined in simple.el in the current tree.

  * transient-mark-mode "only mode" is documented in "(elisp)The Mark"

-Miles

-- 
Kilt, n. A costume sometimes worn by Scotchmen [sic] in America and Americans
in Scotland.

Re: deactivation in "shift-select" mode

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> This implementation only works if transient-mark-mode is disabled,
> because of the way the transient-mark-mode "only mode" works; my guess
> is that this restriction would probably be pretty easy to remove by
> simply having a separate variable to enable "only mode" instead of
> overloading the meaning of the basic transient-mark-mode variable.

This really has nothing to do with transient-mark-mode as such
What is needed here is a similar functionality on deactivate-mark, i.e.:

Setting deactivate-mark to 'only means to deactivate mark after
the next command (during which deactivate-mark = 'identity).

> Anyway, here's the example code, which is very simple and seems to
> work quite nicely; check it!

It's a small step in the right direction...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Richard Stallman]

    Actually in usual practice, this feature is used with many other
    movement commands too, not just the arrow keys -- for instance, S-C-home
    will highlight to the beginning of the buffer in typical MS-type apps
    (so in emacs, that should work, and so should S-M-<), and S-M-right will
    highlight the next word (so in emacs S-M-f should do so as well).

I don't think this should be applied to all shift keys.  Doing it for
S-C-home is ok, and for S-M- arrows, but I think it would be a bad
idea to have this apply to ordinary Emacs commands such as C-f and
M-f.

S-M-< is meaningless because the shift key is required to type <.
Either every M-< counts as shifted, or none of them do.

    There's also the "_non_-shifted movement should _deactivate_ the region"
    issue which Kim mentioned earlier; it occurs to me that perhaps that
    could be handled simply by having "shift activation" (activating the
    region by using a shifted movement command) add a _temporary_
    post-command hook, which would take care of deactivating the mark
    appropriately, and would then remove itself from the post-command-hook
    list.  While it would still be using post-command-hook, I think this
    would be much better than the current cua mechanism,

I agree this is a much better way to use post-command-hook than having
it on all the time.  It may be ok.  However, someone presented another
way to do it using transient-mark-mode.

Re: position on changing defaults?

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>  .  While it would still be using post-command-hook, I think this
>     would be much better than the current cua mechanism,
>
> I agree this is a much better way to use post-command-hook than having
> it on all the time.  It may be ok.  However, someone presented another
> way to do it using transient-mark-mode.

Actually that was me, in a later message ... :-)

-Miles

-- 
Religion, n. A daughter of Hope and Fear, explaining to Ignorance the nature
of the Unknowable.

Shift-movement selection (was: position on changing defaults?)

[Stefan Monnier]

How 'bout solving the problem of shift-movement selection in a less
sophisticated way.  E.g. provide a function like

   (defun activate-on-shift-selecting-movement ()
     (if (this-command-keys-are-shifted-p)
         (progn
           (setq shift-selecting-movement t)
           (unless mark-active (set-mark)))
       (when shift-selecting-movement
         (setq shift-selecting-movement nil)
         (when mark-active (deactivate-mark)))))

and then call it from wherever it's considered useful
(e.g. forward-char, next-line, ...).


-- Stefan

Re: Shift-movement selection

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>    (defun activate-on-shift-selecting-movement ()
>      (if (this-command-keys-are-shifted-p)
>          (progn
>            (setq shift-selecting-movement t)
>            (unless mark-active (set-mark)))
>        (when shift-selecting-movement
>          (setq shift-selecting-movement nil)
>          (when mark-active (deactivate-mark)))))
>
> and then call it from wherever it's considered useful
> (e.g. forward-char, next-line, ...).

AFAICS, such an approach would make deselection much less likely to work
consistently:  the way it's _supposed_ to work is that any pretty much
any command except for the special shifted versions should cause
deactivation -- and in emacs that's pretty much _every command_.
So to make it work "correctly", you need to modify all commands in
emacs!  [yikes!]

The method I showed earlier seems almost as simple, and has the
advantage that it's very unintrusive -- you only need to worry about the
commands which implement the special behavior -- and seems to work
pretty well.

-Miles

-- 
Brain, n. An apparatus with which we think we think.

Re: Shift-movement selection

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

>> and then call it from wherever it's considered useful
>> (e.g. forward-char, next-line, ...).

That was not an option when I wrote CUA-mode.
If that position has changed now, I'm all in favour of this approach!

This would also allow external packages to simply add code like

     (if (fboundp 'activate-on-shift-selecting-movement)
         (activate-on-shift-selecting-movement))

[I don't quite like the name tough].

Easier would be (shift-region-check) or some such.

> The method I showed earlier seems almost as simple, and has the
> advantage that it's very unintrusive -- you only need to worry about the
> commands which implement the special behavior -- and seems to work
> pretty well.

Can't we just combine the two methods (actually three - using the
deactivate-mark 'only instead of transient-mark-mode 'only)?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Shift-movement selection

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> Easier would be (shift-region-check) or some such.

Perhaps we should try to remove the "shift" from the command name -- the
concept seems independent of the actual key modifier used.

>> The method I showed earlier seems almost as simple, and has the
>> advantage that it's very unintrusive -- you only need to worry about the
>> commands which implement the special behavior -- and seems to work
>> pretty well.
>
> Can't we just combine the two methods (actually three - using the
> deactivate-mark 'only instead of transient-mark-mode 'only)?

Yeah, the various issues seem orthogona (copying some text from my
previous message):

 (1) how to turn on shift-selection -- binding keys vs. special
     detection of commands

 (2) How to turn _off_ shift-selection -- post-command-hook
     vs. transient-mark-mode "only mode" vs. ...

You're right that it seems better to extend the deactivate-mark variable
to implement this feature so it works right for t-m-m users too.

Do you have an exact mechanism in mind?  I find the dance of variables
used for deactivate-mark and transient-mark-mode kind of
confusing... :-)

-Miles

-- 
Circus, n. A place where horses, ponies and elephants are permitted to see
men, women and children acting the fool.

Re: Shift-movement selection

[Stefan Monnier]

> Yeah, the various issues seem orthogona (copying some text from my
> previous message):

>  (1) how to turn on shift-selection -- binding keys vs. special
>      detection of commands

>  (2) How to turn _off_ shift-selection -- post-command-hook
>      vs. transient-mark-mode "only mode" vs. ...

> You're right that it seems better to extend the deactivate-mark variable
> to implement this feature so it works right for t-m-m users too.

Could you resend me your proposal?

> Do you have an exact mechanism in mind?  I find the dance of variables
> used for deactivate-mark and transient-mark-mode kind of
> confusing... :-)

Yes, it's terrible.


        Stefan

Re: Shift-movement selection

[Stefan Monnier]

>>> and then call it from wherever it's considered useful
>>> (e.g. forward-char, next-line, ...).

> That was not an option when I wrote CUA-mode.
> If that position has changed now, I'm all in favour of this approach!

Since we're considering changing the default to allow shift-selection,
then yes, that position has indeed changed.


        Stefan

Re: Shift-movement selection

[Stefan Monnier]

>> (defun activate-on-shift-selecting-movement ()
>> (if (this-command-keys-are-shifted-p)
>> (progn
>> (setq shift-selecting-movement t)
>> (unless mark-active (set-mark)))
>> (when shift-selecting-movement
>> (setq shift-selecting-movement nil)
>> (when mark-active (deactivate-mark)))))
>> 
>> and then call it from wherever it's considered useful
>> (e.g. forward-char, next-line, ...).

> AFAICS, such an approach would make deselection much less likely to work
> consistently:  the way it's _supposed_ to work is that any pretty much
> any command except for the special shifted versions should cause
> deactivation -- and in emacs that's pretty much _every command_.
> So to make it work "correctly", you need to modify all commands in
> emacs!  [yikes!]

Most commands already deactivate the mark.  So which ones would be left?
Do they matter?


        Stefan

Re: Shift-movement selection

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> So to make it work "correctly", you need to modify all commands in
>> emacs!  [yikes!]
>
> Most commands already deactivate the mark.  So which ones would be left?

Anything that doesn't modify the buffer -- e.g. all movement commands.

> Do they matter?

I think movement commands matter, yes.

Anyway, since it's becoming clear there's an alternative that actually
does the right thing, and does not require such an obviously brittle
method, why not use it?

-Miles

-- 
Once, adj. Enough.

Re: Shift-movement selection

[Stefan Monnier]

>>> So to make it work "correctly", you need to modify all commands in
>>> emacs!  [yikes!]
>> Most commands already deactivate the mark.  So which ones would be left?

> Anything that doesn't modify the buffer -- e.g. all movement commands.

Supposedly these will be changed to use the new function, so they will
explicitly deactivate the mark if the mark was activated with shift and
the movement is then performed without the shift.

So again, which ones would be left?


        Stefan

Re: Shift-movement selection

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> So to make it work "correctly", you need to modify all commands in
>>>> emacs!  [yikes!]
>>> Most commands already deactivate the mark.  So which ones would be left?
>
>> Anything that doesn't modify the buffer -- e.g. all movement commands.
>
> Supposedly these will be changed to use the new function, so they will
> explicitly deactivate the mark if the mark was activated with shift and
> the movement is then performed without the shift.


One problem is that basic movement commands are in C, not in Lisp.

Another problem may be advise on functions - the "shift" handling
may then be performed too late.

Personally, I like my proposal of just setting a "shift" property
on the relevant commands, and do it by running a shifted-key-hook
in the command loop.  

That method has proven to work excellent with CUA mode!

For one thing, it is trivial for a user to add shift-region support
for new movement commands in an external package - without modifying
the code of that package.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Shift-movement selection

[Stefan Monnier]

>>>>> So to make it work "correctly", you need to modify all commands in
>>>>> emacs!  [yikes!]
>>>> Most commands already deactivate the mark.  So which ones would be left?
>> 
>>> Anything that doesn't modify the buffer -- e.g. all movement commands.
>> 
>> Supposedly these will be changed to use the new function, so they will
>> explicitly deactivate the mark if the mark was activated with shift and
>> the movement is then performed without the shift.

> One problem is that basic movement commands are in C, not in Lisp.

Doesn't look like a problem to me.

> Another problem may be advise on functions - the "shift" handling
> may then be performed too late.

The way I see it, the (un)shift handling would be done in the
`interactive' spec of those commands.  Would that be too late?
In which circumstance?

> Personally, I like my proposal of just setting a "shift" property
> on the relevant commands, and do it by running a shifted-key-hook
> in the command loop.

This suffers from the same problems as pre/post-command-hook.

> That method has proven to work excellent with CUA mode!

I know that pre/post-command-hook work just fine for lots of things,
which is why they're provided.  But it's better to avoid them for core
functionality such as the functionality enabled by default.


        Stefan

Re: Shift-movement selection

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
> The way I see it, the (un)shift handling would be done in the
> `interactive' spec of those commands.  Would that be too late?
> In which circumstance?

But if a user wants to use a particular movement function to extend the 
region and the interactive spec says that this function shuld deactivate 
  the mark?

Or am I misunderstanding? Do you say that only commands that have this 
particular `interactive' spec should activate/deactivate the mark 
(depending on whether the shift key was used or not)?

In that case I like the suggestion.

Re: Shift-movement selection

[Richard Stallman]

    Or am I misunderstanding? Do you say that only commands that have this 
    particular `interactive' spec should activate/deactivate the mark 
    (depending on whether the shift key was used or not)?

In general it is not clean for a command's behavior to depend on the
keys that invoked it.  A given command should do a given thing;
then users can make any key do that thing, by binding it to that command.

Re: Shift-movement selection

[Stefan Monnier]

>     Or am I misunderstanding? Do you say that only commands that have this 
>     particular `interactive' spec should activate/deactivate the mark 
>     (depending on whether the shift key was used or not)?

> In general it is not clean for a command's behavior to depend on the
> keys that invoked it.  A given command should do a given thing;
> then users can make any key do that thing, by binding it to that command.

But the feature we're talking about is specifically trying to change the
behavior of those commands depending on whether they're triggered by
a key with or without a shift modifier.  I.e. it's inherent to the
desired functionality.


        Stefan

Re: Shift-movement selection

[Richard Stallman]

    But the feature we're talking about is specifically trying to change the
    behavior of those commands depending on whether they're triggered by
    a key with or without a shift modifier.  I.e. it's inherent to the
    desired functionality.

I thought the desired functionality was that certain non-shift keys
would disable the mark and certain shift keys would enable it.
There are various ways to implement it.

The cleanest way is one based on binding these keys to commands that
will do what is wanted.

There is a question about which commands should do this.  Some want it
to include C-f and all motion commands, but I think that is a bad idea.

If this applies only to arrow keys and a few function keys, it is easy
to do it just by binding those keys.

If this applis to all motion commands, then it is hard to do by
binding all the keys, there being so many, and some rebound in major
modes, too.  So it would need to be implemented by some special
feature that checks for shift.  But I think that is an unclean way to
do things.  Therefore, this is one reason not to make this apply to
all motion commands.

Re: Shift-movement selection

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> If this applis to all motion commands, then it is hard to do by
> binding all the keys, there being so many, and some rebound in major
> modes, too.  So it would need to be implemented by some special
> feature that checks for shift.  But I think that is an unclean way to
> do things.  
>             

I strongly disagree that doing things consistently for the user is
unclean.  

>             Therefore, this is one reason not to make this apply to
> all motion commands.

That is what CUA mode does now - and it works _very_ well.
E.g. to mark a word, line, or sexp, just do S-M-f, S-C-n, or S-C-M-f.

Why force people to use the arrow-keys etc. when we have the
perfect emacs bindings already.


You may argue that some implementations to achieve this are not clean
(such as using the generic pre-command-hook), but using a shifted-key-hook
and 'shift property on movement commands I've suggested is clean
enough for me -- and it has proven to work well in CUA.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Shift-movement selection

[Richard Stallman]

      So it would need to be implemented by some special
    > feature that checks for shift.  But I think that is an unclean way to
    > do things.  
    >             

    I strongly disagree that doing things consistently for the user is
    unclean.  

It is unclean in Emacs to hard-wire the meaning of the shift key.

    That is what CUA mode does now - and it works _very_ well.
    E.g. to mark a word, line, or sexp, just do S-M-f, S-C-n, or S-C-M-f.

    Why force people to use the arrow-keys etc. when we have the
    perfect emacs bindings already.

What bothers me is not that S-C-f would enable the mark, but that C-f
would disable it.  That is an incompatibility in something important.

But if disabling the mark has no effect in the contexts where it now
has no effect -- for instance, with Transient Mark mode off, or
mark-even-if-inactive t, then the incompatibility only affects an
unusual non-default mode of operation, so it is tolerable.

Re: Shift-movement selection

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>       So it would need to be implemented by some special
>     > feature that checks for shift.  But I think that is an unclean way to
>     > do things.  
>     >             
>
>     I strongly disagree that doing things consistently for the user is
>     unclean.  
>
> It is unclean in Emacs to hard-wire the meaning of the shift key.

With CUA mode, I explicitly mark the movement commands (with a CUA property)
to which the shift key should take effect - so there is no hard-wiring
of the shift key.  If you explicitly bind S-<something> to a command which
does not have this property, it will not do the "shift thing"...


>
>     That is what CUA mode does now - and it works _very_ well.
>     E.g. to mark a word, line, or sexp, just do S-M-f, S-C-n, or S-C-M-f.
>
>     Why force people to use the arrow-keys etc. when we have the
>     perfect emacs bindings already.
>
> What bothers me is not that S-C-f would enable the mark, but that C-f
> would disable it.  That is an incompatibility in something important.

With CUA, C-f ONLY disables it if the region was started with S-C-f.
That works very well in practice.

Maybe you could try using CUA-mode (briefly) to try how it feels.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Shift-movement selection

[Thomas Lord]

Maybe it's even simpler than an i-search-like recursive
edit:

I'm not certain how CUA mode works in particular but
"shift-mark mode" in the abstract is a very logical
extension of Emacs' mark-stack model with the added
benefit that it "works like Windows users expect":

Emacs by default lets you push and pop marks on
the stack.

The shift-mark mode concept seems to me to be the
idea of "tentatively" pushing a mark on the mark stack.
It requires a two-phase commit from the user to turn
that into a first-class mark and the default outcome is
to abandon the tentative mark.

To "enter shift-mark mode" is to push a tentative mark.
 From this point on, commands behave as if a mark was
pushed -- but this is a tentative mark and could go away
easily between any two commands.

After pushing a tentative mark, the user edits as normal
with that mark in effect -- but with a catch.   There is
a post-command hook installed that, unless some flag
is flipped by the last command, will discard the tentative
mark.

By default, we want a shifted key-sequence to mean
the same thing as the un-shifted sequence, except that
the flag is flipped and so the tentative mark stays on
the stack.   A single command used as the default binding
of many shifted keys can accomplish that.   That same
command can also arrange to implicitly push a tentative
mark, if invoked when not already in shift-mode.

This saves keystrokes even for hard-core emacs users:
With tentative marks, the default is to discard the mark.
That's very convenient when copying to the kill ring.
Set a tentative mark at one end of what to copy.  Shiftedly
navigate to the other end.  Copy to the kill ring discarding
the tentative mark (or, S-M-w to copy but keep the tentative
mark).  You've added to the kill ring without needing to
clear an item from your mark stack.

Finally, use S-C-space to convert a tentative mark to a
permanent one, when you want.

Implementing this requires a strange function to serve as
the default binding of relevant shifted keys, plus some
hook functions and tweaks to the mark stack to manage
"tentative marks".  Not much else.

-t

Re: Shift-movement selection

[Thomas Lord]

I'll stop be chatty for a bit after this but:

Additionally, have some key binding that turns
a regular mark on the top of the stack into a
tentative mark.

And, instead of "transient mark mode", have
some display mode that highlights the marked
region when and only when the top of the mark
stack is a tentative mark.

Then, in the common situation when I know the
mark I want is buried  on the stack but I'm not
sure where, I can iteratively turn the top of stack
into transient, to see what it is, and then discard
them until I find the one I want.   The kind of
thing one currently does with maddening iterations
of C-xC-x and C-UC-@, but friendlier.

So, summing up:

Shift-marking can be really nice even for
classic-style Emacs "power users" and it can
be implemented as a combination of a post-command
hook (installed and removed on the fly) plus
a default binding (mildly hairy) for shifted keys.

-t

Re: Shift-movement selection

[tomas]

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

(cc: snipped)

On Wed, Mar 12, 2008 at 05:07:22PM -0700, Thomas Lord wrote:
> I'll stop be chatty for a bit after this but:

Not that I consider myself representative (by a far stretch) here, but
fwiw I do appreciate your chattiness...

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

iD8DBQFH2OWsBcgs9XrR2kYRAi9UAJ99tsgZ2mc+tiBRq+ac0YsIyRzBUwCfTvF0
7GBbN/SSN25iJJ9jCQ8feXo=
=MF+x
-----END PGP SIGNATURE-----

Re: Shift-movement selection

[Alan Mackenzie]

Hi, Kim!

On Mon, Mar 10, 2008 at 04:06:54PM +0100, Kim F. Storm wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >>>> So to make it work "correctly", you need to modify all commands in
> >>>> emacs!  [yikes!]
> >>> Most commands already deactivate the mark.  So which ones would be left?

> >> Anything that doesn't modify the buffer -- e.g. all movement commands.

> > Supposedly these will be changed to use the new function, so they will
> > explicitly deactivate the mark if the mark was activated with shift and
> > the movement is then performed without the shift.


> One problem is that basic movement commands are in C, not in Lisp.

Why not introduce an after-move-hook, somewhat akin to after-change-hook?
Possibly as a normal hook, possibly one where each function takes a
single parameter, the old value of point.  

> Another problem may be advise on functions - the "shift" handling
> may then be performed too late.

> Personally, I like my proposal of just setting a "shift" property
> on the relevant commands, and do it by running a shifted-key-hook
> in the command loop.  

Assuming Emacs knows whether the shift key is currently depressed (it
does, doesn't it, by looking at the key sequence?) the after-move-hook
could be ideal place to deal with "shift"-movement actions.

> That method has proven to work excellent with CUA mode!

> For one thing, it is trivial for a user to add shift-region support
> for new movement commands in an external package - without modifying
> the code of that package.

> -- 
> Kim F. Storm <storm@cua.dk> http://www.cua.dk

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Shift-movement selection

[Lennart Borgman (gmail)]

Alan Mackenzie wrote:
> Why not introduce an after-move-hook, somewhat akin to after-change-hook?
> Possibly as a normal hook, possibly one where each function takes a
> single parameter, the old value of point.  

This is rather similar to what I proposed in anohter message (the 
post-post-command hook), but I would prefer a more general hook. BTW is 
there a way to check if the last command was indeed a move in the 
current buffer?

And, for the turn on of the region a pre-pre-command hook could be used.

> Assuming Emacs knows whether the shift key is currently depressed (it
> does, doesn't it, by looking at the key sequence?) the after-move-hook
> could be ideal place to deal with "shift"-movement actions.

Is not that too late?

Re: Shift-movement selection

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Alan Mackenzie wrote:
>> Why not introduce an after-move-hook, somewhat akin to after-change-hook?
>> Possibly as a normal hook, possibly one where each function takes a
>> single parameter, the old value of point.  
>
> This is rather similar to what I proposed in anohter message (the
> post-post-command hook), but I would prefer a more general hook. BTW
> is there a way to check if the last command was indeed a move in the
> current buffer?
>
> And, for the turn on of the region a pre-pre-command hook could be used.
>
>> Assuming Emacs knows whether the shift key is currently depressed (it
>> does, doesn't it, by looking at the key sequence?) the after-move-hook
>> could be ideal place to deal with "shift"-movement actions.
>
> Is not that too late?

I have not properly followed the discussion.  Has anybody proposed or
rejected adding some letter to the interactive string to mark
shift-sensitive movement commands?  It would be reasonably easy to
interpret this in C-h k and its ilk.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Shift-movement selection

[Lennart Borgman (gmail)]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Alan Mackenzie wrote:
>>> Why not introduce an after-move-hook, somewhat akin to after-change-hook?
>>> Possibly as a normal hook, possibly one where each function takes a
>>> single parameter, the old value of point.  
>> This is rather similar to what I proposed in anohter message (the
>> post-post-command hook), but I would prefer a more general hook. BTW
>> is there a way to check if the last command was indeed a move in the
>> current buffer?
>>
>> And, for the turn on of the region a pre-pre-command hook could be used.
>>
>>> Assuming Emacs knows whether the shift key is currently depressed (it
>>> does, doesn't it, by looking at the key sequence?) the after-move-hook
>>> could be ideal place to deal with "shift"-movement actions.
>> Is not that too late?
> 
> I have not properly followed the discussion.  Has anybody proposed or
> rejected adding some letter to the interactive string to mark
> shift-sensitive movement commands?  It would be reasonably easy to
> interpret this in C-h k and its ilk.

Not sure, but that is what I think Stefan did.

Re: Shift-movement selection

[Stefan Monnier]

>> I have not properly followed the discussion.  Has anybody proposed or
>> rejected adding some letter to the interactive string to mark
>> shift-sensitive movement commands?  It would be reasonably easy to
>> interpret this in C-h k and its ilk.

> Not sure, but that is what I think Stefan did.

Pretty much, except I haven't actually suggested to provide a letter for
it, just a function for use in the interactive spec, but providing
a letter for it did cross my mind, indeed (tho I'm not sure it'd be
a good idea or not).


        Stefan

Re: Shift-movement selection

[Richard Stallman]

    I have not properly followed the discussion.  Has anybody proposed or
    rejected adding some letter to the interactive string to mark
    shift-sensitive movement commands?  It would be reasonably easy to
    interpret this in C-h k and its ilk.

That could be a good method.  It has the advantage that the command
definition controls 100% of the behavior.

It is somewhat ugly that the command behaves differently depending on
what key it is bound to, but at least that happens according to a
simple system, which makes it less ugly than it might have been.

Re: Shift-movement selection

[Richard Stallman]

    Why not introduce an after-move-hook, somewhat akin to after-change-hook?

If the idea is that Fgoto-char and other point-setting primitives
would call this, that would be hard to implement safely and it slow
down Lisp programs terribly.

Re: Shift-movement selection

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Why not introduce an after-move-hook, somewhat akin to after-change-hook?
>
> If the idea is that Fgoto-char and other point-setting primitives
> would call this, that would be hard to implement safely and it slow
> down Lisp programs terribly.

Maybe the idea is to simply call the hook if point after executing the command
is different from the value before the command.  It may be useful, but
I'm not sure it will do the trick... for the shift-move function.
 
-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Shift-movement selection

[Thomas Lord]

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

An idea:  Shift-select has pretty close to the same
"semantics" as recursive edits, when viewed from
the point of view of an emacs interaction loop.
So, use a mechanism pretty close to recursive edits
to implement shift-select.   Two variations on the
idea are given here.   One that does in fact have a
recursive command loop;  a second that fakes having
a recursive command loop using minor modes:

In the default key-maps, bind all shifted keys to a single
command we can call enter-implicit-select-mode

That command essentially begins a recursive edit:

enter-implicit-select-mode should first remember where
the point is starting from, then recursively call the
command that would have been invoked without
the shift (this may require reading more keys from the
user).

enter-implicit-select-mode should then read
key-sequences, mapping them the usual way
in key maps, but examining the function to be
invoked before invoking it.   If the mapped
function is, again, enter-implicit-select-mode
then don't recurse but do look up the unshifted
binding and call that interactively.   If the
mapped function is some other function,
then directly call that function interactively,
but immediately return from enter-implicit-select-mode's
recursive edit afterwards (terminating "shift select").

Commands for cutting, copying, wiping, yanking
etc. would still need to be handled specially and
might benefit from some separate mechanism for
telling enter-implicit-select-mode to not exit its
loop, yet.    In other words, a small number of commands
can be modified to continue shift-selection even if they
are not invoked by a shifted key-sequence.

Some modes might already have shift-bindings that
conflict with this.    Oh well, those need individual
attention anyway.

Recursive edits, as described, might not be quite
right.   A similar effect could be achieved with
minor-modes, I think.   A "ghostly" minor mode
could have no extended key-sequences and map
*all* keys to a function saves up the list of keys
pressed so far until they map to a binding in the
underlying keymaps of the buffer (then call the
right commands interactively, adjust whether shift-select
is going on, possibly de-install the ghostly minor mode,
etc.)

Either way, one advantage might be that nothing
is particular "shift specific".   A user who prefered
"hyper-select-mode" (or whatever) could have that
and the same mechanisms would still work.

Another advantage is that most commands would
not need to change.   

Another advantage is that, while this approach does
*slightly* change the way input key-sequences
invoke commands, it's really a very slight change
and mostly transparent to users.

A practical advantage is that it would probably
"mostly work" and almost never fail or surprise
in horrible ways.    It does (I *think*) 80% of the
job "for free" and then makes it easy to go and
patch up the remaining annoyances "by hand" as
they come to attention.

-t


Kim F. Storm wrote:
> Richard Stallman <rms@gnu.org> writes:
>
>   
>>     Why not introduce an after-move-hook, somewhat akin to after-change-hook?
>>
>> If the idea is that Fgoto-char and other point-setting primitives
>> would call this, that would be hard to implement safely and it slow
>> down Lisp programs terribly.
>>     
>
> Maybe the idea is to simply call the hook if point after executing the command
> is different from the value before the command.  It may be useful, but
> I'm not sure it will do the trick... for the shift-move function.
>  
>   


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

Re: Shift-movement selection

[Richard Stallman]

    An idea:  Shift-select has pretty close to the same
    "semantics" as recursive edits, when viewed from
    the point of view of an emacs interaction loop.

I have to say they don't seem very similar to me
in their behavior.

Re: Shift-movement selection

[Thomas Lord]

Richard Stallman wrote:
>     An idea:  Shift-select has pretty close to the same
>     "semantics" as recursive edits, when viewed from
>     the point of view of an emacs interaction loop.
>
> I have to say they don't seem very similar to me
> in their behavior.
>
>   


Maybe a better way to say it:

"Shift-select" strikes me as a single command.   There
should be an interactive "shift-select" command.

That command takes the sequence that invoked it and,
if it is shifted, removes the shift modifier and looks up
the binding, then runs that command.  After the command
completes, shift-select updates the "shift-selected region".

The shift-select command then enters a loop, reading
key-sequences against the current key-maps.   If a
key-sequence is read that maps to the shift-select command
itself, then again, the shift is removed, the binding
checked again, the new command recursively invoked,
and the shift-select loop continues.

Otherwise, normally, the shift-select loop exits.
As an exception, functions can set a flag that will
cause shift-select to keep looping (after clearing
the flag).

Finally, add a higher-order command generator:

   (shift-select-variant 'some-command)

which returns a function that, when invoked, sets the
flag that keeps select-mode going (or enters select mode)
and then interactively invokes "some-command".

Default bindings to shift-select itself do most of the work.

Further customization can be done by binding sequences
to either shift-select or to some (shift-select-variant 'X).

No?

A nice feature would be an "interactive" declaration
(as someone mentioned) that, in this model, would set
the shift-mode-continue flag.   That way, commands could
be easily written that would only continue shift mode
if they are called interactively.

I'm sorry if I'm misunderstanding the problem but would
appreciate knowing *how* I'm misunderstanding it.

-t

Re: Shift-movement selection

[Richard Stallman]

Now I understand your proposal.  I don't see how it would handle the
issue of making non-shift movement commands deactivate the mark, but
maybe it can be made to do that.

However, I tend to think that the use of the special character in
`interactive' to indicate these commands is a cleaner method overall.

Re: Shift-movement selection

[Thomas Lord]

Richard Stallman wrote:
> Now I understand your proposal.  I don't see how it would handle the
> issue of making non-shift movement commands deactivate the mark, but
> maybe it can be made to do that.
>   

I have accidentally confused things by making, now, three proposals.
Of the three, I particularly like the last.

One proposal is coded almost like i-search as a sorta-kinda
recursive edit.   Non-shift movement commands de-activate
that because deactivation is the default for all commands
which either (a) do not explicitly set a flag otherwise or (b) are
*not* invoked via a shifted keysequence whose binding is
found by defaulting to the unshifted sequence.    That works
but the third one is simpler.

Proposal #2 is similar to #1 but hairier, using minor mode
foo to .... nevermind... the third one is simpler.

Proposal #3 could be re-expressed as:

    Function: enter-shift-mark-mode
    Install the shift-mark-mode-post-command-hook and record the
    point as the tentative mark.

    Function: abandon-shift-mark-mode
    Toss the tentative mark and remove the post command hook

    Function: seal-the-deal-from-shift-mark-mode
    Turn the tentative mark into a normal mark.

    Function: shift-mark-mode-post-command-hook
    If the last command set the right flag, keep the tentative
    mark.   Otherwise, if the last command was invoked by
    defaulting a shifted key-sequence to non-shifted, then
    again keep the tentative mark.   Otherwise, abandon-shift-mark-mode.

    Function: unbound-shift-key-treat-as-enter-shift-mark-mode
    Remove the shift from the keysequence that invoked this command,
    enter-shift-mark-mode, and process the simplified keysequence.

and various convenience functions related to that basis.  Make
the default binding of various shift keys be 
"unbound-shift-key-treat-as-...."


I think #3 could be the best of the lot.



> However, I tend to think that the use of the special character in
> `interactive' to indicate these commands is a cleaner method overall.
>
>   

Works both ways, here.   The underlying enter-shift-mark-mode could
be bound all by itself to a key or, if some prefer, can be called via
unbound-shift-key-treat-as-enter-shift-mark-mode.

The key thing is getting the "semantics of the mark ring" right.
The mistake we've all been making (and me with proposals #1
and #2) is to think that shift-mark state has to be in the command
loop.   Instead, it's a 1-bit flag for the top of the mark stack: the 
distinction
between a normal and a "tentative" mark, where "tentative" marks only
ever occur on the top of the mark stack.


-t



>
>   

Re: Shift-movement selection

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Anything that doesn't modify the buffer -- e.g. all movement commands.
>
> Supposedly these will be changed to use the new function, so they will
> explicitly deactivate the mark if the mark was activated with shift and
> the movement is then performed without the shift.
>
> So again, which ones would be left?

Are you serious?  You intend to modify _every_ movement command in
Emacs, and require that users modify whatever commands they have
written?   You intend to do this when a simple, clean, and more general
solution exists, with no apparent downsides?

Why?

Maybe for activating shift-selection, annotating commands is the  best we
can do, but it's very clear that for deactivating it, we can do better.

-Miles

-- 
Laughter, n. An interior convulsion, producing a distortion of the features
and accompanied by inarticulate noises. It is infectious and, though
intermittent, incurable.

Re: Shift-movement selection

[Stefan Monnier]

>>> Anything that doesn't modify the buffer -- e.g. all movement commands.
>> 
>> Supposedly these will be changed to use the new function, so they will
>> explicitly deactivate the mark if the mark was activated with shift and
>> the movement is then performed without the shift.
>> 
>> So again, which ones would be left?

> Are you serious?  You intend to modify _every_ movement command in
> Emacs, and require that users modify whatever commands they have
> written?

Actually, that's not a requirement.  The failure to change one such
command is pretty harmless.  It just means that you can't combine the
command with a shift to select the region, and that if the region was
selected with a shift and you use this command without a shift, it will
fail to deactivate the region.  The first will disappoint the user, and
the second may surprise him (tho pc-select worked this way for years
before someone complained), but neither sounds terrible, so the commands
can be changed little-by-little.

> You intend to do this when a simple, clean, and more general
> solution exists, with no apparent downsides?

Haven't yet seen other "simple and clean" solutions.

> Maybe for activating shift-selection, annotating commands is the  best we
> can do, but it's very clear that for deactivating it, we can do better.

If a change is needed for activation, I see no harm in using the same
change for deactivation.

This said, I'm not opposed to using the `only' thingy for the
deactivation.


        Stefan

Re: Shift-movement selection

[Richard Stallman]

    > Anything that doesn't modify the buffer -- e.g. all movement commands.

    Supposedly these will be changed to use the new function, so they will
    explicitly deactivate the mark if the mark was activated with shift and
    the movement is then performed without the shift.

I don't think we should change the behavior of the ordinary motion commands.

Re: Shift-movement selection

[Richard Stallman]

    > AFAICS, such an approach would make deselection much less likely to work
    > consistently:  the way it's _supposed_ to work is that any pretty much
    > any command except for the special shifted versions should cause
    > deactivation -- and in emacs that's pretty much _every command_.
    > So to make it work "correctly", you need to modify all commands in
    > emacs!  [yikes!]

    Most commands already deactivate the mark.  So which ones would be left?
    Do they matter?

Ordinary Emacs cursor motion commands such as C-f should not normally
deactivate the mark.  That would be a painfully incompatible change.

Re: Shift-movement selection

[Stefan Monnier]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

>> AFAICS, such an approach would make deselection much less likely to work
>> consistently:  the way it's _supposed_ to work is that any pretty much
>> any command except for the special shifted versions should cause
>> deactivation -- and in emacs that's pretty much _every command_.
>> So to make it work "correctly", you need to modify all commands in
>> emacs!  [yikes!]

>     Most commands already deactivate the mark.  So which ones would be left?
>     Do they matter?

> Ordinary Emacs cursor motion commands such as C-f should not normally
> deactivate the mark.  That would be a painfully incompatible change.

The part of the discussion you clipped said:

>>> (defun activate-on-shift-selecting-movement ()
>>>   (if (this-command-keys-are-shifted-p)
>>>       (progn
>>>         (setq shift-selecting-movement t)
>>>         (unless mark-active (set-mark)))
>>>     (when shift-selecting-movement
>>>       (setq shift-selecting-movement nil)
>>>       (when mark-active (deactivate-mark)))))
>>> 
>>> and then call it from wherever it's considered useful
>>> (e.g. forward-char, next-line, ...).

so cursor motion commands such as C-f would still not normally
deactivate the mark, except when the mark was activated by
a shifted key.  This is the desired behavior.  CUA implements it, and
pc-select was "recently" changed to do the same.


        Stefan

Re: Shift-movement selection

[Richard Stallman]

    so cursor motion commands such as C-f would still not normally
    deactivate the mark, except when the mark was activated by
    a shifted key.  This is the desired behavior.

I doubt that such a broad change is good.

Also, it is rather painful to implement, since there are dozens of
cursor motion commands, if not hundreds.  Lots of modes have their
own motion commands.

I think the only reliable way to implement that feature--if we want
it--is to do it in the main loop, after the command returns, if it has
moved point.  But that hard-wires the meaning of non-shift, which is
very non-Emacs-y.

Re: Shift-movement selection

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     so cursor motion commands such as C-f would still not normally
>     deactivate the mark, except when the mark was activated by
>     a shifted key.  This is the desired behavior.
> 
> I doubt that such a broad change is good.
> 
> Also, it is rather painful to implement, since there are dozens of
> cursor motion commands, if not hundreds.  Lots of modes have their
> own motion commands.
> 
> I think the only reliable way to implement that feature--if we want
> it--is to do it in the main loop, after the command returns, if it has
> moved point.  But that hard-wires the meaning of non-shift, which is
> very non-Emacs-y.

Not if it is done in a separate post-post-command-hook. (And a similar 
pre-pre-command-hook at other side.)

Re: Shift-movement selection

[Richard Stallman]

    Not if it is done in a separate post-post-command-hook. (And a similar 
    pre-pre-command-hook at other side.)

That is both ineffeciant and kludgy.
And it would, more or less, hard-wire shift, in that it would
be hard to override the "standard" meaning of shift
for any one command.  Yes, you could eliminate it entirely,
but that is inflexible.

Re: Shift-movement selection

[Alan Mackenzie]

On Sun, Mar 09, 2008 at 11:37:27PM -0400, Stefan Monnier wrote:
> >> (defun activate-on-shift-selecting-movement ()
> >> (if (this-command-keys-are-shifted-p)
> >> (progn
> >> (setq shift-selecting-movement t)
> >> (unless mark-active (set-mark)))
> >> (when shift-selecting-movement
> >> (setq shift-selecting-movement nil)
> >> (when mark-active (deactivate-mark)))))
> >> 
> >> and then call it from wherever it's considered useful
> >> (e.g. forward-char, next-line, ...).

> > AFAICS, such an approach would make deselection much less likely to work
> > consistently:  the way it's _supposed_ to work is that any pretty much
> > any command except for the special shifted versions should cause
> > deactivation -- and in emacs that's pretty much _every command_.
> > So to make it work "correctly", you need to modify all commands in
> > emacs!  [yikes!]

> Most commands already deactivate the mark.  So which ones would be left?

Scrolling commands should not deactivate the mark; things like C-l,
C-M-l, .....  After all, you're going to be wanting to shift point to
the middle of the screen to see more of what you might want to put into
the region.  C-x 2 should not deactivate the mark, neither should
commands which operate on the other window (such as
scroll-other-window-down).  In fact, more or less all commands with the
'isearch-scroll property could usefully have a 'no-demarkation property.

> Do they matter?

Yes, they matter very much.  Well, they would for me if I were to start
using shift-movement to extend a region.  Two of the most inhibiting
things for me whilst using a "lowest common denominator" editor are the
fear of a painsteakingly created region vanishing in a puff of smoke at a
careless keypress, and the annoyance of practically all the features of
the editor being unavailable whenever I have a region I don't want to
lose.  It would be nice, at least for me, for these annoyances to be
reduced as far as possible.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: position on changing defaults?

[Stefan Monnier]

> How about adding a new type of binding, a "modifier binding", which
> could serve to implement CUA movement, and replace the current automatic
> S-foo => foo remapping.

I'm not sure I understand what you're proposing.
One thing we can do right now is:

  (define-key function-key-map [S-up]
    (lambda (prompt) (setq foo-shited t) [up]))

and one thing I'd like to do is to replace the C-level mapping of S-foo
to foo by some entry in function-key-map.  This requires extending the
function-key-map mechanism, tho.  I don't know what it would look like,
but just to make it more concrete, here's one possible way:

  (define-key function-key-map [S-*]
    (lambda (prompt key) (vector (remove-shift key))))

Obviously, this can't work as is.  Maybe an even better generalization
would be

  (define-key function-key-map [is-shifted-p]
    (lambda (prompt key) (vector (remove-shift key))))
  (define-key function-key-map [is-mouse-4-p]
    (lambda (prompt key)
      (vector (combine-modifiers (modifiers key) 'mwheel-up)))

where `is-shifted-p' and `is-mouse-4-p' are Lisp functions.


        Stefan

Re: position on changing defaults?

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> How about adding a new type of binding, a "modifier binding", which
>> could serve to implement CUA movement, and replace the current automatic
>> S-foo => foo remapping.
>
> I'm not sure I understand what you're proposing.

Essentially, this:

> and one thing I'd like to do is to replace the C-level mapping of S-foo
> to foo by some entry in function-key-map.

-Miles
-- 
Innards, n. pl. The stomach, heart, soul, and other bowels.

Re: position on changing defaults?

[Richard Stallman]

    > and one thing I'd like to do is to replace the C-level mapping of S-foo
    > to foo by some entry in function-key-map.

That mapping is just a fallback: it has no effect if S-foo has a
binding of its own.  So why not just bind the arrow keys and the
shifted arrow keys to 8 commands that DTRT?

Re: position on changing defaults?

[Richard Stallman]

    I'm not sure I understand what you're proposing.
    One thing we can do right now is:

      (define-key function-key-map [S-up]
	(lambda (prompt) (setq foo-shited t) [up]))

It is rather kludgy to set `foo-shited' that way.
(And can you be sure it is reliably reset to nil?
What if you type C-g at the wrong moment?)

Why do this rather than directly bind S-up to a command
that does exactly what is wanted?

Re: position on changing defaults?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I'm not sure I understand what you're proposing.
>     One thing we can do right now is:
>
>       (define-key function-key-map [S-up]
> 	(lambda (prompt) (setq foo-shited t) [up]))
>
> It is rather kludgy to set `foo-shited' that way.
> (And can you be sure it is reliably reset to nil?
> What if you type C-g at the wrong moment?)
>
> Why do this rather than directly bind S-up to a command
> that does exactly what is wanted?


I have rechecked the relevant code - and it seems the S- checking
hacks for ttys is no longer used by cua-mode; it works to check
for the shift modifier in the current key sequence on ttys as well.

Sorry for the noise (in this specific area).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Obviously, this can't work as is.  Maybe an even better generalization
> would be
>
>   (define-key function-key-map [is-shifted-p]
>     (lambda (prompt key) (vector (remove-shift key))))
>   (define-key function-key-map [is-mouse-4-p]
>     (lambda (prompt key)
>       (vector (combine-modifiers (modifiers key) 'mwheel-up)))
>
> where `is-shifted-p' and `is-mouse-4-p' are Lisp functions.

The argument against using pre-command-hook and post-command-hook is 
efficiency - the above seems a lot less efficient (I suppose you have
to run all such lisp functions until you find one which returns
true) - which also means that the sequence of key bindings in 
the keymaps start to matter...

IMO, this interface is even worse that using the current hooks!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Stefan Monnier]

>> Obviously, this can't work as is.  Maybe an even better generalization
>> would be
>> 
>> (define-key function-key-map [is-shifted-p]
>> (lambda (prompt key) (vector (remove-shift key))))
>> (define-key function-key-map [is-mouse-4-p]
>> (lambda (prompt key)
>> (vector (combine-modifiers (modifiers key) 'mwheel-up)))
>> 
>> where `is-shifted-p' and `is-mouse-4-p' are Lisp functions.

> The argument against using pre-command-hook and post-command-hook is 
> efficiency

Actually, for me it is not.  The issue is reliability, maintainability
and debuggability.

This said, the use of a function-key-map binding which sets a variable
is just as bad as a pre-command-hook, if not worse.

OTOH I find the above two examples of "generic function-key-map
bindings" desirable.  Note that they have nothing to do with
pre-command-hook: they just move a hardcoded C-level feature to elisp
(well, the first is in C, the other doesn't exist because I don't want to
add it to the C code but I don't have any clean way to do it in elisp
right now).  More specifically, I feel like anything that will help
reduce the complexity of read_key_sequence is desirable.


        Stefan


PS: And yes, I plead guilty to adding input-decode-map recently which made
it more complex.

Re: position on changing defaults?

[Richard Stallman]

    OTOH I find the above two examples of "generic function-key-map
    bindings" desirable.  Note that they have nothing to do with
    pre-command-hook: they just move a hardcoded C-level feature to elisp
    (well, the first is in C, the other doesn't exist because I don't want to
    add it to the C code but I don't have any clean way to do it in elisp
    right now).

Do you mean that these transformations would be defaults, only
to be used when there is no direct binding -- like the current default
transformations of shifted to nonshifted events?

That seems like a clean feature, if it is useful.

However, I have a bad feeling about using this to implement something
that makes _all_ shift keys do something special.

Binding some set of shifted keys to a command that says "run the
equivalent non-shifted character but do this other special thing"
seems better, because you could override that for individual shifted
keys if you wish.

Re: position on changing defaults?

[Stefan Monnier]

>     OTOH I find the above two examples of "generic function-key-map
>     bindings" desirable.  Note that they have nothing to do with
>     pre-command-hook: they just move a hardcoded C-level feature to elisp
>     (well, the first is in C, the other doesn't exist because I don't want to
>     add it to the C code but I don't have any clean way to do it in elisp
>     right now).

> Do you mean that these transformations would be defaults, only
> to be used when there is no direct binding -- like the current default
> transformations of shifted to nonshifted events?

Yes, of course: function-key-map bindings only apply when there's no
direct binding.

> However, I have a bad feeling about using this to implement something
> that makes _all_ shift keys do something special.

Agreed.  I was only asking Miles what modification of key-remapping he
was thinking about.


        Stefan

Re: position on changing defaults?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Binding some set of shifted keys to a command that says "run the
> equivalent non-shifted character but do this other special thing"
> seems better, because you could override that for individual shifted
> keys if you wish.

The problem is that running something based on the key - rather
than on the command bound to that key is a bad road to take.

CUA mode looks for a 'CUA property with value 'move to detect what
keys are movements to which the shift modifier may apply.
This has the advantage that unrelated modes simply set that property
to make them "CUA aware".  

A generic solution could be to look for a non-nil 'shift property on
the command and run a shifted-key-hook prior to running the command,
i.e. something like this in the command loop just before running the
command:

          if (!NILP (Vshifted_key_hook) && key_shifted_p
             && !NILP (Vthis_command)
             && SYMBOLP (Vthis_command)
             && !NILP (Fget (Vthis_command, Qshift))
             && !NILP (Vrun_hooks))
            safe_run_hooks (Qshifted_key_hook);
            
This could be combined with the delayed deactivate-mark hack
we discussed earlier to deactivate the mark on non-shifted movement...

I can make a patch to do this...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Lennart Borgman (gmail)]

Kim F. Storm wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
>> Binding some set of shifted keys to a command that says "run the
>> equivalent non-shifted character but do this other special thing"
>> seems better, because you could override that for individual shifted
>> keys if you wish.
> 
> The problem is that running something based on the key - rather
> than on the command bound to that key is a bad road to take.
> 
> CUA mode looks for a 'CUA property with value 'move to detect what
> keys are movements to which the shift modifier may apply.
> This has the advantage that unrelated modes simply set that property
> to make them "CUA aware".  
> 
> A generic solution could be to look for a non-nil 'shift property on
> the command and run a shifted-key-hook prior to running the command,
> i.e. something like this in the command loop just before running the
> command:
> 
>           if (!NILP (Vshifted_key_hook) && key_shifted_p
>              && !NILP (Vthis_command)
>              && SYMBOLP (Vthis_command)
>              && !NILP (Fget (Vthis_command, Qshift))
>              && !NILP (Vrun_hooks))
>             safe_run_hooks (Qshifted_key_hook);
>             
> This could be combined with the delayed deactivate-mark hack
> we discussed earlier to deactivate the mark on non-shifted movement...
> 
> I can make a patch to do this...

Maybe this could be done using a pre-emulation-command-hook run before 
pre-command-hook? (Compare emulation-mode-maps.)

Then some code similar to the code Stefan just sent could be used. That 
code could look for the CUA property. Maybe it also could look in a 
table when deciding whether to deactivate the mark.

Re: position on changing defaults?

[Richard Stallman]

    > Binding some set of shifted keys to a command that says "run the
    > equivalent non-shifted character but do this other special thing"
    > seems better, because you could override that for individual shifted
    > keys if you wish.

    The problem is that running something based on the key - rather
    than on the command bound to that key is a bad road to take.

I am having trouble understanding that sentence, but it leads me to
suspect we are miscommunicating.  What I proposed is a command that we
would bind certain shifted keys to.  This command would look up the
binding of the corresponding non-shifted key and call it.
I think that is _less_ "based on the key" than your proposal.

	      if (!NILP (Vshifted_key_hook) && key_shifted_p
		 && !NILP (Vthis_command)
		 && SYMBOLP (Vthis_command)
		 && !NILP (Fget (Vthis_command, Qshift))
		 && !NILP (Vrun_hooks))
		safe_run_hooks (Qshifted_key_hook);

This is not horrible, since rebinding the shift key to some other
unrelated command will still work.

But my solution has the virtue of being less magic.
My solution puts it entirely under the control of the
key binding of the shifted key, instead of a magic property
of shifted keys that causes them to behave differently with
the same binding.

Re: position on changing defaults?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> I am having trouble understanding that sentence, but it leads me to
> suspect we are miscommunicating.  What I proposed is a command that we
> would bind certain shifted keys to.  This command would look up the
> binding of the corresponding non-shifted key and call it.

Ok, that makes sense.

Now, if can make eg. C-h k S-down show the doc string for 
both the shift-region effect AND for the original command,
it would be great.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Lennart Borgman (gmail)]

Kim F. Storm wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
>> I am having trouble understanding that sentence, but it leads me to
>> suspect we are miscommunicating.  What I proposed is a command that we
>> would bind certain shifted keys to.  This command would look up the
>> binding of the corresponding non-shifted key and call it.
> 
> Ok, that makes sense.
> 
> Now, if can make eg. C-h k S-down show the doc string for 
> both the shift-region effect AND for the original command,
> it would be great.

Even greater would perhaps be if C-h k down also showed both too?

Re: position on changing defaults?

[Richard Stallman]

    The argument against using pre-command-hook and post-command-hook is 
    efficiency

That is one argument, but I posted other arguments.

Also note that the de-shifting mechanism is more efficient because it
would only run for shift keys, whereas pre-command-hook and
post-command-hook run for every command.

However, I don't like the de-shifting approach because that imposes a
meaning on all shift commands that cannot be overridden by rebinding
them.  I don't think we should do that, regardless of the precise
mechanism.

Re: position on changing defaults?

[Richard Stallman]

    Unfortunately, I see no way of implementing this in simple.el without
    using pre-command-hook and post-command-hook.  It seems this can be
    implemented only in C in the function that reads characters.

Maybe I can see a way to do it using nicer underlying mechanisms.
I am not entirely sure what the feature does; what does it need
these hooks for?

Miles wrote:

    How about adding a new type of binding, a "modifier binding", which
    could serve to implement CUA movement, and replace the current automatic
    S-foo => foo remapping.

I do not understand -- what would this "modifier binding" mean,
and how would you use it for this?

    Basically, these would be bindings that represent event-modifiers only.
    If normal key lookup fails, the keymapping mechanism would then look up
    and invoke the modifier binding corresponding to the modifiers on the
    key, and invoke it instead; the invoked function could then, if it
    wished (e.g. for CUA), set some variables or frob some state and
    re-invoke the event with the modifiers removed.

I am still not sure I understand.  If it means a kind of default
binding for all Shift keys that have no individual binding,
why is that better than binding the four shift-arrow keys
in the global map?

    In general, I agree with the idea of exposing the translation of unbound
    event-modified keys to Lisp functions that can process untranslated keys.
    Maybe it would be possible to implement the following interface to define
    such bindings?

    (define-key global-map [(shift untranslated)]
      (lambda ()
	(interactive)
	(when (and transient-mark-mode (not mark-active))
	   (push-mark-command nil nil))))

What does (shift untranslated) mean, and what would it do?  And how
does it relate to this feature?

Re: position on changing defaults?

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

>> - selection with Shift-arrow keys
>
> I think this would be a good default.  If someone is willing to make a
> patch that refactors this code from cua-mode into simple.el, it would
> be worth considering.

So you want just shift-arrows to start/expand the region.

And transient-mark-mode on top of that...

Sort of like cua-selection-mode, but not quite ... 
Then don't start from cua-mode!

Or use cua-selection-mode - to get all the benefits it provides!

cua-selection-mode will start/expand the region not just for
the shift-arrow keys, but (in practice) any shifted movement key.  

If that is the objection to using cua-selection-mode, I could add a
customize option to limit it to just the arrow keys.  If not,
please explain what else is wrong with cua-selection-mode.
(oh yes, it also has delete-selection-mode on, but again,
that's a feature which could be optional in cua-selection-mode).

It also gives you the rectangle highlighting (which I think most
users would agree is quite useful) combined with the ability to
use the normal region kill, copy and yank keys also for rectangles.
So there's no need to learn a different command set for rectangles!

I don't see why it is really necessary to insist on refactoring
cua-(selection-)mode for these features to be used by default.
IMO, the time is better spent on writing/improving the documentation
for the cua features!

BTW, why is using a pre- or post- command hook so bad?


Also, why is it necessary to refactor it into simple.el -- it's
not that simple :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> BTW, why is using a pre- or post- command hook so bad?

Because the more packages use those, the slower _basic_ Emacs usage gets.

Many packages are tempted to use them, because they're a quick-and-easy
way to do things; but if _everybody_ starts using them, wham, suddenly
emacs bogs down.  For this reason, we should discourage their use as far
as possible, _especially_ in stuff that's on by default.

Maybe in some cases using them is unavoidable, and the benefit is worth
the cost, and maybe cua mode is such a case -- but OTOH, maybe we can
find a better way.  I think we should try anyway, and if cua or some
cua-like selection mode is to be on by default, it's more important that
we try.

> Or use cua-selection-mode - to get all the benefits it provides!
...
> Also, why is it necessary to refactor it into simple.el -- it's
> not that simple :-)

It may or may not be simple, but easily separated small features are
much more understandable and maintainable, not to mention more elegant.

Giant do-everything gob-modes are bad in general, _especially_ if
they're turned on by default.

-Miles

-- 
Friendless, adj. Having no favors to bestow. Destitute of fortune. Addicted to
utterance of truth and common sense.

Re: position on changing defaults?

[Lennart Borgman (gmail)]

Kim F. Storm wrote:
> Or use cua-selection-mode - to get all the benefits it provides!

I really agree. Beside what Kim mentioned I think it is important to 
keep the default Emacs key usage as close to those in other applications 
as possible (without breaking Emacs use of C-x etc of course) and then 
cua-selection-mode is the natural choice.

Re: position on changing defaults?

[Bastien]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Kim F. Storm wrote:
>> Or use cua-selection-mode - to get all the benefits it provides!
>
> I really agree. Beside what Kim mentioned I think it is important to
> keep the default Emacs key usage as close to those in other applications
> as possible (without breaking Emacs use of C-x etc of course) and then
> cua-selection-mode is the natural choice.

I don't buy the argument "keep it close to other applications".

It's not that I don't buy it *at all*, it's just that I'm a bit worried
people think of this argument as being straightforward.

If a software adopts a widely used convention, it is first a benefit for
the convention itself: it extends its realm.  Then it might be a benefit
for the software himself in two very differents ways: if it helps making
the sofware more popular, or if it improves it.

I'm not arguing that a new feature feature should always improve the
software, I'm just saying that making the software more "conventional"
is barely sufficient for switching to a new feature...

My 2 cents,

-- 
Bastien

Re: position on changing defaults?

[Stefan Monnier]

> cua-selection-mode will start/expand the region not just for
> the shift-arrow keys, but (in practice) any shifted movement key.

That's fine.  I don't think it matters much whether it does or not.

> It also gives you the rectangle highlighting (which I think most
> users would agree is quite useful) combined with the ability to
> use the normal region kill, copy and yank keys also for rectangles.
> So there's no need to learn a different command set for rectangles!

Actually, I think the rectangle support is good, although I'd like it to
be a bit more like the normal region highlighting (e.g. same color, C-g
should deactivate it, should be allowed to have 0-width).  The C-g part
is important: I found it difficult to figure out how to "exit" from the
"rectangle-mode".

Also I'm not convinced by the special M-foo bindings and the special
treatment of self-insert-command.  Maybe it's just that I'm used to it,
but I find C-x r t to work at least as well if not better (e.g. it's
not limited to self-inserting keys).

> BTW, why is using a pre- or post- command hook so bad?

These tend to be brittle (e.g. when entering/exiting minibuffer prompts
or recursive edits) and difficult to debug.  I think the need for
pre/post command-hook is often a sign of a missing
functionality elsewhere.


        Stefan

Re: position on changing defaults?

[Richard Stallman]

    > It also gives you the rectangle highlighting (which I think most
    > users would agree is quite useful) combined with the ability to
    > use the normal region kill, copy and yank keys also for rectangles.
    > So there's no need to learn a different command set for rectangles!

    Actually, I think the rectangle support is good, although I'd like it to
    be a bit more like the normal region highlighting (e.g. same color, C-g
    should deactivate it, should be allowed to have 0-width).

That is a separate feature, and a major change in Emacs's region
mechanism.  It may be good, but it calls for careful discussion and
thought.  We should not adopt such a change because it came along
with some other feature.

Re: position on changing defaults?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > It also gives you the rectangle highlighting (which I think most
>     > users would agree is quite useful) combined with the ability to
>     > use the normal region kill, copy and yank keys also for rectangles.
>     > So there's no need to learn a different command set for rectangles!
>
> That is a separate feature, and a major change in Emacs's region
> mechanism.  It may be good, but it calls for careful discussion and
> thought.  We should not adopt such a change because it came along
> with some other feature.

Unless you explicitly hit C-RET, you'll never notice it's there.
And I don't suggest removing the old rectangle commands...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Richard Stallman]

    > That is a separate feature, and a major change in Emacs's region
    > mechanism.  It may be good, but it calls for careful discussion and
    > thought.  We should not adopt such a change because it came along
    > with some other feature.

    Unless you explicitly hit C-RET, you'll never notice it's there.

We are miscommunicating.  I am saying it is a major change in Emacs's
region mechanism.  You're saying the change is not incompatible.  Ok,
but it is still a major change.  It would require major changes in the
Emacs manual.

These different features are separate and unrelated questions, and we
should not let them be tied together by a historical accident the
available code.  The right way to consider various features is one by
one, as independent issues.

I think we should postpone discussion of rectangle selection until the
matter of shift motion is entirely finished with in one way or another.

Re: position on changing defaults?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > That is a separate feature, and a major change in Emacs's region
>     > mechanism.  It may be good, but it calls for careful discussion and
>     > thought.  We should not adopt such a change because it came along
>     > with some other feature.
>
>     Unless you explicitly hit C-RET, you'll never notice it's there.
>
> We are miscommunicating.  I am saying it is a major change in Emacs's
> region mechanism.  

I don't see _any_ change in Emacs' region mechanism.

I _do_ see a major _supplement_ in Emacs' rectangle mechanism.

>                    You're saying the change is not incompatible.  Ok,
> but it is still a major change.  It would require major changes in the
> Emacs manual.

Of course, if we promote the C-RET method of marking a rectangle as the
default method, manual needs changes.

Also, it may seem logical to have standard commands work in specific
ways depending on whehter no mark is active, the regions is active, or
a rectangle-region is active.  

E.g. M-u to upcase word, region, or rectangle,
     C-w to kill region or rectangle depending on what is marked,
     C-y to yank a rectangle if the last kill was a rectangle, etc.

That's basically what CUA-mode does, in addition to highlighting the
rectagle - and the primary reason why the rectangle support and global-mark
support is tied into CUA mode in the first place.  

So if the basic commands are rewritten to behave correctly in the
presense of a rectangle, then you can easily split apart CUA's
shift-region and CUA's rectangle stuff.

> I think we should postpone discussion of rectangle selection until the
> matter of shift motion is entirely finished with in one way or another.


Ok, they are not really related anyway...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

CUA mode's C-RET binding [was: position on changing defaults?]

[Drew Adams]

> >   Unless you explicitly hit C-RET, you'll never notice it's there.
...
> Of course, if we promote the C-RET method of marking a 
> rectangle as the default method, manual needs changes.

BTW, any chance that we could change the default binding of
`cua-set-rectangle-mark' to something else, besides C-RET? I don't see
anything in the Common User Access definition about C-RET, so I'm guessing
it's not part of that standard anyway.

The current binding presents a problem for Icicles and some other modes.
here are messages about a nxml-mode conflict, for example:
http://osdir.com/ml/emacs.nxml.general/2006-01/msg00052.html,
http://www.mail-archive.com/emacs-devel@gnu.org/msg03655.html.

Since CUA mode is a global minor mode, and minor-mode bindings take
precedence over local bindings, the minibuffer binding of C-RET in Icicles
is overridden by `cua-set-rectangle-mark'.

C-RET is used in Icicles in a way that is analogous to RET. Is there a
similar reason for CUA mode's use of C-RET? If not, how about changing it?

The conflict with Icicles is just an example. It's no biggee for Icicles
users (don't use CUA mode or rebind keys as needed). But if other things are
equal, we might look for a better binding for `cua-set-rectangle-mark'. It's
nice to keep RET + modifier keys for something a bit similar to what RET
does.

Again, this is only a minor annoyance, but if fixed it might let more people
use CUA mode in more contexts.

Re: CUA mode's C-RET binding [was: position on changing defaults?]

[Kim F. Storm]

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

>> >   Unless you explicitly hit C-RET, you'll never notice it's there.
> ...
>> Of course, if we promote the C-RET method of marking a 
>> rectangle as the default method, manual needs changes.
>
> BTW, any chance that we could change the default binding of
> `cua-set-rectangle-mark' to something else, besides C-RET? I don't see
> anything in the Common User Access definition about C-RET, so I'm guessing
> it's not part of that standard anyway.

This has nothing to do with CUA as such - it's about finding a sensible
and convenient binding for setting the rectangle mark.

Since C-SPC sets the region mark, and the SPC key is "one dimensional",
I think that C-RET is a good analogy with the RET key's typical "two
dimensional" form.

And when I chose C-RET, it wasn't used by any other installed
package (not as far as I could see).

If we could move "just-one-space" to some other key, using M-SPC to
set the rectangle mark would be an alternative "logical" binding for
setting the rectangle-mark.

A third possibility would be S-SPC, but that may not work in -nw.

> The current binding presents a problem for Icicles and some other modes.
> here are messages about a nxml-mode conflict, for example:
> http://osdir.com/ml/emacs.nxml.general/2006-01/msg00052.html,
> http://www.mail-archive.com/emacs-devel@gnu.org/msg03655.html.

I guess that no matter what global key is chosen for "set-rectanle-mark",
it will conflict with some other mode...


> Again, this is only a minor annoyance, but if fixed it might let more people
> use CUA mode in more contexts.

Sorry, but if I can decide, I'll not change it :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: CUA mode's C-RET binding

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> Since C-SPC sets the region mark, and the SPC key is "one dimensional",
> I think that C-RET is a good analogy with the RET key's typical "two
> dimensional" form.
>
> If we could move "just-one-space" to some other key, using M-SPC to
> set the rectangle mark would be an alternative "logical" binding for
> setting the rectangle-mark.

From what I've seen, many people use the current just-one-space binding
of M-SPC though, and it seems a particularly good and mnenomic binding
for that command.

> A third possibility would be S-SPC, but that may not work in -nw.

Indeed...

The thing is, I don't think a "set-rectangle-mark" binding has to be all
that lightweight.  In my experience, rectangle operations are fairly
heavyweight anyway -- you set the mark once and do a bunch of movement
(which can take a while) -- so a slightly less convenient binding for
the initial mark-setting would probably be fine.

I'd suggest "C-x r SPC" for obviousness, but that's taken, as is "C-x r
C-SPC" (I have no idea why point-to-register needs _two_ bindings...).

-Miles

-- 
Bacchus, n. A convenient deity invented by the ancients as an excuse for
getting drunk.

Re: CUA mode's C-RET binding [was: position on changing defaults?]

[Lennart Borgman (gmail)]

Kim F. Storm wrote:
> And when I chose C-RET, it wasn't used by any other installed
> package (not as far as I could see).

nxml-mode uses C-RET for completion as an alternative to the famous 
M-TAB which does not work with standard Emacs on w32 for example.

I do not know if that is a good use for C-RET, but it is simple to type 
and cua-set-rectangle-mark is probably not as common as completion, or?

> If we could move "just-one-space" to some other key, using M-SPC to
> set the rectangle mark would be an alternative "logical" binding for
> setting the rectangle-mark.

How about C-x M-space? This is at least a little bit resembles C-space ...

Re: CUA mode's C-RET binding

[Miles Bader]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> How about C-x M-space? This is at least a little bit resembles C-space ...

Well, although I don't think a binding for set-rectangle-mark really has
to be all that quick, using multiple different modifiers on subsequent
keys in a sequence seems like it makes things a bit _too_ difficult to
type....

Unfortunately, gud uses C-x SPC...

-Miles

-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: CUA mode's C-RET binding

[Lennart Borgman (gmail)]

Miles Bader wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>> How about C-x M-space? This is at least a little bit resembles C-space ...
> 
> Well, although I don't think a binding for set-rectangle-mark really has
> to be all that quick, using multiple different modifiers on subsequent
> keys in a sequence seems like it makes things a bit _too_ difficult to
> type....


If you use sticky keys it is not so difficult ...

   http://www.emacswiki.org/cgi-bin/wiki/StickyModifiers

RE: CUA mode's C-RET binding [was: position on changing defaults?]

[Drew Adams]

> > BTW, any chance that we could change the default binding of
> > `cua-set-rectangle-mark' to something else, besides C-RET? 
> > I don't see anything in the Common User Access definition
> > about C-RET, so I'm guessing it's not part of that standard
> > anyway.
> 
> This has nothing to do with CUA as such - it's about finding 
> a sensible and convenient binding for setting the rectangle mark.
> 
> Since C-SPC sets the region mark, and the SPC key is "one 
> dimensional", I think that C-RET is a good analogy with the
> RET key's typical "two dimensional" form.

I don't follow that - I don't see the dimensions. ;-) An analogy from C-SPC
to C-RET seems a bit far-fetched, to me, but I'm probably just not getting
it.

> And when I chose C-RET, it wasn't used by any other installed
> package (not as far as I could see).
> 
> If we could move "just-one-space" to some other key, using M-SPC to
> set the rectangle mark would be an alternative "logical" binding for
> setting the rectangle-mark.

I don't use M-SPC much, but that seems to be a good choice for something
that has to do with spaces. I'd say let's leave that one alone.
 
> A third possibility would be S-SPC, but that may not work in -nw.

Right.

It's not clear to me that SPC and RET variants are natural choices for this,
though I do see the relation with C-SPC (which itself has no relation to
SPC, BTW). It seems like any simple key sequence would be as good for this
as C-RET, but I'm probably missing something.

> I guess that no matter what global key is chosen for 
> "set-rectanle-mark", it will conflict with some other mode...

Yes, no doubt.

This sounds like yet another reason to perhaps split off the CUA rectangle
stuff from CUA mode. IIUC, there is no relation between the two, and if we
did that then people who like CUA mode for its C-x, C-v, C-c and selection
behavior would be able to use other software that conflicts with the
`cua-set-rectangle-mark' binding. That would be a win for both those other
packages and CUA mode.

> > Again, this is only a minor annoyance, but if fixed it 
> > might let more people use CUA mode in more contexts.
> 
> Sorry, but if I can decide, I'll not change it :-)

OK. No big deal.

Here's another thought, FWIW. Does it make sense to set the rectangle mark
in the minibuffer? If not, perhaps CUA mode could set it everywhere else.
IOW, bind `cua-set-rectangle-mark' to nil in each of the minibuffer maps in
CUA mode. 

Just a thought. Dunno if that would do the trick, anyway.

Re: CUA mode's C-RET binding [was: position on changing defaults?]

[Mathias Dahl]

>  Here's another thought, FWIW. Does it make sense to set the rectangle mark
>  in the minibuffer?

I use rectangles quite a lot and have never needed it in the
minibuffer. This is not saying it isn't useful there, of course. In
general I tend to avoid too much editing in the minibuffer, especially
for multi-line data because it kinda feels scary, one wrong keypress
and my data will either be accepted (typing RET instead of C-j) or
gone (typing arrow up/down). It would be interesting to know if other
people do much multi-line editing here.

Re: CUA mode's C-RET binding [was: position on changing defaults?]

[Lennart Borgman (gmail)]

Mathias Dahl wrote:
>>  Here's another thought, FWIW. Does it make sense to set the rectangle mark
>>  in the minibuffer?
> 
> I use rectangles quite a lot and have never needed it in the
> minibuffer. This is not saying it isn't useful there, of course. In
> general I tend to avoid too much editing in the minibuffer, especially
> for multi-line data because it kinda feels scary, one wrong keypress
> and my data will either be accepted (typing RET instead of C-j) or
> gone (typing arrow up/down). It would be interesting to know if other
> people do much multi-line editing here.

Not that much that I have yet done rectangle editing there ...

But what do you mean with that your data is gone if you type arrow 
up/down? When typing a file name for example if I hit <up> then I just 
hit <down> to get the file name I was typing back.

Re: CUA mode's C-RET binding [was: position on changing defaults?]

[Johan Bockgård]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> But what do you mean with that your data is gone if you type arrow
> up/down? When typing a file name for example if I hit <up> then I just
> hit <down> to get the file name I was typing back.

But your changes *are* lost if you do

<up>
Edit the old entry
<down> <up>

-- 
Johan Bockgård

Re: CUA mode's C-RET binding [was: position on changing defaults?]

[Lennart Borgman (gmail)]

Johan Bockgård wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> But what do you mean with that your data is gone if you type arrow
>> up/down? When typing a file name for example if I hit <up> then I just
>> hit <down> to get the file name I was typing back.
> 
> But your changes *are* lost if you do
> 
> <up>
> Edit the old entry
> <down> <up>

Are they lost? How can I tell? I can see them ... ;-)

Or in other words: Please give me an example so I understand.

Re: CUA mode's C-RET binding [was: position on changing defaults?]

[Juri Linkov]

>> But your changes *are* lost if you do
>>
>> <up>
>> Edit the old entry
>> <down> <up>
>
> Are they lost? How can I tell? I can see them ... ;-)
>
> Or in other words: Please give me an example so I understand.

This means that if your history contains something like "rm -rf /",
and you accidently type `M-! M-p RET', your data are lost ;-)
That's why I suggest putting the following code in .emacs:

;; Remove potentially dangerous commands from the history immediately
(add-hook 'minibuffer-exit-hook
          (lambda ()
            (when (string-match
                   "^rm"
                   (car (symbol-value minibuffer-history-variable)))
              (set minibuffer-history-variable
                   (cdr (symbol-value minibuffer-history-variable))))))

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: CUA mode's C-RET binding [was: position on changing defaults?]

[Richard Stallman]

    This means that if your history contains something like "rm -rf /",
    and you accidently type `M-! M-p RET', your data are lost ;-)

Why does your history contain "rm -rf /"?
Did you run that command recently?

Re: CUA mode's C-RET binding

[Manoj Srivastava]

On Tue, 11 Mar 2008 16:25:03 -0400, Richard Stallman <rms@gnu.org> said: 

>     This means that if your history contains something like "rm -rf
>     /", and you accidently type `M-! M-p RET', your data are lost ;-)

> Why does your history contain "rm -rf /"?  Did you run that command
> recently?

        A more plausible scenario is if I have recently run "rm -rf .",
 in a directory where that was appropriate.  Now I have cd'd  to
 a different directory (perhaps even my home directory), where executing
 that command could do damage.

        manoj
-- 
And you can't get any Watney's Red Barrel, because the bars close every
time you're thirsty...
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: CUA mode's C-RET binding

[Juri Linkov]

>>     This means that if your history contains something like "rm -rf
>>     /", and you accidently type `M-! M-p RET', your data are lost ;-)
>
>> Why does your history contain "rm -rf /"?  Did you run that command
>> recently?
>
>         A more plausible scenario is if I have recently run "rm -rf .",
>  in a directory where that was appropriate.  Now I have cd'd  to
>  a different directory (perhaps even my home directory), where executing
>  that command could do damage.

Yes, I meant exactly the same scenario.  When in a dired buffer I type
e.g. `! du -s RET' on a directory, and after this I type `! rm -rf RET'
on the same directory.  Then if I want to repeat the command `du -s'
on another directory, I type `! M-p', and I feel uneasy when at the last
moment before confirming the command with RET, I notice a wrong command.
There is no such problems with other commands that are less damaging.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: CUA mode's C-RET binding

[Richard Stallman]

	    A more plausible scenario is if I have recently run "rm -rf .",
     in a directory where that was appropriate.  Now I have cd'd  to
     a different directory (perhaps even my home directory), where executing
     that command could do damage.

Yes, it could.  But what can we do about that rare case
without causing lots and lots of hassles in more common cases?

Re: CUA mode's C-RET binding

[Manoj Srivastava]

On Wed, 12 Mar 2008 11:12:05 -0400, Richard Stallman <rms@gnu.org> said: 

> 	    A more plausible scenario is if I have recently run "rm -rf
> 	    .",
>      in a directory where that was appropriate.  Now I have cd'd to a
>      different directory (perhaps even my home directory), where
>      executing that command could do damage.

> Yes, it could.  But what can we do about that rare case without
> causing lots and lots of hassles in more common cases?

        The shell that I occassionally use, zsh, has an optional
 mechanism that intercepts "rm -rf *", and asks a y-or-n-p kind of
 question, *but* (and this is critical) -- adds a 10 second window where
 keystrokes are ignored.  I like that feature, it makes me take a time
 out, think about what I am doing, and prevents my fingers from learning 
 "rm -rf *<RET>y<RET>" as the sequence to use.

        Could this be a useful model for emacs as well?

        manoj
 from the zsh manual page:

  RM_STAR_SILENT (-H) <K> <S>
         Do not query the user before executing ‘rm *’ or ‘rm path/*’.

  RM_STAR_WAIT
         If querying the user before executing ‘rm *’ or ‘rm path/*’,
         first wait ten seconds and ignore anything typed in that time.
         This avoids the problem of reflexively answering ‘yes’ to the
         query when one didn’t really mean it.  The wait and query can
         always be avoided by expanding the ‘*’ in ZLE (with tab).

-- 
A chicken is an egg's way of producing more eggs.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Dangerous shell commands? (was: CUA mode's C-RET binding)

[Reiner Steib]

On Wed, Mar 12 2008, Manoj Srivastava wrote:

> On Wed, 12 Mar 2008 11:12:05 -0400, Richard Stallman <rms@gnu.org> said: 
>
>> 	    A more plausible scenario is if I have recently run "rm -rf .",
>>      in a directory where that was appropriate.  Now I have cd'd to a
>>      different directory (perhaps even my home directory), where
>>      executing that command could do damage.
>
>> Yes, it could.  But what can we do about that rare case without
>> causing lots and lots of hassles in more common cases?
>
>         The shell that I occassionally use, zsh, has an optional
>  mechanism that intercepts "rm -rf *", and asks a y-or-n-p kind of
>  question, *but* (and this is critical) -- adds a 10 second window where
>  keystrokes are ignored.  I like that feature, it makes me take a time
>  out, think about what I am doing, and prevents my fingers from learning 
>  "rm -rf *<RET>y<RET>" as the sequence to use.

If I type `rm -rf', I actually *want* "never prompt".  If I'd like to
have "prompt before every removal", I use `-i'.

I also have `unalias cp mv rm ln 2>/dev/null' in my shell init files
to undo stupid alias like alias cp='cp -i'; alias mv='mv -i'; alias
rm='rm -i'.

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

Re: Dangerous shell commands?

[David Kastrup]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Wed, Mar 12 2008, Manoj Srivastava wrote:
>
>>         The shell that I occassionally use, zsh, has an optional
>>  mechanism that intercepts "rm -rf *", and asks a y-or-n-p kind of
>>  question, *but* (and this is critical) -- adds a 10 second window where
>>  keystrokes are ignored.  I like that feature, it makes me take a time
>>  out, think about what I am doing, and prevents my fingers from learning 
>>  "rm -rf *<RET>y<RET>" as the sequence to use.
>
> If I type `rm -rf', I actually *want* "never prompt".  If I'd like to
> have "prompt before every removal", I use `-i'.

One of the most dreaded messages once it sinks in:

rm: cannot remove `.o': No such file or directory

Spoiler:
\f
This is after
rm * .o

And I agree that I don't want a prompt when I do
rm -rf *

However, when I type
<up> <up> <up> RET

and typed one <up> too many, namely when I did _not_ actually type the
terrible command, getting asked a question would not be amiss.

I have actually, after this has happened to me once or twice, taken the
pain to look up what to do in order to not have a command enter the
command history at all.

> I also have `unalias cp mv rm ln 2>/dev/null' in my shell init files
> to undo stupid alias like alias cp='cp -i'; alias mv='mv -i'; alias
> rm='rm -i'.

In important directories (using POSIX sort order),

touch ./-i

can become a life saver at some future point of time.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Dangerous shell commands?

[Manoj Srivastava]

On Wed, 12 Mar 2008 21:21:51 +0100, Reiner Steib <reinersteib+gmane@imap.cc> said: 

> On Wed, Mar 12 2008, Manoj Srivastava wrote:
>> On Wed, 12 Mar 2008 11:12:05 -0400, Richard Stallman <rms@gnu.org>
>> said:
>> 
>>> A more plausible scenario is if I have recently run "rm -rf .", in a
>>> directory where that was appropriate.  Now I have cd'd to a
>>> different directory (perhaps even my home directory), where
>>> executing that command could do damage.
>> 
>>> Yes, it could.  But what can we do about that rare case without
>>> causing lots and lots of hassles in more common cases?
>> 
>> The shell that I occassionally use, zsh, has an optional mechanism
>> that intercepts "rm -rf *", and asks a y-or-n-p kind of question,
>> *but* (and this is critical) -- adds a 10 second window where
>> keystrokes are ignored.  I like that feature, it makes me take a time
>> out, think about what I am doing, and prevents my fingers from
>> learning "rm -rf *<RET>y<RET>" as the sequence to use.

> If I type `rm -rf', I actually *want* "never prompt".  If I'd like to
> have "prompt before every removal", I use `-i'.

        Actually, I like zsh presenting me a middle path, not the black
 or white options you present here.  If I want a prompt on every rm
 invocation, I use rm -i.  I also do not want prompts when I say rm -rf A*

        I do like having a prompt when I say "rm -rf *" ; since that is
 fraught with possibility of danger.


        So, this is not always prompt, nor is it never prompt, it is
 "optionally" sometimes prompt for the most risky uses of rm -rf.

        I like the nuanced prompting option.

        manoj

-- 
IBM Advanced Systems Group -- a bunch of mindless jerks, who'll be first
against the wall when the revolution comes...  -- with regrets to
D. Adams
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: CUA mode's C-RET binding [was: position on changing defaults?]

[Mathias Dahl]

>  But what do you mean with that your data is gone if you type arrow
>  up/down? When typing a file name for example if I hit <up> then I just
>  hit <down> to get the file name I was typing back.

Hmm, seems I was misremembering, it works for me too now. Still, I
never feel comfortable or "safe" when editing a multi-line data in the
minibuffer. The biggest problem is that I need to remember to type C-q
before each newline and that I cannot use the arrow keys (I use the
arrow keys and C-n, C-p in different situations).

RE: CUA mode's C-RET binding [was: position on changing defaults?]

[Drew Adams]

> >  But what do you mean with that your data is gone if you type arrow
> >  up/down? When typing a file name for example if I hit <up> 
> >  then I just hit <down> to get the file name I was typing back.
> 
> Hmm, seems I was misremembering, it works for me too now. Still, I
> never feel comfortable or "safe" when editing a multi-line data in the
> minibuffer. The biggest problem is that I need to remember to type C-q
> before each newline and that I cannot use the arrow keys (I use the
> arrow keys and C-n, C-p in different situations).

You might try binding C-j in the minibuffer so that it self-inserts. That's
what I do in Icicles, where it's not unusual to use multi-line completions
and input.

I use C-n and C-p in the minibuffer to move between input lines. I didn't
understand what you said about those keys. 

In addition, I use a version of `end-of-line' and `beginning-of-line' that,
when repeated, moves to the end/beginning of the next/previous line. That
helps in moving about long lines of multi-line input.

Re: CUA mode's C-RET binding [was: position on changing defaults?]

[Mathias Dahl]

>  You might try binding C-j in the minibuffer so that it self-inserts. That's
>  what I do in Icicles, where it's not unusual to use multi-line completions
>  and input.

I am sure I can but I have never bothered doing it.

>  I use C-n and C-p in the minibuffer to move between input lines. I didn't
>  understand what you said about those keys.

C-n and C-p I can use but not the arrow keys, unless I rebind them too.

When I want to input multi-line data as answer to a prompt I create
the data in a buffer and then yank that onto the prompt.

RE: CUA mode's C-RET binding [was: position on changing defaults?]

[Drew Adams]

> >  You might try binding C-j in the minibuffer so that it 
> >  self-inserts. That's what I do in Icicles, where it's not
> >  unusual to use multi-line completions and input.
> 
> I am sure I can but I have never bothered doing it.
> 
> >  I use C-n and C-p in the minibuffer to move between input 
> >  lines. I didn't understand what you said about those keys.
> 
> C-n and C-p I can use but not the arrow keys, unless I rebind 
> them too.
> 
> When I want to input multi-line data as answer to a prompt I create
> the data in a buffer and then yank that onto the prompt.

That's OK if you seldom want to use multiple-line input. If that's not the
case, then it seems like extra work, just to give you the safety
(reassurance) that forgetting a C-q won't accidentally send something you
didn't want to send.

I mentioned a use case (Icicles) where it is not uncommon to use multi-line
input - to match multi-line completion candidates. In that case, it helps to
let C-j self-insert.

For most Emacs users, however, it is probably not that often that they
insert C-j, so for them it really doesn't matter that C-j is not
self-inserting. The point was that if you do want to make it easier to
insert C-j, then just make it self-insert. ;-)

Similarly, for the arrow keys. I use them for something else in the
minibuffer (in Icicles), but you can easily bind them in the minibuffer maps
to do what C-n and C-p do.

Re: position on changing defaults?

[Richard Stallman]

    I don't see _any_ change in Emacs' region mechanism.

    I _do_ see a major _supplement_ in Emacs' rectangle mechanism.

Maybe that is a clearer way of putting it.  But...

	 C-w to kill region or rectangle depending on what is marked,
	 C-y to yank a rectangle if the last kill was a rectangle, etc.

I would call that a change in the region mechanism.

Anyway, it seems we agree on the conclusion: we should judge
each of these features separately.

Re: position on changing defaults?

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It also gives you the rectangle highlighting (which I think most
>> users would agree is quite useful) combined with the ability to
>> use the normal region kill, copy and yank keys also for rectangles.
>> So there's no need to learn a different command set for rectangles!
>
> Actually, I think the rectangle support is good, although I'd like it to
> be a bit more like the normal region highlighting (e.g. same color, 

That would be ok with me (as the default for a new `rectangle' face).

>                                                                     C-g
> should deactivate it, 

It does!  If not, you've found a bug.  Please tell me how to repeat it.

>                       should be allowed to have 0-width).  

Why?

>                                                            The C-g part
> is important: I found it difficult to figure out how to "exit" from the
> "rectangle-mode".
>
> Also I'm not convinced by the special M-foo bindings 

Some or all of them?
What's the alternative?

>                                                      and the special
> treatment of self-insert-command.  

I find it extremely useful - but of course, it could be an advanced option.

>                                    Maybe it's just that I'm used to it,
> but I find C-x r t to work at least as well if not better (e.g. it's
> not limited to self-inserting keys).

The self-insert-char feature inserts OUTSIDE the rectangle, so
I don' see how it compares to C-x r t?

E.g. to put ( ) around all lines of a rectangle, just mark
the rectangle (top-down), and enter ) RET ( .  Can you do that
faster with C-x r t ?

BTW, M-s is equivalent to C-x r t (I believe).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Stefan Monnier]

>>> It also gives you the rectangle highlighting (which I think most
>>> users would agree is quite useful) combined with the ability to
>>> use the normal region kill, copy and yank keys also for rectangles.
>>> So there's no need to learn a different command set for rectangles!
>> 
>> Actually, I think the rectangle support is good, although I'd like it to
>> be a bit more like the normal region highlighting (e.g. same color, 

> That would be ok with me (as the default for a new `rectangle' face).

>> C-g should deactivate it,
> It does!  If not, you've found a bug.  Please tell me how to repeat it.

Hmm...  now it seems to work indeed.  Good.
I'll have to investigate some more to try and reproduce the problem.
Oh... I see, I have C-g bound to sm-keyboard-quit which does:

  (defun sm-keyboard-quit ()
    (interactive)
    (sm-special-frames-auto-iconify)
    (keyboard-quit))

I tried replacing the last call by (call-interactively 'keyboard-quit)
but it didn't help.  I think deactivate-mark should do the trick.

>> should be allowed to have 0-width).  
> Why?

Because that's how the region behaves and that's how Emacs rectangles
behave, so it's more consistent.

>> The C-g part is important: I found it difficult to figure out how to
>> "exit" from the "rectangle-mode".
>> Also I'm not convinced by the special M-foo bindings 
> Some or all of them?

All of them.

> What's the alternative?

What do you mean?  I've never used any of them, yet managed to edit my
texts just fine ;-)

Basically, I want rectangle regions to behave pretty much *exactly* like
normal regions (the only difference is that it sets a var
`region-is-rectangle' and for that reason it is displayed differently)
and then some commands (like C-w ...) behave differently depending on
whether the region was rectangle or not, and other commands only work
with one of the two kinds of regions.

>> and the special treatment of self-insert-command.  
> I find it extremely useful - but of course, it could be an advanced option.

>> Maybe it's just that I'm used to it, but I find C-x r t to work at
>> least as well if not better (e.g. it's not limited to self-inserting
>> keys).

> The self-insert-char feature inserts OUTSIDE the rectangle, so
> I don' see how it compares to C-x r t?

If the rectangle has 0-width, C-x r t also inserts "outside".

> E.g. to put ( ) around all lines of a rectangle, just mark
> the rectangle (top-down), and enter ) RET ( .  Can you do that
> faster with C-x r t ?

No.  But then, I never put (...) around all lines of a rectangle.

If someone needs such a feature, maybe we could add some kind of escape
mechanism so C-x r t could accept "(\0)" kind of like a replace-regexp.
Not sure it's worth the trouble, tho.

> BTW, M-s is equivalent to C-x r t (I believe).

Except that it applies to one more column, so it can't be used as a form
of insert-rectangle, contrary to C-x r t.  About half of my uses of C-x
r t is as a form of insert-rectangle.  I understand that you can use the
self-insert-char feature to get the same effect and it's a neat idea,
but restricting it to self-insert-char is problematic.


        Stefan

Re: position on changing defaults?

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> should be allowed to have 0-width).  
>> Why?
>
> Because that's how the region behaves and that's how Emacs rectangles
> behave, so it's more consistent.

Well, I've never had a use for them in practice - and one of the
features of CUA rectangles is that the cursor is INSIDE one of the
rectangle corners -- namely the corner which you expand by moving the
cursor.  

Visually, this is much more pleasing than having the cursor
sometimes inside, sometimes outside the rectangle.

Also, with CUA-rectangles, the cursor can be at any of the four
corners of the rectangle.  So having zero size rectangle breaks
this - which is the main reason I didn't insist on having them.

Finally, CUA-rectangles are not limited by arbitrary line endings;
you can expand a rectangle beyond the end of the current line.
For example, with standard rectangles, how can you mark the
text marked with X'es in the following sample:

     ...............
     ........XXXXX....
     ........XXX
     ........XXXXX..
     ........X
     ............

?

With CUA rectangles, you simply place the cursor at the
top-left X, and hit C-RET, down x 4, right x 4.   Try it!

So *I* don't want rectangles to work just like the region - I want the
rectangles to work better than that - also in the presense of tabs in
the middle of lines!

>>> Also I'm not convinced by the special M-foo bindings 
>> Some or all of them?
>
> All of them.
>
>> What's the alternative?
>
> What do you mean?  I've never used any of them, yet managed to edit my
> texts just fine ;-)
>
> Basically, I want rectangle regions to behave pretty much *exactly* like
> normal regions (the only difference is that it sets a var
> `region-is-rectangle' and for that reason it is displayed differently)
> and then some commands (like C-w ...) behave differently depending on
> whether the region was rectangle or not, and other commands only work
> with one of the two kinds of regions.

I'm _definitely_ in favor of modifying basic commands to behave
correctly/sensibly if "rectangle-active-p".

BTW, shouldn't a command like upcase-region be merged into upcase-word
so that marking the region (transient-mark-mode active) so that M-u will
upcase the region instead of the word following the region...

>> The self-insert-char feature inserts OUTSIDE the rectangle, so
>> I don' see how it compares to C-x r t?
>
> If the rectangle has 0-width, C-x r t also inserts "outside".

Ok, but you don't an iota of visible clue as to where the rectangle is.

And transient-mark-mode is damn ugly as an indicator for standard 
rectangles.

>
>> E.g. to put ( ) around all lines of a rectangle, just mark
>> the rectangle (top-down), and enter ) RET ( .  Can you do that
>> faster with C-x r t ?
>
> No.  But then, I never put (...) around all lines of a rectangle.

I don't do that often either, but take it as an illustration of the
principle of inserting on the "active" side of the rectangle.
And moving the active corner with RET.

>> BTW, M-s is equivalent to C-x r t (I believe).
>
> Except that it applies to one more column, so it can't be used as a form
> of insert-rectangle, contrary to C-x r t.
> ... but restricting it to self-insert-char is problematic.

Just use M-o M-s for that ...  It's still shorter than C-x r t :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
>>>> should be allowed to have 0-width).  
>>>
>>> Why?
>>
>> Because that's how the region behaves and that's how Emacs rectangles
>> behave, so it's more consistent.
>
> Well, I've never had a use for them in practice

I have -- in fact, I use zero-width rectangles quite often, with the
"C-x r t" command.

-Miles

-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: position on changing defaults?

[Stefan Monnier]

>>>> should be allowed to have 0-width).  
>>> Why?
>> Because that's how the region behaves and that's how Emacs rectangles
>> behave, so it's more consistent.

> Visually, this is much more pleasing than having the cursor
> sometimes inside, sometimes outside the rectangle.

Doesn't strike me as something particularly important.

> Also, with CUA-rectangles, the cursor can be at any of the four
> corners of the rectangle.  So having zero size rectangle breaks
> this - which is the main reason I didn't insist on having them.

I don't understand how that's different whether zero-width rectangles
are allowed.

> Finally, CUA-rectangles are not limited by arbitrary line endings;

Again, I don't see how that relates to whether or not zero-width
rectangles are allowed.

> you can expand a rectangle beyond the end of the current line.

Yes, I understand the problems posed by TABs and end of lines when faced
with rectangles, and yes I think the way CUA handles it is perfectly fine.

> So *I* don't want rectangles to work just like the region - I want the
> rectangles to work better than that - also in the presense of tabs in
> the middle of lines!

I meant conceptually.  To the user they should mostly behave "just like
a non-rectangular region".  But of course, there are some
necessary differences.

> I'm _definitely_ in favor of modifying basic commands to behave
> correctly/sensibly if "rectangle-active-p".

I think we all agree on this.

> BTW, shouldn't a command like upcase-region be merged into upcase-word
> so that marking the region (transient-mark-mode active) so that M-u will
> upcase the region instead of the word following the region...

Sounds like a good idea to me.

>>> The self-insert-char feature inserts OUTSIDE the rectangle, so
>>> I don' see how it compares to C-x r t?
>> If the rectangle has 0-width, C-x r t also inserts "outside".
> Ok, but you don't an iota of visible clue as to where the rectangle is.

Now, that is a very good point.  Supporting highlighting of zero-width
rectangles would probably require special-cased code.  E.g. we could add
a vertical line with overlay after-strings, tho that would tend to shift
the rest of the text.  Experimentation would be needed.

> And transient-mark-mode is damn ugly as an indicator for standard 
> rectangles.

Yes, I live with it, but there's no doubt that it's not a feature.

>>> E.g. to put ( ) around all lines of a rectangle, just mark
>>> the rectangle (top-down), and enter ) RET ( .  Can you do that
>>> faster with C-x r t ?
>> No.  But then, I never put (...) around all lines of a rectangle.
> I don't do that often either, but take it as an illustration of the
> principle of inserting on the "active" side of the rectangle.
> And moving the active corner with RET.

Yes, I understand, but I'm not convinced it deserves so
much importance.  These are operations that might better be served by
packages like picture-mode.

>>> BTW, M-s is equivalent to C-x r t (I believe).
>> Except that it applies to one more column, so it can't be used as a form
>> of insert-rectangle, contrary to C-x r t.
>> ... but restricting it to self-insert-char is problematic.
> Just use M-o M-s for that ...  It's still shorter than C-x r t :-)

The problem is not just a question of number of key presses.
C-x r t is good because with a single command I get to do most of the
operations I usually need to do: insert-rectangle (when the rectangle
is empty), delete-rectangle (when the inserted string is empty), and of
course replacement of each line of the rectangle with a given string.

Now I understand that C-x r t works fine with CUA rectangles, but I'm
just not sure that having "active-rectangle" be a minor mode with
special bindings is the way I want to go.


        Stefan

Re: position on changing defaults?

[Richard Stallman]

    Well, I've never had a use for them in practice - and one of the
    features of CUA rectangles is that the cursor is INSIDE one of the
    rectangle corners -- namely the corner which you expand by moving the
    cursor.  

Such an inconsistency between two ways of marking a rectangle seems
really bad.  At present, since one of them is "just an emulation",
perhaps the inconsistency is not important.  But if both of them were
part of recommended Emacs interfaces, the inconsistency would be
glaring.

Re: position on changing defaults?

[Chong Yidong]

storm@cua.dk (Kim F. Storm) writes:

>> Because that's how the region behaves and that's how Emacs rectangles
>> behave, so it's more consistent.
>
> Well, I've never had a use for them in practice - and one of the
> features of CUA rectangles is that the cursor is INSIDE one of the
> rectangle corners -- namely the corner which you expand by moving the
> cursor.  
>
> Visually, this is much more pleasing than having the cursor
> sometimes inside, sometimes outside the rectangle.

But it's inconsistent with how the Emacs cursor typically behaves, and
it looks weird when you are using a bar cursor.

(For instance, I have a customization in my .emacs file that turns the
cursor into a bar whenever the mark is active:

  (add-hook 'deactivate-mark-hook '(lambda () (setq cursor-type t)))
  (add-hook 'activate-mark-hook   '(lambda () (setq cursor-type 'bar)))

With the bar cursor, cua rectangle selection doesn't do what is
expected.)

Re: position on changing defaults?

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> But it's inconsistent with how the Emacs cursor typically behaves, and
> it looks weird when you are using a bar cursor.
>
> (For instance, I have a customization in my .emacs file that turns the
> cursor into a bar whenever the mark is active:
>
>   (add-hook 'deactivate-mark-hook '(lambda () (setq cursor-type t)))
>   (add-hook 'activate-mark-hook   '(lambda () (setq cursor-type 'bar)))
>
> With the bar cursor, cua rectangle selection doesn't do what is
> expected.)

Well, it does what's expected - it's just the cursor which is off-by-one
at the right edge (it is ok at the left edge, isn't it)?

But it's a bug, and I'll see what to do about it.

Maybe the simple solution is to make it a config option, whether
the rectangle cursor is inside or outside the rectangle on the
right edge - then people can have it the way they like (there
obviously isn't consensus on the issue).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> BTW, why is using a pre- or post- command hook so bad?
>
> These tend to be brittle (e.g. when entering/exiting minibuffer prompts
> or recursive edits) and difficult to debug.  I think the need for
> pre/post command-hook is often a sign of a missing
> functionality elsewhere.

It seems I could get by with the following hooks:

pre-command-shifted-key-hook

        Called before executing command if transient-mark-mode
        is enabled and current command is invoked by a shifted key.

pre-command-mark-active-hook

        Called before executing command if transient-mark-mode
        is enabled and mark is active.

post-command-mark-active-hook

        Called after executing command if transient-mark-mode
        is enabled and mark is active.  Called before checking
        value of deactivate-mark!


I can probably do without the two mark-active hooks if it is
ok to use activate-mark-hook and deactivate-mark-hook to
add and remove functions on the general pre-command-hook
and post-command-hook, but having dedicated hooks would
be easier.



-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Making the command loop mode-dependent [was: position on changing defaults?]

[Alan Mackenzie]

Morning, Kim!

On Sat, Mar 08, 2008 at 09:56:01PM +0100, Kim F. Storm wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >> BTW, why is using a pre- or post- command hook so bad?

> > These tend to be brittle (e.g. when entering/exiting minibuffer
> > prompts or recursive edits) and difficult to debug.  I think the need
> > for pre/post command-hook is often a sign of a missing functionality
> > elsewhere.

> It seems I could get by with the following hooks:

> pre-command-shifted-key-hook

>         Called before executing command if transient-mark-mode
>         is enabled and current command is invoked by a shifted key.

> pre-command-mark-active-hook

>         Called before executing command if transient-mark-mode
>         is enabled and mark is active.

> post-command-mark-active-hook

>         Called after executing command if transient-mark-mode
>         is enabled and mark is active.  Called before checking
>         value of deactivate-mark!

Where are these hooks going to be called from?  The command loop?
I think this needs a _LOT_ of thinking about.

Up to now, the command loop has been @dfn{vi-modeless} (i.e. doesn't
have things like vi's "insert-mode" and "command-mode").  This is a
fundamental assumption which (I think) has always been implicit up till
now.  

If the command loop starts calling hooks IF certain user-level conditions
hold, it will cease to be vi-modeless.  Things will surely break.
Somehow, sometime, this is going to cause a LOT of pain in the far
future, since it will constrain our options.  In the medium future,
possibly, some modes might have to start testing the values of these
hooks to behave properly.

[Stefan:]
> > These [pre- and post-command-hooks] tend to be brittle (e.g. when
> > entering/exiting minibuffer prompts or recursive edits) and difficult
> > to debug.

I can't see that pre-command-shifted-key-hook and friends would be any
less brittle.

[ .... ]

> -- 
> Kim F. Storm <storm@cua.dk> http://www.cua.dk

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: position on changing defaults?

[Richard Stallman]

    I don't see why it is really necessary to insist on refactoring
    cua-(selection-)mode for these features to be used by default.

So that we don't have to have all of CUA loaded by default, for one
thing.

    BTW, why is using a pre- or post- command hook so bad?

Every use of them (1) slows Emacs down and (2) creates the possibility
of bad interactions with other features.

The more commonly used a feature is, the more desirable it becomes
to avoid using those hooks.

Re: position on changing defaults?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I don't see why it is really necessary to insist on refactoring
>     cua-(selection-)mode for these features to be used by default.
>
> So that we don't have to have all of CUA loaded by default, for one
> thing.

Basic CUA functionality is already split into a separate module,
which is fairly small (most of cua-base.el is commentary and defcustoms).

I doubt it can be made much smaller than that.

> The more commonly used a feature is, the more desirable it becomes
> to avoid using those hooks.

I agree - and I'll think about what's needed.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Richard Stallman]

    >     I don't see why it is really necessary to insist on refactoring
    >     cua-(selection-)mode for these features to be used by default.
    >
    > So that we don't have to have all of CUA loaded by default, for one
    > thing.

    Basic CUA functionality is already split into a separate module,

It sounds like basic CUA functionality includes more than this one
feature.  If we want to install the shift-arrow feature by default, we
should install just that, and implement it in the best way we can.

Re: position on changing defaults?

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     Basic CUA functionality is already split into a separate module,
>
> It sounds like basic CUA functionality includes more than this one
> feature.  If we want to install the shift-arrow feature by default, we
> should install just that, and implement it in the best way we can.

Try the code I posted yesterday (in this same thread, but with the
Subject: line changed to "deactivation in "shift-select" mode").

It does a good job of implementing the desired shift-select
functionality, with _extremely_ simple code.

I think something similar would be a great basis for implementing this
feature for default emacs use -- it's very simple and does exactly
what's wanted for the typical user.

-Miles

-- 
Generous, adj. Originally this word meant noble by birth and was rightly
applied to a great multitude of persons. It now means noble by nature and is
taking a bit of a rest.

Re: position on changing defaults?

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> I think something similar would be a great basis for implementing this
> feature for default emacs use -- it's very simple and does exactly
> what's wanted for the typical user.

IMO that approach is severely broken for several reasons.
And it is not _excatly_ what any typical user wants.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
>> I think something similar would be a great basis for implementing this
>> feature for default emacs use -- it's very simple and does exactly
>> what's wanted for the typical user.
>
> IMO that approach is severely broken for several reasons.

Why?

> And it is not _excatly_ what any typical user wants.

Why?

I've actually been using this code all day, and it seems to work
absolutely great.  It certainly matches the instincts I've acquired from
using other apps (which all use shift-select "natively").

-Miles

-- 
Quidquid latine dictum sit, altum viditur.

Re: position on changing defaults?

[Stefan Monnier]

>> I think something similar would be a great basis for implementing this
>> feature for default emacs use -- it's very simple and does exactly
>> what's wanted for the typical user.

> IMO that approach is severely broken for several reasons.
> And it is not _excatly_ what any typical user wants.

I haven't thought hard enough yet about what his suggestion does, so
could you expand on its downsides?


        Stefan

Re: position on changing defaults?

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I think something similar would be a great basis for implementing this
>>> feature for default emacs use -- it's very simple and does exactly
>>> what's wanted for the typical user.
>
>> IMO that approach is severely broken for several reasons.
>> And it is not _excatly_ what any typical user wants.
>
> I haven't thought hard enough yet about what his suggestion does, so
> could you expand on its downsides?

1) It binds special commands to the shifted keys, which doesn't
   work for minor modes which put different commands on the
   non-shifted keys.

2) C-h k S-down doesn't show the doc string of the original command.

3) It only works with transient-mark-mode off, so explicit
   region start C-SPC has no highlighting.

4) The list of supported keys/commands is not complete.

5) This approach is already used by s-mark and pc-selection-mode...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
>> I haven't thought hard enough yet about what his suggestion does, so
>> could you expand on its downsides?
>
> 1) It binds special commands to the shifted keys, which doesn't
>    work for minor modes which put different commands on the
>    non-shifted keys.

Let's split the discussion into two separate issues though:

 (1) how to turn on shift-selection -- binding keys vs. special
     detection of commands

 (2) How to turn _off_ shift-selection -- post-command-hook
     vs. transient-mark-mode "only mode" vs. ...

From what I've seen of the discussion, these two points are orthogonal.

> 2) C-h k S-down doesn't show the doc string of the original command.

Well obviously that's a simple matter of writing the right doc
strings...

> 3) It only works with transient-mark-mode off, so explicit
>    region start C-SPC has no highlighting.

My supposition is that this issue can be fixed with simple changes to
the existing "only mode" to make it support this new usage better.

> 4) The list of supported keys/commands is not complete.

Er, _that's_ obviously a simple matter of writing more wrappers (and the
wrappers are trivial).

To be honest I don't think it's necessary to support every single
movement command emacs has, only the common ones, and the ones supported
by other apps (and their native emacs equivalents).

The critical thing is to let people's muscle-memory do the right thing,
and the other apps they get this muscle memory from usually have a very
limited set of keybindings anyway.

> 5) This approach is already used by s-mark and pc-selection-mode...

So?  Maybe they (or some variant of them) are good candidates to
implement this functionality for default-enabling.

-Miles

-- 
Un-American, adj. Wicked, intolerable, heathenish.

Re: position on changing defaults?

[Johan Bockgård]

storm@cua.dk (Kim F. Storm) writes:

> 5) This approach is already used by s-mark and pc-selection-mode...

No, it isn't. pc-selection-mode not only defines the bindings that turn
selection on, it also has to redefine all the commands that should turn
if off (which--if it actually did this correctly--would be many, many
more).

-- 
Johan Bockgård

Re: position on changing defaults?

[Richard Stallman]

    > I haven't thought hard enough yet about what his suggestion does, so
    > could you expand on its downsides?

    1) It binds special commands to the shifted keys, which doesn't
       work for minor modes which put different commands on the
       non-shifted keys.

Can you show a scenario so we can judge whether this has significant
implications?

    2) C-h k S-down doesn't show the doc string of the original command.

We could change C-h k to DTRT.

    3) It only works with transient-mark-mode off, so explicit
       region start C-SPC has no highlighting.

Can that be fixed?

    5) This approach is already used by s-mark and pc-selection-mode...

(Which approach is "this" approach?)

That does not seem like a strong argument, because neither s-mark nor
pc-selection-mode is normally enabled.

Re: position on changing defaults?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > I haven't thought hard enough yet about what his suggestion does, so
>     > could you expand on its downsides?
>
>     1) It binds special commands to the shifted keys, which doesn't
>        work for minor modes which put different commands on the
>        non-shifted keys.
>
> Can you show a scenario so we can judge whether this has significant
> implications?

I can only say that over time, I've had people tell me that when they
enable some xyz-mode, the shift-region keys no longer works as expected.
The cause has always been that the mode rebound e.g. the arrow keys to
some variation of the normal cursor movement.
Adding the 'CUA property to the relevant commands fixed the problems.

However, your proposal to bind S-<whatever> to a command which runs 
the command of the underlying unshifted key would actually do better
than that, as it doesn't need to know in advance what that command is.

Actually, I think your approach is the best proposal so far!

>
>     2) C-h k S-down doesn't show the doc string of the original command.
>
> We could change C-h k to DTRT.

Yes.

>     3) It only works with transient-mark-mode off, so explicit
>        region start C-SPC has no highlighting.
>
> Can that be fixed?

I suppose so.

>
>     5) This approach is already used by s-mark and pc-selection-mode...
>
> (Which approach is "this" approach?)

Explicitly binding shift keys -- but they bind them to individual commands.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Stefan Monnier]

> However, your proposal to bind S-<whatever> to a command which runs 
> the command of the underlying unshifted key would actually do better
> than that, as it doesn't need to know in advance what that command is.

Instead, it presumes that that key is only ever used for
cursor movement.  If the key is rebound to something that behaves
differently.  E.g. if the user rebinds C-f to find-file, S-C-f might
activate the region and then call find-file.


        Stefan

Re: position on changing defaults?

[Richard Stallman]

    Instead, it presumes that that key is only ever used for
    cursor movement.  If the key is rebound to something that behaves
    differently.  E.g. if the user rebinds C-f to find-file, S-C-f might
    activate the region and then call find-file.

That is true, so the method is not perfect.  But at least you can fix
it by rebinding S-C-f.

However, I don't think we should change C-f by default.

Re: position on changing defaults?

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> However, your proposal to bind S-<whatever> to a command which runs 
>> the command of the underlying unshifted key would actually do better
>> than that, as it doesn't need to know in advance what that command is.
>
> Instead, it presumes that that key is only ever used for
> cursor movement.  If the key is rebound to something that behaves
> differently.  E.g. if the user rebinds C-f to find-file, S-C-f might
> activate the region and then call find-file.

That's very true - but if a major mode binds some other command to
e.g. C-f, it would be very odd if that command is not a movement
command - anything else would break "user expectations".

OTOH, there are specialized modes, such as ido-mode where C-f
(in the minibuffer) has a rather tricky behaviour depending
on position and context - and in general does NOT do movement.
But I've not had any reason to use shift- movement in
the minibuffer when ido is active (that has very little
meaning).

I've made a working implementation of RMS' approach together with
variations of Miles proposal and there is one major problem with it -
you cannot in general give a prefix arg to a shifted movement command.

E.g. C-5 S-right works, marking next 5 chars.

But S-right C-5 S-right, also just marks 5 chars, as the C-5
prefix deactivates the mark set by the first S-right.


BTW, we discussed making transient-mark-mode the default - so
can we assume that transient-mark-mode is _on_ for the shifted
movement keys to work?  Or do we have to find a solution which
works also for transient-mark-mode off (e.g. setting it on
temporarily as Miles approach did).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[Stefan Monnier]

> But S-right C-5 S-right, also just marks 5 chars, as the C-5
> prefix deactivates the mark set by the first S-right.

This, and the issue with scrolling, makes me think that the `only'-TTM
is maybe not the best approach.

> BTW, we discussed making transient-mark-mode the default - so
> can we assume that transient-mark-mode is _on_ for the shifted
> movement keys to work?  Or do we have to find a solution which
> works also for transient-mark-mode off (e.g. setting it on
> temporarily as Miles approach did).

AFAICT, the approach I proposed where most/all the movement commands get
changed to call a special function in the interactive spec wouldn't
suffer from any such problems.  I think it's the best approach so far.


        Stefan

Re: position on changing defaults?

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
> AFAICT, the approach I proposed where most/all the movement commands get
> changed to call a special function in the interactive spec wouldn't
> suffer from any such problems.  I think it's the best approach so far.

I can not see what the advantage with an interactive spec over a 
property on the function name is. Could you please tell?

To me Kim's suggestion using a property seems much more flexible and 
easier to implement.

And for the actual implementation of activating/deactivating the mark I 
can not see the advantage of doing it directly in the command loop 
instead of in special hooks before and after pre/post-command-hook. 
Doing it there seems more flexible to me and it can also be implemented 
in elisp. (But maybe this is not an issue at all?)

Re: position on changing defaults?

[Stefan Monnier]

>> AFAICT, the approach I proposed where most/all the movement commands get
>> changed to call a special function in the interactive spec wouldn't
>> suffer from any such problems.  I think it's the best approach so far.

> I can not see what the advantage with an interactive spec over a property on
> the function name is. Could you please tell?

Very simple: no magic, no pre/post-command-hook.


        Stefan

Re: position on changing defaults?

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>>> AFAICT, the approach I proposed where most/all the movement commands get
>>> changed to call a special function in the interactive spec wouldn't
>>> suffer from any such problems.  I think it's the best approach so far.
> 
>> I can not see what the advantage with an interactive spec over a property on
>> the function name is. Could you please tell?
> 
> Very simple: no magic, no pre/post-command-hook.


Why is an interactive spec less magic than the property on a function 
name? To the end user (non-lisper) it could be equally visible, or?

The pre-pre/post-post-command-hook I proposed has nothing to do with 
this, or? (I believe such a hook could be used for other emulations too, 
like Viper.)

Re: position on changing defaults?

[Stefan Monnier]

>>>> AFAICT, the approach I proposed where most/all the movement commands get
>>>> changed to call a special function in the interactive spec wouldn't
>>>> suffer from any such problems.  I think it's the best approach so far.
>> 
>>> I can not see what the advantage with an interactive spec over a property on
>>> the function name is. Could you please tell?
>> 
>> Very simple: no magic, no pre/post-command-hook.

> Why is an interactive spec less magic than the property on a function name?
> To the end user (non-lisper) it could be equally visible, or?

The property is irrelevant.  The relevant problem is the code that uses
those properties which is placed on pre/post-command-hook.

> The pre-pre/post-post-command-hook I proposed has nothing to do with this,
> or? (I believe such a hook could be used for other emulations too,
> like Viper.)

Such a proposal is just making things worse.


        Stefan

Re: position on changing defaults?

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>>>>> AFAICT, the approach I proposed where most/all the movement commands get
>>>>> changed to call a special function in the interactive spec wouldn't
>>>>> suffer from any such problems.  I think it's the best approach so far.
>>>> I can not see what the advantage with an interactive spec over a property on
>>>> the function name is. Could you please tell?
>>> Very simple: no magic, no pre/post-command-hook.
> 
>> Why is an interactive spec less magic than the property on a function name?
>> To the end user (non-lisper) it could be equally visible, or?
> 
> The property is irrelevant.  The relevant problem is the code that uses
> those properties which is placed on pre/post-command-hook.

There are obviously (at least) two problems:
- whether to use property or interactive spec, and
- whether to do things in an interactive spec or in the command loop 
(maybe using a hook then).

Does not using only an interactive spec makes things very stiff? What if 
the user wants other commands (that he/she has not written self) to join 
the dance?

>> The pre-pre/post-post-command-hook I proposed has nothing to do with this,
>> or? (I believe such a hook could be used for other emulations too,
>> like Viper.)
> 
> Such a proposal is just making things worse.

That is not my intention ;-)

If a property is used then the dance must happen in the command loop. 
For that I have (several times) suggested using new hooks:

   pre-pre pre doit post post-post

Handling of shift should AFAICS be done early, ie pre-pre.

There are however other emulations than the shift-emulation that may 
require handling as late as possible instead. One such thing is Vipers 
move-related copy and cut commands. I think a post-post hook could serve 
to generalize those Viper copy and cut commands. It could also be used 
to restrict movements to a field for example. (I cc:ed Michael K. I hope 
I am not misunderstanding this.)

Re: position on changing defaults?

[Richard Stallman]

    If a property is used then the dance must happen in the command loop. 

Doing it in the command loop is clean and efficient.
It is best to avoid hooks for something as basic as this.

Re: position on changing defaults?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     If a property is used then the dance must happen in the command loop. 
>
> Doing it in the command loop is clean and efficient.

That does not rule out solutions that don't _force_ us to do it there as
long as they leave us with the option to do so.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: position on changing defaults?

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> AFAICT, the approach I proposed where most/all the movement commands get
>>> changed to call a special function in the interactive spec wouldn't
>>> suffer from any such problems.  I think it's the best approach so far.
>
>> I can not see what the advantage with an interactive spec over a property on
>> the function name is. Could you please tell?
>
> Very simple: no magic, no pre/post-command-hook.

I think this functionality is eligible for an actual interactive spec
letter.  That makes people more comfortable with using it where
appropriate.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: position on changing defaults?

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>> AFAICT, the approach I proposed where most/all the movement commands get
>>>> changed to call a special function in the interactive spec wouldn't
>>>> suffer from any such problems.  I think it's the best approach so far.
>>
>>> I can not see what the advantage with an interactive spec over a property on
>>> the function name is. Could you please tell?
>>
>> Very simple: no magic, no pre/post-command-hook.
>
> I think this functionality is eligible for an actual interactive spec
> letter.  That makes people more comfortable with using it where
> appropriate.

I'm not sure about using a letter, but maybe a symbol like ^ at the
head of the interactive spec is fairly clear.

But will XEmacs ignore such an interactive spec symbol?

If not, it becomes harder to make external packages with movement
commands which want to honor the "shift-region" feature of GNU Emacs.

The 'shift property on the command name is transparent to those
who don't understand it...

Using the shift property doesn't imply using a pre-command-hook --
it can just as well be done at the command loop.

Also, checking for a shift property in the command loop (where we
lookup the key sequence) seems a lot simpler _and cleaner_ than
checking it inside call-interactively.

Consider a case where some command (without the ^ spec) is bound to
a shifted key, and it calls call-interactive on a movement command
(with the ^ spec) -- then, should this activate the region or not?

If this is done in the command loop, such issues are clearly resolved.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>>>> AFAICT, the approach I proposed where most/all the movement commands get
>>>>> changed to call a special function in the interactive spec wouldn't
>>>>> suffer from any such problems.  I think it's the best approach so far.
>>>
>>>> I can not see what the advantage with an interactive spec over a property on
>>>> the function name is. Could you please tell?
>>>
>>> Very simple: no magic, no pre/post-command-hook.
>>
>> I think this functionality is eligible for an actual interactive spec
>> letter.  That makes people more comfortable with using it where
>> appropriate.
>
> I'm not sure about using a letter, but maybe a symbol like ^ at the
> head of the interactive spec is fairly clear.
>
> But will XEmacs ignore such an interactive spec symbol?

Why would that bother us?  We are talking about core editing macros: I
doubt that any of those will get copied verbatim into Emacs without also
synching the interactive-spec code.

> If not, it becomes harder to make external packages with movement
> commands which want to honor the "shift-region" feature of GNU Emacs.

By the time this interactive spec can be depended on to be available in
the Emacs variants one uses with those external packages, I suppose it
will have trickled into XEmacs as well.

So XEmacs is a bit of a red herring here.

> The 'shift property on the command name is transparent to those who
> don't understand it...

It is also ugly and does not lend itself to anonymous interactive
functions.  Would probably also not work well with function aliases.  It
is not my call to make, but I think the right place is the interactive
spec and not the rather arbitrary symbol that the function is bound to.

> Consider a case where some command (without the ^ spec) is bound to a
> shifted key, and it calls call-interactive on a movement command (with
> the ^ spec) -- then, should this activate the region or not?

Red herring: in either the case of an interactive spec or a property,
call-interactively would be the point to interpolate the shift key
here.  So this consideration is not relevant for the choice.

> If this is done in the command loop, such issues are clearly resolved.

What issues exactly?

-- 
David Kastrup

Re: position on changing defaults?

[Stephen J. Turnbull]

David Kastrup writes:
 > Kim Storm [it looks like] wrote:

 > > But will XEmacs ignore such an interactive spec symbol?

Most likely it will, since we already have the feature natively.  It
Just Works for me (and IIRC there have been no complaints from users)
since 2000, when it was made default.

Re: position on changing defaults?

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>  > Kim Storm [it looks like] wrote:
>
>  > > But will XEmacs ignore such an interactive spec symbol?
>
> Most likely it will, since we already have the feature natively.  It
> Just Works for me (and IIRC there have been no complaints from users)
> since 2000, when it was made default.

How do you expect us to come up with an incompatible implementation
without volunteering more details?

Anyway, it would be interesting to see how you solved the problems.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: position on changing defaults?

[Stephen J. Turnbull]

David Kastrup writes:

 > How do you expect us to come up with an incompatible implementation
 > without volunteering more details?

Well, the only detail I know off hand is that the variable controlling
the behavior is `shifted-motion-keys-select-region' and that it
defaults to t.

My only point here was to admit that 3rd party developers should not
hope that XEmacs's decade-old working implementation will soon be made
conformable to GNU's not-yet-decided one.

I see no point in going into detail, especially as that would cost me
some hours studying code I have never touched.

Re: position on changing defaults?

[Richard Stallman]

    I can not see what the advantage with an interactive spec over a 
    property on the function name is. Could you please tell?

The interactive spec is where you specify other things about how to
call the function interactively.  So it is a cleaner interface to put
this in the same place.

    And for the actual implementation of activating/deactivating the mark I 
    can not see the advantage of doing it directly in the command loop 
    instead of in special hooks before and after pre/post-command-hook. 

Using those hooks is unreliable and slow.

Re: position on changing defaults?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I can not see what the advantage with an interactive spec over a 
>     property on the function name is. Could you please tell?
>
> The interactive spec is where you specify other things about how to
> call the function interactively.  So it is a cleaner interface to put
> this in the same place.

What about commands which have a lisp form as interactive spec?

>
>     And for the actual implementation of activating/deactivating the mark I 
>     can not see the advantage of doing it directly in the command loop 
>     instead of in special hooks before and after pre/post-command-hook. 
>
> Using those hooks is unreliable and slow.

That's simply not true!
CUA mode uses them, and it works fast and flawlessly.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: position on changing defaults?

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     I can not see what the advantage with an interactive spec over a 
>>     property on the function name is. Could you please tell?
>>
>> The interactive spec is where you specify other things about how to
>> call the function interactively.  So it is a cleaner interface to put
>> this in the same place.
>
> What about commands which have a lisp form as interactive spec?

I fail to see the point you are trying to make.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: position on changing defaults?

[Richard Stallman]

    > The interactive spec is where you specify other things about how to
    > call the function interactively.  So it is a cleaner interface to put
    > this in the same place.

    What about commands which have a lisp form as interactive spec?

There can be a function they can call to do this
(Stefan proposed that).

    > Using those hooks is unreliable and slow.

    That's simply not true!
    CUA mode uses them, and it works fast and flawlessly.

The more things use these hooks, the more danger there is of bugs
due to running things in the wrong order.  For things like this,
something fixed, at the right place in the command loop, is better.

Re: position on changing defaults?

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     I can not see what the advantage with an interactive spec over a 
>     property on the function name is. Could you please tell?
> 
> The interactive spec is where you specify other things about how to
> call the function interactively.  So it is a cleaner interface to put
> this in the same place.

Thanks. Then I think using a interactive spec has to be compared with 
the greater flexibility with using a property on the function.

>     And for the actual implementation of activating/deactivating the mark I 
>     can not see the advantage of doing it directly in the command loop 
>     instead of in special hooks before and after pre/post-command-hook. 
> 
> Using those hooks is unreliable and slow.

Using a hook can't be too slow here since this is just one hook at the 
top level of the command loop, or? (I think this is Stefan's position.)

If shift things are added to pre-command hook then there can be some 
trouble because other functions might to things before those we want to 
do. However if a new hook is introduced that runs before pre-command 
hook then it should be reliable. (If this hook is not used for things 
that can break the shift things.)

The advantage of such a hook is that it can be used for other similar 
things and that the "shift things" can be written in elisp.

Re: position on changing defaults?

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> But S-right C-5 S-right, also just marks 5 chars, as the C-5
>> prefix deactivates the mark set by the first S-right.
>
> This, and the issue with scrolling, makes me think that the `only'-TTM
> is maybe not the best approach.
>
>> BTW, we discussed making transient-mark-mode the default - so
>> can we assume that transient-mark-mode is _on_ for the shifted
>> movement keys to work?  Or do we have to find a solution which
>> works also for transient-mark-mode off (e.g. setting it on
>> temporarily as Miles approach did).
>
> AFAICT, the approach I proposed where most/all the movement commands get
> changed to call a special function in the interactive spec wouldn't
> suffer from any such problems.  I think it's the best approach so far.

I'll code up a prototype and see how well it works.