-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wired justify in bindings with map on the left #273
Comments
I'm not entirely sure just what you find odd in these examples, but your red boxes certainly give me some clues. If I've guessed wrong, please ask me again. In the first example, the map is indeed justified, but the The second example seemed complex to me until I broke it down a bit, but at least what I see as odd is a result of an interaction between
You can see that the three let locals are justified. Here it is with everything above, and
You can see that the second local has In any case, I hope that this clears up and explains the oddities that you noticed in the output. If not please ask again! Thanks! |
Thanks for your detailed explanation. There's a feature in
Here's a thread with video showing the behavior status-im/status-mobile#14128 (comment) What do you think about this behavior? |
Does this mean there's no justify in bindings that with at least one multiline left-hand thing? |
I'm looking again at this issue, and with the current code when I run the second example I gave, above, it is different in that it doesn't justify the That said, I looked at the conversation that you pointed me at, above, with the videos and the back and forth between you and someone else. It took me a while to figure out what was going on, but I think I understand at least the blank line bit, where justification is broken up into segments separated by blank lines. Which isn't something I had ever thought of since I don't use blank lines. zprint is pretty interested in getting the maximum amount of readable code into the minimum of vertical space, and blank lines don't help that. But I can see the appeal of grouping by blank lines. However, you clearly are interested in justification, and from looking at your code base as much as I have (which is, sigh, quite a bit), I can see why. Justification makes a lot of things look a lot clearer. I'm thinking of offering more control over justification. It looks like the "don't justify unless it is "better" than not justifying" approach that zprint currently takes isn't something that is appreciated in your environment. I think that you would like zprint to justify (or not) based on your configuration of zprint, but not decide in real-time whether justification is "better" than not justifying in every group of pairs. So, the changes I'm contemplating (without yet knowing how easy or even possible they might be to implement):
Those are the things that I'm planning to look into. I'm interested in your input in several areas:
Thanks! |
Wow, thanks for your patience reading all the discussions
This is like
Yes, absolutely!
You mean exceeds the
Don't quite understand what does this mean. Do you mean to refocus on all code included in parent level and try find ways to reduce the occupied columns?
If the answer of (1) and (2) is yes. Both ( (2) and (3) ) are reasonable solutions to me. But I think (1) might be a better choice for all zprint users. |
Got 4 videos for this one, based on the
Video1CleanShot.2022-11-10.at.12.02.49.mp4Video 2CleanShot.2022-11-10.at.12.03.11.mp4Video 3CleanShot.2022-11-10.at.12.04.56.mp4Video 4CleanShot.2022-11-10.at.12.05.27.mp4 |
Thanks for your quick response. I'm not sure I'm getting all of the information that you are sending with the videos, but I'm certainly trying! First, when I said "a pair simply doesn't fit for justification", yes I meant within the width. Like the left hand side is just too big to leave any room on the right for anything. Or, perhaps the left hand side fits, but barely, leaving the right hand side very little room -- so that if you justify the pair, the right hand side runs on and on down the side, with mostly just one thing on each line, which can look pretty bad. I see places in the videos (after they are finished) where the right hand side is on the next line (flowed, in zprint terminology) even though other contiguous things are justified (and there are no blank lines). Typically Here is an interesting one. The first one is ok, but not great, in that
I'll get back to you once I prototype some of these changes and see what I can (and can't) do. Thanks again for your feedback. |
Hi, just spend some time to go over this issue again. I think the issue
Back off is definitely better since one of the main goal of using zprint
Summary in word would be
|
After a bit of time away, I'm still working through the complexities of this situation. I am definitely up for having justification work when there is a multi-line left hand form. Thanks for asking for that. Prior to this issue, I've not see a lot of examples of that situation, but I agree it looks a lot better. When prototyping that, I found that the justification is pretty sad when there is no pressure to squeeze a multi-line left hand form into something narrower than the entire remaining width. So I've been experimenting with narrowing the apparent Anyway, I have hacked together some code that formats one of your examples like this:
I haven't yet even begun to clean up the code to qualify this as a prototype. I'm showing it to you as an example of what I'm working toward making happen, largely to see if this looks like something that would be useful to you. Please let me know, when you have a chance, if this output is interesting or if there is something that you find terrible about it. Nothing is more painful for me than to spend a lot of time polishing up a feature just to have the folks which prompted the work to not use it. One thing that isn't all that obvious in the above example is how I calculate the spacing between the justification. At present I've decided to allow a multi-line left hand form to overflow to the right of the justification column for the right hand side things. You can see that in Below is a hacked up version of your example where there is a lot more in the map that extends to the right.
I shortened the map and put some larger right hand side thing in it. It still seems reasonable to me, since if I forced the whole map into the narrower width for the justification, it would be quite a bit longer. I quickly hacked in some code to see what that would look like. Below is an example of restricting the map from overflowing to the right on the lines that are not the last line. It caused the map to not justify at all, which is too bad but not surprising.
At least in this example, the output looks much less desirable to me, but I'm open to an opinion here too. There are a number of configuration and tuning "knobs" I need to add, to say nothing of many other examples I need to try. There is a lot of work left to turn this into something that is generally useful, as opposed to something that makes this particular example look very nice (which I happen to think the first example above does). I will continue to pursue finishing this, and am interested in your feedback along the way. Thanks for taking the time to look at this. |
The first example is great! One question about it, it will be possible to turn the On my side, several people in my org asked me about the progress of integrating zprint and showed that they can't wait no more. The blockers on my side is
My plan is
|
Thanks for the feedback. I'm glad the first example looked good to you, it did to me too. Yes, the I'm sorry that zprint isn't all ready for your group yet, but the format twice problem was quite a challenge, and this one too is causing some major rethinking on how the various tuning parameters are configured. I think that your plan is reasonable, since I don't have a quick fix for the format twice problem. I'm still pushing to get the next release out before year end. Regarding Cursive, if there is a way to export a file and re-import it then zprint can fit into that workflow. In a quick perusal of the Cursive documentation, I don't actually see any way to do that, so I looked in the IntelliJ docs, and didn't see a way to do that there either. Which was kind of surprising, because most editors historically have allowed piping part of or all of a buffer through an external "filter" (in the Unix parlance) and replacing the text piped through the filter with the resulting output of the filter. For what it is worth, I know of a VSCode extension that integrates zprint with VSCode, but it tends to lag the version of zprint by a bit. I collaborated with the author on that extension, and I think it actually works very nicely. If that is interesting to you, let me know and I'll encourage the author to update as soon as I finish the next zprint release. Anyway, thanks for your patience. I'll let you know when I have finished the release. |
Release Here is an example (notably w/out
Here is an even better version, with a little different tuning:
From the
I would suggest that you try it without Please respond with questions about these capabilities, as I'm sure I haven't explained them very well. I've been so deep in it for so long that I have probably lost sight of what you really need to know to use them. I've been pushing to get this release out for a long time! |
Thanks! Will try. |
To address issue described in: kkinnear/zprint#273 Signed-off-by: Jakub Sokołowski <jakub@status.im>
To address issue described in: kkinnear/zprint#273 Signed-off-by: Jakub Sokołowski <jakub@status.im>
To address issue described in: kkinnear/zprint#273 Signed-off-by: Jakub Sokołowski <jakub@status.im>
To address issue described in: kkinnear/zprint#273 Signed-off-by: Jakub Sokołowski <jakub@status.im>
To address issue described in: kkinnear/zprint#273 Signed-off-by: Jakub Sokołowski <jakub@status.im>
* nix: upgrade zprint from 1.2.4 to 1.2.5 To address issue described in: kkinnear/zprint#273 Signed-off-by: Jakub Sokołowski <jakub@status.im> * chore: use zprint :multi-lhs-hang * refactor: re-format clojure using zprint 1.2.5 --------- Signed-off-by: Jakub Sokołowski <jakub@status.im> Co-authored-by: yqrashawn <namy.19@gmail.com>
I'm going to consider this basically fixed. I created a new issue for "Consider segregating justification domains between blank lines", to capture that part of the request here. |
zprint config status-im/status-mobile@817a249#diff-ad67b6e0a11904cfc29b634bde55f00d9961091fb1d34ccdb98e79cd7c2f4febR1-R49
example 1: status-im/status-mobile@9ba1f28#diff-acc2864028c846a967aae52fa52b23048f98d0b5cee98b2e118047f2dbb52171R58-R137
example 2: status-im/status-mobile@f19bf88#diff-b95d5dad0bb120bacc3d6495349ebec19ed96bd1c2aba6a3c9ad84bc638bb78cR61-R79
The text was updated successfully, but these errors were encountered: