freenode/#clim - IRC Chatlog
Search
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)
22:16:53
Inline
i mean ok you change stuff and commit, so ideally you'd have 1 change per commit or so ?
22:17:35
jackdaniel
commits should represent atomic improvements (by atomic I mean: one commit fixes one thing and can't be divided more without)
22:18:16
Inline
so these conversation threads on which you comment on my changes for example are those all commits ?
22:19:13
jackdaniel
as of number of lines, to day for instance I have changes which count around 250 lines, but it is a very poor way of measuring things
22:19:50
jackdaniel
also often you work whole day towards understanding the problem to change one line
22:20:24
jackdaniel
other times you perform mundane changes which are no brainer (but can't be really automated) and you may get thousands of lines
22:21:17
jackdaniel
conversation you saw on gitlab is a peer review tool which allows commenting on changes