Add option for ignoring blank lines for report line indentation#15057
Add option for ignoring blank lines for report line indentation#15057seanbudd merged 18 commits into
Conversation
See test results for failed build of commit 85bf451aa5 |
|
Please add an accelerator key for this checkbox. I suggest Alt+b. Also, would an unassigned gesture to toggle it be useful? |
|
Nice! I hope this will be merged into NVDA. Just a question, instead of the indentation read change occurring on the last line, will it be possible to have NVDA say something like this? That makes a lot more sense to me. Thanks for bringing this to NVDA! |
|
In testing this build, it performs in every way as I would expect.
While I haven't reviewed the code, the behavior is good IMO, and a useful feature to have. |
|
@brunoprietog How would it know which blanks were safe to ignore, and which blanks to reset on? I agree that your wish would make it a more useful feature, but it seems impossible to implement. That said, if it were a combobox with options of:
Then that third option could turn something like: Into: Which is more Pythonic (consistent with pep-8) for top-level functions anyway, though won't help you with methods. |
|
It's difficult. What occurs to me is that as the user listens to the lines, NVDA checks what is the indentation level of the next line that is not blank in the direction the user navigated (up or down). If the user presses the up or down arrow, NVDA should check the indentation level of the next line that is not blank, in the direction in which the user navigated (up or down).
Here is an example: def foo
pass
def bar
pass
def baz
passReading it from top to bottom, NVDA should say this: Reading it from the bottom up, NVDA should say this: That's more intuitive for me, at least in my case |
|
Hi @SamKacer This is a nice change and I like it. Thanks |
|
NVDA has never tried to be predictive about what navigation the user might do
next. I understand why you want this, and it even seems reasonable. But that is
a more controversial change than the original request I think.
I would rather see this go forward as is (or with my one-line-only
modification), then see the proposal to be predictive as a feature request after
this feature is established.
All kinds of things open up if we're willing to predict what the user might want
to know or do next, but I think that will need deeper discussion than is called
for by this simple change. A proposal like that has potentially concerning
side-effects, and will need exploration.
|
|
How ought this to behave when indentation reporting with tones is on? |
|
@XLTechie wrote
Thanks, will do those when I have time. This is my first time adding any new config property, so please let me know about anything I missed. Actually, how do I add the accelerator key? I haven't noticed that when making my changes. Also in which file are the commands for toggling setting properties defined? to do:
|
|
how do I add the accelerator key? I haven't noticed that when making my changes.
Ampersand before the letter in the setting name. So if it was "Announce blanks",
and you wanted the key to be alt+b, you would write it as "Announce &blanks".
Btw, while you're in gui/settingsDialogs.py, please consider fixing the spelling
of "panel" on lines 2393 and 2400.
Also in which file are the commands for toggling setting properties defined?
globalCommands.py
See script_toggleProgressBarOutput for an example.
Also see script_reportLinkDestinationInWindow, for an example of proper typing,
which isn't done in the other one.
|
|
How ought this to behave when indentation reporting with tones is on?
Based on testing it, it behaves exactly as I expected.
There are no de-indent beeps on the lines that are blank.
|
|
In regards to @brunoprietog request. He has already asked this in #13394 and I gave a very long reply there in this comment. Linking in case someone wants full context. Thanks for the suggestion, but this would require a significant overhaul of the indentation reporting code. I am not entirely sure if I would even prefer that behavior. I think I might prefer if the rules for indentation reporting are kept simpler without special cases like this. In any case, I'm not sure the amount of effort to implement would be that worth it. |
@LeonarddeR the behavior should be the same whether you are using tones or speech |
See test results for failed build of commit 2274421602 |
See test results for failed build of commit 14abbf5d78 |
See test results for failed build of commit 7b637323a4 |
|
Ok, this is officially ready for review. I implemented the 2 features @XLTechie suggested. I added a system test. I fixed all the Flake8 issues. The summary is up to date. Please let me know if anything else is missing or if anything could be improved. Thanks |
See test results for failed build of commit acdc8d32b4 |
e6744be to
41d2c3c
Compare
Qchristensen
left a comment
There was a problem hiding this comment.
User guide reads well, thanks!
…ReportLineIndentation
Follow-up of #15057 Summary of the issue: In the GUI, the recent trend is to disable (grey out) the options that are not applicable due to the values of other options. New option "Ignore blank lines for line indentation reporting" has no sense when report indentation is OFF. Thus it should be greyed out when report indent is off. This is especially needed to reduce the number of tab presses when navigating in the Doc formatting settings dialog which contains a lot of items. Description of user facing changes Option "Ignore blank lines for lineis greyed out when report indent is off and enabled when other indent reporting types are configured. While at it, in this PR, I have also changed the context help target for "Ignore blank lines" option. Before it was jumping by default to "Document formatting settings" paragraph; now it jumps to "Line indentation reporting" paragraph, which contains more precise information on this topic.
Link to issue number:
closes #13394
Summary of the issue:
As elaborated in #13394, line indentation reporting can be too noisy in contexts where indentation changes for blank lines aren't meaningful and distract from the actually meaningful indentation changes, such as is the case when reading source code for Python and many other programming languages.
Description of user facing changes
A new checkbox is added to Document formatting, "Ignore blank lines for line indentation reporting". By default it is off, in which case line indentation reporting behaves as it does currently. If the user ticks the checkbox, then indentation changes are not reported for blank lines.
There is also a new unassigned global command for toggling the setting.
Description of development approach
ignoreBlankLinesForRLI = boolean(default=false)ignoreBlankLinesForReportLineIndentation, which was too long and causing Flake8 issuesignoreBlankLinesForRLIspeech.speech.getTextInfoSpeech, ifignoreBlankLinesForRLIis true and the line is blank, the block of code that inserts the indentation announcement and updates the indentation cache is skipped, otherwise it behaves as usualignoreBlankLinesForRLITesting strategy:
I added a new test in
symbolPronunciationTeststhat confirms the correct behavior by comparing speech output when the new setting is on/off.I also tested manually by reading the following text with "Ignore blank lines for line indentation reporting" turned off and on. In either case make sure to have line indentation reporting switched on. To quickly find the new setting, open document formatting settings with NVDA + Shift + D and press Alt + I to get to "line indentation reporting", then press tab to get to "Ignore blank lines for line indentation reporting". Alternatively, you can press alt + B twice.
Test text:
With current NVDA or with this change and "Ignore blank lines for line indentation reporting" turned off, the text should report 4 indentation changes like:
With "Ignore blank lines for line indentation reporting" turned on, it should instead report just 2 indentation changes like:
Known issues with pull request:
None that I am aware of.
Change log entries:
New features
Changes
Bug fixes
For Developers
Code Review Checklist: