Feature request: add indentation navigation commands #16230
Comments
|
As far as I know, for NVDA, every desktop command has a corresponding laptop equivalent. |
|
So are you not talking of the indent nav add on, or a kind of souped up version. I don't recal which, but there used to be a text editor that could be set to do indenting. Brian
…--
***@***.***
Sent via blueyonder.(Virgin media)
Please address personal E-mail to:-
***@***.***, putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: mltony
To: nvaccess/nvda
Cc: Subscribed
Sent: Tuesday, February 27, 2024 1:45 AM
Subject: [nvaccess/nvda] Feature request: add indentation navigation commands (Issue #16230)
Is your feature request related to a problem? Please describe.
Most modern programming languages make use of indentation, so that sighted people can easily grasp the structure of program or function visually. Currently NVDA announces indentation level but doesn't offer any more advanced ways to leverage indentation to ease navigation in source code. I propose to add indentation navigation commands to NVDA.
Describe the solution you'd like
1.. I propose to add the following indentation navigation commands to NVDA:
a.. Jump to next/previous/first/last line with the same indentation level within current block. Current block refers here to a chunk of code limited by lower indentation lines, e.g. if we're searching for same indentation lines within a python function, then all of these commands would only search for lines within the same function and will not jump to same indentation lines in adjacent functions.
b.. Jump to next/previous line with lesser/greater indentation level.
c.. Jump to next/previous line with the same indentation level, but not necessarily bounded by the limits of current block.
d.. Jump to next/previous line with the same indentation level, but ignoring clutter. Let's define clutter here to be the lines composed of characters like "(){}:" (we will make this configurable). The motivation for this command is following: in C++ codebase for example, we have code like this:
void my_function(
int arg1
) {
printf("x = %d\n", arg1);
}
So on the lowest indentation level, we can say that the first line is important, but lines 3 and 5 are just clutter and often times it it is worth skipping them when exploring functions in the current file on a given indentation level.
e.. If this is triaged, in later feature requests I will also propose other indentation related features, such as selection of indented blocks, indent-aware pasting from clipboard.
2.. For keyboard shortcuts, I would really like to use NumPad block because four arrow keys are not enough to capture the semantics of all these commands. We really need to have keys for diagonal commands, therefore I think making use of NumPad would be ideal. Therefore, here is what I propose:
a.. There is this rarely used Windows feature: when pressing alt+numpad number it prints a character by its ASCII or Unicode code. I propose to reuse these keystrokes for indentation navigation with an ability to exit indentation navigation mode in case someone wants to use original Windows functionality.
b.. Alt+numLock: toggle between indentation navigation and ASCII/Unicode character modes.
c.. Alt+numPad2/NumPad8/NumPad4/NumPad6: Jump to next/previous/first/last line with the same indentation level within current block.
d.. alt+numPad1/numPad3/numPad7/numPad9: Jump to next/previous line with lesser/greater indentation level.
e.. control+alt+numPad4/numPad6: Jump to next/previous line with the same indentation level, but not necessarily bounded by the limits of current block.
f.. control+alt+numpad2/numPad8: Jump to next/previous line with the same indentation level, but ignoring clutter.
Describe alternatives you've considered
N/A
Additional context
1.. Prototype is already available in my IndentNav add-on.
2.. From technical point of view, I would need to optimize TextInfo.move(UNIT_LINE) function as its current implementation is way too slow in many programs when need to move by 100..1000 lines.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
@cary-rowen, |
|
@mltony thank you very much for this proposal, I think this would really change the way people navigate the screen in many use cases and I think if implemented properly it helps alot in working together with sighted people and also in understanding better visually aligned structures while using the screen reader. some questions:
Previous / next line with same indentation is already handled via numpad2/numpad8 in your proposal above within the limits of the block, which is kind of a vertical navigation. so why not using something like ctrl+alt+Numpad2/numpad8 also for navigating at the same indent level between blocks and ctrl+alt+numad3/numpad9 to navigate at the same indent level ignoring clutter? |
|
Regarding laptop keyboard layout, I agree it is a concern that we don't have an alternative. What do you think about following proposal? Navigation Hotkeys laptop layout:
So involving the ctrl key means we deal with clutter. Involving the NVDA key means we ignonre either the block or the clutter (in case the ctrl key is also involved). |
A block is a bunch of lines with higher indentation level bounded on either or both sides by lines with lower indentation level. Think of a Python or properly indented C++ function - function declaration line has lower offset than its entire body, so function body would be a single block. Blocks can also be also nested, so if your cursor is within an
There is this diagonal navigation intuition. We can either find previous or next line (think up or down) and at the same time we can find a line with lesser or greater indentation level (think left/right). Therefore the most intuitive way would be to make use of four corners.
Because NumPad3 and NumPad9 are reserved for diagonal commands - finding greater indentation level. If I reuse them with Re: laptop keybindings, if we go back to arrow keys, we would loose diagonal intuition. Also you propose to make use of |
|
I have another idea about keys and navigation style.
I guess you are basing this off of object navigation, and the windows keymap?
Personally, I think I would find it more logical to base it off of review keys.
That is, where 7, 9 jump to prev/next line with current indent, and 4, 6 or 1,2
change the level of indent until the next change.
I haven't thought through all of the functions you are proposing here regarding
clutter, etc., but I wanted to put the basics of this thought out there.
Also I think I agree with the direction @Adriani90's thinking is going with
that, as far as a cycling hotkey to change modes, instead of putting nav keys on
every possibility separately.
|
|
Text editors such as NotepadPlusPlus, can do indenting (many, such as nano in
Linux, also can). I believe NP++ can also do various kinds of navigation by
blocks and indent nav, especially with Derek's add-on.
That's fine for a coding context, but what about web navigation? There you need
something like this proposal, or Tony's original add-on.
|
No. I base this off of my IndentNav add-on. Except I am proposing a new set of keyboard shortcuts. Because the one that I used in IndentNav is flawed specifically in the sense that it's only using four arrow keys and so it doesn't have diagonal intuition, and so itit's more tedious to use in certain cases. That's why I am proposing to make use of numpad block here. Based on my 5+ years working with IndentNav - that's going to be more convenient.
I can see the logic with numPad 7 and 9 keys. But Using numPad 1,3,4,6 doesn't follow any logic. Moreover, what gesture would you use for jump to first/last line with same indentation level? And for skip clutter commands?
Not sure what you're referring to here - could you clarify?
What do you mean by "indenting"?
Please explain. I am not aware of any such functionality. |
|
At this stage, we do not think this can be accepted in NVDA core. |
seanbudd
added
blocked/needs-product-decision
|
@seanbudd I think people use indentnav for other use cases as well (i.e. navigating on redit by comment level). So this is something that is already known in the community and is by far not limited to IDEs. Still we can use the IDEs as use case to build something upon a practical example. |
Which IDEs are you talking about? I am not aware of a single IDE that supports this.
True, this is mostly limited to blind developers. But developers do this feature invaluable. I'm going to collect all the mentions of IndentNav on the NVDA mailing lists to show you how many people use IndentNav and recommend it to other users. |
|
@mltony, and why not keep the commands of indentNav? |
I see your point. @mltony regarding my proposal, I originally wanted to propose a way where users can toggle between block limited indent navigation, clutter limited intend navigation or no limit indent navigation (i.e. toggling via nvda+i). But still we would have this diagonal navigation problem. Could you please explain in more details why this diagonal navigation is so useful? Is same indent or greater/lesser indent not sufficient for higher efficiency? You say:
If diagonal navigation causes this, is it not counter-intuitive to fly out of the block / clutter accidentally? |
I compiled for you all positive feedback as well as people looking for or suggesting IndenNav that I have received in the last 6 years. The deduped list below contains 43 users - 3 of whom are Jaws users looking for IndentNav functionality in Jaws, the rest are NVDA users either praising IndenNav, or recommending it to others or reporting issues or saying something that suggests that they are using it. Most of these are from public email lists and github, so these are all verifiable - except for the last section, that lists people sending private emails to me. I hope this serves as evidence that the add-on is quite popular in NVDA community and people do have legitimate use cases for it. program-l
NVDA and NVDA-addons
Github issues
Personal emails
vmahdi abedi [email protected]
Deduped list of users from the sections above:Pratyush Kaushal, Jacob Kruger, Florian Beijers, joeldodson, Fawaz abdul rahman, Stefan Moisei, Ben Humphreys, Dzhovani Chemishanov, Gabriele Battaglia, Carter Temm, Duong Tuan Nam, Sanchit Ghule, Rejin Jose k, Corbett, James, Parthy Siva, [email protected], Mike Sedmak, Bruno Aníbal Prieto González, lcong5946, Rui Fontes, Greg Wocher, Adriani Botez, William, Cyrille, Han Solo, Norberto Sousa, Brandon Cross, dingpengyu , David Moore, MJW matthewjwilliams101, André-Abush Clause, legle, TheQuinbox, Thiago Seus, davidacm, SkyDreamer, Andrew Downie, timothyjb310, Peter Lecky, Olexandr Gryshchenko, vmahdi abedi, David Mehler, Marlon Brandão de Sousa, Samuel Kacer |
I did a thorough investigation of modern IDEs and I couldn't find a single one that would come with indentation navigation functionality. I am pretty familiar with all IDEs below - except for IntelliJ Idea, so I'm rather confident that when phind.com AI says there is no such function, it doesn't hallucinate, I also double checked with traditional Google search. VSCodeAI says that the way to go is my IndentNav VSCode extension, that is nearly identical to IndentNav add-on. The rationale for writing VSCode extension was that back in 2019 or 2020 VSCode exposed only 10 lines of code at a time through accessibility API, so IndentNav add-on was completely broken in VSCode - the situation with Monaco accessiblity improved significantly since then and the VSCode extension is kind of abandoned at this point. I would argue that between NVDA functionality (either core NVDA or an add-on) and a VSCode extension, the right way would be to use NVDA functionality, since this way indentation navigation can be brought to all supported text editors at once. Another option for VSCode is an extension IndentNavKit, that its author says is a fork of my IndentNav extension by what appears to be a non-blind user, so it's not clear that it would work with NVDA. Besides extensions, AI thinks there are a few indentation-related features in VSCode core, but none of them as you can see has anything to do with navigation by indentation level. Finally, what AI didn't mention is that in VSCode there is symbols lookup feature that allows you to jump between functions defined in a file. That's the closest I can think of, but the problemn with this approach is that it only works on one level - that is top-level functions, while IndenNav works at all levels of indentation. So symbols lookup, while indeed present in most IDEs, can't replace IndentNav. Visual StudioEclipseIntelliJ IDEA |
|
Finally, I would like to mention some of my personal use cases where I find IndentNav indispensable. I hope other IndentNav users - (I know many of them are lurking here on github :) ) - can chime in with their use cases as well.
|
|
I am also happy if nvda can include this function in nvda |
|
Hi all, |
|
I am a visually impaired software engineer and I have been in tech industry for almost 20 years. I feel being able to do indentation navigation is critical to my daily work, from coding to notes taking. Honestly, this is one of key features I switched from JAWS. |
|
When I discovered IdentNav my productivity got a real kick in the butt. In addition to the other arguments I would like to highlight the ease which I can find matching braces or discover that they don't match... I remember the resistance when I proposed implementing a screen curtain in NVDA. The argument was that it didn't affect screen reader users. Fortunately it whent through and is essential for us so we can retain privacy. |
|
Being a VI software engineer, The indent nav add-on is the most useful add-on that I've ever used. It just bumped-up my productivity drastically. Jumping between the large block of code is just very easy and intuitive. I don't know why? if something is valuable for the users, then why it cannot be the part of the NVDA core it self. |
|
Know of very few IDE's that actually support indent-level navigation by default - yes, if they know you are working with a specific programming language, they might attempt to automatically implement it, but, not everyone uses the same IDE at all, and, I would also generally prefer to have full control over where I landed when navigating through blocks of code - lots of us work in different forms of text editors, where it is also unlikely they would support it by default, without having installed another plugin per editor, so, having it available, even without a keystroke initially being assigned to it would definitely be beneficial - malso provides us with the means to remember a single keystroke across environments? |
|
I wish this was not added by a screenr eader and that people would write addins to things like VSCod enad IntelliJ to do this. I am not even sure there is not one. With that said this would be a good addon to NVDA. |
|
It will definitely a godsend if it gets added into NVDA |
|
am a blind developer, and indent nav was a huge help to my work flow. I use it in the notepad++ editor with C++, Ruby, Perl, Python, etc... |
|
It appears we were mistaken on the limited functionality of indent navigation in IDEs. We need to draw the boundary between core features and add-ons somewhere, and it is not clear what value this brings to most NVDA users, particularly while this add-on serves the minority who use this. |
|
Again, what does give you the impression that this is used by a ninority of users? Actually the majority of users use this addon indeed. In Germany and Romania I don‘t know any user who doesn‘t use this addon.I don‘t se a lot of naintenance comming up. To be honnest, the maintenance of such features in the core is mostly done by the community anyway. See for example object navigation which is being maintained through community Pull Requests since more than 10 years.And by the way, I think an addons environment as we have it now requires more maintenance by all means when comparing to features in the core.Could you please elaborate more on how you come to such a decision? Von meinem iPhone gesendetAm 05.03.2024 um 02:19 schrieb Sean Budd ***@***.***>:
It appears we were mistaken on the limited functionality of indent navigation in IDEs.
However, this feature still serves an extremely limited audience, which brings in the question of maintenance cost and scope creep.
Could you explain what value incorporating this into core brings, when an add-on is available?
We need to draw the boundary between core features and add-ons somewhere, and it is not clear what value this brings to most NVDA users, particularly while this add-on serves the minority who use this.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@seanbudd #16236 is certainly a slight improvement for browse mode only, but it doesn't allow to navigate to greater or lesser indentation levels, nor it proides a way to restrict the navigation to the current block. This is needed for navigating websites such as Redit or other complex websites such as concept boards. And all the use cases where browse mode is not available are not covered at all, i.e mathematical expressions written in tabular structure including complex divisions, applications where quick navigation is not supported, etc. So the use cases above still stand. |
|
However, I am not sure the diagonal navigation @mltony talks about is really needed. I don't understand the real efficiency gain from that navigation patern. @mltony can you elaborate to my #16230 (comment) ? |
|
Let me clarify. There are two separate use cases:
Could you clarify this one - I didn't understand this use case. |
|
@mltony thanks for this good explanation.
Example 2: Google docs document (applies also for other type of documents where browse mode is not really supported like Libreoffice:
Example 3: mathematics
You can basically build up every cost calculation formula which contains a division as a tabular structure or as a table. Cost calculations can contain more than one level, that means you can have more than one indentation level for the tabular structure depending on the production cycle and the costs that are involved. |
|
|
Your indent nav addon worked well in non browse mode scenarios as explained above.Also it is not just about vertical nav, lesser or greater indent level is as important as same indentation level.Adding browse mode to Libreoffice needs first a full implementation of IAccessible API esxposures from the LO developers which will not happen in the near future as they confirmed.And even if browse mode was implemented, table navigation support is not implemented. Also LO is not the only example, let‘s take basically every text editor without browse mode and table support, powerpoint in presentation mode for example.RE Indent nav in Google Docx, you say in focus mode indent nav did never work reliably. What was the reason? Is focus mode not implying the standard system caret like in a text editor?Von meinem iPhone gesendetAm 13.03.2024 um 01:38 schrieb mltony ***@***.***>:
Regarding diagonal navigation in browsers, although initially I implemented that as a feture in IndentNav, I moved this feature to BrowserNav long time ago, like maybe 5 years ago. If you find it useful I can keep it there. As for whetehr it should be merged into core, I personally think that it's not useful enough, but I can be convinced otherwise.
Regarding Google Docs - accessibility model of Google Docs is just terrible. None of indent-nav related commands are going to work reliably in Google Docs, just because it only exposes a part of document at a time. This affects both browse and focus mode. So no, neither indentNav for editables, nor indentation navigation in browse mode will work correctly with Google Docs and this can't be fixed unless for example #15995 happens.
Regarding LibreOffice, since it doesn't support browse mode, then BrowserNav indentation navigation must have never worked there. We can think about porting vertical navigation QuickNav command to non-browse-mode documents. But then I'd have to ask the question of utility - are we only doing this for LibreOffice? Wouldn't it make more sense to add browse mode to LibreOffice instead?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Even though I'm a passionate user of Indent Nav, I'm inclined to say that it is out of scope for core. I find the concerns from @seanbudd perfectly valid. |
|
And what about my very concrete use cases above? I still don‘t see why they should be just ignored. Can you provide a strong argument?Von meinem iPhone gesendetAm 13.03.2024 um 07:52 schrieb Leonard de Ruijter ***@***.***>:
Even though I'm a passionate user of Indent Nav, I'm inclined to say that it is out of scope for core. I find the concerns from @seanbudd perfectly valid.
As suggested in #16056 (comment), I'd rather see investment in proper rating of add-ons in the store, so if the add-on is as often used as claimed, it can be part of a recommended add-ons category. In that case, it is pretty easy for users to install it.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
In addition, I may be asking a somewhat controversial question, but it seems to me as if the Indent Nav add-on is hardly maintained. Latest commits on https://github.com/mltony/nvda-indent-nav are from two years ago. |
Happy to see them incorporated in the add-on 😉 |
|
That‘s why many users still didn‘t update NVDA, this is the reality and what we see in many cases in Germany and Romania.You gave the obvious reason why this feature should not be an add-on given its global usage in so many use cases.Von meinem iPhone gesendetAm 13.03.2024 um 07:59 schrieb Leonard de Ruijter ***@***.***>:
In addition, I may be asking a somewhat controversial question, but it seems to me as if the Indent Nav add-on is hardly maintained. Latest commits on https://github.com/mltony/nvda-indent-nav are from two years ago.
That really gives me the impression that the broad use as claimed by some is somewhat exaggerated. I for me had to tweak the manifest and the code to use it in 2024.1 alpha. for example.I think there are quite a few alpha or beta testers around here who have had to perform a similar trick.
Not trying to be harsh here, just sharing some facts that really worry me with regard to maintenance of the code, especially when it breaks. As stated elsewhere, it should not be the intention that various features come to core at the insistence of the community, while NV Access ultimately becomes responsible for their maintenance. This is just to further support @seanbudd's objections.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Also same as already said, this feature could also be used and help people a lot in corporate environments where add-ons are not allowed.Von meinem iPhone gesendetAm 13.03.2024 um 07:59 schrieb Leonard de Ruijter ***@***.***>:
In addition, I may be asking a somewhat controversial question, but it seems to me as if the Indent Nav add-on is hardly maintained. Latest commits on https://github.com/mltony/nvda-indent-nav are from two years ago.
That really gives me the impression that the broad use as claimed by some is somewhat exaggerated. I for me had to tweak the manifest and the code to use it in 2024.1 alpha. for example.I think there are quite a few alpha or beta testers around here who have had to perform a similar trick.
Not trying to be harsh here, just sharing some facts that really worry me with regard to maintenance of the code, especially when it breaks. As stated elsewhere, it should not be the intention that various features come to core at the insistence of the community, while NV Access ultimately becomes responsible for their maintenance. This is just to further support @seanbudd's objections.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@Adriani90, in Portugal and Brasil, indentNav is almost used only by developers... |
@ruifontes this is most probably due to the communication strategy in your communities. If you describe the add-on of being useful only for developers, ofcourse only developers will feel addressed. In our communities this add-on has been applied in multiple use cases from the beginning on, ofcourse we also targeted developers when promoting it, but not only.
It is not just about add-on usage, it is about the potential this kind of feature has on the entire community. |
|
I'm seconding everything said by @Adriani90 and @brunoprietog. I've incorporated indent navigation into my workflow in such a heavy way and it's helpful in so many cases, including reading code, structured text, diagrams, trees, etc. |
|
While I am not using indent nav and quite frankly could not care less if it is in included into the core or not, conclusions drawn by @LeonarddeR and @ruifontes do worry me:
There are also several different conclusions which can be drawn from this data:
As explained above it is your interpretation of the current state of affairs in terms of maintenance, rather than facts.
This is not about add-on usage - without any statistics we have to trust @Adriani90 that indent nav is used as often as they claim. The difference is that indent nav eliminates one of the advantages directly caused by blindness i.e. comprehending indented content is easier, whereas ClipSpeak gives a notification in cases where sighted people don't get one. |
There is still perhaps some confusion here. After 2019 IndentNav only works by indentation level in plain text editors. If it worked in LibreOffice/MSOffice - that's not by design. This feature is only for developers and therefore as Sean pointed out we shouldn't include this in core. Navigation by x axis has always been supported in browse mode only. This was part of IndentNav before 2019 and part of BrowserNav after 2019. As for vertical navigation in LibreOffice without browse mode, perhaps you convinced me, that might be a reasonable feature request. As for Google docs, they only expose tiny part of the document through accessibility API. Sometimes less than a page. So if you do vertical navigation, you'd be limited to a small subset of the document. Bug reports guaranteed. |
|
@mltony I still would like to challenge your argument that it is useful only for developers.
This was your design choice, but still this feature is not relevant for plain texxt only.
It is again not about writing code. It is about understanding structures on the screen whether they are in a plain text editor or not. And visually structuring something means always you use indentations in every kind of form.
I am quite sure there should be a technical possibility to work around this, you can scroll the document while using the system caret, that's what happens when you navigate with arrow keys only. The document scrolls, making other parts of the document visible. Why should this not be possible for indent navigation? You move the system caret to certain positions in the document, so the screen could be scrolled there as it happens in MS Word for example. I think you have exposed your add-on only to a use case and people did more out of it without giving further feedback, maybe this is the reason you still limit the use case. |
Sure, I can see that IndentNav can be used in this case. I'll leave it up to Sean to decide how important this case is.
people don't typically use spaces to indent things in MS Word. I didn't work much with LibreOffice, but I would assume it's similar. MSWord got better tools to do layout. IIRC tab doesn't even work as a character in MSWord. So the point is I can hardly imagine VIP people using MSWord to do indentation like programmers do in plain text editors. It's possible in theory, but that would be inconenient. I personally think that would be a very weird use case. You can argue that a properly indented document can always be copied into MSWOrd, but it doesn't make it less weird. During6 years of INdentNav I had many people suggesting features, but MSWOrd support wasn't one of them. So I still maintain my opinion that indentNav for MSWord doesn't make much sense. I think we're already talking about minority of users who use IndentNav - those are developers plus few non-developers who work with indentation-formatted documents, and those who would want to use formatted documents in MSWOrd would be minority among minority.
No you can't. Delay would measure in seconds, sometimes dozens of seconds. I tried that approach in IndentNav for VSCode and it failed miserably, I didn't even do a public release. |
|
Thanks @mltony your last comment helps to understand better the limitations you faced when desiging this add-on. At least for MS Word and Libreoffice 24.0, they expose the distance of characters from the left edge of the screen, so you have a x-achsis that is always available. Could we not use that information to define the indentation in these applications? You might have the perception that is a minority of people, but this perception is definitely due to the way this add-on has been promoted over the last years, and it doesn't really tell the full truth of this functionality. just because programatical languages use indentations this doesn't mean that other fields do not use indentation to structure information on the screen. |
This is how indentation has always been defined in browse mode. It has never been defined like this in IndentNav. That's why I'm saying that the best course of action seems to me to implement maybe imperfect browse mode in LO. In MSWord this should already be working since browse mode is working. If you feel that there is enough demand to have vertical navigation in LO without browse mode - I might agree here - perhaps you know better what users watn.
Sure that must be possible. And sure, NVDA beeps indent level in MSWord. But again my point is I am not convinced that this would be very useful to anyone. NVDA beeps progress most likely because beeping has been implemented in editableText class, which MSWord inherits. Not because someone desperately needed to hear indentation level specifically in mSWord. Also, MSWord has word wrap enabled by default - IDK if there's even a way to disable it - and with word wrap indentation navigation would be broken the first time your line wraps.
Trying to combine two approaches is not a good idea. Way too confusing. |
|
@mltony wrote:
It is not only useful to have vertical naivgation both in focus and browse mode, it is even very useful to have this working also by lesser or greater indent level. I have been using NVDA for more than 10 years and I have been building the german community as well as contributing to the romanian community, and definitely indent navigation both in browse and focus mode would make life easier for many users in many use cases.
MS Word was just an example. Beeping indent level definitely has a lot of use cases, although at the time of implementation developers did not have all of them in mind. Lots of users are thankful to this feature, especially when reviewing or desiging well structured documents in different applications.
Generally speaking, there are a lot of cases where in MS Word indentation is broken, e.g. when wrapping lists around a table. But this is an issue for sighted people as well, and if this should be solved, then it needs an external fix. |
|
I think I have found a proposal that might make sense for the laptop keyboard layout as well:
Now on the keyboard commands for laptop keyboard layout which would work in all of three indent modes:
This approach should work both in browse and focus mode in editable areas and in the virtual document. |
|
@Adriani90, I am not a user of such type of navigation and, for now, have no opinion on its inclusion in NVDA core. However, reading your last comment, some questions come to my mind:
Do you mean:
Note that NVDA cannot test if the keyboard has a numpad and make a decision depending on this; indeed, what happens with a laptop without numpad having an external keyboard with numpad plugged in? Both keyboard can be considered.
Note that these gestures are already taken by read row/column commands. Do you have this in mind? Do you expect to have a different behaviour in table and out of tables? |
|
@CyrilleB79 wrote:
That's what I mean, because for the numpad there are enough key combinations to cover indent navigation in a logical way for block, clutter and no limitation and also to cover the diagonal navigation in case of top right to lower left of the screen. My understanding is that NVDA can make the difference whether someone presses arrow keys or numpad keys, so the indent modes would only impact the use of x+y+z+arrow keys. This is how it works with review modes for example.
Good catch, thanks I didn't have this in mind. In this case an additional toggle would be needed for NVDA+i which turns off the indent navigation feature completely so people who need this command in tables can use it without problems.
Not really. In browser nav add-on you can currently navigate tables by using the indent navigation instead of ctl+alt+arrow keys, so there is no conflict so far. The advantage is with indent navigation you even can navigate tables row by row or column by column whether they are css tables or properly defined tables. So it works in situations where NVDA doesn't support table navigation. |
|
I edited my #16230 (comment) |
|
Closing in favor of #16467. |
and others
Is your feature request related to a problem? Please describe.
Most modern programming languages make use of indentation, so that sighted people can easily grasp the structure of program or function visually. Currently NVDA announces indentation level but doesn't offer any more advanced ways to leverage indentation to ease navigation in source code. I propose to add indentation navigation commands to NVDA.
Describe the solution you'd like
alt+numpad numberit prints a character by its ASCII or Unicode code. I propose to reuse these keystrokes for indentation navigation with an ability to exit indentation navigation mode in case someone wants to use original Windows functionality.Alt+numLock: toggle between indentation navigation and ASCII/Unicode character modes.Alt+numPad2/NumPad8/NumPad4/NumPad6: Jump to next/previous/first/last line with the same indentation level within current block.alt+numPad1/numPad3/numPad7/numPad9: Jump to next/previous line with lesser/greater indentation level.control+alt+numPad4/numPad6: Jump to next/previous line with the same indentation level, but not necessarily bounded by the limits of current block.control+alt+numpad2/numPad8: Jump to next/previous line with the same indentation level, but ignoring clutter.Describe alternatives you've considered
N/A
Additional context
TextInfo.move(UNIT_LINE)function as its current implementation is way too slow in many programs when need to move by 100..1000 lines.The text was updated successfully, but these errors were encountered: