python-mode (python.el): python-backspace

python-mode (python.el): python-backspace

[Karl Chen]

I liked the <backspace>/DEL key better the way it worked in the
python-mode.el's python-mode.

Python-mode.el's backspace:
    Close the current block, or unindent one level if already at that indentation

    Logical inverse of python.el's TAB.

Python.el's python-backspace:
    Close the current block

    Counter-intuitive in many cases, such as if point is already
    left of where python-backspace moves indents to (backspace
    moves the cursor rightward?!)


I suggest python-backspace's behavior be changed so that: if point
is <= where the current behavior would have indented to, then
unindent by 1 python-indent level



-- 
Karl 2004-05-16 14:51

Re: python-mode (python.el): python-backspace

[Dave Love]

Karl Chen <quarl@hkn.eecs.berkeley.edu> writes:

> Python.el's python-backspace:
>     Close the current block
>
>     Counter-intuitive in many cases, such as if point is already
>     left of where python-backspace moves indents to (backspace
>     moves the cursor rightward?!)

I don't understand that.

> I suggest python-backspace's behavior be changed so that: if point
> is <= where the current behavior would have indented to, then
> unindent by 1 python-indent level

I don't remember whether the behaviour was intended to be the same as
python-mode.el or not.  Anyhow, I don't object if someone cares to
change it.

I see the `python-backspace' doc string is unclear/incorrect.  I'd
suggest changing it to something like this for the current
implementation:

  "Maybe delete a level of indentation on the current line.
Do so if point is at the end of line's indentation.
Otherwise, just call `backward-delete-char-untabify'.
With ARG, repeat that many times."

Re: python-mode (python.el): python-backspace

[Karl Chen]

>>>>> "Dave" == Dave Love <d.love@dl.ac.uk> writes:
    Dave> 
    Dave> Karl Chen <quarl@hkn.eecs.berkeley.edu> writes:
    >> Python.el's python-backspace: Close the current block
    >> 
    >> Counter-intuitive in many cases, such as if point is
    >> already left of where python-backspace moves indents to
    >> (backspace moves the cursor rightward?!)
    Dave> 
    Dave> I don't understand that.

Suppose you have typed the following, where | represents point.
Here are 4 cases of where point is, and where it ends up after
<backspace>.

# 1:
class Class:                      class Class:
    def fun():          ==>           def fun():
        if foo:                           if foo:
            bar()                             bar()
            |                             |

# 2:
class Class:                      class Class:
    def fun():          ==>           def fun():
        if foo:                           if foo:
            bar()                             bar()
        |                                 |

# 3:
class Class:                      class Class:
    def fun():          ==>           def fun():
        if foo:                           if foo:
            bar()                             bar()
    |                                     |

# 4:
class Class:                      class Class:
    def fun():          ==>           def fun():
        if foo:                           if foo:
            bar()                             bar()|
|


The first and fourth cases make sense.  But cases 2 and 3 are
counter-intuitive in my opinion, especially #3 where the cursor
moves rightward on <backspace>.

The behavior I recommend is that the cursor/indentation moves left
in cases 1-3:


# 1:
class Class:                      class Class:
    def fun():          ==>           def fun():
        if foo:                           if foo:
            bar()                             bar()
            |                             |

# 2:
class Class:                      class Class:
    def fun():          ==>           def fun():
        if foo:                           if foo:
            bar()                             bar()
        |                             |

# 3:
class Class:                      class Class:
    def fun():          ==>           def fun():
        if foo:                           if foo:
            bar()                             bar()
    |                             |

# 4:
class Class:                      class Class:
    def fun():          ==>           def fun():
        if foo:                           if foo:
            bar()                             bar()|
|



I didn't mean to compare <backspace> to the other python-mode
implementation for compatibility or old time's sake, but because
I like its behavior better

-- 
Karl 2004-05-17 10:17

Re: python-mode (python.el): python-backspace

[Richard Stallman]

It is not a good thing for a major mode to redefine DEL or Backspace
so drastically, because that breaks a general convention that is supposed
to be universal in Emacs.  It is ok to have an option to do this,
but it should not be the default.

The default should be to delete one character backwards,
one way or another.

Re: python-mode (python.el): python-backspace

[Karl Chen]

There could be a python electric minor mode.

