[bug] "up" keypress not properly handled

[adbenitez]

when "up" key is pressed and the editor is already at the first line, keypress should be considered not handled and propagated to parent widget, that seems to be already intended at:

https://github.com/rr-/urwid_readline/blob/46cfd3bba7c4028a7659e5317ca712db6248e1e8/urwid_readline/readline_edit.py#L139-L140

but then previous_line() is not returning False when there is not previous line:

https://github.com/rr-/urwid_readline/blob/46cfd3bba7c4028a7659e5317ca712db6248e1e8/urwid_readline/readline_edit.py#L213-L215

this is due to that max(0, y - 1) which causes to always pass 0 at the worse case so move_cursor_to_coords() never actually returns False since line 0 is valid, max(0, y - 1) is unnecessary because move_cursor_to_coords() will check this and return the expected False result if the coordinate is out of bounds:

    def move_cursor_to_coords(
        self,
        size: tuple[int],
        x: int | Literal[Align.LEFT, Align.RIGHT],
        y: int,
    ) -> bool:
        """
        Set the cursor position with (x,y) coordinates.
        Returns True if move succeeded, False otherwise.
        ...
        """
        (maxcol,) = size
        trans = self.get_line_translation(maxcol)
        _top_x, top_y = self.position_coords(maxcol, 0)
        if y < top_y or y >= len(trans):
            return False

        pos = text_layout.calc_pos(self.get_text()[0], trans, x, y)
        e_pos = min(max(pos - len(self.caption), 0), len(self.edit_text))
        self.edit_pos = e_pos
        self.pref_col_maxcol = x, maxcol
        self._invalidate()
        return True

[rr-]

@neiljp can you confirm this doesn't break anything on your end? Thanks.

[neiljp]

@Niloth-p Would you be up for checking if this is a problem? (@rr- @adbenitez Apologies for the delay, this slipped through my email)

[Niloth-p]

@neiljp can you confirm this doesn't break anything on your end? Thanks.

Hi @rr- @adbenitez ! Sorry for the delay since Neil pinged me in. Checked the issue and the PR change - both seem to be working fine, no changes in behaviour.

We don't currently use these particular returned keypresses, so this issue has not been affecting us. But, this PR would allow us to use them in future ofc. :)