Subject: bug#32281: shr.el align support patch

From: Bad Blue Bull <[email-masked]>
Date: Tue, 07 Aug 2018 19:54:58 +0300

07.08.2018, 18:10, "Eli Zaretskii" <[email-masked]>:

From: Bad Blue Bull <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 07 Aug 2018 03:51:52 +0300

Why did you decide to use u+2028 and u+2029 for these purposes? Emacs
doesn't yet support these characters as Unicode intended, so using
them might have unexpected effects, and might produce different effect
if we start supporting them in the future.

I need to use a character to mark places where lines must be split (specified by <br> tags and end of list
items), also a character to mark end of a paragraph to be filled (a mark can be used for this purpose but docs
warn against it). These chars will be removed when a paragraph gets filled, I don't see them cause any trouble
in the future and those values can easily be altered to diffirent ones if it happens.

I'm not sure I understand why you needed a character for that role.
fill-region-as-paragraph accepts buffer positions, and
re-search-forward can be told not to search beyond a certain buffer
position. So you should be able to record the positions in some
variables, and use them instead of inserting characters that need to
be deleted afterwards.

The disadvantage of inserting characters that were not there in the
first place is that if the user types C-g at some unfortunate moment,
these characters might be left in the buffer (unless you complicate
the code by arranging for them to be deleted in that case). Using
buffer positions avoids all those complications.

Am I missing some reason why you needed characters as markers?

Thanks.

I've escaped using of paragraph separator symbol by using narrowing (can't just use constant position as fill-region-as-paragraph will change the text before it and it won't correspond the end of paragraph anymore).

Using a marker symbol to mark line breaks is still necessary, any attempt to avoid it would lead to ridicously complicated solution. Also note that shr-fill-paragraph-with-breaks is a great function that deserves to be inluded into fill.el, for example it allows a user to fill lists without joining lines inside of them (maybe upgrade needed to handle fill-prefix in such case, but still it's a function that can be useful outside of shr.el).

There's a problem found with images inside paragraphs and also tables got broken now that I switched to using narrowing (see pics).

fill-region-as-paragraph disregards fill-collumn when aligns pic, all I can do is not to justify images at all (but I'm really puzzled how to do it, I could use other marker just to determine where image starts and ends and skip that region, but since you're against such approach... )

Justification is badly implemented in fill, it's useless for proportional fonts and you can see it's bad for images too. TBH would be good to make fill.el just ignore justify in such cases (maybe giving a warning message).