Re: python-mode: keep mark when shifting [patch]

Re: python-mode: keep mark when shifting [patch]

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> In C or Lisp I
> would use C-u TAB to shift a subexpression to the proper position.
> (There's no need to specify left or right, because the command figures
> that out.)  Could that work in Python mode?

There isn't a single correct indentation in general.  (TAB cycles
between the valid values.)

Note that Python mode obeys the Emacs conventions for indentation
commands, unlike Lisp mode.  It just binds `indent-line-function',
which doesn't take an arg.  It would probably make sense for C-u TAB
to re-indent the rest of a block rigidly when used on the head line of
the block, and/or to have TAB act on the region when it's active, but
there are better things to spend time on.

The shift-region functions are inherited from the old python-mode.el
and may or may not really be a good idea.

> I recall Python is weird in regard to indentation.  Maybe it simply
> needs different kinds of commands from those needed by other
> languages.

Python uses something like Landin's offside rule to define blocks by
indentation.  I don't think it needs different commands, though the
behaviour of TAB is unusual -- successive use cycles between the valid
indentations for a line (like in Haskell mode).

Re: python-mode: keep mark when shifting [patch]

[David Reitter]

On 13 Mar 2006, at 00:22, Dave Love wrote:

>  The shift-region functions are inherited from the old python-mode.el
> and may or may not really be a good idea.

Consider the following use case:  A code block is to be moved out of  
its context in order to stick it into a separate function. I yank it  
at its destination, write a "def newfunc():" at the top. But now I  
have to reindent it. Repeated use of C-c > and C-c < do that job just  
fine. However, because it is typically used repeatedly on the same  
region, deactivating the mark is very inconvenient.

In other languages, I would use C-M-\ to re-indent automatically,  
which is impossible in Python, since indentation carries semantics  
and doesn't follow from the code. You mentioned that other  
indentation function (i.e. shift functions) also deactivate the mark.  
If that's so, I would argue that these should be changed as well for  
the same reason.

Re: python-mode: keep mark when shifting [patch]

[Richard Stallman]

    Repeated use of C-c > and C-c < do that job just  
    fine. However, because it is typically used repeatedly on the same  
    region, deactivating the mark is very inconvenient.

That does seem like a persuasive argument.

    Consider the following use case:  A code block is to be moved out of  
    its context in order to stick it into a separate function. I yank it  
    at its destination, write a "def newfunc():" at the top. But now I  
    have to reindent it. Repeated use of C-c > and C-c < do that job just  
    fine. However, because it is typically used repeatedly on the same  
    region, deactivating the mark is very inconvenient.

Suppose you define C-u TAB to cycle thru the same positions that TAB
would cycle thru.  Would that be a convenient solution?

Re: python-mode: keep mark when shifting [patch]

[Dave Love]

David Reitter <david.reitter@gmail.com> writes:

> The ideal situation in my view would be a default indent command
> which is modified by the major mode if necessary. That way, I
> wouldn't have to learn different key bindings for indent commands for
> programming in Perl and Python.

What command for you mean for Perl?  I can't see anything equivalent.

Whatever, it would be best to fix the bugs first.

Re: python-mode: keep mark when shifting [patch]

[Dave Love]

David Reitter <david.reitter@gmail.com> writes:

> The patch below fixed a behavior of python-mode that I've found
> somewhat annoying: it deactivates the mark whenever you do C-c < or C-
> c > to shift a block to the left or right. Because one commonly needs
> to do this several times in a row (checking visually in between),
> it's very unhelpful if the mark gets deactivated.

I don't have an opinion on the behaviour, and it probably wouldn't be
relevant anyway, but if anything changes it should be
`indent-rigidly', which python-shift-... uses.

python-mode: keep mark when shifting [patch]

[David Reitter]

