Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]


Hi 

I am one of the maintainer of matlab-mode. That code is currently hosted
in sourceforge (with a github mirror) and available as a package in
MELPA.

5 years in a discussion RMS asked in
https://lists.gnu.org/archive/html/emacs-devel/2016-04/msg00429.html

«Is someone making an effort to find the contributors to matlab-mode.el?
How much code do we not have papers for?»

At the moment, however, Mathwork still hold copyright over parts of the code.

That however changed a while ago: Mathwork not only renounced its
copyright, they explicitly asked us to remove any reference to it from
all the files, which we did.

    1. Git blame (or hg annotate for that matter) told me that currently
       the code belongs to only 4 authors, of whom 3 have signed the FSF
       papers, and the other one is in the process of doing so.

    2. There is another point that worries me: According to the
       changelogs at some points the maintainers committed patches from
       other authors, but in their own (the maintainers name).

However, before addressing this problem, I would like to know:

Could matlab-mode become part of ELPA or even could dwell in the GNU
emacs tree?

I know that matlab is a commercial product and its license is not
compatible with the GPL, but the same could be said about MS Windows OS
and MacOS and yet GNU Emacs support these OSs.

It would benefit the users of matlab who wish to use GNU Emacs for coding.

Regards

Uwe Brauer

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Philip Kaludercic]

Uwe Brauer <oub@mat.ucm.es> writes:

> However, before addressing this problem, I would like to know:
>
> Could matlab-mode become part of ELPA or even could dwell in the GNU
> emacs tree?

If the CA situation is solved, there shouldn't be an issue with adding
the package to GNU ELPA (and later perhaps GNU Emacs), but...

> I know that matlab is a commercial product and its license is not
> compatible with the GPL, but the same could be said about MS Windows OS
> and MacOS and yet GNU Emacs support these OSs.

my understanding is that the GNU Project doesn't want to refer to
propitiatory software and/or incentivise it's users to use non-free
software.  With Mathlab, there is the additional issue that GNU Octave
exists.

> It would benefit the users of matlab who wish to use GNU Emacs for coding.
>
> Regards
>
> Uwe Brauer
>

-- 
	Philip Kaludercic

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Stefan Monnier]

Uwe Brauer [2021-11-20 18:53:08] wrote:
> That however changed a while ago: Mathwork not only renounced its
> copyright, they explicitly asked us to remove any reference to it from
> all the files, which we did.
>
>     1. Git blame (or hg annotate for that matter) told me that currently
>        the code belongs to only 4 authors, of whom 3 have signed the FSF
>        papers, and the other one is in the process of doing so.
>
>     2. There is another point that worries me: According to the
>        changelogs at some points the maintainers committed patches from
>        other authors, but in their own (the maintainers name).

Regarding point 1: the output of `git blame` does not tell the whole
story (if you reindent or move code, `git blame` will only list you as
the author even tho the real author is the one who write that code
before you moved/reindented it).

It's not irrelevant, but it's not sufficient to decide if the copyright
is clean.

Point 2 is also another example where Git metadata (not just `git
blame`) needs to be double checked, indeed.

> However, before addressing this problem, I would like to know:
>
> Could matlab-mode become part of ELPA or even could dwell in the GNU
> emacs tree?

Very good question.  I think it would be acceptable in GNU ELPA or Emacs
(the legal&philosophical issues are the same for both) *if*
`matlab-mode` can be used meaningfully without proprietary software
(i.e. without Matlab).

I think it's a big "if".  Maybe a more interesting/promising path might
be to split the part of `matlab-mode` that also makes sense with Octave
and try to add/include/merge it into `octave-mode`, and then turn
`matlab-mode` into an extension on top of `octave-mode` that's dedicated
to supporting the bits of Matlab that aren't in Octave (that
extension won't be included in GNU ELPA nor Emacs, obviously).

> I know that matlab is a commercial product and its license is not
> compatible with the GPL, but the same could be said about MS Windows OS
> and MacOS and yet GNU Emacs support these OSs.
> It would benefit the users of matlab who wish to use GNU Emacs for coding.

Indeed, it's not completely black or white.  You may want to ask RMS
whether this gray is rather dark or light.


        Stefan

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 5387 bytes --]

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

> Uwe Brauer [2021-11-20 18:53:08] wrote:
>> That however changed a while ago: Mathwork not only renounced its
>> copyright, they explicitly asked us to remove any reference to it from
>> all the files, which we did.
>> 
>> 1. Git blame (or hg annotate for that matter) told me that currently
>> the code belongs to only 4 authors, of whom 3 have signed the FSF
>> papers, and the other one is in the process of doing so.
>> 
>> 2. There is another point that worries me: According to the
>> changelogs at some points the maintainers committed patches from
>> other authors, but in their own (the maintainers name).

> Regarding point 1: the output of `git blame` does not tell the whole
> story (if you reindent or move code, `git blame` will only list you as
> the author even tho the real author is the one who write that code
> before you moved/reindented it).

> It's not irrelevant, but it's not sufficient to decide if the copyright
> is clean.

Ok, I tried 
 hg churn

And more or less its git equivalent 

git shortlog -ns | more

These commands reveal one author more, but not the same one.
A comment about the history of matlab-mode might help. It started using
patches and emails, as many now attic proyects that dates back to the 90
or 80, at some point I think RCS was used, then CVS and then it was
converted to git (and mercurial). [1]

The problem is that old «commits» often very sketchy, and not full names
were used, but usernames such as for examples RMS, DAK etc (actually
neither RMS nor David contributed to matlab, it was just an example).

In any case, I presume I have to checkout the corresponding commit and
then try to eyeball the relevant code, whether it still remains in the
current commit.

The problem is if it remains but the author cannot not be found or does
not respond. But before I even start this, I want to know whether at the
end matlab-mode can enter ELPA or the tree, so see below:

> Point 2 is also another example where Git metadata (not just `git
> blame`) needs to be double checked, indeed.

Actually this worries me much more, because in some cases the commit
reads apply patch from Name without an email address.


>> However, before addressing this problem, I would like to know:
>> 
>> Could matlab-mode become part of ELPA or even could dwell in the GNU
>> emacs tree?

> Very good question.  I think it would be acceptable in GNU ELPA or Emacs
> (the legal&philosophical issues are the same for both) *if*
> `matlab-mode` can be used meaningfully without proprietary software
> (i.e. without Matlab).

> I think it's a big "if".  Maybe a more interesting/promising path might
> be to split the part of `matlab-mode` that also makes sense with Octave
> and try to add/include/merge it into `octave-mode`, and then turn
> `matlab-mode` into an extension on top of `octave-mode` that's dedicated
> to supporting the bits of Matlab that aren't in Octave (that
> extension won't be included in GNU ELPA nor Emacs, obviously).

That last part I don't understand. Let me try to get that straight.

You would allow a part of matlab that could be used also in octave (and
I presume in other matlab clones such as scilab) to be part of ELPA or
the GNU emacs tree.

That part of the code most likely would be the part that takes care of
fortification or syntax checking. However octave's commands are is at
best a subset of matlab's so matlab would highlight more commands than
octave, but I don't think that is a problem. That is not trivial but
somehow doable.

The part where a merge is more difficult or almost impossible (or at
least as difficult as merging Xemacs and GNU emacs 20 years ago)
concerns debugging and the interaction with the shell. But Eric Ludlam
is more qualified to answer that. In any case I doubt that at the moment
any maintainer has the time to deal with that.

So if a merge is not possible, you are saying that the this specific
code could not enter ELPA or the emacs tree?

But then by the very same logic all part of the code (I presume it is
the C code) that allows GNU emacs to be compiled in MS Windows and MacOS
should be removed as well. (I don't think that is a good idea, but just
for the shake of an argument)



>> I know that matlab is a commercial product and its license is not
>> compatible with the GPL, but the same could be said about MS Windows OS
>> and MacOS and yet GNU Emacs support these OSs.
>> It would benefit the users of matlab who wish to use GNU Emacs for coding.

> Indeed, it's not completely black or white.  You may want to ask RMS
> whether this gray is rather dark or light.

So, it is up to RMS?

RMS if you read this: would you allow to have a part of matlab-mode that
interacts with matlab via the so called matlab shell, to be part of ELPA or GNU
emacs?

Rationale: there is already specific code that allows GNU emacs to be
compiled in non free systems.

regards

Uwe 


>         Stefan




Footnotes:
[1]  Fun fact, there was a discussion on the mailing list, whether it
     should be git or mercurial, no surprise git won, but then those who
     voted for git (and wanted in github) never really contributed, at
     least not with write access to the repository.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Po Lu]

Uwe Brauer <oub@mat.ucm.es> writes:

>>> I know that matlab is a commercial product and its license is not
>>> compatible with the GPL, but the same could be said about MS Windows OS
>>> and MacOS and yet GNU Emacs support these OSs.
>>> It would benefit the users of matlab who wish to use GNU Emacs for coding.
>
>> Indeed, it's not completely black or white.  You may want to ask RMS
>> whether this gray is rather dark or light.

> So, it is up to RMS?

> RMS if you read this: would you allow to have a part of matlab-mode that
> interacts with matlab via the so called matlab shell, to be part of ELPA or GNU
> emacs?

FWIW the GNU project has a replacement for Matlab named Octave.  Does
this editing mode also work with Octave code?  Does it provide any
features that work with Matlab, but not Octave?

I think these are the important questions here.

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

>>> "PL" == Po Lu <luangruo@yahoo.com> writes:

> Uwe Brauer <oub@mat.ucm.es> writes:
>>> I know that matlab is a commercial product and its license is not
>>> compatible with the GPL, but the same could be said about MS Windows OS
>>> and MacOS and yet GNU Emacs support these OSs.
>>> It would benefit the users of matlab who wish to use GNU Emacs for coding.
>> 
>>> Indeed, it's not completely black or white.  You may want to ask RMS
>>> whether this gray is rather dark or light.

>> So, it is up to RMS?

>> RMS if you read this: would you allow to have a part of matlab-mode
>> that interacts with matlab via the so called matlab shell, to be part
>> of ELPA or GNU emacs?

> FWIW the GNU project has a replacement for Matlab named Octave. 

Well there is a also GNU project called HURD, but GNU Emacs runs on free
and non free OS, so although that is important point I don't think it is
essential.

> Does this editing mode also work with Octave code? Does it provide any
> features that work with Matlab, but not Octave?

> I think these are the important questions here.

As I said, most likely the editing features might be merged, the matlab
specific code concerns the interaction with matlab through a function
called matlab-shell. That part is much harder to merge, but again GNU
emacs runs on non free OSs.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Po Lu]

Uwe Brauer <oub@mat.ucm.es> writes:

>> FWIW the GNU project has a replacement for Matlab named Octave. 

> Well there is a also GNU project called HURD.

How is the Hurd relevant?  Isn't GNU/Linux also free software?

> But GNU Emacs runs on free and non free OS, so although that is
> important point I don't think it is essential.

AFAIU, the GNU project only provides Emacs on proprietary platforms to
give users of those platforms a taste of free software, to encourage
their to switch to a free platform.  I don't see how providing editing
capabilities for a proprietary system would make people switch to free
software.

> As I said, most likely the editing features might be merged, the matlab
> specific code concerns the interaction with matlab through a function
> called matlab-shell.

Does it work with GNU Octave?

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

>>> "PL" == Po Lu <luangruo@yahoo.com> writes:

> Uwe Brauer <oub@mat.ucm.es> writes:
>>> FWIW the GNU project has a replacement for Matlab named Octave. 

>> Well there is a also GNU project called HURD.

> How is the Hurd relevant?  Isn't GNU/Linux also free software?

My point was you named a GNU project I named another one. The Linux
kernel is not GNU software.

>> But GNU Emacs runs on free and non free OS, so although that is
>> important point I don't think it is essential.

> AFAIU, the GNU project only provides Emacs on proprietary platforms to
> give users of those platforms a taste of free software, to encourage
> their to switch to a free platform.

I doubt that very much, on the contrary, having the possibility to run
GNU software on a OS makes it more attractive to stay or even to chose
that system. 

For example if I am forced to run MS Office, then I would chose MacOS
because I can, via fink, macports and homebrew, I can run GNU software,
while that is a lot harder in MS Windows.


> I don't see how providing editing capabilities for a proprietary
> system would make people switch to free software.

I don't share your promise, that is why I question also this argument.



>> As I said, most likely the editing features might be merged, the matlab
>> specific code concerns the interaction with matlab through a function
>> called matlab-shell.

> Does it work with GNU Octave?

Ok, I really have to check that one, my guess is now, but I have to sort
it out.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Po Lu]

Uwe Brauer <oub@mat.ucm.es> writes:

> My point was you named a GNU project I named another one. The Linux
> kernel is not GNU software.

But why is it relevant?  The Linux kernel is free software.

> I doubt that very much, on the contrary, having the possibility to run
> GNU software on a OS makes it more attractive to stay or even to chose
> that system. 

It gives the users of the proprietary system a taste of free software.
To quote part of the Emacs manual:

   We support GNU Emacs on proprietary operating systems because we hope
   this taste of freedom will inspire users to escape from them.

> For example if I am forced to run MS Office, then I would chose MacOS
> because I can, via fink, macports and homebrew, I can run GNU software,
> while that is a lot harder in MS Windows.

MS Office, MS Windows and macOS are all proprietary software.  The goal
is to eradicate them, not to make it more convenient for people to use
them.

But my main concern is whether or not it works with Octave, which
directly concerns me (as a user of Octave).  It would certainly be
disappointing if Emacs supported Matlab better than Octave, and it would
also be harmful to the GNU project.

> Ok, I really have to check that one, my guess is now, but I have to sort
> it out.

Please do that, thanks :)

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]

>>> "PL" == Po Lu <luangruo@yahoo.com> writes:


> It gives the users of the proprietary system a taste of free software.
> To quote part of the Emacs manual:

>    We support GNU Emacs on proprietary operating systems because we hope
>    this taste of freedom will inspire users to escape from them.

>> For example if I am forced to run MS Office, then I would chose MacOS
>> because I can, via fink, macports and homebrew, I can run GNU software,
>> while that is a lot harder in MS Windows.

> MS Office, MS Windows and macOS are all proprietary software.  The goal
> is to eradicate them, not to make it more convenient for people to use
> them.

I know, and I do share your goals, however the real world is different.
As I can personally testify, it is all about document format, if a free
software cannot read and write 100% accurate a document in the infamous
docx format, then it will not be used in a lot of environments (official
commercial etc).


> But my main concern is whether or not it works with Octave, which
> directly concerns me (as a user of Octave).  It would certainly be
> disappointing if Emacs supported Matlab better than Octave, and it would
> also be harmful to the GNU project.

I am not sure what better here means, for example debugging would work
better with matlab then with octave? I presume it will be the other way
around since mathworks sometimes changes internals without, ahm a well
extended documentation.

Syntax highlighting might be another issue, but what could be easily
resolved I guess.

>> Ok, I really have to check that one, my guess is now, but I have to sort
>> it out.

> Please do that, thanks :)



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[dick]

PL>    We support GNU Emacs on proprietary operating systems because we hope
PL> this taste of freedom will inspire users to escape from them.

Inertia is real, and institutions will always opt for circuitous rhetoric over
policy reversal to avoid retcon'ing a longstanding inconsistency.  GNU happens
to be rather expert at this kind of casuistry.

Without data, I agree with OP that if I were a Windows user, I imagine myself
more inclined to stick with Windows if GNU offered a fully functioning emacs
there (fortunately for GNU, it doesn't).

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Andy Moreton]

On Sun 21 Nov 2021, dick wrote:

> PL>    We support GNU Emacs on proprietary operating systems because we hope
> PL> this taste of freedom will inspire users to escape from them.
>
> Inertia is real, and institutions will always opt for circuitous rhetoric over
> policy reversal to avoid retcon'ing a longstanding inconsistency.  GNU happens
> to be rather expert at this kind of casuistry.

Please drop the rude tone. It does not advance your arguments.

> Without data, I agree with OP that if I were a Windows user, I imagine myself
> more inclined to stick with Windows if GNU offered a fully functioning emacs
> there (fortunately for GNU, it doesn't).

Wrong. Emacs works fine on Windows, and has for decades.

    AndyM

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Alfred M. Szmidt]

The reason to mention GNU Octave is because it is replacement for the
non-free Matlab, Emacs also already includes a mode for GNU Octave.

The goal for the GNU project is to make non-free software irrelevant,
maybe matlab support could be added in some form to octave-mode rather
than add a specific mode that only works with non-free software which
would be counter productive to the goals of the GNU project.  

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[dick]

AMS> The goal for the GNU project is to make non-free software irrelevant,
AMS> maybe matlab support could be added in some form to octave-mode

I fail to see how adding matlab support would achieve the goal of making
non-free irrelevant.  Is this some form of the "taste of freedom" argument
which aims to trundle free Trojan horses into non-free dens of iniquity?

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

>>> "AMS" == Alfred M Szmidt <ams@gnu.org> writes:

> The reason to mention GNU Octave is because it is replacement for the
> non-free Matlab, Emacs also already includes a mode for GNU Octave.

> The goal for the GNU project is to make non-free software irrelevant,
> maybe matlab support could be added in some form to octave-mode rather
> than add a specific mode that only works with non-free software which
> would be counter productive to the goals of the GNU project.  



Whats about the opposite szenario? 

I am forced to use MS Windows and
matlab, and don't like its internal editor. I learn the GNU emacs
supports matlab coding and immediately fell in love with it. 
From then on I contribute to the development of Emacs and 

In fact:

"Louis, I think this is the beginning of a beautiful friendship."



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Alfred M. Szmidt]

   I am forced to use MS Windows and
   matlab, and don't like its internal editor. 

I doubt (and hope) that you are really forced, rather that you might
find it a significant effort and non trivial effort to switch.  You
could try and see if you can replace matlab with GNU octave when
possible.  GNU Emacs comes with an octave-mode out of the box.

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

>>> "AMS" == Alfred M Szmidt <ams@gnu.org> writes:

>    I am forced to use MS Windows and
>    matlab, and don't like its internal editor. 

> I doubt (and hope) that you are really forced, rather that you might
> find it a significant effort and non trivial effort to switch.  You
> could try and see if you can replace matlab with GNU octave when
> possible.  GNU Emacs comes with an octave-mode out of the box.

That was an example, fortunately I am not forced to use MS Windows. I am
forced, however, in my university to use Matlab for my lectures and
interactions with the students. That is *not* negotiable, although I did
not try to bring it to the courts.

So octave is not an alternative, and I have to add that at some point in
the past I tried very hard to convince the university authorities to
switch to octave.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Alfred M. Szmidt]

   >    I am forced to use MS Windows and
   >    matlab, and don't like its internal editor. 

   > I doubt (and hope) that you are really forced, rather that you might
   > find it a significant effort and non trivial effort to switch.  You
   > could try and see if you can replace matlab with GNU octave when
   > possible.  GNU Emacs comes with an octave-mode out of the box.

   That was an example, fortunately I am not forced to use MS Windows. I am
   forced, however, in my university to use Matlab for my lectures and
   interactions with the students. That is *not* negotiable, although I did
   not try to bring it to the courts.

Experience tells me, at least, otherwise.  Here is a great article
which might give you some inspiration:
https://www.gnu.org/education/how-i-fought-to-graduate-without-using-non-free-software.html

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]

>>> "AMS" == Alfred M Szmidt <ams@gnu.org> writes:

>> I am forced to use MS Windows and
>> matlab, and don't like its internal editor. 

>> I doubt (and hope) that you are really forced, rather that you might
>> find it a significant effort and non trivial effort to switch.  You
>> could try and see if you can replace matlab with GNU octave when
>> possible.  GNU Emacs comes with an octave-mode out of the box.

>    That was an example, fortunately I am not forced to use MS Windows. I am
>    forced, however, in my university to use Matlab for my lectures and
>    interactions with the students. That is *not* negotiable, although I did
>    not try to bring it to the courts.

> Experience tells me, at least, otherwise.  Here is a great article
> which might give you some inspiration:
> https://www.gnu.org/education/how-i-fought-to-graduate-without-using-non-free-software.html

Interesting but, well that seems to be a single case. Truth being told
it is the student who is asking for using free software, that is an
entirely different issue. 
A student indeed has more «power» in this regard than the professor[1],
but I have seen very little initiative from the student side on this
issue. I would rather welcome this. 
Some students a year ago expressed their desire to switch to use python
instead of matlab (given the different versions of python and its
incompatibilities I am bit sceptical about this idea, I'd rather prefer octave)

However truth being told, there are subjects, especially for higher
degrees such as a master, that are different to treat with octave, at
least the last time I checked, as far as I know there is no equivalent
to Simulink in octave, which might come hand for, example, control
theory


Footnotes:
[1]  even «Spain is different»


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Stefan Monnier]

> GNU Emacs runs on free and non free OS, so although that is important
> point I don't think it is essential.

But Emacs does not work better under Windows (or macOS) than under GNU/Linux.
E.g. we explicitly disabled support for colored fonts on macOS until we
had support for that under GNU/Linux.

So a comparable situation would be for a mode that works both with
Matlab and Octave but doesn't provide any feature which only works
with Matlab.


        Stefan

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

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

>> GNU Emacs runs on free and non free OS, so although that is important
>> point I don't think it is essential.

> But Emacs does not work better under Windows (or macOS) than under GNU/Linux.
> E.g. we explicitly disabled support for colored fonts on macOS until we
> had support for that under GNU/Linux.

> So a comparable situation would be for a mode that works both with
> Matlab and Octave but doesn't provide any feature which only works
> with Matlab.

I am not sure that the  command-shell would fit into that description. 

Frankly, I don't see here a problem, in my understanding currently we
have

    1. One shell for octave

    2. One shell for matlab

It would be different, if there were only a command shell for matlab and
none for octave, but that's not the case.

Whats about my argument, a matlab mode for emacs, could encourage users
of the internal non free matlab user to switch to GNU emacs (and then
potentially could contribute either by bug reports, fixes or even more
features...)

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[dick]

UB> a matlab mode for emacs could encourage non free matlab user to switch to
UB> GNU emacs

An emacs user new to matlab seeks a matlab mode.

A matlab user new to emacs does not seek emacs.

Adding matlab-mode to ELPA would not affect these behaviors.  I would go
further and say adding packages to ELPA generally does not affect behaviors.

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Stefan Monnier]

>>> GNU Emacs runs on free and non free OS, so although that is important
>>> point I don't think it is essential.
>
>> But Emacs does not work better under Windows (or macOS) than under GNU/Linux.
>> E.g. we explicitly disabled support for colored fonts on macOS until we
>> had support for that under GNU/Linux.
>
>> So a comparable situation would be for a mode that works both with
>> Matlab and Octave but doesn't provide any feature which only works
>> with Matlab.
>
> I am not sure that the  command-shell would fit into that description. 
>
> Frankly, I don't see here a problem, in my understanding currently we
> have
>
>     1. One shell for octave
>
>     2. One shell for matlab

Other than (re)writing the indentation code in `octave-mode` (used as
a guinea pig back then for experimentation with SMIE), I know very
little about Octave and Matlab, so I really don't know at all what might
be the differences in terms of features that matlab/octave-mode could
offer when used with Matlab vs when used with Octave.

All I was saying is that in order to get `matlab-mode` into GNU ELPA,
you'll probably have to make sure it doesn't provide any feature that
only works with Matlab but not with Octave.

[ And if such a feature is missing, the way forward is to add it to the
  Octave side, potentially by adding some underlying feature to Octave
  itself and then adding support for it to the ELisp package.  ]


        Stefan

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > All I was saying is that in order to get `matlab-mode` into GNU ELPA,
  > you'll probably have to make sure it doesn't provide any feature that
  > only works with Matlab but not with Octave.

That's right.  We want to give Octave at least as good support
as Matlab gets.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Sun, 21 Nov 2021 09:08:37 +0100
> 
> RMS if you read this: would you allow to have a part of matlab-mode that
> interacts with matlab via the so called matlab shell, to be part of ELPA or GNU
> emacs?
> 
> Rationale: there is already specific code that allows GNU emacs to be
> compiled in non free systems.

Can you explain in simple words what is so important about matlab-mode
that we'd like to have it in ELPA?  Is it syntax support, or is it the
fact that you can invoke the REPL of the Matlab interpreter from
Emacs, or is it something else?

I'm asking because I never understood why people who use Matlab would
like to use Emacs in conjunction with Matlab, since the Matlab
interactive mode provides so many features that are practically
necessary for any reasonable use of Matlab.  So what can Emacs
possibly add to that?

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]

>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

>> From: Uwe Brauer <oub@mat.ucm.es>
>> Date: Sun, 21 Nov 2021 09:08:37 +0100
>> 
>> RMS if you read this: would you allow to have a part of matlab-mode that
>> interacts with matlab via the so called matlab shell, to be part of ELPA or GNU
>> emacs?
>> 
>> Rationale: there is already specific code that allows GNU emacs to be
>> compiled in non free systems.

> Can you explain in simple words what is so important about matlab-mode
> that we'd like to have it in ELPA?  Is it syntax support, or is it the
> fact that you can invoke the REPL of the Matlab interpreter from
> Emacs, or is it something else?

Several reasons:

    1. You can use your favorite editor for writing code.

    2. Matlab-mode has a specific syntax support (like auctex does) that concerns keyword expansion, fontification and these sorts of things.

    3. It has a function matlab-shell that does allow you execute code, either the whole part or just parts of it (you have a similar feature using org mode, the python kernel, and jupyter, however not all commands are supported using org mode, plotting for example is not, debugging neither). Again a similarity with auctex

    4. You can debug code, although that worked better in the past, but it is still quite reasonable 

> I'm asking because I never understood why people who use Matlab would
> like to use Emacs in conjunction with Matlab, since the Matlab
> interactive mode provides so many features that are practically
> necessary for any reasonable use of Matlab.  So what can Emacs
> possibly add to that?

I am not sure what you mean by interactive mode here? Do you mean that matlab allows you to open a specific matlab file with emacs, but configuring as an external editor?

If this is the case, then, you cannot debug, and you cannot execute code from emacs, it is more of a one way thing.

I am not sure I answered your question, I have to admit.

regards



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Sun, 21 Nov 2021 09:32:10 +0100
> 
>     1. You can use your favorite editor for writing code.

The Matlab code editor is IMNSHO vastly superior, as it has code
completion, links to the Matlab documentation, etc.  Emacs can at best
be a dumb text editor in this regard.

>     2. Matlab-mode has a specific syntax support (like auctex does) that concerns keyword expansion, fontification and these sorts of things.

That could be easily merged into Octave mode, I think.  the syntax is
similar, right?

>     3. It has a function matlab-shell that does allow you execute code, either the whole part or just parts of it (you have a similar feature using org mode, the python kernel, and jupyter, however not all commands are supported using org mode, plotting for example is not, debugging neither). Again a similarity with auctex
> 
>     4. You can debug code, although that worked better in the past, but it is still quite reasonable 

Don't these work much better in the Matlab interpreter?

> > I'm asking because I never understood why people who use Matlab would
> > like to use Emacs in conjunction with Matlab, since the Matlab
> > interactive mode provides so many features that are practically
> > necessary for any reasonable use of Matlab.  So what can Emacs
> > possibly add to that?
> 
> I am not sure what you mean by interactive mode here?

Where you get the ">>" prompt and can examine data, run code
fragments, etc.  The REPL.

> If this is the case, then, you cannot debug, and you cannot execute code from emacs, it is more of a one way thing.

Given the above, I still don't understand why you'd want to have Emacs
support for it.  Why not use the Matlab facilities, which AFAIK are
significantly more powerful and flexible than anything Emacs can
reasonably provide?

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 3704 bytes --]

>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

>> From: Uwe Brauer <oub@mat.ucm.es>
>> Date: Sun, 21 Nov 2021 09:32:10 +0100
>> 
>> 1. You can use your favorite editor for writing code.

> The Matlab code editor is IMNSHO vastly superior, as it has code
> completion, links to the Matlab documentation, etc.  Emacs can at best
> be a dumb text editor in this regard.

I disagree with the use of the term vastly superior: we have code completion and
you can use the matlab-shell to access the matlab documentation if you
desire. I can also use my favorite editor as the swiss knife it is to
write my code, I have tried the matlab editor in several occasion and
find it superior. Here is a simple example.

I have to check a lot of matlab files students present in an exam, so I
have to read the code execute parts of it, write comments, use the spell
checker, access my email etc etc in that process, and I don't have to
use an external editor, that is different from emacs to do this. Heck
even at mathworks there are, I think hundreds of users (or at least a
dozen that use emacs for hacking and not the internal editor).

