Subject: bug#75486: [PATCH] Python: disable some unconditional messaging

From: Eli Zaretskii <[email-masked]>
Date: Sat, 25 Jan 2025 10:43:30 +0200

tags 75486 notabug
close 75486
thanks

> Date: Sat, 11 Jan 2025 21:02:57 +0900
> From: kobarity <[email-masked]>
> Cc: [email-masked]
> 
> Eli Zaretskii wrote:
> > 
> > > Date: Sat, 11 Jan 2025 06:36:15 -0000
> > > From:  Vitaliy Chepelev via "Bug reports for GNU Emacs,
> > >  the Swiss army knife of text editors" <[email-masked]>
> > > 
> > > Severity: minor
> > > 
> > > This code disable function that used in one place and just do
> > >  unconditional messaging about a indented block, I don't know for what.
> > >  I guess, it was used for debuging
> > >  python-info-dedenter-opening-block-position. This functions just call
> > >  one function and message a result. Messaging happen when TAB key pressed
> > >  as a part of python-indent-line-function.  I use master head to create
> > >  this patch.
> > 
> > Thanks.  kobarity, any comments about the usefulness of this function?
> > The code looks like it's there on purpose, not for debugging, but I
> > don't use python.el.
> 
> Yes, I think it's working as expected.  Try the following example.
> 
> #+begin_src python
> if a == 1:
>     if b == 2:
>         if c == 3:
>             pass
>         else:
> #+end_src
> 
> If you enter the last "else:", Emacs displays "Closes if c == 3:".
> This means that this "else:" corresponds to the "if c == 3:".
> 
> You can change the indentation by hitting the TAB key several times on
> the else line.  Each time you do this, Emacs will display the
> corresponding if statement.
> 
> For example, Emacs displays "Closes if b == 2:" when the "else:" is
> indented as follows:
> 
> #+begin_src python
> if a == 1:
>     if b == 2:
>         if c == 3:
>             pass
>     else:
> #+end_src
> 
> Of course, in this case it is easy to find the corresponding if
> statement.  However, in practice, many lines can go in between the if
> statements and disappear from the screen.  This feature would be
> useful in such cases.

Thanks.  No further comments in 2 weeks, so I'm now closing this bug.