From: Gustaf Waldemarson <gustaf.waldemarson@gmail.com>
To: kobarity <kobarity@gmail.com>
Cc: 62696@debbugs.gnu.org
Subject: bug#62696: python.el: Extra indentation for conditionals
Date: Mon, 10 Apr 2023 13:11:32 +0200 [thread overview]
Message-ID: <CABehr5cRaBpYsHMxLYrZhtC+1PRaso3kohqOJAbLd42mcaJH3w@mail.gmail.com> (raw)
In-Reply-To: <eke7jzyljlw1.wl-kobarity@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3991 bytes --]
Hello!
Thanks a lot for this! I had no idea that they had changed the relevant
PEPs to account
for this, but as mentioned it is still a good idea to have the option to
change this depending
on your preference. And as far as I have been able to tell from coding with
this patch for a
few hours, it seems to work beautifully and I would love to see this as an
official feature!
Best regards,
Gustaf
Den sön 9 apr. 2023 kl 14:11 skrev kobarity <kobarity@gmail.com>:
>
> Gustaf Waldemarson wrote:
> > One noticeable caveat is that **any** parenthesis can now be additionally
> > indented, e.g., the follow is now also possible:
> >
> > this_is_a_tuple = (long_variable_name_here,
> > also_a_long_variable_name)
> >
> > Although, given that this can be cycled at will by the user, I'm not
> sure if it
> > is a bad additional feature or not.
> >
> > Ideally, I suppose that `python-indent-context` could be modified to add
> a
> > `:inside-cond-paren` symbol that signals that the parenthesis is for a
> > conditional expression and thus the extra indentation should be applied,
> and not
> > in any other case. That does seem a bit harder for me to fix at a
> cursory glance
> > however, so maybe this fix is enough?
>
> Hi Gustaf,
>
> I agree with you in that it's better to have a new indent context, and
> I tried to implement it.
>
> At first, I thought that it would be enough to add a counterpart of
> the user option `python-indent-def-block-scale' and corresponding
> `:inside-paren-newline-start-from-block' context.
> `python-indent-def-block-scale' can be used to customize the following
> code
>
> #+begin_src python
> if (
> "VALUE" in my_unnecessarily_long_dictionary
> and some_other_long_condition_case
> ):
> do_something()
> #+end_src
>
> to be indented as follows (with a TAB at "):" line):
>
> #+begin_src python
> if (
> "VALUE" in my_unnecessarily_long_dictionary
> and some_other_long_condition_case
> ):
> do_something()
> #+end_src
>
> This is the style used by the popular formatter "black".
>
> From the name `python-indent-def-block-scale' and its docstring, it is
> easy to assume that it only works for def block, but in fact it works
> for every blocks. As `python-indent-def-block-scale' works only when
> there is no item on the same line following the opening paren, I tried
> to add a similar user option and an indent context for the opening
> paren followed by some items on the same line. It could indent as
> follows:
>
> #+begin_src python
> if ("VALUE" in my_unnecessarily_long_dictionary
> and some_other_long_condition_case):
> do_something()
> #+end_src
>
> However, it could not handle correctly the following example:
>
> #+begin_src python
> elif (some_case or
> another_case):
> do_another()
> #+end_src
>
> The extra indentation is not needed here.
>
> So I think it is best to increase the indentation only if the
> calculated indentation equals to the indentation of the contents of
> the block ("do_something()" in the above example). This is similar to
> the way I fixed Bug#57262.
>
> Unlike Bug#57262, the current indentation shown below is not a
> violation of the latest PEP8:
>
> #+begin_src python
> if ("VALUE" in my_unnecessarily_long_dictionary
> and some_other_long_condition_case):
> do_something()
> #+end_src
>
> Although pycodestyle reports E129 "visually indented line with same
> indent as next logical line," PEP8 was changed to allow this. This is
> explained in the following issue, for example:
> https://github.com/PyCQA/pycodestyle/issues/474
>
> So changing this indentation should be a user option. Attached is my
> implementation of this. The user option
> `python-indent-block-paren-deeper' is added to customize this
> indentation. I would be glad if you could try it.
>
[-- Attachment #2: Type: text/html, Size: 4884 bytes --]
next prev parent reply other threads:[~2023-04-10 11:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-06 12:47 bug#62696: python.el: Extra indentation for conditionals Gustaf Waldemarson
2023-04-09 12:11 ` kobarity
2023-04-10 11:11 ` Gustaf Waldemarson [this message]
2023-04-10 15:21 ` kobarity
2023-04-11 11:11 ` Gustaf Waldemarson
2023-04-12 15:26 ` kobarity
2023-04-16 13:24 ` kobarity
2023-04-16 15:49 ` Gustaf Waldemarson
2023-04-18 14:23 ` kobarity
2023-04-20 8:22 ` Eli Zaretskii
2023-04-20 13:40 ` Gustaf Waldemarson
2023-04-20 14:19 ` kobarity
2023-04-20 17:44 ` Gustaf Waldemarson
2023-04-22 9:33 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABehr5cRaBpYsHMxLYrZhtC+1PRaso3kohqOJAbLd42mcaJH3w@mail.gmail.com \
--to=gustaf.waldemarson@gmail.com \
--cc=62696@debbugs.gnu.org \
--cc=kobarity@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.