triple quote patch

Here's my (untested) stab at making this patch work against the latest version. Note that this won't
byte compile under XEmacs which lacks a string-to-syntax function.

Ack... That patch appears to be riddled with GNU Emacs-specific stuff. Here's an updated patch with another
fix or two for XEmacs, but this is far from workable with XEmacs as far as I can tell.

That patch is basically my code. It's licensed (only) under the GPL,
so distributing it like this infringes the FSF's copyright.

Please respect the licence.

I'm sorry if I infringed your copyright. The patch was sent without any comment whatsoever, no name, no license, on the mailinglist already. So I just put it here for better tracking.

Where is it offered including a proper license, so that we confirm it's origin?

As python-mode is PSF-licensed, I guess it then can't be included.

python-mode.el isn't really psf licensed, but it's not technically gpl'd either, though it could be. The original author (Tim), and I have both assigned our changes to the FSF in the past, which would cover the majority of the code. I think Skip has tried repeatedly to assign his changes, and I think Ken has assigned his changed.

We could re-release python-mode.el with a GPLv3 license. Would that solve your problem?

Barry Warsaw <email address hidden> writes:

> python-mode.el isn't really psf licensed, but it's not technically gpl'd
> either,

It just isn't GPL'd or PSF-licensed, though probably it should be GPL'd
since it's already taken code from Emacs which is probably
copyright-significant -- at least some of it is still there. The
python-mode.el licence is a simple permissive one, compatible with the
GPL, so it can be distributed under the GPL. However, if it was
distributed that way, you still can't, for instance, strip the
`appropriate copyright notices' from GPL'd code.

> though it could be. The original author (Tim), and I have both
> assigned our changes to the FSF in the past,

The FSF has no papers from you for python-mode.el. We tried several
times, but when I corresponded with you about it, it turned out to
actually need papers from your (then or former?) employer. You either
couldn't get those, or were unlikely to, so I gave up. (There is an old
assignment from Tim Peters listed, but not from anyone else, although
other contributors may have Emacs blanket assignments.)

> which would cover the majority of the code.

The majority isn't good enough, though. It's also not clear that
there's a decent change history to figure out other contributions
anyway. That's the problem I faced merging potentially-assigned code
from XEmacs and Gnus, amongst others. It's typically easier to
re-write.

> We could re-release python-mode.el with a GPLv3 license. Would that
> solve your problem?

I don't have a problem to solve here, but anyone distributing code
contrary to the licence does. Obviously anyone can incorporate Emacs
code into a GPL3'd file, as long as they don't strip copyright notices,
for instance.

Common sense says distributing patches without an explicit licence is
normally fine -- with the implication that they're under the licence of
the patched code. You can't generally do that with someone else's
material under a different licence to what you're patching, and you need
to consider patching copyright notices appropriately.

[I'm trying to spell some of this out for anyone reading who doesn't,
for instance, maintain a GNU package as I think Barry does.]

I think it is the same issue as reported by Debian users in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=328894

hence I am very eager to see any progress on getting it resolved ;)

Hi,

I see that Barry has released 5.1 and this resolves a number of Triple Quoting issues.

Syntax highlighting works correctly for the following text:

"""
""
"""

If a quote is placed on the second line

"""
" ' "
"""

between the inner two double quotes then the syntax highlighting is incorrect.

This is also the case if the outer triple quotes are single quotes.

python.el in emacs 22 highlights the syntax correctly.

I first noted the bug in the dbapi20.py file which is a file containing a testsuite for
DB-API compliant drivers

Thanks for all your work on python-mode.

Tom

I reopened this bug report. The current stable version of XEmacs (21.4.22)
does not have a string-to-syntax function. This needs to be fixed ASAP, since
the 5.2.0 release includes this problematic function in several places.

Here's a putative patch which pulls the string-to-syntax code out into a minimalist implementation
of that function for XEmacs.

Hi Skip,

could you please write a separate bug-report so I may see, why the XEmacs fails.

AFAIS string-to-syntax is exclusively employed at three places in forms like

(if (featurep 'xemacs)
                '(15)
            (eval-when-compile (string-to-syntax "|")))

So XEmacs should not see it.

    Andreas> could you please write a separate bug-report so I may
    Andreas> see, why the XEmacs fails.

It fails during byte-compile-file. Doesn't write a .elc file.

I've already backed out the latest release because it fails completely
because of the syntax-ppss stuff. I have work to do, so I'm not going to
mess with this any more today.

Skip

Am 09.01.2011 20:02, schrieb Skip Montanaro:
>
> Andreas> could you please write a separate bug-report so I may
> Andreas> see, why the XEmacs fails.
>
> It fails during byte-compile-file. Doesn't write a .elc file.

Yes, get this error too. Also your fix works for me with both Emacsen.
I'll make a new branch.

BTW think we should keep Emacs and XEmacs bugs apart:

If a bug reported for one of them it should be closed if fixed there.
If a related bug in other flavor is detected, it deserves a separate
opening/closing IMHO.

Andreas

>
> I've already backed out the latest release because it fails completely
> because of the syntax-ppss stuff. I have work to do, so I'm not going to
> mess with this any more today.
>
> Skip
>