Is any sort of "global electric" customization/variable that tells
packages to turn on some default level of electricity?  I tend to
turn on all the automatic stuff, but I could see other people that
would prefer them all off.



>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:
    Richard> 
    Richard> It is not a good thing for a major mode to redefine
    Richard> DEL or Backspace so drastically, because that breaks
    Richard> a general convention that is supposed to be universal
    Richard> in Emacs.  It is ok to have an option to do this, but
    Richard> it should not be the default.
    Richard> 
    Richard> The default should be to delete one character
    Richard> backwards, one way or another.
    Richard> 
-- 
Karl 2004-05-17 23:16

Re: python-mode (python.el): python-backspace

[Stefan Monnier]

> It is not a good thing for a major mode to redefine DEL or Backspace
> so drastically, because that breaks a general convention that is supposed
> to be universal in Emacs.  It is ok to have an option to do this,
> but it should not be the default.

I'd suggest that if we start fiddling with such code, we introduce a generic
way to electrify backspace.  Otherwise people who want it need to enable it
separately (and differently) for each and every major mode they use.


        Stefan

Re: python-mode (python.el): python-backspace

[David Kastrup]

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

> > It is not a good thing for a major mode to redefine DEL or Backspace
> > so drastically, because that breaks a general convention that is supposed
> > to be universal in Emacs.  It is ok to have an option to do this,
> > but it should not be the default.
> 
> I'd suggest that if we start fiddling with such code, we introduce a generic
> way to electrify backspace.  Otherwise people who want it need to enable it
> separately (and differently) for each and every major mode they use.

While we are electrifying, I want to point out the complete lack of
an "LF" key on almost all of today's keyboards.  I think that in most
modes, people would prefer to have RET bound to newline-and-indent
instead of newline.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: python-mode (python.el): python-backspace

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> While we are electrifying, I want to point out the complete lack of
> an "LF" key on almost all of today's keyboards.

It's spelled C-j. :-)

> I think that in most modes, people would prefer to have RET bound to
> newline-and-indent instead of newline.

I would immediately change that back.

Andreas.

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

Re: python-mode (python.el): python-backspace

[Dave Love]

Karl Chen <quarl@hkn.eecs.berkeley.edu> writes:

> The first and fourth cases make sense.  But cases 2 and 3 are
> counter-intuitive in my opinion, especially #3 where the cursor
> moves rightward on <backspace>.

Oh...  I can't test it at present, but I didn't think it did that.

> The behavior I recommend is that the cursor/indentation moves left
> in cases 1-3:

Indeed.  That's what I thought it did when I used it.

> I didn't mean to compare <backspace> to the other python-mode
> implementation for compatibility or old time's sake, but because
> I like its behavior better

Sure.

Thanks for the feedback.  Can you send a fix for it, or do you want me
to look at it sometime?

Re: python-mode (python.el): python-backspace

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> It is not a good thing for a major mode to redefine DEL or Backspace
> so drastically,

I don't think it's very drastic, else I'd probably agree.  It's a
refinement of what many modes do anyway in redefining DEL, and I think
most people editing Python would think it just DTRT (more-or-less).

Apparently it's broken, but the intention is that it deletes a level
of indentation backwards iff it's at the end of indentation.  That
(probably) keeps the source syntactically correct, as opposed to what
the the default binding would do for indent steps >1.

