bug#32281: shr.el align support patch

[Noam Postavsky <npostavs@gmail.com>]

Bad Blue Bull <ibmbull@yandex.ru> writes:

>>  The first line of the doc string should not be longer than 78
>>  characters, and should be a complete sentence.
>
> I don't know what do you mean of "complete sentence", docs say it must
> start with a capital letter and end with a period.  First sentence now
> fills 2 lines I know it's not good for apropos, I can edit it again if
> needed.

Yeah, that's all we mean there, the whole sentence (i.e., from capital
letter to period) needs to fit on the first line.

>>  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).
[also quoting clarification from following message]
> This phrase looks confusing, sorry, I meant push-mark can be used for
> this purpose but it's no good.

By "docs warn against it", were you referring to

    Novice Emacs Lisp programmers often try to use the mark for the wrong
    purposes.  See the documentation of ‘set-mark’ for more information.

That's just about using that particular function for non-interactive use
cases.  If it does makes sense to use a mark for this, just don't use
push-mark or set-mark, but rather copy-mark and save the resulting mark
object to a local variable.

> +  (save-excursion
> +   (let ((line-begin) (paragraph-end))
> +	 (forward-paragraph)
> +	 (insert "\x2029") ; use \x2029 (unicode paragraph separator) to mark end
> +					   ; of a paragraph
> +	 (backward-paragraph)
> +	 (setq line-begin (point))
> +	 (while (not paragraph-end)
> +			(re-search-forward bre-regexp)
> +			(if (equal (match-string 0) "\x2029") (setq paragraph-end t))
> +										; end of paragraph reached
> +			(if (or bre-del paragraph-end) (replace-match ""))
> +			(unless (equal (char-after) ?\n) (insert "\n"))
> +										; I don't know why but two adjacent \n
> +										; leave an empty line after fill
> +			(fill-region-as-paragraph line-begin (- (point) 1)
> +			justify)
> +			(setq line-begin (point)))
> +	 (delete-char -1))))

Regarding the indentation, here's what I get after running indent-region
over the above code:

  (save-excursion
    (let ((line-begin) (paragraph-end))
      (forward-paragraph)
      (insert "\x2029") ; use \x2029 (unicode paragraph separator) to mark end
                                        ; of a paragraph
      (backward-paragraph)
      (setq line-begin (point))
      (while (not paragraph-end)
        (re-search-forward bre-regexp)
        (if (equal (match-string 0) "\x2029") (setq paragraph-end t))
                                        ; end of paragraph reached
        (if (or bre-del paragraph-end) (replace-match ""))
        (unless (equal (char-after) ?\n) (insert "\n"))
                                        ; I don't know why but two adjacent \n
                                        ; leave an empty line after fill
        (fill-region-as-paragraph line-begin (- (point) 1)
                                  justify)
        (setq line-begin (point)))
      (delete-char -1)))

Notice especially the difference in the while loop body.  You mentioned
lisp-body-indent, but that only affects indentation increase after a
defun line.  I do see that your indentation after the let seems to be
based on 4-space tabs, but Emacs uses 8-space tabs.  If you could set
indent-tabs-mode to nil (which is what the .dir-locals in the git
repository does), that would take care of it regardless.