The speech history add-on being built in to nvda

[kl-productions]

OK so I made an issue like this but it was closed because there was a duplicate topic already which would've been fine except for the fact that it was seven years old and it didn't have a single response and that's not very much related to what I was talking about. I'm talking about making the add-ons functions built-in because I don't know a single blind person who doesn't use speech history. this would also make it so if such a vital add-on wasn't updated to support the latest version you couldn't use it. If it was built in that issue wouldn't exist anymore

[CyrilleB79]

@kl-productions your previous issue is #16644 and has been closed as duplicate of #6905. When an issue is closed as duplicate, it normally means that the discussion is meant to be continued in the main issue, here #6905.

Reading #6905 though, Sean from NV Access writes in https://github.com/nvaccess/nvda/issues/6905#issuecomment-1990087781:

I think a clearer issue needs to be written up. i.e. using the feature request template, and covering some of the discussion in the issue

So NV Access is expecting someone to open a new issue on this topic, using the new feature template and where a summary of the discussion in #6905 is made. When this new issue has been opened and is valided, #6905 will be closed in favor of the new one.

If the effort of writing a clear new issue is not made, there is no point opening a new issue.

For now, I'll close this issue again as duplicate of #6905 since what you have written here is not clearer as #6905 and having a second similar issue is not useful.

[kl-productions]

yes. But that issue has been inactive for seven years and the add-on didn't even exist then I'm pretty sure

[josephsl]

Hello,

Community contributor intervention: we understand that there is a need to incorporate speech history add-on to enhance NVDA feature set and for continued compatibility. While I (Joseph) can see the benefit of this feature, please keep the following three things in mind, all of which are important for reasons described below:

1. Code maintenance: incorporating add-on features means commitment to its maintenance, with NV Access and NVDA screen reader contributors taking more responsibility as opposed to asking add-on authors to maintain it. As you rightfully said, integrating add-on features would guarantee maintenance across compatibility breaking releases. However, this must be balanced against complexity of code maintenance as changes to NVDA may break speech history in unexpected ways, more so when NVDA code affecting speech history functionality is changed in a major way in a future year.1 release (especially more so when Python is upgraded to say, from 3.11 to 3.13/3.14). If the add-on author and NV Access agree that maintaining speech history as part of the screen reader is beneficial after assessing maintainability, then I think integrating that add-on feature should be considered with the caveat noted next.
2. Getting add-on code ready for integration: it is not enough to say, "let's integrate ad-on features" and get a pull request going right away by using current add-on code; I guarantee that this is not an effective solution. Because add-ons are maintained by third parties for the most part, some add-ons may use coding style different than that of NV Access or might use a dependency that may conflict with what the screen reader itself is using. We had cases where integrating an add-on feature took longer than expected (for example, application volume adjustment feature that ran into coding and design issues), involving code rewrites from both NV Access and ad-on authors. I expect speech history to go through this route, most importantly over the issue of keyboard shortcut assignment (F12 conflicts with features such as toggling developer mode in web browsers). In short, integrating add-on features at the code level requires a balancing act and continued negotiation/compromises between ad-on authors, NV Access, and testers/users (this is why I sometimes show hesitancy when commenting on suggestions to incorporate add-on features, and you can tell there is some hesitancy in this comment as well). I can speak to the compromises I had to make and the effort involved when bringing in add-on features to NVDA itself, mostly involving discussions around design and keeping up with NVDA code changes while working on some add-on feature integration work.
3. Community culture and norm matters: while hinted somewhat by Cyrille, think about community culture, especially the continued request by NV Access to get folks to use the issue template when creating new issues. The norm here is for folks to think systematically when writing issues, and using the issue template forces people to think twice (or three times) before clicking submit button i.e. people want to see an effort gone into organizing your thoughts. I promise you: this way of thinking takes time, and I advise folks to practice this to make lives easier for NV Access folks, community contributors, the public reading NVDA issues, and for yourself. In short, I ask folks to remember: in some cases, community culture and norms override our personal culture and norms, and in case of NVDA GitHub issues, filling out the issue template to the fullest is an acknowledgement of this reminder.

I am intervening as a community contributor with the above three things for an important reason: to get us to think about complexities and effort involved when reporting software issues or suggesting features. I think Cyrille did the right thing by closing this as a duplicate (at least this is my opinion as a contributor), and I felt it would be a good opportunity to remind folks about why filling out the template is important (among other things). Therefore, I kindly advise: step back, and please try again, this time following recommendations from Sean Budd (NV Access staff), Cyrille, and I, including fillin out the template and giving details as Sean suggested while doing so. That way, speech history integration can gain more support.

Thanks.