how to highlight block end in Python-mode indentation

how to highlight block end in Python-mode indentation

[Krishnakant]

Hi,

let's say I have my cursor on a def func():

I wish to know if there is a way to highlite where this indented block 
of function ends?

Same applies to if, for and while etc.

It comes in very handy when there is nested indentation.


Happy hacking.

Krishnakant.

Re: how to highlight block end in Python-mode indentation

[Joost Kremers]

On Fri, May 19 2017, Krishnakant wrote:
> let's say I have my cursor on a def func():
>
> I wish to know if there is a way to highlite where this indented 
> block of
> function ends?
>
> Same applies to if, for and while etc.
>
> It comes in very handy when there is nested indentation.

Perhaps not exactly what you're looking for, but it should serve 
the same purpose: check out the packages highlight-indentation or 
(my personal preference) indent-guide.

HTH


-- 
Joost Kremers
Life has its moments

Re: how to highlight block end in Python-mode indentation

[Krishnakant]

On Friday 19 May 2017 05:48 PM, Joost Kremers wrote:
>
> On Fri, May 19 2017, Krishnakant wrote:
>> let's say I have my cursor on a def func():
>>
>> I wish to know if there is a way to highlite where this indented 
>> block of
>> function ends?
>>
>> Same applies to if, for and while etc.
>>
>> It comes in very handy when there is nested indentation.
>
> Perhaps not exactly what you're looking for, but it should serve the 
> same purpose: check out the packages highlight-indentation or (my 
> personal preference) indent-guide.
Thank you,
I am right now trying Smartparens to see if it serves my purpose.
Then will try indent-guide.
Happy hacking.
Krishnakant.

Re: how to highlight block end in Python-mode indentation

[Krishnakant]

On Friday 19 May 2017 05:48 PM, Joost Kremers wrote:
>
> On Fri, May 19 2017, Krishnakant wrote:
>> let's say I have my cursor on a def func():
>>
>> I wish to know if there is a way to highlite where this indented 
>> block of
>> function ends?
>>
>> Same applies to if, for and while etc.
>>
>> It comes in very handy when there is nested indentation.
>
> Perhaps not exactly what you're looking for, but it should serve the 
> same purpose: check out the packages highlight-indentation or (my 
> personal preference) indent-guide.
HI,
I tryed indent-gide and it sutes perfectly.
Just one question.
How can I have it work for every block and not just for class and 
function in Python?
It is not effective for if, while try: catch etc.
I am sure it can be made to work because the screenshot on the github 
page has it there.
Just wondering what to toggle.
Happy hacking.
Krishnakant.

Re: how to highlight block end in Python-mode indentation

[Joost Kremers]

On Sat, May 20 2017, Krishnakant wrote:
> I tryed indent-gide and it sutes perfectly.
> Just one question.
> How can I have it work for every block and not just for class 
> and function in
> Python?
> It is not effective for if, while try: catch etc.
> I am sure it can be made to work because the screenshot on the 
> github page has
> it there.

Well, the only customisation I have regarding `indent-guide' is 
this:

(setq indent-guide-char "│")

And for me, it does work with if and other blocks.

Are you sure it doesn't work? Note that indent-guide doesn't show 
indentation if point is on the line that begins the block. So if 
you have:

```
def some_fun(arg):
  print("Hi!")
  if arg = 1:
    print("How are you?")
  elif arg = 2:
    print("How do you do?")
  else:
    print("I don't want to know you.")

Now if point is on the line `def...`, no indentation markers are 
shown. They appear when you move point down. Similarly, if point 
is on the line `if...`, it doesn't show the indentation of the if 
block but of the def block. Once you move down to the line 
`print("How are you?")`, it'll show the indentation of the if 
block.

HTH


-- 
Joost Kremers
Life has its moments

Re: how to highlight block end in Python-mode indentation

[Tomas Nordin]

Krishnakant <krmane@openmailbox.org> writes:

> Hi,
>
> let's say I have my cursor on a def func():
>
> I wish to know if there is a way to highlite where this indented block 
> of function ends?

Since some time back I have started using elpy-mode for python. As far
as I can remember it has this highlighting of indentation on per
default. If that is what you mean. I remember because in the beginning I
didn't like it, but now I do.

Right now I cannot remember what the variable or hook is to turn it on
and off. Elpy comes with other nice things, like M-. works out of the
box to jump to a definition of something.

>
> Same applies to if, for and while etc.
>
> It comes in very handy when there is nested indentation.
>
>
> Happy hacking.
>
> Krishnakant.
>
>

Re: how to highlight block end in Python-mode indentation

[Joost Kremers]

On Fri, May 19 2017, Tomas Nordin wrote:
> Since some time back I have started using elpy-mode for python. 
> As far
> as I can remember it has this highlighting of indentation on per
> default.

Yup, it does. It uses highlight-indentation. 

> Right now I cannot remember what the variable or hook is to turn 
> it on
> and off.

To turn off highlight-indentation, you need to customise the 
variable `elpy-modules':

    M-x customize-option RET elpy-modules RET

I know because I turned it off. I prefer `indent-guide'. ;-)

HTH

-- 
Joost Kremers
Life has its moments

Re: how to highlight block end in Python-mode indentation

[Krishnakant]

On Saturday 20 May 2017 12:48 AM, Tomas Nordin wrote:
> Krishnakant <krmane@openmailbox.org> writes:
>
>> Hi,
>>
>> let's say I have my cursor on a def func():
>>
>> I wish to know if there is a way to highlite where this indented block
>> of function ends?
> Since some time back I have started using elpy-mode for python. As far
> as I can remember it has this highlighting of indentation on per
> default. If that is what you mean. I remember because in the beginning I
> didn't like it, but now I do.
>
> Right now I cannot remember what the variable or hook is to turn it on
> and off. Elpy comes with other nice things, like M-. works out of the
> box to jump to a definition of something.
>
I tryed it and seems that since I shifted from using space to tabs, the 
highlighting from within elpy is gone.
I think may be I will have to shift back to spaces any how.
Happy hacking.
Krishnakant.

Re: how to highlight block end in Python-mode indentation

[Skip Montanaro]

Not too insert too much software engineering into the discussion, but how
big are your blocks (and how small is your block indentation) that you need
to highlight the end of a block to be sure where it ends?

Skip Montanaro

Re: how to highlight block end in Python-mode indentation

[Krishnakant]

On Sunday 21 May 2017 04:57 PM, Skip Montanaro wrote:
> Not too insert too much software engineering into the discussion, but how
> big are your blocks (and how small is your block indentation) that you need
> to highlight the end of a block to be sure where it ends?
>
The base is large enough, more than 1500 lines in a buffer (python 
module ).  There is a lot of nesting going on and we all know that we do 
get lost in it.
Do you have some solution?
Basically I have now figured out that spaces instead of tabs makes elpy 
work fine with highlight-indentation-mode.  So our team will have to 
switch to using spaces again.
Happy hacking.
Krishnakant.

Re: how to highlight block end in Python-mode indentation

[Yuri Khan]

On Sun, May 21, 2017 at 6:38 PM, Krishnakant <krmane@openmailbox.org> wrote:

> The base is large enough, more than 1500 lines in a buffer (python module ).

That is a lot. See if any top-level functions or classes want to live
in separate modules.

> There is a lot of nesting going on and we all know that we do get lost in
> it.
> Do you have some solution?

Apply Torvalds’ razor: “if you need more than 3 levels of indentation,
you’re screwed[…], and should fix your program”.

See which deep-nested blocks carry out some action that could be given
a name. Extract those as functions. If you see a block of code with an
explanatory comment before it — that’s a function wanting to break
out.

Also, The Zen of Python, item 5: “Flat is better than nested.”

See if you have this pattern:

def …:
    if some condition:
        do something
        …

Rewrite this to:

def …:
    if not some condition:
        return
    do something
    …

Similarly with loops, using “continue”.

Sometimes replacing conditions with conditional expressions (x if y
else z) and loops with comprehensions and utility functions will do
wonders to your nesting levels.

> Basically I have now figured out that spaces instead of tabs makes elpy work
> fine with highlight-indentation-mode.  So our team will have to switch to
> using spaces again.

You use tabs with Python in a *team*?

Print out PEP8. Discuss it with your team. Unless you have good
reasons, format according to that. (Unfortunately, having lots of
existing code qualifies as “good reasons”.)

Re: how to highlight block end in Python-mode indentation

[Krishnakant]

On Sunday 21 May 2017 05:34 PM, Yuri Khan wrote:
> On Sun, May 21, 2017 at 6:38 PM, Krishnakant <krmane@openmailbox.org> wrote:
>
>> The base is large enough, more than 1500 lines in a buffer (python module ).
> That is a lot. See if any top-level functions or classes want to live
> in separate modules.
>
>> There is a lot of nesting going on and we all know that we do get lost in
>> it.
>> Do you have some solution?
> Apply Torvalds’ razor: “if you need more than 3 levels of indentation,
> you’re screwed[…], and should fix your program”.
>
> See which deep-nested blocks carry out some action that could be given
> a name. Extract those as functions. If you see a block of code with an
> explanatory comment before it — that’s a function wanting to break
> out.
>
> Also, The Zen of Python, item 5: “Flat is better than nested.”
>
> See if you have this pattern:
>
> def …:
>      if some condition:
>          do something
>          …
>
> Rewrite this to:
>
> def …:
>      if not some condition:
>          return
>      do something
>      …
>
> Similarly with loops, using “continue”.
>
> Sometimes replacing conditions with conditional expressions (x if y
> else z) and loops with comprehensions and utility functions will do
> wonders to your nesting levels.
>
>> Basically I have now figured out that spaces instead of tabs makes elpy work
>> fine with highlight-indentation-mode.  So our team will have to switch to
>> using spaces again.
> You use tabs with Python in a *team*?
>
> Print out PEP8. Discuss it with your team. Unless you have good
> reasons, format according to that. (Unfortunately, having lots of
> existing code qualifies as “good reasons”.)
>
PEP8 just says about using space.
It is more of a popular way of doing things rather than a highly 
convincing advantage.
I personally worked with both tabs and spaces and never find any major 
problem as such.
Just that I am myself blind and find managing tabs with screen readers 
more convenient, but I am not against using any style.
Never the less found white-space as the default in Emacs and is ok with 
my team who needs to see the code (unlike me who depends on speech ).
Happy hacking.
Krishnakant.

Re: how to highlight block end in Python-mode indentation

[Skip Montanaro]

> PEP8 just says about using space.
> It is more of a popular way of doing things rather than a highly convincing
> advantage.

You are correct that PEP8 is convention, not stricture. Still, it was
written from experience by Guido van Rossum and a few other Python
experts. Despite the fact that it is only convention,
PEP8-compatibility is often an expectation by tools such as pylint,
and by other developers who need to read code others have written.
There is a certain amount of cognitive dissonance when you read Python
code written by someone whose personal coding style is much different
than what PEP8 outlines.

There are two advantages to using spaces:

1. Indentation (assuming < 8 spaces per indent) doesn't take the start
of the line so far to the right. If you use tabs, at the third level
you've already gobbled up 24 spaces. If (like many, but not all,
people) you work in an 80-column window, you've now got only 55
columns left for the actual bit of code on that line (assuming you
only go to column 79, which is typical). That means you wrap lines
more often and extend the vertical space necessary to express the
concept embodied in that code.

2. Woe unto anyone who winds up (accidentally or otherwise) mixing
spaces and tabs.

> I personally worked with both tabs and spaces and never find any major
> problem as such.

Don't worry, that day will come.

> Just that I am myself blind and find managing tabs with screen readers more
> convenient, but I am not against using any style.
> Never the less found white-space as the default in Emacs and is ok with my
> team who needs to see the code (unlike me who depends on speech ).

I don't think the fact that you are blind came up earlier in the
discussion. My apologies if I missed it. I don't know how you read
what's on the screen, but I can certainly understand that the computer
saying "TAB" instead of "SPACE SPACE ..." would be much easier.

I would be interested in your experience (off-list is almost certainly
best in this case) in how you adapt various coding conventions
(including PEP8) to work with your blindness. For example, you
mentioned TAB vs. SPACE. What about 80-columns? Different
capitalization for different types of identifiers?

Best,

Skip Montanaro

Re: how to highlight block end in Python-mode indentation

[Yuri Khan]

On Sun, May 21, 2017 at 8:46 PM, Krishnakant <krmane@openmailbox.org> wrote:

> Just that I am myself blind and find managing tabs with screen readers more
> convenient, but I am not against using any style.

Okay, I honestly cannot comprehend how coding styles work for a blind
person. I do understand that a simple “End if” (or “for”, or
“function”) announcement will help in all but the simplest cases. And
I do believe you will benefit from shorter functions even more than
your sighted teammates.

Re: how to highlight block end in Python-mode indentation

[Krishnakant]

On Sunday 21 May 2017 08:15 PM, Yuri Khan wrote:
> On Sun, May 21, 2017 at 8:46 PM, Krishnakant <krmane@openmailbox.org> wrote:
>
>> Just that I am myself blind and find managing tabs with screen readers more
>> convenient, but I am not against using any style.
yes you are correct about shorter code.  Refactoring always goes on but 
there are tuns of Formula we have to use and the calculations are very 
complex involving lot of conditions.
But you are right about making the code compact.
It  is an evolving process.
Thanks to the wonderful power of Emacs for editing code, searching text 
jumping between functions and excelent regexp based searches, I find it 
very powerful when used with Emacspeak.
As I write this reply, I am actually posting a blog on my experience and 
from a new point of view making it an easy entry point for programmers 
like me.
Will surely send you the link/
Happy hacking.
Krishnakant.


> Okay, I honestly cannot comprehend how coding styles work for a blind
> person. I do understand that a simple “End if” (or “for”, or
> “function”) announcement will help in all but the simplest cases. And
> I do believe you will benefit from shorter functions even more than
> your sighted teammates.

Re: how to highlight block end in Python-mode indentation

[Skip Montanaro]

Do you have some solution?


I think Yuri summarized the places to start quite well. In general, it
sounds like a fair amount of code refactoring is in order.

I would caution against trying to do it all at once, however. Assuming you
have unit tests or even just some regression tests you can run, make sure
everything passes, do a little refactoring, verify your tests still pass
(and that they exercise the modified code - if not, write more test cases),
check in the changes, then it's a process of lather, rinse, repeat.

One mistake I make repeatedly, is mixing changes in a commit. Suppose I
want to refactor a chunk of code into a separate function. While doing
that, I notice something unrelated which needs doing too, and do that. Now
my next commit mixes two functional changes to the code base, making it
difficult to back out just one of them later. Small, precise commits are
preferable to big, rambling commits. Such problematic commits are more
tempting to make when you know you have a fair amount of work to do.

Sorry, this is off-topic from your original request. Hopefully these few
posts give you a bit different way to think about the problem you face.

Skip Montanaro