Note that the indentation is actually part of the syntax in Python and
it has to match the start of a block to be syntactically correct.
[It's similar to, but not the same as Landin's `offside' rule, if that
means anything.]

> because that breaks a general convention that is supposed
> to be universal in Emacs.  It is ok to have an option to do this,
> but it should not be the default.
>
> The default should be to delete one character backwards,
> one way or another.

Programming modes typically use `backward-delete-char-untabify', not
`delete-backward-char', though some bind it to something different.

Re: python-mode (python.el): python-backspace

[Dave Love]

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

> I'd suggest that if we start fiddling with such code, we introduce a
> generic way to electrify backspace.  Otherwise people who want it
> need to enable it separately (and differently) for each and every
> major mode they use.

But in general the `electric' behaviour will be different between
modes, e.g. Python v. Lisp.  A minor mode for using
`backward-delete-char-untabify' seems reasonable from that POV.
However, it seems unnecessary in view of the established usage and
would mean changing yet more longstanding behaviour.

Re: python-mode (python.el): python-backspace

[Karl Chen]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
    Stefan> I'd suggest that if we start fiddling with such code,
    Stefan> we introduce a generic way to electrify backspace.
    Stefan> Otherwise people who want it need to enable it
    Stefan> separately (and differently) for each and every major
    Stefan> mode they use.

How about another mode-specific layer analogous to the way
`indent-line-function' specifies how indent-according-to-mode
works.  `electric-delete-backwards-function' can specify how
`electric-delete-backwards' works.  That way a user can bind DEL
to `electric-delete-backwards' and not have to figure out per-mode
how to do it.

The default can be something that acts like cc-mode's
c-electric-backspace.

-- 
Karl 2004-05-18 11:02

Re: python-mode (python.el): python-backspace

[Stefan Monnier]

>> I'd suggest that if we start fiddling with such code, we introduce a
>> generic way to electrify backspace.  Otherwise people who want it
>> need to enable it separately (and differently) for each and every
>> major mode they use.

> But in general the `electric' behaviour will be different between
> modes, e.g. Python v. Lisp.

Then it's not what I have in mind.  What I have in mind is the kind of
"electric backspace" seen in python-mode or in cc-mode.  It can do
things like:
- delete hungrily all whitespace.
- delete to previous level of indentation.
Both of those are conceptually mode-independent (although the
implementation might be mode-dependent), just like M-; and others.
There is already the "untabify" version of backspace and I think we should
make it easier for people to change such things globally.


        Stefan

Re: python-mode (python.el): python-backspace

[Richard Stallman]

    There could be a python electric minor mode.

That would be a good way to handle it.

    Is any sort of "global electric" customization/variable that tells
    packages to turn on some default level of electricity?

No, and I don't see that it makes sense, given that these features are
ideosyncratic for specific modes.  If every major mode, or many of them,
had some sort of electric backspace, it would make sense to have
a uniform way to turn them on.  But they don't.

Re: python-mode (python.el): python-backspace

[Richard Stallman]

    I'd suggest that if we start fiddling with such code, we introduce a generic
    way to electrify backspace.

I don't see how that makes any sense.  Only a few modes have any such
concept, and what it does is specific to each mode.

The only problem that needs to be solved here is the problem
that Python mode by default redefines Backspace in a manner
inconsistent with general the Emacs convention for Backspace.

Re: python-mode (python.el): python-backspace

[Richard Stallman]

    While we are electrifying, I want to point out the complete lack of
    an "LF" key on almost all of today's keyboards.  I think that in most
    modes, people would prefer to have RET bound to newline-and-indent
    instead of newline.

It would be good for these "electric" minor modes to operate by
remapping the command rather than by rebinding a specific key.
We could make this change in various modes as we get to them.

Re: python-mode (python.el): python-backspace

[Richard Stallman]

    > It is not a good thing for a major mode to redefine DEL or Backspace
    > so drastically,

    I don't think it's very drastic, else I'd probably agree.  It's a
    refinement of what many modes do anyway in redefining DEL, and I think
    most people editing Python would think it just DTRT (more-or-less).

If it doesn't look like deleting one character backwards,
it is a drastic change.

    > The default should be to delete one character backwards,
    > one way or another.

    Programming modes typically use `backward-delete-char-untabify', not
    `delete-backward-char', though some bind it to something different.

This redefinition is ok because it fits with the description that DEL
deletes one character backwards.  It reinterprets "one character" in a
legitimate way.

However, to describe the current Python mode definition as "deleting
one character backwards" is clearly untrue.  That redefinition does
not reinterpret the description.  This command does a different job,
not the same job.

Re: python-mode (python.el): python-backspace

[Stefan Monnier]

> No, and I don't see that it makes sense, given that these features are
> ideosyncratic for specific modes.  If every major mode, or many of them,
> had some sort of electric backspace, it would make sense to have
> a uniform way to turn them on.  But they don't.

I think that many modes don't have them because they're not crucial and/or
their author wouldn't use it, not because it doesn't make sense for that
major mode.
AFAIK cc-modes were the only ones to offer hungry delete, yet that didn't
mean it had to stay that way.  I think the same applies to "delete one
indentation step".


        Stefan

Re: python-mode (python.el): python-backspace

[Karl Chen]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:
    Richard>     Programming modes typically use
    Richard>     `backward-delete-char-untabify', not
    Richard>     `delete-backward-char', though some bind it to
    Richard>     something different.
    Richard> 
    Richard> This redefinition is ok because it fits with the
    Richard> description that DEL deletes one character backwards.
    Richard> It reinterprets "one character" in a legitimate way.
    Richard> 
    Richard> However, to describe the current Python mode
    Richard> definition as "deleting one character backwards" is
    Richard> clearly untrue.  That redefinition does not
    Richard> reinterpret the description.  This command does a
    Richard> different job, not the same job.

If you were willing to interpret tabs as single characters in some
modes, one could argue that in Python, <python-indent number of
spaces> at the beginning of lines is really a substitute for a
TAB.  People think of indenting as pressing TAB (not 4 spaces),
and actual tabs are discouraged from use because of their
ambiguity.

-- 
Karl 2004-05-19 09:24

Re: python-mode (python.el): python-backspace

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> If it doesn't look like deleting one character backwards,
> it is a drastic change.

It actually does that with indent-tabs-mode and the indentation step
equal to a tab width.

> This redefinition is ok because it fits with the description that DEL
> deletes one character backwards.  It reinterprets "one character" in a
> legitimate way.

As I think Python mode does, and major modes are explicitly documented
thus (`Major Modes'):

     Selecting a major mode changes the meanings of a few keys to become
  more specifically adapted to the language being edited.  The ones that
  are changed frequently are <TAB>, <DEL>, and `C-j'.

It's adapted (modulo possible bugs) in a way which people who actually
use it find natural.
  
> However, to describe the current Python mode definition as "deleting
> one character backwards" is clearly untrue.

As far as I can tell, it does always delete characters backwards,
whereas in Lisp mode, it can actually add space characters.

Now I've had a chance to try, I can't reproduce the reported behaviour
where it moved point forward and, as I said, that would be a bug.
I've got confused by the state of the sources, but as far as I can
tell, I'm running the latest version.

Is the issue with the DEL binding just that reported behaviour or is
it with the intended behaviour?

> That redefinition does
> not reinterpret the description.  This command does a different job,
> not the same job.

If you won't accept DEL, what would be a natural key for the job
`delete a level of indentation when deleting a single space would be
syntactically incorrect'?

Re: python-mode (python.el): python-backspace

[Karl Chen]

>>>>> "Dave" == Dave Love <fx@gnu.org> writes:
    Dave> Now I've had a chance to try, I can't reproduce the
    Dave> reported behaviour where it moved point forward and, as
    Dave> I said, that would be a bug.  I've got confused by the
    Dave> state of the sources, but as far as I can tell, I'm
    Dave> running the latest version.

Sorry, the current version works fine.  I guess an old version had
the problem.

-- 
Karl 2004-05-20 23:01

Re: python-mode (python.el): python-backspace

[Richard Stallman]

    If you won't accept DEL, what would be a natural key for the job
    `delete a level of indentation when deleting a single space would be
    syntactically incorrect'?

I am not sure, but is that really a legitimate stretching of the meaning
of DEL?

Re: python-mode (python.el): python-backspace

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     If you won't accept DEL, what would be a natural key for the job
>     `delete a level of indentation when deleting a single space would be
>     syntactically incorrect'?
>
> I am not sure, but is that really a legitimate stretching of the meaning
> of DEL?

I suppose it depends on who you talk too -- I suspect people who would
like RET bound to `newline-and-indent' (and there seem to be quite a few
of them, judging from the mailing lists) might also like DEL bound to
something higher-level too, and the people who strongly oppose the
former binding might hate the latter as well...

-Miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: python-mode (python.el): python-backspace

[Dave Love]

Miles Bader <miles@lsi.nec.co.jp> writes:

> I suppose it depends on who you talk too -- I suspect people who would
> like RET bound to `newline-and-indent' (and there seem to be quite a few
> of them, judging from the mailing lists) might also like DEL bound to
> something higher-level too, and the people who strongly oppose the
> former binding might hate the latter as well...

I don't think a binding that attempts to keep the Python source
syntactically correct in a simple way is comparable with rebinding RET
like that, which isn't related to the language syntax.

I guess someone could ask Barry Warsaw & al what complaints there were
about the similar binding in his mode.

I still don't understand the comments from the head of this thread
about the behaviour of python-backspace, which I can't reproduce.

Re: python-mode (python.el): python-backspace

[Dave Love]

[I'm not sure this got out before.]

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

> - delete hungrily all whitespace.
> - delete to previous level of indentation.
> Both of those are conceptually mode-independent

I don't think they are.  Most modes have only a single `valid'
indentation for any line (according to their indentation rules), and
it may not be clear how to define a `level of indentation'
(e.g. Lisp).  That's not the case in Python and Haskell, for instance,
where deleting a level of indentation is well-defined and either
meaningful or syntactically invalid.

> There is already the "untabify" version of backspace and I think we should
> make it easier for people to change such things globally.

What's wrong with `backward-delete-char-untabify-method' for that?

Re: python-mode (python.el): python-backspace

[Stefan Monnier]

>> - delete hungrily all whitespace.
>> - delete to previous level of indentation.
>> Both of those are conceptually mode-independent

> I don't think they are.  Most modes have only a single `valid'
> indentation for any line (according to their indentation rules), and
> it may not be clear how to define a `level of indentation'
> (e.g. Lisp).  That's not the case in Python and Haskell, for instance,
> where deleting a level of indentation is well-defined and either
> meaningful or syntactically invalid.

Hmm... in my world, only Python and Haskell have a notion of a "valid"
indentation.  All others all any indentation whatsoever.  In most modes, it
is true that the syntax is redundant enough that there is little choice
given a particular indentation style, but indentation style is not
always followed, and auto-indentation doesn't always work correctly.
Several major modes use a M-TAB binding to "delete one level of
indentation".  I remember writing a generic "delete to previous level of
indentation" because someone asked for it on gnu.emacs.help...
yes, here it is:

   http://groups.google.com/groups?selm=5lbrx8e1rc.fsf%40rum.cs.yale.edu&output=gplain

I think binding such a command to DEL makes perfect sense.  But it would be
good to allow modes like python-mode to tune its behavior to be more correct.

>> There is already the "untabify" version of backspace and I think we should
>> make it easier for people to change such things globally.

> What's wrong with `backward-delete-char-untabify-method' for that?

Nothing, other than the fact that it does not include "delete to prev level
of indent".  Oh and that you first have to bind
backward-delete-char-untabify globally and then set the variable (and that
some major modes might then "gratuitously" override the binding locally, of
course).


        Stefan

Re: python-mode (python.el): python-backspace

[Richard Stallman]

      I remember writing a generic "delete to previous level of
    indentation" because someone asked for it on gnu.emacs.help...
    yes, here it is:

       http://groups.google.com/groups?selm=5lbrx8e1rc.fsf%40rum.cs.yale.edu&output=gplain

What is the generic definition of "level of indentation"?
I'm not sure what that would mean in Lisp or C.

Re: python-mode (python.el): python-backspace

[Kai Grossjohann]

Richard Stallman <rms@gnu.org> writes:

> What is the generic definition of "level of indentation"?
> I'm not sure what that would mean in Lisp or C.

Stefan's definition is based on lines in the buffer.  I think that's a
good definition.

If point is currently at column N, search backward for a line with
indentation M < N.  Then delete characters to the left until column M
is reached.

Kai

Re: python-mode (python.el): python-backspace

[Richard Stallman]

    If point is currently at column N, search backward for a line with
    indentation M < N.  Then delete characters to the left until column M
    is reached.

I suppose that could be useful in many modes.  Not, I think, in modes
that compute the exact indentation, such as Lisp mode and C mode.  But
there are many modes which don't have such careful
indentation computations.

Re: python-mode (python.el): python-backspace

[Stefan Monnier]

>     If point is currently at column N, search backward for a line with
>     indentation M < N.  Then delete characters to the left until column M
>     is reached.

> I suppose that could be useful in many modes.  Not, I think, in modes
> that compute the exact indentation, such as Lisp mode and C mode.  But
> there are many modes which don't have such careful
> indentation computations.

Yes, it would obviously need a hook so that modes like Lisp, Python, C, ...
can provide a more precise definition.  But I think as a first
approximation for those mode authors who don't have the time/energy to fine
tune every little detail, it's a pretty good default.


        Stefan

Re: python-mode (python.el): python-backspace

[Richard Stallman]

    > I suppose that could be useful in many modes.  Not, I think, in modes
    > that compute the exact indentation, such as Lisp mode and C mode.  But
    > there are many modes which don't have such careful
    > indentation computations.

    Yes, it would obviously need a hook so that modes like Lisp, Python, C, ...
    can provide a more precise definition.

These modes already provide a completely precise definition,
in TAB.  I don't see any case where I'd want to use this command
in such modes.  The cases where I do hand-modification of the results
of TAB almost always have to do with how to align the inside of
a construct; going back to the top of the construct is always
too little.

However, we need not argue about that; I agree the command is useful
for other modes.

Re: python-mode (python.el): python-backspace

[Dave Love]

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

> Hmm... in my world, only Python and Haskell have a notion of a "valid"
> indentation.

I'm obviously in a different world, but `indentation rules' meant what
the indentation engine does, not whether indentation is significant.

> All others all any indentation whatsoever.  In most modes, it
> is true that the syntax is redundant enough that there is little choice
> given a particular indentation style, but indentation style is not
> always followed, and auto-indentation doesn't always work correctly.

I'm not convinced that a specific binding of DEL would help most of
the time in such cases.

> Several major modes use a M-TAB binding to "delete one level of
> indentation".

That seems pretty broken.  Which ones?

> I think binding such a command to DEL makes perfect sense.

I think it would break various things (even if it did check for being
outside strings and comments), and I don't think that it makes sense
in most of the modes I use, including programming language ones.  I'm
sure it shouldn't be the default for DEL.

> But it would be good to allow modes like python-mode to tune its
> behavior to be more correct.

Well, I still maintain that Python and Haskell, for instance, should
have specialized behaviour for TAB and DEL which aren't likely to
result from tuning anything else.

>> What's wrong with `backward-delete-char-untabify-method' for that?
>
> Nothing, other than the fact that it does not include "delete to prev level
> of indent".  Oh and that you first have to bind
> backward-delete-char-untabify globally and then set the variable (and that
> some major modes might then "gratuitously" override the binding locally, of
> course).

That seems to apply to anything you change globally.  At least that
gives people/modes a hook to change things if they want to, assuming
the global binding of DEL to backward-delete-char-untabify with
default value of nil, but I don't see the need to break compatibility
to do that sort of thing at all.

Re: python-mode (python.el): python-backspace

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> What is the generic definition of "level of indentation"?
> I'm not sure what that would mean in Lisp or C.

Yes, I had Lisp in mind especially.  In the cases I can think of where
I typically want to delete some Lisp indentation, going to the level
of the previous line would be wrong.

Re: python-mode (python.el): python-backspace

[Richard Stallman]

    > Several major modes use a M-TAB binding to "delete one level of
    > indentation".

    That seems pretty broken.  Which ones?

The default binding for M-TAB is complete-symbol.  That is not a
basic command, and if in mode XYZ complete-symbol is not useful,
I would not object that the mode redefines M-TAB to something
completely different.

DEL is a basic command, too basic to be redefined in that way.

Re: python-mode (python.el): python-backspace

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> The default binding for M-TAB is complete-symbol.  That is not a
> basic command, and if in mode XYZ complete-symbol is not useful,
> I would not object that the mode redefines M-TAB to something
> completely different.

As a user of programming language modes, I'd find that very confusing.
Symbol completion ought to make sense generally in programming modes,
at least.

> DEL is a basic command, too basic to be redefined in that way.

I don't understand this policy, given how it's been used and
documented since the year dot.  Are you really suggesting changing the
bindings everywhere, like in Info?

Re: python-mode (python.el): python-backspace

[Richard Stallman]

    > DEL is a basic command, too basic to be redefined in that way.

    I don't understand this policy, given how it's been used and
    documented since the year dot.  Are you really suggesting changing the
    bindings everywhere, like in Info?

I was talking about modes for programming languages.
You're talking read-only modes for special text.
These are separate issues.

Re: python-mode (python.el): python-backspace

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     > DEL is a basic command, too basic to be redefined in that way.
>
>     I don't understand this policy, given how it's been used and
>     documented since the year dot.  Are you really suggesting changing the
>     bindings everywhere, like in Info?
>
> I was talking about modes for programming languages.
> You're talking read-only modes for special text.
> These are separate issues.

Perhaps you could explain the issues somewhere in the manuals,
including to what other keys it applies, and in exactly what
circumstances.  What I did was in accordance with the manual, existing
practice, and what was natural to me as a user, so I guess are likely
to make the same sort of mistake.