unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#19691: 24.4; python.el: indentation RFE
@ 2015-01-26 14:25 Carlos Pita
  2015-01-30  3:52 ` Fabián Ezequiel Gallina
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Carlos Pita @ 2015-01-26 14:25 UTC (permalink / raw)
  To: 19691; +Cc: galli.87

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.





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#19691: 24.4; python.el: indentation RFE
  2015-01-26 14:25 bug#19691: 24.4; python.el: indentation RFE Carlos Pita
@ 2015-01-30  3:52 ` Fabián Ezequiel Gallina
       [not found] ` <handler.19691.D19691.14225899572400.notifdone@debbugs.gnu.org>
  2015-02-02 20:28 ` bug#19691: Carlos Pita
  2 siblings, 0 replies; 5+ messages in thread
From: Fabián Ezequiel Gallina @ 2015-01-30  3:52 UTC (permalink / raw)
  To: 19691-done

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





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#19691: closed (24.4; python.el: indentation RFE)
       [not found] ` <handler.19691.D19691.14225899572400.notifdone@debbugs.gnu.org>
@ 2015-01-30 10:18   ` Carlos Pita
  0 siblings, 0 replies; 5+ messages in thread
From: Carlos Pita @ 2015-01-30 10:18 UTC (permalink / raw)
  To: 19691; +Cc: Fabian Ezequiel Gallina

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@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@debbugs.gnu.org.
>
> --
> 19691: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19691
> GNU Bug Tracking System
> Contact help-debbugs@gnu.org with problems
>
>
> ---------- Forwarded message ----------
> From: "Fabián Ezequiel Gallina" <fgallina@gnu.org>
> To: 19691-done@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@gmail.com>
> To: bug-gnu-emacs@gnu.org
> Cc: galli.87@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.
>
>
>





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#19691:
  2015-01-26 14:25 bug#19691: 24.4; python.el: indentation RFE Carlos Pita
  2015-01-30  3:52 ` Fabián Ezequiel Gallina
       [not found] ` <handler.19691.D19691.14225899572400.notifdone@debbugs.gnu.org>
@ 2015-02-02 20:28 ` Carlos Pita
  2015-02-04 22:56   ` bug#19691: Fabián Ezequiel Gallina
  2 siblings, 1 reply; 5+ messages in thread
From: Carlos Pita @ 2015-02-02 20:28 UTC (permalink / raw)
  To: 19691; +Cc: Fabian Ezequiel Gallina

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

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

[-- Attachment #2: top-level.patch --]
[-- Type: text/x-patch, Size: 798 bytes --]

diff --git a/.emacs.d/lisp/python.el b/.emacs.d/lisp/python.el
index bade9d9..788d09f 100644
--- a/.emacs.d/lisp/python.el
+++ b/.emacs.d/lisp/python.el
@@ -963,6 +963,15 @@ keyword
        ((let ((start (python-info-dedenter-statement-p)))
           (when start
             (cons :at-dedenter-block-start start))))
+       ;; After two or more blank lines.
+       ((save-excursion
+          (when (and (progn
+                       (forward-line -1)
+                       (python-info-current-line-empty-p))
+                     (progn
+                       (forward-line -1)
+                       (python-info-current-line-empty-p)))
+            (cons :no-indent 0))))
        ;; After normal line.
        ((let ((start (save-excursion
                        (back-to-indentation)

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* bug#19691:
  2015-02-02 20:28 ` bug#19691: Carlos Pita
@ 2015-02-04 22:56   ` Fabián Ezequiel Gallina
  0 siblings, 0 replies; 5+ messages in thread
From: Fabián Ezequiel Gallina @ 2015-02-04 22:56 UTC (permalink / raw)
  To: Carlos Pita; +Cc: 19691, Fabian Ezequiel Gallina

Carlos Pita <carlosjosepita@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.





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-02-04 22:56 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-26 14:25 bug#19691: 24.4; python.el: indentation RFE Carlos Pita
2015-01-30  3:52 ` Fabián Ezequiel Gallina
     [not found] ` <handler.19691.D19691.14225899572400.notifdone@debbugs.gnu.org>
2015-01-30 10:18   ` bug#19691: closed (24.4; python.el: indentation RFE) Carlos Pita
2015-02-02 20:28 ` bug#19691: Carlos Pita
2015-02-04 22:56   ` bug#19691: Fabián Ezequiel Gallina

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).