Sending multiple patches

Sending multiple patches

[Michal Nazarewicz]

Hi,

I'm preparing a few changes to tildify.el which at the moment consist of
four separate commits (and there are at least two more to come).  I am
a bit unsure how such a change should be sent to the list.  Will
a threaded messages to bug-gnu-emacs@gnu.org do?  Should I send a git
pull request?

By the way, the aforementioned code is at:

    git pull git://github.com/mina86/emacs tildify

    https://github.com/mina86/emacs/tree/tildify

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +--<mpn@google.com>--<xmpp:mina86@jabber.org>--ooO--(_)--Ooo--

Re: Sending multiple patches

[Stefan Monnier]

> Will a threaded messages to bug-gnu-emacs@gnu.org do?

I think currently this would generate N distinct bug numbers (tho I seem
to remember that Glenn implemented some kind of Message-ID/In-Reply-To
based system to try and correct this, so maybe it'll work).

But you can send a first message to bug-gnu-emacs@gnu.org and then send
threaded messages to the corresponding NNN@debbugs.gnu.org address.

> Should I send a git pull request?

Since we use Bzr, that wouldn't help very much.

> By the way, the aforementioned code is at:
>     https://github.com/mina86/emacs/tree/tildify

The patches look OK, feel free to commit (adjusting the commit comments
to the ChangeLog formatting convention, of course).
Some comments that came up while reading the patches:
- "TeX-commnad" -> "TeX-command".
- "can be arbitrary character" -> "can be an arbitrary character".
- "hnadled" -> "handled".
- XML doesn't define " "?  Really?  So when is it defined?
  I know very little about SG/XML, but I'd love to hear the full story.
- Rather than ("end-" 1), tildify-ignored-environments-alist should
  probably just use "end-\\1" so it can just use `replace-match'.
- The settings in tildify-ignored-environments-alist should probably be
  moved to a buffer-local var set in the respective major modes.


        Stefan

Re: Sending multiple patches

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> - XML doesn't define "&nbsp;"?  Really?  So when is it defined?
>   I know very little about SG/XML, but I'd love to hear the full
>   story.

XML has only five predefined entities:

    &lt; represents "<"
    &gt; represents ">"
    &amp; represents "&"
    &apos; represents '
    &quot; represents "

You can use &#xa0; namely a numeric character reference to refer to
HTML's &nbsp; if you want to.

-- 
David Kastrup

Re: Sending multiple patches

[Glenn Morris]

Stefan Monnier wrote:

>> Will a threaded messages to bug-gnu-emacs@gnu.org do?
>
> I think currently this would generate N distinct bug numbers

Yes, it probably would. See http://debbugs.gnu.org/15361

> (tho I seem to remember that Glenn implemented some kind of
> Message-ID/In-Reply-To based system to try and correct this, so maybe
> it'll work).

I did implement that, but while it works ok for "normal" email
conversations, it doesn't for git send-email, as explained in the above
bug.

> But you can send a first message to bug-gnu-emacs@gnu.org and then send
> threaded messages to the corresponding NNN@debbugs.gnu.org address.

Yes, that is what I would recommend.

Re: Sending multiple patches

[Stefan Monnier]

> XML has only five predefined entities:
>     &lt; represents "<"
>     &gt; represents ">"
>     &amp; represents "&"
>     &apos; represents '
>     &quot; represents "

Hmm... so the rest is only available depending on the particular schema
in use?

> You can use &#xa0; namely a numeric character reference to refer to
> HTML's &nbsp; if you want to.

And the code is Unicode, right?


        Stefan

Re: Sending multiple patches

[Yuri Khan]

On Mon, Jun 2, 2014 at 11:15 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> XML has only five predefined entities:
>>     &lt; represents "<"
>>     &gt; represents ">"
>>     &amp; represents "&"
>>     &apos; represents '
>>     &quot; represents "
>
> Hmm... so the rest is only available depending on the particular schema
> in use?

DTDs (not schemas) can define more entities. XHTML, for example,
defines all the entities HTML does.
http://www.w3.org/TR/xhtml1/dtds.html#h-A2

>> You can use &#xa0; namely a numeric character reference to refer to
>> HTML's &nbsp; if you want to.
>
> And the code is Unicode, right?

Of course.

Alternatively, &#xa0; can also be spelled &#160; — in decimal.

Re: Sending multiple patches

[Michal Nazarewicz]

On Mon, Jun 02 2014, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> But you can send a first message to bug-gnu-emacs@gnu.org and then send
> threaded messages to the corresponding NNN@debbugs.gnu.org address.

I'll do that then once I get the final version of the patches.

> - XML doesn't define "&nbsp;"?  Really?  So when is it defined?
>   I know very little about SG/XML, but I'd love to hear the full
>   story.

HTML defines a whole bunch of entities, full list at [2], including
nbsp.  XML, which formally has no relation to HTML (in the sense that
those are separate standards, one not referring to the other), defines
only a handful of entities listed at [1] (namely lt, gt, amp, apos and
quot meaning <, >, &, ' and " respectively).

On the other hand, XHTML 1.x, which is a format built on top of XML,
defines the same entities as HTML -- which is mentioned at [3] -- but
I have encountered problems with some browsers (no, I don't mean IE)
when &#nbsp; was used in an XHTML document.

As for SGML I don't know the full story to be honest.  I'm not really
sure what SGML *is*, but if I'm not mistaken, an SGML document in itself
does not define any entities, so technically a numeric reference should
probably be used for it as well.

I did not change the hard space character for SGML because of my
ignorance.  I'm not sure of use cases and what kind of documents people
edit with sgml-mode, so I decided to leave it as it.

The simplest would probably be to change the entity to numeric one even
in HTML, but I'm not sure if users would like it.

[1] http://www.w3.org/TR/REC-xml/#sec-predefined-ent
[2] http://www.w3.org/TR/html401/sgml/entities.html#h-24.2.1
[3] http://www.w3.org/TR/xhtml1/#h-A2

> - Rather than ("end-" 1), tildify-ignored-environments-alist should
>   probably just use "end-\\1" so it can just use `replace-match'.

Good idea.  Do you think it'd be acceptable to completely drop support
for “("end-" 1)” and change the meaning of strings to be processed by
`replace-mach'?  It would greatly simplify the code and I don't expect
many people customising `tildify-ignored-environments-alist' much, so
I would go for it myself.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +--<mpn@google.com>--<xmpp:mina86@jabber.org>--ooO--(_)--Ooo--

Re: Sending multiple patches

[Michal Nazarewicz]

On Mon, Jun 02 2014, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> - Rather than ("end-" 1), tildify-ignored-environments-alist should
>   probably just use "end-\\1" so it can just use `replace-match'.

I started implementing this which is when I realised that "end-\\1"
won't cut it because contents of the matched capture group must be
escaped with `regexp-quote'.  For example, if we had:

    ("verb\\(.\\)" . "\\1")

and a buffer had:

    verb\foo\

the end-regex for “verb\” would become just a single back-slash,
i.e. not a valid regex.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +--<mpn@google.com>--<xmpp:mina86@jabber.org>--ooO--(_)--Ooo--

Re: Sending multiple patches

[Stefan Monnier]

> The simplest would probably be to change the entity to numeric one even
> in HTML, but I'm not sure if users would like it.

Indeed, I for one would be very disappointed to see   instead of
  there.  Of course, I'd even prefer seeing " ".

>> - Rather than ("end-" 1), tildify-ignored-environments-alist should
>> probably just use "end-\\1" so it can just use `replace-match'.
> Good idea.  Do you think it'd be acceptable to completely drop support
> for “("end-" 1)” and change the meaning of strings to be processed by
> `replace-mach'?

For the major-mode-set buffer-local variable, there'd be no backward
compatibility issue, of course.

> It would greatly simplify the code and I don't expect many people
> customising `tildify-ignored-environments-alist' much, so I would go
> for it myself.

You can give it a try, and see if someone screams.


        Stefan

Re: Sending multiple patches

[Stefan Monnier]

> I started implementing this which is when I realised that "end-\\1"
> won't cut it because contents of the matched capture group must be
> escaped with `regexp-quote'.  For example, if we had:

AFAICT, you can regexp-quote the whole result.


        Stefan

Re: Sending multiple patches

[Michal Nazarewicz]

>> The simplest would probably be to change the entity to numeric one even
>> in HTML, but I'm not sure if users would like it.

On Mon, Jun 02 2014, Stefan Monnier wrote:
> Indeed, I for one would be very disappointed to see   instead of
>   there.  Of course, I'd even prefer seeing " ".

Agreed, but that could create encoding issues for some users, therefore
I think it's better to leave it as entity reference and let users change
it to the non-break space character themselves.

>> I started implementing this which is when I realised that "end-\\1"
>> won't cut it because contents of the matched capture group must be
>> escaped with `regexp-quote'.  For example, if we had:

On Mon, Jun 02 2014, Stefan Monnier wrote:
> AFAICT, you can regexp-quote the whole result.

Unfortunately that is not the case.  For example, imagine a hypothetical
language where comments can be written as “<!-- … -->” or “<!== … ==>”
with optional spaces like in HTML.  Regex pair to match it would be:

    ("<! *\\(--\\|==\\)" . (1 " *>"))

If the code was changed so that the whole end-pattern is regexp-quote'd,
the asterisk would get escaped.

>> Good idea.  Do you think it'd be acceptable to completely drop support
>> for “("end-" 1)” and change the meaning of strings to be processed by
>> `replace-mach'?

> For the major-mode-set buffer-local variable, there'd be no backward
> compatibility issue, of course.

Let's leave it as is for now then, and bundle both changes together in
some way.

Do you think that adding Perl's \Q…\E support to `replace-match' would
make sense? For instance, we could than have:

    ("verb\\(.\\)" . "\\E\\1\\Q")

Or is tildify.el to small of a user to justify fiddling with
`replace-match'?

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +--<mpn@google.com>--<xmpp:mina86@jabber.org>--ooO--(_)--Ooo--

Re: Sending multiple patches

[Stefan Monnier]

> Unfortunately that is not the case.  For example, imagine a hypothetical
                                                              ^^^^^^^^^^^^
As you say, it's hypothetical.

AFAICT, there's currently no actual use of regular expressions in the
"end pattern", so we very much can regexp-quote the whole thing (or
alternatively search it via search-forward instead of
re-search-forward).  If/when a need for something more flexible comes
up, we can allow the use of "a function returning a regexp" or maybe
even better "a function that jumps to the end" instead of a string.

> Do you think that adding Perl's \Q…\E support to `replace-match' would
> make sense?

No.  This would naturally lead to adding support for other operations
than regexp-quote, and then you end up quoting chunks of code inside
strings which is not only ugly but can't be macroexpanded, can't refer
to lexical-scoped vars, can't be byte-compiled, ...

If useful, we could extend replace-match such that NEWTEXT can be
a function instead of a string.  That should be easy and clean.


        Stefan

RE: Sending multiple patches

[Herring, Davis]

>     ("<! *\\(--\\|==\\)" . (1 " *>"))
> 
> If the code was changed so that the whole end-pattern is regexp-quote'd,
> the asterisk would get escaped.

(What we really want here is a "backreference to another match".)  If `store-match-data' is sufficiently tolerant of the deception, there is the possibility of a fairly complicated dance of `match-data', `replace-match', `regexp-quote', and `store-match-data' to quote exactly the submatches in the replacement.  (Is there a function to compute, rather than apply, a replacement?  That would cut down on the circuitousness...)

Davis

Re: Sending multiple patches

[Michal Nazarewicz]

On Tue, Jun 03 2014, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> If useful, we could extend replace-match such that NEWTEXT can be
> a function instead of a string.  That should be easy and clean.

I don't think that would be useful to be honest.  However, what I think
would help is to let STRING be a function which would be called for
every \N in the NEWTEXT.  tildify would then use it as:

  (replace-match end-re-fmt t nil
                 (lambda (num) (regexp-quote (match-string num string))))

end-re-fmt would be a format of a environment end regex such as
"end-\\1", and string would be the text matched by environment open
regex.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +--<mpn@google.com>--<xmpp:mina86@jabber.org>--ooO--(_)--Ooo--

Re: Sending multiple patches

[Stefan Monnier]

>   (replace-match end-re-fmt t nil
>                  (lambda (num) (regexp-quote (match-string num string))))

Actually, rather than replace-match we'd want
match-substitute-replacement for tildify (since we don't want to keep
the surrounding context), in any case.  But yes the above might make
sense.


        Stefan