Comment 1 by jteh on 2014-12-11 02:57
The problem is that we actually can't tell which was the last selected line in many cases; some programs simply don't expose that information. For shift+downArrow, it's always the last line. However, you can also select backwards with shift+upArrow, in which case it's actually the first line. In fact, I'm not sure any program supports this, but we should at least try to support it for any that do.

Comment 2 by surfer0627 (in reply to comment 1) on 2014-12-12 03:00
Replying to jteh:

However, you can also select backwards with shift+upArrow, in which case it's actually the first line.

Yes, this is a temperate solution.
In a multiline selection case, braille user need to know the position they are located.

Comment 3 by dkager on 2015-10-19 18:41
Bump. I ran into this today in browse mode. Here it should be possible to always braille the last line that is (partially) selected. At first glance there are two cases:

1. If the initial selection goes down at least one line, then braille the last line, even when the user then presses the up arrow, e.g. to unselect a line if they got a little carried away.
2. If the initial selection goes up at least one line, then braille the topmost line.
   The corner case is when one scenario changes into the other. NVDA manages the buffer itself so should know what is being selected.

Another problem of the current implementation of braille.TextInfoRegion.update() is that it restricts itself to the line that contains the cursor. This prevents translating text into braille that the user can't scroll to without moving the cursor. We need to extend this so it moves to the active end of the selection, if any. Code to find the active end is part of #5770.

@jcsteh In braille.TextInfoRegion.update() I read:

        # HACK: Some TextInfos only support UNIT_LINE properly if they are based on POSITION_CARET,
        # so use the original cursor TextInfo for line and copy for cursor.
        self._readingInfo = readingInfo = self._getCursor()
        cursor = readingInfo.copy()

This is only used near the end of the function:

        # If this is not the start of the object, hide all previous regions.
        start = cursor.obj.makeTextInfo(textInfos.POSITION_FIRST)
        self.hidePreviousRegions = (start.compareEndPoints(readingInfo, "startToStart") < 0)

Why does this not use self.obj.makeTextInfo? It would simplify the code a bit if this could be avoided. If not it'd be great if the comment could be a bit clearer.

The comment you reference isn't at all related to the question you're asking.

Those are the very best questions!
Anyway, that local variable 'cursor' is only used in the bit of code I quoted. It seems to me that readingInfo.obj == cursor.obj, though readingInfo does get expanded along the way.

According to deaf blind community in Japan, people who uses only braille display cannot check the ending character of selected text region, when the region contains several lines.

step to reproduce:

• put text to multiline edit (such as notepad.exe) which contains two or three lines of string
• NVDA+Ctrl+T to set "braille tether to focus"
• move to the beginning
• press shift + right arrow for several times. braille display shows the text and the selected region is underlined.
• press shift + right arrow and the caret goes to the second line. braille display only shows the text of first line.
• the press of shift + right arrow is accompanied by the speech announcement of newly selected character. however, the braille-only user cannot figure out where is the caret.
• during the procedure, scroll forward/back of braille display may be available, but sometimes such operations may fail and the selection is cancelled.

The workaround for this is firstly move to the ending of the region, and then, use shift + left arrow to increase the region in reverse. however, it is not intuitive.

Is this duplicate of #5770 or here?
Or is there any other solutions for this case and should be filed separately?

@dkager, am I correct that this is fixed by #6775? It seems to work for me, but I know you felt #5770 and this issue were a bit different.

I believe I initially wanted to do the selection code in two steps: first for left/right selections on a single line in #5770 and then multi-line selections in this issue. But in the end I did both, so yes this is fixed.