80 character line

[bennuttall]

I wondered if it was worth adding (either for everyone, or as an option), a visible 80 character line length ruler? No wrapping, just an indicator so you know where the 80 character limit is.

Personally I think I'd find it really useful, and it would help guide beginners.

The Check button will tell you if you go over 79 characters, but not where the 80th character is in your line, so it's hard to know where exactly you need to break the line.

[martinohanlon]

Playing devils advocate on this one...

Is this going to be confusing for new learners? Will they think there is a hard limit? Does it add complexity where its not required?

If you are writing programs where you need to worry about lines over 80 chars (I only tend to think about this in the later stages of a project before release), you have probably moved past Mu.

[tjguk]

FWIW I'm with @martinohanlon on this. I think an advantage of Mu is its relative clean-ness: just a blank space and a row of buttons.

I don't remember whether one of the check tools picks this up, but I suspect that at least one does.

[ZanderBrown]

PEP8 would / does

[carlosperate]

We have a list of PEP8 rules to ignore: https://github.com/mu-editor/mu/blob/master/mu/logic.py#L413-L414
Perhaps it would be worth adding this one as another exception.

Although a bigger question could be if these exceptions are worth adding to the settings window as a new tab? Not all the pycodestyle rules, but popular/controversial ones as tick boxes with some same defaults for Python learners.
My first instinct would be "not necessary right now until more people request it", but I wonder what everybody else thinks about this one.

[NDevox]

I was going to suggest some possible configuration around line length but in the end convinced myself that I'd rather not have to configure all my students machines.

This extends to tick boxing on rules.

In our dojo we do do some initial setup with editors etc but I'm 90% sure that in the end for things like this we'd just use whatever the default setting would be for this kind of thing.

I'd rather not keep this rule in by default. It's just off putting when a child is writing sentences of text in the editor only to be told they have to break it up.

But then I use 120 as my limit. So I'm not really one to argue on standards.

[dybber]

I agree with what has previously has been said, that this will add more complexity for new learners, who are working with something already cognitive demanding. I think it's a good idea to make it possible for users to customize which pycodestyle rules are checked, e.g. by right-clicking on an error with a menu item to ignore the warning in the future.

If the complexity is that users don't know where to break up the line, they can hit the Tidy button, and make black do it for them, and thus get a suggestion for how to break things up that they can use next time in a similar situation.

[dybber]

Can we close this? I don't think the horizontal line will ever be part of Mu. Perhaps we could create a separate issue for "ignore these types of errors in the future" feature for the PEP8-checker.

[ntoll]

Closing after interesting debate and with a desire for GitHub gardening..! ;-) I believe the consensus is a qualified, "let's not".

Thank you folks for your contributions, thoughtfulness and respectful and friendly debate.

[ntoll]

Also, apologies for the arbitrary "executive decision" on my part. Feel free to re-open if folks have a burning desire to continue and flesh this out.

Historically, Mu has tried to ensure the UI is as simple and uncluttered as possible with as much of the UI presented in a clearly explorable way and designed to appear friendly. I'm personally -0 on this for the "what does that line mean?" added UX dissonance should people use it. Also, when you start coding, keeping to an (arbitrary?) 80 line limit feels like asking beginner skiers to only pass through the designated slalom gates (when there's a very wide piste... ) (snow related metaphor for @martinohanlon there....). 🏂 👍

If 80 character width is a thing you're worrying about, you probably shouldn't be using Mu. 😉

[bennuttall]

Absolutely, fair enough 👍

Not as an attempt to re-open this issue, but if anyone wants to consider this in future, based on the original suggestion:

The Check button will tell you if you go over 79 characters, but not where the 80th character is in your line, so it's hard to know where exactly you need to break the line.

... a compromise could be that a line comes up after hitting the check button, maybe only while that's the reason for the check failing 🤷‍♂️

[ntoll]

Absolutely.

However, I've long felt (and feedback suggests) that the "check" button is, ummmm.... a tad "enthusiastic". ;-)

I guess we first need to get our PEP8-ish story straight when it comes to using pycodestyle (which is what's giving such stylistic warnings, along with flake8 which gives warnings about unused objects etc).

[dybber]

I think the suggestion of having the line show up after "Check" is pushed makes this something that was closed to early. However, as this thread has mostly been a discussion, I will convert it from an issue to a discussion in our new discussion board here on Github.

[xbecas]

Hi all. Some notes after a brief research on this topic.

Note: if the decision is to remove the 'Line too long' warning from (Check) — adding this as a PEP8 exception —, do not consider the message at all! ;-)

Looking forward to your comments.

Previously on "80 character line" discussion:

Following on this path, I agree that showing a vertical line / ruler upfront will be confusing for beginners — good analogy with the 'slalom gates', @ntoll :-).

But I also agree with @bennuttall that if the (Check) feature raises a flag, then a visual guide would be handy.

My suggestion:

• Show the ruler at MAX_LINE_LENGTH only when (Check) detects a 'Line too long';
• Hide the ruler if there are no 'Line too long' detections on using (Check);
• MAX_LINE_LENGTH can be overriden using envars.

Code review:

There is a self.setEdgeColumn(79) line in the editor's configuration (see reference below).

The line is not visible but as the EDGE_MODE is set to EDGE_NONE by default, thus the ruler is initially invisible.

According to https://www.scintilla.org/ScintillaDoc.html#SCI_SETEDGEMODE, an extra code line needs to but inserted (code location and enums below).

Additionally, there is a line in config.py's that sets the limit at 88 characters per line: MAX_LINE_LENGTH = 88. This value could/should be used in the setEdgeColumn call.

Reference to editor.py — where vertical ruler's code seems to be:

    | ...
 83 | class EditorPane(QsciScintilla):
    |      ...
177 |     def configure(self)
    |        ...
  + |        self.setEdgeMode(self.EDGE_LINE)
193 |        self.setEdgeColumn(79)
    | ...

Reference to the Scintilla's documentation:

Symbol	Value	Long line display mode
EDGE_NONE	0	Long lines are not marked. This is the default state.
EDGE_LINE	1	A vertical line is drawn at the column number set by SCI_SETEDGECOLUMN. This works well for monospaced fonts. The line is drawn at a position based on the width of a space character in STYLE_DEFAULT, so it may not work very well if your styles use proportional fonts or if your style have varied font sizes or you use a mixture of bold, italic and normal text.
EDGE_BACKGROUND	2	The background colour of characters after the column limit is changed to the colour set by SCI_SETEDGECOLOUR. This is recommended for proportional fonts.
EDGE_MULTILINE	3	This is similar to EDGE_LINE but in contrary to showing only one single line a configurable set of vertical lines can be shown simultaneously. This edgeMode uses a completely independent dataset that can only be configured by using the SCI_MULTIEDGE* messages.