all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Bad Blue Bull <ibmbull@yandex.ru>
Cc: npostavs@gmail.com, 32281@debbugs.gnu.org
Subject: bug#32281: shr.el align support patch
Date: Tue, 07 Aug 2018 18:07:50 +0300	[thread overview]
Message-ID: <83bmaeqkop.fsf@gnu.org> (raw)
In-Reply-To: <4760541533603112@sas1-890ba5c2334a.qloud-c.yandex.net> (message from Bad Blue Bull on Tue, 07 Aug 2018 03:51:52 +0300)

> From: Bad Blue Bull <ibmbull@yandex.ru>
> Cc: "32281@debbugs.gnu.org" <32281@debbugs.gnu.org>
> 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.





  parent reply	other threads:[~2018-08-07 15:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-26 14:06 bug#32281: shr.el align support patch Bad Blue Bull
2018-08-06  2:52 ` Noam Postavsky
2018-08-06 15:13   ` Eli Zaretskii
2018-08-07  0:51     ` Bad Blue Bull
2018-08-07  0:59       ` Bad Blue Bull
2018-08-07  2:34       ` Noam Postavsky
2018-08-07 15:07       ` Eli Zaretskii [this message]
2018-08-07 16:54         ` Bad Blue Bull
2018-08-07 17:11           ` Bad Blue Bull
2018-08-07 17:19           ` Eli Zaretskii
2018-08-07 18:15             ` Bad Blue Bull
2018-08-07 18:15       ` Lars Ingebrigtsen
2018-08-07 19:56         ` Bad Blue Bull
2018-08-10  0:12           ` Noam Postavsky
2018-08-06 17:36 ` Noam Postavsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83bmaeqkop.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=32281@debbugs.gnu.org \
    --cc=ibmbull@yandex.ru \
    --cc=npostavs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.