GNU bug report logs - #19691
24.4; python.el: indentation RFE

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19691 in the body.
You can then email your comments to 19691 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Carlos Pita <carlosjosepita <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: galli.87 <at> gmail.com
Subject: 24.4; python.el: indentation RFE
Date: Mon, 26 Jan 2015 11:25:18 -0300

When you're in a blank line and press Enter, IMHO it would be better if
python.el kept the cursor column position, instead of restoring the last
non-blank line indentation level.

For example, say the cursor is X:

def f():
    pass
X

When I press Enter most often I don't want to get:

def f():
    pass

    X

Instead, I think a more sensible default behaviour would be:

def f():
    pass

X

That is, to keep the cursor vertical position. This is consistent with
the criterion of auto-indenting up to the indentation of last (both
blank or non-blank) line, except for the technicality that a blank last
line is not really indented... although you still have a point position
there to infer desired indentation for the new line.

Maybe this should be made a customizable option.

What do you think? I'll try to submit a patch later today.

Message #10 received at 19691-done <at> debbugs.gnu.org (full text, mbox):

From: fgallina <at> gnu.org (Fabián Ezequiel Gallina)
To: 19691-done <at> debbugs.gnu.org
Subject: 24.4; python.el: indentation RFE
Date: Fri, 30 Jan 2015 00:52:32 -0300

tags 19691 + notabug
quit


Hi Carlos,

The functionality already exists, it's a matter of toggling
`electric-indent-mode` OR alternate between using RET and `C-j` for
creating a newline (depending the case).

When `electric-indent-mode` is enabled, you can achieve what you want by
using `C-j`, while RET would indent just like you see right now.

When `electric-indent-mode` is disabled, you can achieve what you want
by using RET, and `C-j` would indent.

If what you want is to keep the current column in places where there are
several indentation levels involved, then `C-a C-j` or `C-a RET`
(depending on the status `electric-indent-mode`) will help.



Cheers,
Fabián

Message #15 received at 19691 <at> debbugs.gnu.org (full text, mbox):

From: Carlos Pita <carlosjosepita <at> gmail.com>
To: 19691 <at> debbugs.gnu.org
Cc: Fabian Ezequiel Gallina <galli.87 <at> gmail.com>
Subject: Re: bug#19691: closed (24.4; python.el: indentation RFE)
Date: Fri, 30 Jan 2015 07:18:13 -0300

Hi Fabian,

I was thinking a bit more about this after my report and I concluded
that a simpler approach based on the recommendations of pep8 could fit
the bill: two consecutive blank lines can be considered as an
"indentation context" that finishes a top level definition, so the
next line will have no indentation at all. I've already implemented
this and could post a patch later if you want, but it's a pretty
trivial one and I'm sure you would do it better than me.

Cheers
--
Carlos

On Fri, Jan 30, 2015 at 12:53 AM, GNU bug Tracking System
<help-debbugs <at> gnu.org> wrote:
> Your bug report
>
> #19691: 24.4; python.el: indentation RFE
>
> which was filed against the emacs package, has been closed.
>
> The explanation is attached below, along with your original report.
> If you require more details, please reply to 19691 <at> debbugs.gnu.org.
>
> --
> 19691: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19691
> GNU Bug Tracking System
> Contact help-debbugs <at> gnu.org with problems
>
>
> ---------- Forwarded message ----------
> From: "Fabián Ezequiel Gallina" <fgallina <at> gnu.org>
> To: 19691-done <at> debbugs.gnu.org
> Cc:
> Date: Fri, 30 Jan 2015 00:52:32 -0300
> Subject: 24.4; python.el: indentation RFE
> tags 19691 + notabug
> quit
>
>
> Hi Carlos,
>
> The functionality already exists, it's a matter of toggling
> `electric-indent-mode` OR alternate between using RET and `C-j` for
> creating a newline (depending the case).
>
> When `electric-indent-mode` is enabled, you can achieve what you want by
> using `C-j`, while RET would indent just like you see right now.
>
> When `electric-indent-mode` is disabled, you can achieve what you want
> by using RET, and `C-j` would indent.
>
> If what you want is to keep the current column in places where there are
> several indentation levels involved, then `C-a C-j` or `C-a RET`
> (depending on the status `electric-indent-mode`) will help.
>
>
>
> Cheers,
> Fabián
>
>
>
> ---------- Forwarded message ----------
> From: Carlos Pita <carlosjosepita <at> gmail.com>
> To: bug-gnu-emacs <at> gnu.org
> Cc: galli.87 <at> gmail.com
> Date: Mon, 26 Jan 2015 11:25:18 -0300
> Subject: 24.4; python.el: indentation RFE
> When you're in a blank line and press Enter, IMHO it would be better if
> python.el kept the cursor column position, instead of restoring the last
> non-blank line indentation level.
>
> For example, say the cursor is X:
>
> def f():
>     pass
> X
>
> When I press Enter most often I don't want to get:
>
> def f():
>     pass
>
>     X
>
> Instead, I think a more sensible default behaviour would be:
>
> def f():
>     pass
>
> X
>
> That is, to keep the cursor vertical position. This is consistent with
> the criterion of auto-indenting up to the indentation of last (both
> blank or non-blank) line, except for the technicality that a blank last
> line is not really indented... although you still have a point position
> there to infer desired indentation for the new line.
>
> Maybe this should be made a customizable option.
>
> What do you think? I'll try to submit a patch later today.
>
>
>

Message #18 received at 19691 <at> debbugs.gnu.org (full text, mbox):

From: Carlos Pita <carlosjosepita <at> gmail.com>
To: 19691 <at> debbugs.gnu.org
Cc: Fabian Ezequiel Gallina <galli.87 <at> gmail.com>
Date: Mon, 2 Feb 2015 17:28:12 -0300

[Message part 1 (text/plain, inline)]

Here is a patch updated against current master.

I know you have closed this issue, but please reconsider it in the
light of my new proposal: it's very simple and PEP 8 friendly.

The implementation just set a :no-indent context after two or more
consecutive blank lines. That's it.

PEP 8 states: Separate top-level function and class definitions with
two blank lines.

This is not mandatory, of course, but it's often the real intention of
the coder and, in any case, it promotes honoring basic conventions.

Cheers
--
Carlos

[top-level.patch (text/x-patch, attachment)]

Message #23 received at 19691 <at> debbugs.gnu.org (full text, mbox):

From: fgallina <at> gnu.org (Fabián Ezequiel Gallina)
To: Carlos Pita <carlosjosepita <at> gmail.com>
Cc: 19691 <at> debbugs.gnu.org, Fabian Ezequiel Gallina <galli.87 <at> gmail.com>
Subject: Re: bug#19691:
Date: Wed, 04 Feb 2015 19:56:29 -0300

Carlos Pita <carlosjosepita <at> gmail.com> writes:

> Here is a patch updated against current master.
>
> I know you have closed this issue, but please reconsider it in the
> light of my new proposal: it's very simple and PEP 8 friendly.
>
> The implementation just set a :no-indent context after two or more
> consecutive blank lines. That's it.
>
> PEP 8 states: Separate top-level function and class definitions with
> two blank lines.
>
> This is not mandatory, of course, but it's often the real intention of
> the coder and, in any case, it promotes honoring basic conventions.


Hi Carlos,

I do like this idea.  I'd accept your patch right away but I'd like to
differentiate the case with a special keyword (e.g. :after-blank-lines).
Also I want some tests.

BTW, I'm quite happy you are getting into the internals and started
submitting patches.  If you plan to work on python.el (or any other part
of Emacs) you'll need to sign the copyright assignment (if you haven't)
for non trivial changes.  I would recommend you to start the process to
do so, not because this patch is not trivial enough, but because you
have few other patches in the queue that may be useful.


PS: I haven't forgot about your other reports but I'm not finding time
to work on python.el yet, but know they are under my radar.



Regards,
Fabián.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.