It seems that you are acquainted with matlab, why don't you give
matlab-mode a try?
 


>> 2. Matlab-mode has a specific syntax support (like auctex does) that
>> concerns keyword expansion, fontification and these sorts of things.

> That could be easily merged into Octave mode, I think.  the syntax is
> similar, right?

Yes, but since matlab contains more commands, it supports, logically,
more


>> 3. It has a function matlab-shell that does allow you execute
>> code, either the whole part or just parts of it (you have a similar
>> feature using org mode, the python kernel, and jupyter, however not
>> all commands are supported using org mode, plotting for example is
>> not, debugging neither). Again a similarity with auctex
>> 
>> 4. You can debug code, although that worked better in the past, but it is still quite reasonable 

> Don't these work much better in the Matlab interpreter?

Do you mean, does debugging work better using the internal editor. It
depends, the pointer when moving is  bit better explained, but I have
tried both and I prefer emacs for debugging, but again that might be a
personal preference.

>> > I'm asking because I never understood why people who use Matlab would
>> > like to use Emacs in conjunction with Matlab, since the Matlab
>> > interactive mode provides so many features that are practically
>> > necessary for any reasonable use of Matlab.  So what can Emacs
>> > possibly add to that?
>> 
>> I am not sure what you mean by interactive mode here?

> Where you get the ">>" prompt and can examine data, run code
> fragments, etc.  The REPL.

But this is not an editor, I don't understand you. I am given a single
matlab file what I need to examine, you want to do this from the command
line?




>> If this is the case, then, you cannot debug, and you cannot execute
>> code from emacs, it is more of a one way thing.

> Given the above, I still don't understand why you'd want to have Emacs
> support for it.  Why not use the Matlab facilities, which AFAIK are
> significantly more powerful and flexible than anything Emacs can
> reasonably provide?

All I can say is, I have to use matlab more than 15 years, and I have
tried it both ways, I much prefer emacs, it is more, when I am forced to
use Windows (no surprise my university uses MS windows for their PC,
than I am much slower in debugging and checking students code, the emacs
matlab shell does not work in MS Windows, only in GNU/Linux and MacOs,
most likely in BSD as well)

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: Uwe Brauer <oub@mat.ucm.es>, emacs-devel@gnu.org
> Date: Sun, 21 Nov 2021 09:51:24 +0100
> 
> It seems that you are acquainted with matlab, why don't you give
> matlab-mode a try?

I did (in the past), and I didn't like it.  Thus my questions.

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

>> From: Uwe Brauer <oub@mat.ucm.es>
>> Cc: Uwe Brauer <oub@mat.ucm.es>, emacs-devel@gnu.org
>> Date: Sun, 21 Nov 2021 09:51:24 +0100
>> 
>> It seems that you are acquainted with matlab, why don't you give
>> matlab-mode a try?

> I did (in the past), and I didn't like it.  Thus my questions.

When was the last time you checked?

Just in case here is the link 

https://git.code.sf.net/p/matlab-emacs/src


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[dick]

EZ> Why not use the Matlab facilities, which AFAIK are significantly more
EZ> powerful and flexible than anything Emacs can reasonably provide?

This question is fatuous given the deep knowledge of its author regarding
emacs and its computing niche.

Emacs knows it cannot hold a candle to specialized editors like Matlab and
Rstudio on features and out-of-the-box accessbility.  Its selling point has
always been UNIX-y interop (cutting and pasting say to a LaTeX doc) for
command line people.

I used matlab-mode right until spring 2015 when Mathworks reformatted their
prompt codes, thereby crippling debug mode.

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]

>>> "d" == dick  <dick.r.chiang@gmail.com> writes:

EZ> Why not use the Matlab facilities, which AFAIK are significantly more
EZ> powerful and flexible than anything Emacs can reasonably provide?

> This question is fatuous given the deep knowledge of its author regarding
> emacs and its computing niche.

In fact I feel increasily strange of defending the use of GNU emacs on
the *emacs dev* list

> Emacs knows it cannot hold a candle to specialized editors like Matlab and
> Rstudio on features and out-of-the-box accessbility.  

Well I beg to differ, although part of the statement is true, GNU emacs
has the huge advantage of being extenable, I often find myself in a
situation what while checking matlab files, I need to edit them and the
way is to write a simple lisp function, job done. That is hardly
possible in say matlab internal editor.

> Its selling point has always been UNIX-y interop (cutting and pasting
> say to a LaTeX doc) for command line people.

Again for me it is its universal swiss knife feature and its
extenability, but taste can differ, obviously.

> I used matlab-mode right until spring 2015 when Mathworks reformatted their
> prompt codes, thereby crippling debug mode.

Well it is back, have you a look yourself. And if you are not satisfied,
to quote RMS[1], «it will be faster if *you* help»


Footnotes:
[1]  improvising a bit, not sure about its exact wording.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I know that matlab is a commercial product and its license is not
  > compatible with the GPL, but the same could be said about MS Windows OS
  > and MacOS and yet GNU Emacs support these OSs.

The GNU Project has standard about what to do in situations like this.
Its conclusion in this case is that it is ok to include Matlab mode in
Emacs.  Likewise, ok to make Emacs run on Windows or MacOS.

See the GNU Coding Standards, node References, for the way we reason
about questions like this.  I urge everyone here to read it.

First, what are our goals?
We want to lead/help users of Matlab to try using Emacs.
We want NOT to lead/help users of Emacs to try using Matlab.

In practice, I think Matlab mode will not do the latter, not much.
It will mainly do the former.
Why so?

Because a tool like Matlab is more domain-specific than an editor.
Basically, most users would not find Matlab or Octave useful;
those who WOULD find them useful probably already know about them.
Thus, there is little chance that someone reading about Emacs's Matlab
mode would trigger per to use Matlab.  But it might lead a Matlab user
to try using Emacs with it.

It is good for Emacs to suggest to Matlab users that they use Emacs
with Matlab.  But we should be careful to avoid going the other way!

The node References explains more.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

>>> "RS" == Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

>> I know that matlab is a commercial product and its license is not
>> compatible with the GPL, but the same could be said about MS Windows OS
>> and MacOS and yet GNU Emacs support these OSs.

> The GNU Project has standard about what to do in situations like this.
> Its conclusion in this case is that it is ok to include Matlab mode in
> Emacs.  Likewise, ok to make Emacs run on Windows or MacOS.

Ok, thanks for the clarification RMS. 
Anybody else: is this settled, then?

I am asking because I have to start round two of code-digging as Stefan suggested to find out whether each and every line that has been included by patches a long time ago is 

    1. either deleted or

    2. in case it survived try to contact the author.

That is a rather time consuming activity and I don't want in the last minute to hear an objection to include matlab-mode, as you maybe understand.

Regards


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Stefan Monnier]

> Ok, thanks for the clarification RMS. 
> Anybody else: is this settled, then?

If Richard is OK with it, it's good enough for me.


        Stefan

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2021-11-22 17:01]:
> > Ok, thanks for the clarification RMS. 
> > Anybody else: is this settled, then?
> 
> If Richard is OK with it, it's good enough for me.

Why is then NonGNU ELPA included, but to avoid packages made solely to
interact with proprietary software.

If Richard is OK with including such packages, he may be so. I am
surprised, but I follow free software principles by RMS, not his
individual reasoning, which I find in this case incorrect.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2021-11-22 05:30]:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > I know that matlab is a commercial product and its license is not
>   > compatible with the GPL, but the same could be said about MS Windows OS
>   > and MacOS and yet GNU Emacs support these OSs.
> 
> The GNU Project has standard about what to do in situations like this.
> Its conclusion in this case is that it is ok to include Matlab mode in
> Emacs.  Likewise, ok to make Emacs run on Windows or MacOS.
> 
> See the GNU Coding Standards, node References, for the way we reason
> about questions like this.  I urge everyone here to read it.
> 
> First, what are our goals?
> We want to lead/help users of Matlab to try using Emacs.
> We want NOT to lead/help users of Emacs to try using Matlab.
> 
> In practice, I think Matlab mode will not do the latter, not much.
> It will mainly do the former.
> Why so?

Your reasoning is individual and I don't agree to that reasoning. I
cannot see how is that reasoning aligned to the references as quoted
on: https://www.gnu.org/prep/standards/standards.html#References

"A GNU program should not recommend, promote, or grant legitimacy to
the use of any non-free program."

And by including `matlab-mode' would come especially that event of
recommending, promoting and granting legitimacy of the ose of non-free
Matlab.

Thus I don't agree on the proposal to include matlab-mode into GNU
ELPA neither NonGNU ELPA neither into Emacs if the matlab-mode is
specifically made to run and interact with non-free software.

Was that (packages that are made to solely interact to non-free
software) not the main reason why MELPA is not included in Emacs as
repository and why NonGNU ELPA came into existence?

- I would not even call it "matlab" as if it appears in ELPA, it
  promotes non-free software;

- if features of matlab-mode are analogous to lisp-mode, where person
  may insert same type of binary to run with it; such as for GNU
  Octave and features are not Matlab-proprietary software specific,
  then such package could be included IMHO. lisp-mode works with many
  Lisp binaries and I guess with proprietary once as well.

- if features are specific to Matlab -- there is no way I would ever
  include it to ELPA, Emacs or NonGNU ELPA; as acting based upon free
  software principles and the same reference you quoted above.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Your reasoning is individual and I don't agree to that reasoning.

I wrote the node References, and I know the policy that I wrote
it to describe.  We have always included modes for Emacs to work
with widely used nonfree tools, when that would mainly encourage
the users of those tools to use Emacs with them.

If you read further on in the node References, you'll see the text
that the exception that seems to cover referring to Matlab,
and the goals we should keep in mind about it.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)