The patch below fixed a behavior of python-mode that I've found  
somewhat annoying: it deactivates the mark whenever you do C-c < or C- 
c > to shift a block to the left or right. Because one commonly needs  
to do this several times in a row (checking visually in between),  
it's very unhelpful if the mark gets deactivated.

Secondly, I was wondering if there is / could be a convention for  
shifting code horizontally.


*** python.el	22 Feb 2006 19:15:41 +0000	1.36
--- python.el	09 Mar 2006 18:24:05 +0000	
***************
*** 1532,1544 ****
       (setq count python-indent))
     (when (> count 0)
       (save-excursion
         (goto-char start)
         (while (< (point) end)
   	(if (and (< (current-indentation) count)
   		 (not (looking-at "[ \t]*$")))
   	    (error "Can't shift all lines enough"))
   	(forward-line))
!       (indent-rigidly start end (- count)))))

   (add-to-list 'debug-ignored-errors "^Can't shift all lines enough")

--- 1532,1545 ----
       (setq count python-indent))
     (when (> count 0)
       (save-excursion
+       (let ((deactivate-mark))
         (goto-char start)
         (while (< (point) end)
   	(if (and (< (current-indentation) count)
   		 (not (looking-at "[ \t]*$")))
   	    (error "Can't shift all lines enough"))
   	(forward-line))
!       (indent-rigidly start end (- count))))))

   (add-to-list 'debug-ignored-errors "^Can't shift all lines enough")

***************
*** 1553,1559 ****
     (if count
         (setq count (prefix-numeric-value count))
       (setq count python-indent))
!   (indent-rigidly start end count))

   (defun python-outline-level ()
     "`outline-level' function for Python mode.
--- 1554,1562 ----
     (if count
         (setq count (prefix-numeric-value count))
       (setq count python-indent))
!
!   (let ((deactivate-mark))
!     (indent-rigidly start end count)))

   (defun python-outline-level ()
     "`outline-level' function for Python mode.

Re: python-mode: keep mark when shifting [patch]

[Henrik Enberg]

David Reitter <david.reitter@gmail.com> writes:

> The patch below fixed a behavior of python-mode that I've found  
> somewhat annoying: it deactivates the mark whenever you do C-c < or C- 
> c > to shift a block to the left or right. Because one commonly needs  
> to do this several times in a row (checking visually in between),  
> it's very unhelpful if the mark gets deactivated.

Since other indent commands that works on a region in Emacs deactivate
the mark, wouldn't this be a bit surprising?

Re: python-mode: keep mark when shifting [patch]

[David Reitter]

On 10 Mar 2006, at 20:40, Henrik Enberg wrote:

> David Reitter <david.reitter@gmail.com> writes:
>
>> The patch below fixed a behavior of python-mode that I've found
>> somewhat annoying: it deactivates the mark whenever you do C-c <  
>> or C-
>> c > to shift a block to the left or right. Because one commonly needs
>> to do this several times in a row (checking visually in between),
>> it's very unhelpful if the mark gets deactivated.
>
> Since other indent commands that works on a region in Emacs deactivate
> the mark, wouldn't this be a bit surprising?

I agree, as long as we are talking about manual indent commands,  
which are often applied repeatedly.
(fill-paragraph, for example, can deactivate the mark of course.)

The ideal situation in my view would be a default indent command  
which is modified by the major mode if necessary. That way, I  
wouldn't have to learn different key bindings for indent commands for  
programming in Perl and Python.
This command can then ensure that the mark does not get deactivated.

Re: python-mode: keep mark when shifting [patch]

[Richard Stallman]

    The ideal situation in my view would be a default indent command  
    which is modified by the major mode if necessary.

In theory we could add another such general command that modes would
modify, as they do TAB.  However, is that necessary?  In C or Lisp I
would use C-u TAB to shift a subexpression to the proper position.
(There's no need to specify left or right, because the command figures
that out.)  Could that work in Python mode?

I recall Python is weird in regard to indentation.  Maybe it simply
needs different kinds of commands from those needed by other
languages.