-
Notifications
You must be signed in to change notification settings - Fork 251
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
Simplify specifying the new position after multline text #343
Comments
On closer inspection, it's even worse than I first thought, since
And no, a non-true value doesn't necessarily indicate no line jump. This conflicts with reusing |
Thank you for opening this reflection @gmischler One important thing to keep in mind is backward compatibility. Also, the default behaviour (without I think you are right, API clarity could be improved here, and I'm open to deprecating the |
No doubt about either of those.
"End of..." is a helpful concept! But maybe Do you think we can get away with just one new parameter? After all, we have two directions to deal with: Horizontally (
Vertically (
I'm just brainstorming right now, so some of those may not have much practical value... Or are you actually suggesting to turn the |
If we want to support all combinations of the values for |
Build it and they will come! 😉 I'm trying to think about the most easily accessible and understandable API at the moment. |
No they don't cost much :) It's all about ease of use I think. |
Along the same lines... I see that |
Seems OK with me if |
When having a closer look at how to best adapt
.write()
to the new line wrapping code (per #340), I ended up struggling a bit with the concept behind theln=#
parameter to both.multicell()
and.write()
, and now also._render_styled_cell_text()
. Judging by its name, I suspect that originally it was only meant as aTrue/False
value to indicate wether the position should move to a new line. Later it seems to have been increasingly overloaded to also indicate horizontal movement (or maybe it was badly designed right from the start, who knows...) Either way, using an arbitrary single numerical value to indicate movement choices in both x and y is rather confusing and unintuitive.To improve the clarity of the API and also simplify maintenance, I think it would make sense to seperate the two functionalities. The simplest way is probably to introduce a seperate argument
new_xpos=""
, with a single character value choice of"L|R|S|E"
, for Left/Right of the requested cell extents, or Start/End of the actual text rendered.The
ln=
parameter could then again be reduced to aTrue|False
choice of moving to a new line or not, ideally with a deprecation warning for other uses.Any thoughts? Better names for the new parameter?
The text was updated successfully, but these errors were encountered: