Make several speech functions return sequences instead of strings

[LeonarddeR]

Brought up by @jcsteh

Is your feature request related to a problem? Please describe.

Something that's going to be needed to get the full benefit of speech refactor is to make speech.getControlFieldSpeech and speech.getFormatFieldSpeech return speech sequences instead of simple strings. For example, this will be necessary if we want to use sounds instead of text to indicate spelling errors, change voice parameters for emphasised text or links, etc.

Originally, @jcsteh intended this to be done later. However, given that it's a pretty big backwards compatibility break, He pointed out whether it'd make sense to do that before the first Python 3 based release is shipped.

Describe the solution you'd like

The following functions need to return speech sequences (lists) instead of strings:
Note: used git grep -E "def get(\w+)Speech"

• speech.getSpeechTextForProperties: rename while at it?
• speech.getControlFieldSpeech
• speech.getFormatFieldSpeech
• appModules.kindle.BookPageViewTextInfo.getFormatFieldSpeech
• browseMode.BrowseModeDocumentTextInfo.getControlFieldSpeech
• treeInterceptorHandler.RootProxyTextInfo.getFormatFieldSpeech: It actually amazes me that there is no treeInterceptorHandler.RootProxyTextInfo.getControlFieldSpeech override

@derekriemer brought up speech.getIndentationSpeech, whereas I'd say speech.getTableInfoSpeech is also a candidate.

Describe alternatives you've considered

Leave code as is now. It shouldn't be very difficult to add backwards compatibility later on by means of instance checking for controlFieldSpeech and formatFieldSPeech provided by custom TextInfo implementations.

Cc @feerrenrut

[jcsteh]

Describe alternatives you've considered

Leave code as is now. It shouldn't be very difficult to add backwards compatibility later on by means of instance checking for controlFieldSpeech and formatFieldSPeech provided by custom TextInfo implementations.

I thought of this and was considering it back in the days when I was trying hard to have a compatibility layer for pre speech refactor things. I don't think this is going to be feasible. Most getControl/FormatFieldSpeech implementations are going to extend the superclass implementation, not just override it; i.e. they'll call super and expect that to be a string. Unless we want to have the superclass inspect the stack, realise it's being called by an outdated caller and modify its return type accordingly, accepting that any add-ons that depend on this will break bits of NVDA functionality (e.g. inbuilt audio cues) whenever that add-on overrides getControl/FormatFieldSpeech. I think trying to do this would be a world of pain.

[derekriemer]

We will need this to do font related sound schemes.

…

On Thu, Aug 15, 2019 at 7:50 PM James Teh ***@***.***> wrote: Describe alternatives you've considered Leave code as is now. It shouldn't be very difficult to add backwards compatibility later on by means of instance checking for controlFieldSpeech and formatFieldSPeech provided by custom TextInfo implementations. I thought of this and was considering it back in the days when I was trying hard to have a compatibility layer for pre speech refactor things. I don't think this is going to be feasible. Most getControl/FormatFieldSpeech implementations are going to extend the superclass implementation, not just override it; i.e. they'll call super and expect that to be a string. Unless we want to have the superclass inspect the stack, realise it's being called by an outdated caller and modify its return type accordingly, accepting that any add-ons that depend on this will break bits of NVDA functionality (e.g. inbuilt audio cues) whenever that add-on overrides getControl/FormatFieldSpeech. I think trying to do this would be a world of pain. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10098?email_source=notifications&email_token=ABI2FPJB4FYFYN5SDNJCMSLQEYBVFA5CNFSM4IL3MYM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4NODOI#issuecomment-521855417>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABI2FPMG6EA3SP2Y7IG2MYLQEYBVFANCNFSM4IL3MYMQ> .

-- Derek Riemer: Improving the world one byte at a time! - University of Colorado Boulder Department of computer science, 4th year undergraduate student. - Accessibility enthusiast. - Proud user of the NVDA screen reader. - Open source enthusiast. - Skier. Personal website <http://derekriemer.com>

[feerrenrut]

Any suggestions for a better name for getSpeechTextForProperties ?

• getSpeechSequenceForProperties?
• getPropertiesSpeech?

[LeonarddeR]

I prefer getPropertiesSpeech

[jcsteh]

+1 on getPropertiesSpeech. Fits with getControlFieldSpeech, etc.