freenode/#clim - IRC Chatlog
Search
10:08:09
jackdaniel
we need to call finish-output on seos after display, is (redisplay-frame-pane :after) method the right place to issue that?
10:11:30
jackdaniel
I think not, method and qualifier is correct, but not specialization. seos is not a pane-display-mixin
10:24:24
jackdaniel
Wow, :WRAP end-of-page-action seems useless. I can't think of a single practical purpose of it. Maybe it should clean the viewport? Then it would be a "modulo" output sort of thing
10:40:46
jackdaniel
previous find-split function was looking at text-size character by character with an annotation (comment) that it could be done smarter
10:48:45
loke
jackdaniel: Coudl end-of-page action be a throwback to the behaviour of things like ITS?
10:54:01
loke
WHen you log in to an ITS terminal, you can configure the end-of-page behaviour. You can use either scroll (which is how a regular terminal works), or clear whch pauses output until you press a key and then clears the screen.
10:54:50
jackdaniel
loke: I have suggested that as more useful behavior indeed: "maybe it should clean the viewport"
10:55:33
jackdaniel
but yes, that would be more useful behavior and given a historical perspective it makes even more sense
10:56:18
loke
Yes. It was your comment to clearing that reminded me on ITS behaviour (also, MVS (Z/OS these days) works the same way.
10:56:43
jackdaniel
another interpretation (which has a little sense) is vertical text, so you wrap vertically and start in a second "vertical line"
12:37:56
jdz
jackdaniel: Pretty sure you could keep record of calculated widths when midpoint is moving to the right.
12:40:07
jackdaniel
due to kerning "foo bar qux" length is not the same as sum of "fo" "o b" "ar qux"
12:41:56
jdz
My other idea was to approximate split point using some average glyph width (like ems in CSS).
12:44:30
jdz
Also when keeping record of pre-calculated width one could do that at some well-known non-kerned places (like whitespace).
12:48:19
jdz
What I meant was that first you calculate split point (bisection or prediction), and then find the nearest point where it would be safe to split without fear of invalid calculations (due to e.g. kerning).
12:48:39
jackdaniel
(in honesty I think that iterating over string was good enough, I've just succumbed to my microoptimization urges :-)
12:50:32
jackdaniel
so this second approach of yours is basically bisecting with calculated section point (not exactly 1/2)?
12:51:43
jdz
Yes. And in addition to that, adjusting the point to a safe spot, and keeping the calculated result is not good enough.
12:53:16
jackdaniel
OK, now I understand it a bit better (still not clearly though) - i.e what is a safe spot, how do yo udetermine it?
12:53:18
jdz
I mean, if we know that on average a character takes 5 units, and we have 60 units space, and the string is 100 characters long, we'd first try to split at 12 characters.
12:55:02
jdz
And then, if the 12 characters only give us 53 units, and we assume that the width of the 12 character string will not change (hence safe spot), we can now deal with filling 7 units with the rest of the string.
12:55:31
jackdaniel
currently text-style-width returns width of #\m in a medium font (which is nearing the widest characters, not average), but it could be repurposed, because wording in the spec is: "The width of a font is the width of some representative character in the font."
12:55:52
jdz
If the 12 characters give us more than 60 units, we might adjust the predicted character width, and try again.
12:56:22
jackdaniel
OK, so by safe spots you mean bisection boundaries which are already confirmed to meet the criterium
13:00:19
jdz
Could it be worthwhile first splitting string into words? I'd figure this would come in handy when resizing (continuously) a window.
13:08:24
jackdaniel
regarding continously resizing a window: if you want wrapping to change you'd need to redisplay pane (not repaint)
13:10:06
jackdaniel
I think that making adjustable-on-repaint-text-output-records is not impossible, but that would be a non-trivial task being a whole feature (and not a simple fix / improvement)
13:11:29
jackdaniel
I don't want to send too big batches in hope they'll get better peer review that way
14:04:43
loke
I split by word first, and deal with those. Also, I word-wrap at presentation boundaries as well.
14:06:09
loke
The main problem is that CL-UNICODE doesn't implement a way to look up the word-wrap class for characters, so first I need to submit a patch to cl-unicode that allows that.
14:58:18
mgiraud
having a look at drawing-tests, i don't understand why everything is done in a pattern (and then draw-pattern* is called) for the render backend while in the standard backend everything is drawn to the output
16:04:46
Inline
uhuh, my changes seem to have also deleted the window-splitting thing somehow, oh man
16:12:49
Inline
i started and restarted my sbcl several times and in between also deleted the whole fasl cache directory
17:39:52
jackdaniel
now that I have word wrap and other bugs sorted out I'm tempted to split lines by word with minimum raggedness
18:19:33
Inline
maybe a drawing application which draws randomly in space without regards to being in finite space area ?
19:05:10
jackdaniel
Inline: if you found a seemingly correct solution please make a pull request. also please include detailed steps how to reproduce the issue from empty lisp image
19:10:23
Inline
i just changed my Apps/Listener/listener.lisp s class definition to use :end-of-line-action :wrap in the pane definition fields
19:23:47
Inline
and also, what should be my model, i don't want to fork, so i suppose i'd have to use share based pull request
19:43:26
Inline
so i can view the difference between local and remote master vie git diff, but how would i push my changes ? all at once ?
19:44:19
Inline
like i told i'm pretty new to git actually, and i don't have the workflow/routine with it
21:21:45
jackdaniel
Inline: thank you. I've reviewed your PR – you need to clean it up from unnecessary changes, fix indentation and split separate changes into commits with commit messages which describe why the change was made (what was wrong and how it addresses the issue)