Announce number of character repititions instead of truncating to 5 #43

nvaccessAuto opened this Issue Jan 1, 2010 · 5 comments


None yet
2 participants

Reported by jteh on 2008-03-18 20:13
Currently, when speaking repeated characters, NVDA simply truncates any repititions after the first five characters. For example, if 10 dashes are encountered, this will be announced as 5 dashes only. This gives no indication of how many repititions actually occurred. It would be more useful to announce the number of times a character occurred if there are more than a certain number of repititions; 2 repititions is probably ideal. For example, two dashes would be announced as "--", but three dashes would be announced as "- 3 times".


  • Should this be configurable?
    • Is the current behaviour preferable in some cases? If so, there could be an option to switch back to the old behaviour.
    • Should the number of occurrences of a repeated character before this behaviour is triggered be configurable? I think this is overkill; 3 occurrences (2 repititions) should be fine, as "- 3 times" is the same number of syllables as "---".
      Blocked by #332

Attachment repeated_chars.patch added by jteh on 2008-03-19 03:21
Proof of concept implementation.

Comment 2 by jteh on 2008-03-19 03:23
This patch is a proof of concept implementation.

Change from the spec above:

  • The behaviour is triggered after 3 repeats; i.e. 4 of the same character. Otherwise, "..." gets announced as ". 3 times", which is rather annoying.


  • This needs to be integrated with the punctuation code somehow to avoid expansion when punctuation expansion is disabled. Currently, if speak punctuation is disabled, 5 dashes will produce "5 times", even though the dash is later removed.
    • This will get even more tricky once we start using the synth to handle punctuation expansion. We'll need to figure out what punctuation the synth is announcing in order to know when to expand for repeats.
  • How should we handle whitespace?
    • Currently, whitespace gets handled as well, but, for example, "30 times" without knowing it is a space character is bad.
    • Should this avoid handling whitespace?

In hindsight, this idea may be more trouble than it's worth. :)

Comment 5 by jteh on 2009-07-24 06:22
Bzr branch:

Comment 6 by jteh on 2011-04-14 03:19
This is already fixed in the new code for #332. On further reflection, I think indentation needs to be handled separately.

Comment 7 by jteh on 2011-04-18 03:12
Milestone changed from None to 2011.2
State: closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment