unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Sending multiple patches
@ 2014-06-02  8:35 Michal Nazarewicz
  2014-06-02 13:17 ` Stefan Monnier
  0 siblings, 1 reply; 15+ messages in thread
From: Michal Nazarewicz @ 2014-06-02  8:35 UTC (permalink / raw)
  To: emacs-devel

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--



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Sending multiple patches
  2014-06-02  8:35 Sending multiple patches Michal Nazarewicz
@ 2014-06-02 13:17 ` Stefan Monnier
  2014-06-02 13:24   ` David Kastrup
                     ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Stefan Monnier @ 2014-06-02 13:17 UTC (permalink / raw)
  To: Michal Nazarewicz; +Cc: emacs-devel

> 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 "&nbsp;"?  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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Sending multiple patches
  2014-06-02 13:17 ` Stefan Monnier
@ 2014-06-02 13:24   ` David Kastrup
  2014-06-02 16:15     ` Stefan Monnier
  2014-06-02 15:47   ` Glenn Morris
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 15+ messages in thread
From: David Kastrup @ 2014-06-02 13:24 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Sending multiple patches
  2014-06-02 13:17 ` Stefan Monnier
  2014-06-02 13:24   ` David Kastrup
@ 2014-06-02 15:47   ` Glenn Morris
  2014-06-02 18:33   ` Michal Nazarewicz
  2014-06-02 19:03   ` Michal Nazarewicz
  3 siblings, 0 replies; 15+ messages in thread
From: Glenn Morris @ 2014-06-02 15:47 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Michal Nazarewicz, emacs-devel

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.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Sending multiple patches
  2014-06-02 13:24   ` David Kastrup
@ 2014-06-02 16:15     ` Stefan Monnier
  2014-06-02 17:58       ` Yuri Khan
  0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2014-06-02 16:15 UTC (permalink / raw)
  To: David Kastrup; +Cc: emacs-devel

> 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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Sending multiple patches
  2014-06-02 16:15     ` Stefan Monnier
@ 2014-06-02 17:58       ` Yuri Khan
  0 siblings, 0 replies; 15+ messages in thread
From: Yuri Khan @ 2014-06-02 17:58 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: David Kastrup, Emacs developers

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.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Sending multiple patches
  2014-06-02 13:17 ` Stefan Monnier
  2014-06-02 13:24   ` David Kastrup
  2014-06-02 15:47   ` Glenn Morris
@ 2014-06-02 18:33   ` Michal Nazarewicz
  2014-06-02 19:11     ` Stefan Monnier
  2014-06-02 19:03   ` Michal Nazarewicz
  3 siblings, 1 reply; 15+ messages in thread
From: Michal Nazarewicz @ 2014-06-02 18:33 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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--



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Sending multiple patches
  2014-06-02 13:17 ` Stefan Monnier
                     ` (2 preceding siblings ...)
  2014-06-02 18:33   ` Michal Nazarewicz
@ 2014-06-02 19:03   ` Michal Nazarewicz
  2014-06-03  0:00     ` Stefan Monnier
  3 siblings, 1 reply; 15+ messages in thread
From: Michal Nazarewicz @ 2014-06-02 19:03 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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--



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Sending multiple patches
  2014-06-02 18:33   ` Michal Nazarewicz
@ 2014-06-02 19:11     ` Stefan Monnier
  2014-06-03  6:28       ` Michal Nazarewicz
  0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2014-06-02 19:11 UTC (permalink / raw)
  To: Michal Nazarewicz; +Cc: emacs-devel

> 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 &#160; instead of
&nbsp; 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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Sending multiple patches
  2014-06-02 19:03   ` Michal Nazarewicz
@ 2014-06-03  0:00     ` Stefan Monnier
  0 siblings, 0 replies; 15+ messages in thread
From: Stefan Monnier @ 2014-06-03  0:00 UTC (permalink / raw)
  To: Michal Nazarewicz; +Cc: emacs-devel

> 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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Sending multiple patches
  2014-06-02 19:11     ` Stefan Monnier
@ 2014-06-03  6:28       ` Michal Nazarewicz
  2014-06-03 13:25         ` Stefan Monnier
  2014-06-07 15:05         ` Herring, Davis
  0 siblings, 2 replies; 15+ messages in thread
From: Michal Nazarewicz @ 2014-06-03  6:28 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

>> 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 &#160; instead of
> &nbsp; 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--



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Sending multiple patches
  2014-06-03  6:28       ` Michal Nazarewicz
@ 2014-06-03 13:25         ` Stefan Monnier
  2014-06-07 17:28           ` Michal Nazarewicz
  2014-06-07 15:05         ` Herring, Davis
  1 sibling, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2014-06-03 13:25 UTC (permalink / raw)
  To: Michal Nazarewicz; +Cc: emacs-devel

> 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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* RE: Sending multiple patches
  2014-06-03  6:28       ` Michal Nazarewicz
  2014-06-03 13:25         ` Stefan Monnier
@ 2014-06-07 15:05         ` Herring, Davis
  1 sibling, 0 replies; 15+ messages in thread
From: Herring, Davis @ 2014-06-07 15:05 UTC (permalink / raw)
  To: Michal Nazarewicz, Stefan Monnier; +Cc: emacs-devel@gnu.org

>     ("<! *\\(--\\|==\\)" . (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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Sending multiple patches
  2014-06-03 13:25         ` Stefan Monnier
@ 2014-06-07 17:28           ` Michal Nazarewicz
  2014-06-08  1:26             ` Stefan Monnier
  0 siblings, 1 reply; 15+ messages in thread
From: Michal Nazarewicz @ 2014-06-07 17:28 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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--



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Sending multiple patches
  2014-06-07 17:28           ` Michal Nazarewicz
@ 2014-06-08  1:26             ` Stefan Monnier
  0 siblings, 0 replies; 15+ messages in thread
From: Stefan Monnier @ 2014-06-08  1:26 UTC (permalink / raw)
  To: Michal Nazarewicz; +Cc: emacs-devel

>   (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



^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2014-06-08  1:26 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-02  8:35 Sending multiple patches Michal Nazarewicz
2014-06-02 13:17 ` Stefan Monnier
2014-06-02 13:24   ` David Kastrup
2014-06-02 16:15     ` Stefan Monnier
2014-06-02 17:58       ` Yuri Khan
2014-06-02 15:47   ` Glenn Morris
2014-06-02 18:33   ` Michal Nazarewicz
2014-06-02 19:11     ` Stefan Monnier
2014-06-03  6:28       ` Michal Nazarewicz
2014-06-03 13:25         ` Stefan Monnier
2014-06-07 17:28           ` Michal Nazarewicz
2014-06-08  1:26             ` Stefan Monnier
2014-06-07 15:05         ` Herring, Davis
2014-06-02 19:03   ` Michal Nazarewicz
2014-06-03  0:00     ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).