Re: [Python-mode] replacing python.el
15 years, 2 months
Andreas Röhler
Barry Warsaw wrote:
> On Feb 1, 2009, at 10:42 AM, Jeff Kowalczyk wrote:
>
>> On Sun, 01 Feb 2009 07:33:15 -0500, Barry Warsaw wrote:
>>> As Andreas pointed out, we have not yet merged his changes into python-
>>> mode.el.
>>>
>>> I had hoped that it would be possible to merge python-mode.el and
>>> python.el and reduce the confusion and inconvenience of Python X/Emacs
>>> users. Andreas's opinion is that that is technically impossible and I
>>> believe it is Dave's opinion that it will be practically impossible
>>> from a legal perspective.
>
>> If Andreas' changes were to remain unmerged, would the merger of
>> python-mode.el and python.el still be regarded as technically and/or
>> legally impossible?
>
> I will defer to Andreas and Bev since they've looked at this issue most
> closely.
>
> Barry
>
Ahh Barry, you are really a wise man. I'm looking
forward for some funny days. :)
Hi Jeff,
we had a lot of traffic around this question last days:
maybe let the course of events giving the answer?
Beverley has declared its interest, from which I expect
in any case knowledge return for all of us.
My interest is compatibility, which can be reached by
different means.
So let's go back to coding and see what comes out. OK?
Andreas Röhler
--
http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/files
https://code.launchpad.net/s-x-emacs-werkstatt/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: replacing python.el
15 years, 2 months
Chong Yidong
Beverley Eyre <fbe2(a)comcast.net> writes:
> From my understanding, no one suggesting cutting and pasting your
> code.
Dave's objection, if I understand it correctly, is precisely the cutting
and pasting of his code:
this all originated when I complained about someone distributing a
chunk of my code with the FSF copyright notice stripped as a patch for
python-mode.el, which was under a simple permissive licence.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: FSF assignment policy
15 years, 2 months
Andreas Röhler
Dave Love wrote:
> Andreas Roehler <andreas.roehler(a)online.de> writes:
>
>> Barry Warsaw wrote:
>
>>> For this audience, I'll restate my position, vis-à-vis python-mode.
>>>
>>> I assert that Tim Peters and myself have assigned copyright in
>>> python-mode.el to the FSF.
>
> For this audience, again: Unfortunately the FSF only has an assignment
> from Tim Peters, and when I tried to get one from Barry some years go,
> the problem was that it needed papers from his employer. (Several of us
> had tried to get full paperwork for python-mode.el, maybe including rms.
> The authorship of all the code wasn't clear at that stage, so it may not
> have been profitable anyway. I've no doubt that Barry wants to DTRT in
> this respect, and I wouldn't have spent the effort on separate code if
> it looked as if we had a reasonable chance of complete paperwork.
IMO assignment policy contradicts the spirit of free software.
It shows very unpleasant damages in mind
already. Copyright is an important issue now, taken
very seriously. Before code was exchanged freely, as
Richard told nicely the very beginnings of the
movement. Meanwhile we came to the opposite: jealously
and meticulous line counting habits.
Assignment stifles cooperation rather then being helpful.
If
> the employer isn't now a problem, maybe an assignment for future
> contributions would be useful.)
>
>>> I want it to be possible from a legal standpoint to merge python-mode.el
>>> and python.el, taking the best and most popular features and
>>> functionality from each. I think python-mode.el should form the basis
>>> of the merge, with code pulled in from python.el as needed.
>
> Current maintainers may disagree, but I don't think popularity with
> Python programmers trumps the Emacs coding conventions. Still, the only
> missing things I've heard of either violate the conventions or aren't
> specific to Python and should be elsewhere, or already are.
>
>> Difference is not at the level of feature-function, but
>> from the very beginning. It's a little bit the same as
>> with GNU and XEmacs: you can't merge with reasonable
>> cost and result now.
>
> Yes, this follows what's mostly happened with XEmacs historically. It's
> not a question of merging now, though -- this was all long ago.
>
>> From this some chances too: Not every feature once
>> implemented turns out useful. Not every feature is
>> needed by everyone.
>
> After working with and on python-mode.el, I did take the opportunity to
> try to write something clean without undue mis-features.
That was a general remark, in no way aimed at your code.
Let me take the opportunity to assert you: I'm well
respecting the work.
My offer was and is: let's cooperate. There are enough
things to do beside pure code-writing. Nor should the
assignment nor the GPL-versions-question block
cooperation completely. We must respect hindrances as
it exists, that's right.
>
>> I would welcome a friendly, sportive concurrence. So if
>> Dave may tell, what's the point of python.el is in
>> contrast to python-mode.el, I'm interested to read.
>
> We wanted decent Python support for and in Emacs. There's commentary in
> the file, although it may not be complete.
>
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: replacing python.el
15 years, 2 months
Dave Love
Beverley Eyre <fbe2(a)comcast.net> writes:
> Don't forget that there was a peck of code that Dave Love took from
> python-mode.el in his python.el.
That's not true, as I've already responded to Eyre with some subset of
these Ccs. As well as this claim of wholesale copying, and thus me
lying about the copyright status of the code, there was the implication
that I was violating other's copyright, and that people should ignore
the licence on free software (bizarrely on the basis of what rms
supposedly wrote). I advised legal advice on copyright, and should
probably have mentioned libel.
[For the benefit of emacs-devel, this all originated when I complained
about someone distributing a chunk of my code with the FSF copyright
notice stripped as a patch for python-mode.el, which was under a simple
permissive licence. I also saw a call for volunteers to merge the two
modes, and pointed out the GPL'd code couldn't be used under the
permissive licence -- there was no mention of changing it -- and that
code couldn't be used in Emacs without a proper assignment.]
Obviously if the FSF's legal advice on what's significant for copyright
purposes has changed, if I misinterpreted it, or made a mistake, I'd
re-write stuff appropriately. However, I don't think it's worth
worrying about it on the basis of someone who's so far quoted some
duplicated keybindings, and a Fixme comment that was clearly mine, as
evidence of all this copied code. If Emacs developers are worried,
please contact me more privately.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
#'query-coding-region and invalid Unicode sequences.
15 years, 2 months
Aidan Kehoe
At the moment, #'query-coding-region ignores invalid Unicode sequences, it
treats them as always encodable--which they are, it is clear what they
should correspond to when written to disk. But Unicode says they are not
encodable. In the interactive code which will eventually use
#'query-coding-region I want to make this clear, and offer the user the
option of treating them like other unencodable characters (that is, removing
them from the file, or choosing other characters, for the most part), or of
ignoring this and going ahead and writing them to disk. So,
#'query-coding-region would need two modes, one where such sequences are
treated as encodable, one where they give an error (or give a range table
describing where to find the problematic characters.)
What would be a good way to provide this? Should I re-order the existing
parameters (now would be the time to do it) and add a new one after BUFFER,
or add it at the end? What should the argument be called?
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghe, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Mercurial "r####" numbers are not stable, use commit ids
15 years, 2 months
Stephen J. Turnbull
I like Mercurial a little less every day.
*Always* post the log messages or commit ID, *never* the r numbers.
The r numbers are *not stable* across repositories, and just confuse
the readers.
You can get the commit IDs with "hg log" or "hg id".
Somebody wrote to me:
> Aidan thought one of your commits between r4532 and r4534 influenced
> the handling of Xresource.
This is what I get, fingering Aidan, not me, amusingly enough.
(Amusing, because this isn't real evidence that Aidan had anything to
do with it. I have no idea what commits the OP's revisions 4532:4534
might refer to.)
$ hg log -r 4532:4534
changeset: 4532:16906fefc8df
branch: bytecomp-coding-system-2008-10-29
user: Aidan Kehoe <kehoea(a)parhasard.net>
date: Sun Dec 21 17:23:06 2008 +0000
summary: Return a list copy in #'built-in-face-specifiers,
pre-empting modification.
changeset: 4533:4a7c4ccac2fe
parent: 4527:8418d1ad4944
parent: 4532:16906fefc8df
user: Aidan Kehoe <kehoea(a)parhasard.net>
date: Mon Dec 22 12:05:47 2008 +0000
summary: Merge.
changeset: 4534:f32c7f843961
user: Aidan Kehoe <kehoea(a)parhasard.net>
date: Mon Dec 22 12:09:08 2008 +0000
summary: #'built-in-face-specifiers; document that we're returning
a copy.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Fortran.el
15 years, 2 months
Tom Browder
When compiling Fortran code using gfortran inside xemacs I cannot get
xemacs to point to the source lines for errors and warnings. I have
attempted to get help on comp.emacs.xemacs but no luck yet. I will also
try the gfortran mailing list.
Thanks.
-Tom
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
check-parens
15 years, 2 months
Andreas Röhler
Hi,
below a parentese check function. Couldn't see it so
far.
Please note, while retaining the name of a GNU function,
wrote it completely new.
Thanks all
Andreas Röhler
(when (featurep 'xemacs)
(defun check-parens ()
"Check for unbalanced parentheses. Stop at the beginning of defective form. "
(interactive)
(let ((pos (point)))
(goto-char (point-min))
(or (condition-case nil
(while (not (eobp))
(forward-list))
(error (skip-chars-forward " \n\t")))
(progn (message "%s" "ok")
(goto-char pos))))))
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
forward-comment re-implemented
15 years, 2 months
Andreas Röhler
Hi all,
`forward-comment' seems broken in all Emacsen more or
less, i.e. backward-comment failed completely, `forward-comment'
worked in GNU for me, but is buggy in XEmacs.
Having a look into XEmacs syntax.c, fixing in C seems difficult.
As forward-comment-lor might be fast enough and speed should not be not
crucial for this function, maybe the C code should be dropped and
this re-implementation used instead?
BTW: This code is coupled out from comment-lor.el.
It's suffix `-lor' means `line-or-region': If no
active region exists, line is commented or uncommented.
Thus taking action to mark a region is no longer needed.
Complete new version of comment-lor.el should come soon.
Andreas Röhler
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
FSF assignment policy
15 years, 2 months
Andreas Röhler
Hi (X)Emacs folks,
as FSF assignment policy was raised again at
python-mode(a)python.org, please permit to ask you a
thing I never understood:
AFAIS every Emacs-file is inspired by many, many others
from the very beginning. We see almost always a plenty
of revisions with a lot of people involved.
So how a single developer could ever declare what the
assignment formula demands? How could any person
declare, he _owns_ the rights at the code, thus
assigning it.
Isn't that assignment policy driving developers in a
kind of forgery? Making them false declarations,
thus having rights about them, being everyday able to
sue them for these false declarations?
Or am I simply dreaming a bad dream?
Sincerely
Andreas Röhler
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta