bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32281: shr.el align support patch


From: Bad Blue Bull
Subject: bug#32281: shr.el align support patch
Date: Tue, 07 Aug 2018 19:54:58 +0300

07.08.2018, 18:10, "Eli Zaretskii" <address@hidden>:
 From: Bad Blue Bull <address@hidden>
 Cc: "address@hidden" <address@hidden>
 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).

Attachment: test.jpg
Description: JPEG image

Attachment: test_ff.jpg
Description: JPEG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]