Merging granite patches?

[RedHatter]

So how are we going to go about this? What needs to be done to the patches
to get them ready? How should I go about patches in the future? It's
doubtful that you'll want to merge all the features I'm planing to
implement.

BTW great work on the program, and sorry about thing it was dead.

[Ben Cressey]

Thanks for following up!

For those who don't follow intfiction.org, the relevant patches are here:
https://github.com/RedHatter/granite


Re: your anticipated volume of patches, I would encourage you to err on the
side of submitting them. The UI hasn't been a major area of focus for me
and I'm sure there are many places we can improve, and many convenience
features we can offer to players. It's great that you're interested in
doing that work!


Re: the tab completion patch, I have three issues with the current form:
- There are text buffer implementation details in event.c. Most of that
logic belongs in wintext.c. Anything that touches win->data really belongs
in win{text,grid,gfx}.c, depending on the window type. I'm sure there are
exceptions scattered here and there, but that's the overall goal.

- The tab key is somewhat overloaded with this change, as it's also used to
switch between windows with a pending input request (char or line event).
There aren't too many multi-window games out there, but ideally we'd find
one or two and test to make sure tab could still perform that role. From an
implementation perspective, I'd want tab to retain its window-switching
behavior if used on an empty line.

- keycode_Tab can be returned to the underlying game, so for example
authors can request that the player "press the tab key" and wait on the
keypress. The code can't assume that a text buffer is always waiting for a
line event - it's not always legal to call gcmd_buffer_accept_readline().
By the same token, if you add a tab complete hook to that function, you can
be assured that there's an input line waiting. So that's probably the best
place to address the first concern.

Post by RedHatter
So how are we going to go about this? What needs to be done to the patches
to get them ready? How should I go about patches in the future? It's
doubtful that you'll want to merge all the features I'm planing to
implement.
BTW great work on the program, and sorry about thing it was dead.
--
You received this message because you are subscribed to the Google Groups
"garglk-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/garglk-dev/-/spL8ZxcAGygJ.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/garglk-dev?hl=en.

[RedHatter]

First and third issues fixed by moving tab completion code from
event.c:gli_input_handle_key to wintext.c:gcmd_buffer_accept_readline.

As for the tab key being overloaded, I think it should still work. Pressing
tab when another window has a pending input request should still switch
windows, it will trigger my code but without the user intending to I doubt
it will do anything. Do you know of a game with multiple windows to make
sure of this? We could still test for empty input line, but that would
require accessing dwin from event.c.

How does the click to insert patch look, anything that needs to change?

Post by Ben Cressey
Thanks for following up!
https://github.com/RedHatter/granite
Re: your anticipated volume of patches, I would encourage you to err on
the side of submitting them. The UI hasn't been a major area of focus for
me and I'm sure there are many places we can improve, and many convenience
features we can offer to players. It's great that you're interested in
doing that work!
- There are text buffer implementation details in event.c. Most of that
logic belongs in wintext.c. Anything that touches win->data really belongs
in win{text,grid,gfx}.c, depending on the window type. I'm sure there are
exceptions scattered here and there, but that's the overall goal.
- The tab key is somewhat overloaded with this change, as it's also used
to switch between windows with a pending input request (char or line
event). There aren't too many multi-window games out there, but ideally
we'd find one or two and test to make sure tab could still perform that
role. From an implementation perspective, I'd want tab to retain its
window-switching behavior if used on an empty line.
- keycode_Tab can be returned to the underlying game, so for example
authors can request that the player "press the tab key" and wait on the
keypress. The code can't assume that a text buffer is always waiting for a
line event - it's not always legal to call gcmd_buffer_accept_readline().
By the same token, if you add a tab complete hook to that function, you can
be assured that there's an input line waiting. So that's probably the best
place to address the first concern.

Post by RedHatter
So how are we going to go about this? What needs to be done to the
patches to get them ready? How should I go about patches in the future?
It's doubtful that you'll want to merge all the features I'm planing to
implement.
BTW great work on the program, and sorry about thing it was dead.
--
You received this message because you are subscribed to the Google Groups
"garglk-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/garglk-dev/-/spL8ZxcAGygJ.
.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/garglk-dev?hl=en.