matlab-emacs-discuss — Discuss Emacs/MATLAB integration

Re: [Matlab-emacs-discuss] the filling patch and its problems

[Eric L. <el...@ma...>]

Hi Uwe,

If you think it is useful, then feel free to turn that error into a warning.

A problem with the algorithm is it doesn’t plan ahead.  It tries to break at the fill-column, and if that happens to be at the beginning of a string, then the resultant split adds some syntax to re-assemble the broken string.  Once you do that, the remaining string can’t be re-broken b/c the words may be too long.   There are a series of other similar problems like this for different kinds of syntaxes.

The reason it used to “work” is because it treated a line as all comment even if it was an end-of-code comment.  To treat it correctly, I needed to treat the beginning as code.  Ie – need to fill the code in order to get the comment close enough to the fill column that it will be fillable.  That’s why comments would fill erratically sometimes.

There is lots of room to make the algorithm a bit better, but like I said, it needs a deeper heuristic.  Maybe tweaking matlab-fill-fudge will help.  I haven’t worked on this bit in a long time to remember how it all works.

Eric

From: Uwe Brauer <ou...@ma...>
Sent: Monday, July 31, 2023 11:57 AM
To: Eric Ludlam <el...@ma...>
Cc: Uwe Brauer <ou...@ma...>; Matlab-emacs-discuss <mat...@li...>
Subject: Re: the filling patch and its problems

>>> "EL" == Eric Ludlam <el...@ma...<mailto:el...@ma...>> writes:

> Is anyone out there interested in the "code fill" feature?

You mean besides me 😇 I do hope so!


> It was a hairy thing to implement back in the day, and most of the
> feedback I got was "how do I turn this off?" It is likely easier to
> drop the feature than figure out how to fix it for all cases.

I cannot judge this and I don't want to cause you headaches.

However I can tell you that code that is written with the native matlab
editor (say by my students) tend to have these enormous comment lines as
in the files


fill_prob2.m
fill_prob.m

So filling these lines would help me quite a bit and I thought emacs
users sharing code with those using the native editor might face similar
problems.


The thing that puzzles me:

in commit 0f305501f26d633048c83a89b6652db169394a3f
that line filling problems seemed to be solved

But in the last two commits it throws an error.

So what changed and can't we just go back?


> Basically, it isn't hard to create a line of code it can't fill, in
> which case it throws this error. Maybe a warning is better?

Yes I think so.

Uwe
--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/<https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view>

Re: [Matlab-emacs-discuss] the filling patch and its problems

[Uwe B. <ou...@ma...>]

>>> "EL" == Eric Ludlam <el...@ma...> writes:

> Is anyone out there interested in the "code fill" feature? 

You mean besides me 😇 I do hope so!


> It was a hairy thing to implement back in the day, and most of the
> feedback I got was "how do I turn this off?" It is likely easier to
> drop the feature than figure out how to fix it for all cases.

I cannot judge this and I don't want to cause you headaches.

However I can tell you that code that is written with the native matlab
editor (say by my students) tend to have these enormous comment lines as
in the files 


fill_prob2.m
fill_prob.m

So filling these lines would help me quite a bit and I thought emacs
users sharing code with those using the native editor might face similar
problems.


The thing that puzzles me:

in commit 0f305501f26d633048c83a89b6652db169394a3f
that line filling problems seemed to be solved

But in the last two commits it throws an error. 

So what changed and can't we just go back?


> Basically, it isn't hard to create a line of code it can't fill, in
> which case it throws this error. Maybe a warning is better?

Yes I think so. 

Uwe 
-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: [Matlab-emacs-discuss] the filling patch and its problems

[Eric L. <el...@ma...>]

Is anyone out there interested in the "code fill" feature?  It was a hairy thing to implement back in the day, and most of the feedback I got was "how do I turn this off?"   It is likely easier to drop the feature than figure out how to fix it for all cases.

Basically, it isn't hard to create a line of code it can't fill, in which case it throws this error.  Maybe a warning is better?

Eric

From: Uwe Brauer <ou...@ma...>
Sent: Monday, July 31, 2023 11:26 AM
To: Eric Ludlam <el...@ma...>
Cc: Uwe Brauer <ou...@ma...>; Matlab-emacs-discuss <mat...@li...>
Subject: Re: the filling patch and its problems

>>> "EL" == Eric Ludlam <el...@ma...<mailto:el...@ma...>> writes:

> For prob2, it looks like when 'matlab-fill-code' is nil, it won't fill
> the code (via auto-fill mode), and it throws that error. I pushed a
> change that will not fill code if matlab-fill-code is nil so it won't
> error anymore.

I have set matlab-fill-code to t and now the latest commit of yours
produces more errors, I just pushed the updated README file with the new
bug, sorry
--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/<https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view>

Re: [Matlab-emacs-discuss] the filling patch and its problems

[Uwe B. <ou...@ma...>]

>>> "EL" == Eric Ludlam <el...@ma...> writes:

> For prob2, it looks like when 'matlab-fill-code' is nil, it won't fill
> the code (via auto-fill mode), and it throws that error. I pushed a
> change that will not fill code if matlab-fill-code is nil so it won't
> error anymore.

I have set matlab-fill-code to t and now the latest commit of yours
produces more errors, I just pushed the updated README file with the new
bug, sorry
-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: [Matlab-emacs-discuss] the filling patch and its problems

[Eric L. <el...@ma...>]

For prob2, it looks like when 'matlab-fill-code' is nil, it won't fill the code (via auto-fill mode), and it throws that error.

I pushed a change that will not fill code if matlab-fill-code is nil so it won't error anymore.

Ideally, I suppose you might wan to set matlab-fill-code to t round-about line 2774 if you think it should fill if you specifically ask it to.  ie:

             (if (= (point)
                      (progn
                        (matlab-auto-fill)
                        (point)))
                   (error "Fill algorithm failed!"))

Would become

             (if (= (point)
                      (let ((matlab-fill-code t))
                        (matlab-auto-fill)
                        (point)))
                   (error "Fill algorithm failed!"))

In addition to removing the initial check to short-circuit this block.

I remember this going in where the request was to auto-fill comments, but stop auto-filling code since it often didn't do what was desired.

Eric

From: Uwe Brauer <ou...@ma...>
Sent: Thursday, July 27, 2023 11:46 AM
To: Eric Ludlam <el...@ma...>
Cc: Uwe Brauer <ou...@ma...>; Matlab-emacs-discuss <mat...@li...>
Subject: Re: the filling patch and its problems

>>> "EL" == Eric Ludlam <el...@ma...<mailto:el...@ma...>> writes:

> I saw an error indicated in your readme and tried it out. I pushed a
> fix that will improve that particular case. Eric

Thanks I did test it. It is better but still not perfect

1. It does not return error, but

2. it did not change much the filling
(contrary to matlab-fill-comment-line which now works very nicely.

3. I also added a new test file, for which it still returns error.

4. I pushed

Uwe


--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/<https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view>

From: Uwe Brauer <ou...@ma...>
Sent: Thursday, July 27, 2023 11:46 AM
To: Eric Ludlam <el...@ma...>
Cc: Uwe Brauer <ou...@ma...>; Matlab-emacs-discuss <mat...@li...>
Subject: Re: the filling patch and its problems

>>> "EL" == Eric Ludlam <el...@ma...<mailto:el...@ma...>> writes:

> I saw an error indicated in your readme and tried it out. I pushed a
> fix that will improve that particular case. Eric

Thanks I did test it. It is better but still not perfect

1. It does not return error, but

2. it did not change much the filling
(contrary to matlab-fill-comment-line which now works very nicely.

3. I also added a new test file, for which it still returns error.

4. I pushed

Uwe


--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/<https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view>

Re: [Matlab-emacs-discuss] the filling patch and its problems

[Uwe B. <ou...@ma...>]

>>> "EL" == Eric Ludlam <el...@ma...> writes:

> I saw an error indicated in your readme and tried it out. I pushed a
> fix that will improve that particular case. Eric

Thanks I did test it. It is better but still not perfect

    1. It does not return error, but

    2. it did not change much the filling
       (contrary to matlab-fill-comment-line which now works very nicely.

    3. I also added a new test file, for which it still returns error.

    4. I pushed 

Uwe 


-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: [Matlab-emacs-discuss] the filling patch and its problems

[Eric L. <el...@ma...>]

I saw an error indicated in your readme and tried it out.  I pushed a fix that will improve that particular case.

Eric

From: Uwe Brauer <ou...@ma...>
Sent: Thursday, July 27, 2023 2:59 AM
To: Eric Ludlam <el...@ma...>
Cc: Uwe Brauer <ou...@ma...>; Matlab-emacs-discuss <mat...@li...>
Subject: Re: the filling patch and its problems

>>> "EL" == Eric Ludlam <el...@ma...<mailto:el...@ma...>> writes:

> Hi Uwe,
> I created a fill-fix branch which I hung off master to include the changes.

> That branch happens to include an mlint hack for Cygwin, and a toy I
> wrote a while ago but never got around to sending a long. The commit
> log should explain the changes.

Thanks, I just tested it, looks much better save matlab-fill-region

I created a new subdirectory test-fill-but, with an example and a README
file and pushed


Please have a look

Thanks very much for your effort.

Uwe
--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/<https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view>

Re: [Matlab-emacs-discuss] the filling patch and its problems

[Uwe B. <ou...@ma...>]

>>> "EL" == Eric Ludlam <el...@ma...> writes:

> Hi Uwe,
> I created a fill-fix branch which I hung off master to include the changes.

> That branch happens to include an mlint hack for Cygwin, and a toy I
> wrote a while ago but never got around to sending a long. The commit
> log should explain the changes.

Thanks, I just tested it, looks much better save matlab-fill-region

I created a new subdirectory test-fill-but, with an example and a README
file and pushed


Please have a look

Thanks very much for your effort.

Uwe 
-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: [Matlab-emacs-discuss] the filling patch and its problems

[Eric L. <el...@ma...>]

Hi Uwe,

I created a fill-fix branch which I hung off master to include the changes.

That branch happens to include an mlint hack for Cygwin, and a toy I wrote a while ago but never got around to sending a long.   The commit log should explain the changes.

Eric

From: Uwe Brauer <ou...@ma...>
Sent: Tuesday, July 25, 2023 12:12 PM
To: Eric Ludlam <el...@ma...>
Cc: Uwe Brauer <ou...@ma...>; Matlab-emacs-discuss <mat...@li...>
Subject: Re: the filling patch and its problems

>>> "EL" == Eric Ludlam <el...@ma...<mailto:el...@ma...>> writes:

> The patch was based on the same rev that the previous patch was based
> on. Ie – it includes the previous patch, or changes to it. If that
> doesn’t fit, I can make and push a branch against main instead. That
> might be easier to work with if you have more feedback.

Oops indeed I cannot apply the patch to the current master version (I
thought I applied your patch and already put it on a different branch
that I did not push for sure).

So maybe the easiest way to proceed indeed is if you create a new branch
fix-fill say
and apply that patch to the current master commit? I changed only in the
relevant files, the copyright stuff.

The last commit on the master branch should be
803f9d3d8ee25950ad5352ec0651b2531aaa29e5

Thanks

Uwe


--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/<https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view>

Re: [Matlab-emacs-discuss] [a mess of GPL versions]

[Uwe B. <ou...@ma...>]

>>> "EL" == Eric Ludlam <eri...@gm...> writes:

> Yes, I have the updated filling bug info.  Thanks.
> I have also noticed some filling bugs after my previous patch I would like
> to fix.  Hoping to get to it soon.

I thanks I saw your push, I just pulled and will run my tests later.

BTW The Debian person, asked for the copyright headers for the files in the
tests directory, so I boldly inserted the GPLv3+ headers to all of them,
but this is in the master branch.


> Eric


> On Fri, Jul 14, 2023, 3:51 AM Uwe Brauer <ou...@ma...> wrote:

>> >>> "UB" == Uwe Brauer <ou...@ma...> writes:
>> 
>> >>> "EL" == Eric Ludlam <eri...@gm...> writes:
>> >> I'm not picky about what version of GPL we use as long as it is 2 or
>> >> greater.
>> 
>> 
>> >> I fixed things up on the semantic stuff recently, but I agree that I
>> may be
>> >> the only one who uses that stuff.  There's a bunch of esoteric options
>> that
>> >> could move to a subdir, and if needed use something like (require
>> >> 'subir/srcfile) to get it.  I'd recommend a "cedet" subdir, and/or
>> leave it
>> >> out of the debian package.
>> 
>> 
>> BTW, did you receive my mails concerning the filling issue?
>> 
>> I created branch called filling-bug but still did not push it, to keep
>> the number of branches low.
>> 
>> So we can discuss this issue by email or I push the new branch, in which I
>> just applied your patch.
>> 
>> 
>> Uwe
>> --
>> Warning: Content may be disturbing to some audiences
>> I strongly condemn Putin's war of aggression against the Ukraine.
>> I support to deliver weapons to Ukraine's military.
>> I support the NATO membership of the Ukraine.
>> I support the EU membership of the Ukraine.
>> 
>> https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
>> 

-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: [Matlab-emacs-discuss] the filling patch and its problems

[Uwe B. <ou...@ma...>]

>>> "EL" == Eric Ludlam <el...@ma...> writes:

> The patch was based on the same rev that the previous patch was based
> on. Ie – it includes the previous patch, or changes to it. If that
> doesn’t fit, I can make and push a branch against main instead. That
> might be easier to work with if you have more feedback.

Oops indeed I cannot apply the patch to the current master version (I
thought I applied your patch and already put it on a different branch
that I did not push for sure).

So maybe the easiest way to proceed indeed is if you create a new branch
fix-fill say
and apply that patch to the current master commit? I changed only in the
relevant files, the copyright stuff.

The last commit on the master branch should be 
803f9d3d8ee25950ad5352ec0651b2531aaa29e5

Thanks

Uwe 


-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: [Matlab-emacs-discuss] the filling patch and its problems

[Eric L. <el...@ma...>]

The patch was based on the same  rev that the previous patch was based on.  Ie – it includes the previous patch, or changes to it.

If that doesn’t fit, I can make and push a branch against main instead.  That might be easier to work with if you have more feedback.

Eric

From: Uwe Brauer <ou...@ma...>
Sent: Tuesday, July 25, 2023 5:11 AM
To: Eric Ludlam <el...@ma...>
Cc: Uwe Brauer <ou...@ma...>; Matlab-emacs-discuss <mat...@li...>
Subject: Re: the filling patch and its problems

>>> "EL" == Eric Ludlam <el...@ma...<mailto:el...@ma...>> writes:

> Hi Uwe,

> Here’s a revised patch that does a better job filling comments, and
> also fixes the indent region issue you found.

It seemed that I was able to repair your message (it seems that
MATHWORKS changed something with its servers basically all message from
them cause me now problems.


> Hope these work for you.

So to which commit shall I apply that patch?

Uwe
--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/<https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view>

Re: [Matlab-emacs-discuss] the filling patch and its problems

[Uwe B. <ou...@ma...>]

>>> "EL" == Eric Ludlam <el...@ma...> writes:

> Hi Uwe,

> Here’s a revised patch that does a better job filling comments, and
> also fixes the indent region issue you found.

It seemed that I was able to repair your message (it seems that
MATHWORKS changed something with its servers basically all message from
them cause me now problems.


> Hope these work for you.

So to which commit shall I apply that patch?

Uwe 
-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: [Matlab-emacs-discuss] the filling patch and its problems

[Uwe B. <ou...@ma...>]

>>> "EL" == Eric Ludlam <el...@ma...> writes:

Hi Eri

I am not sure who is the culprit here.
But this is what I see in emacs/gnus.


> --_004_mn2pr05mb65581320f9aede6160120580af02amn2pr05mb6558namp_
> Content-type: multipart/alternative; boundary="_000_mn2pr05mb65581320f9aede6160120580af02amn2pr05mb6558namp_"

I can't read this email in emacs, don't know what happened, could you
sent it again please?

It seems that your are sending a patch, against which commit?

Uwe 

Re: [Matlab-emacs-discuss] the filling patch and its problems

[Eric L. <el...@ma...>]

Hi Uwe,

Here’s a revised patch that does a better job filling comments, and also fixes the indent region issue you found.

Hope these work for you.
Eric

From: Uwe Brauer <ou...@ma...>
Sent: Tuesday, July 11, 2023 2:53 AM
To: Eric Ludlam <el...@ma...>
Cc: Matlab-emacs-discuss <mat...@li...>
Subject: the filling patch and its problems


Hi

Just to resume the discussion. I insert below the emails discussing the two problems I found

I applied the two patches, I attach below and then I run into a problem:

First problem

Take one of these awful long comment line

ev = 0; % el número de evaluaciones al inicio es cero, pues no ha habido ninguna iteración

this after running matlab-fill-comment-line to

ev = 0; % el número de evaluaciones al inicio es cero, pues no ha % habido % ninguna % iteración

Which does not look correct to me, shouldn't it be

ev = 0; % el número de evaluaciones al inicio es cero, pues no ha % habido ninguna iteración Or do I miss here something

Second problem.

I tried just to run matlab-indent-region on

    ev = 0; % el número de evaluaciones al inicio es cero, pues no ha

                                                                  % habido

                                                                  % ninguna

                                                                  % iteración

and I obtained an error I attach, something is not right here

Re: [Matlab-emacs-discuss] [a mess of GPL versions]

[Eric L. <eri...@gm...>]

Yes, I have the updated filling bug info.  Thanks.

I have also noticed some filling bugs after my previous patch I would like
to fix.  Hoping to get to it soon.

Eric


On Fri, Jul 14, 2023, 3:51 AM Uwe Brauer <ou...@ma...> wrote:

> >>> "UB" == Uwe Brauer <ou...@ma...> writes:
>
> >>> "EL" == Eric Ludlam <eri...@gm...> writes:
> >> I'm not picky about what version of GPL we use as long as it is 2 or
> >> greater.
>
>
> >> I fixed things up on the semantic stuff recently, but I agree that I
> may be
> >> the only one who uses that stuff.  There's a bunch of esoteric options
> that
> >> could move to a subdir, and if needed use something like (require
> >> 'subir/srcfile) to get it.  I'd recommend a "cedet" subdir, and/or
> leave it
> >> out of the debian package.
>
>
> BTW, did you receive my mails concerning the filling issue?
>
> I created branch called filling-bug but still did not push it, to keep
> the number of branches low.
>
> So we can discuss this issue by email or I push the new branch, in which I
> just applied your patch.
>
>
> Uwe
> --
> Warning: Content may be disturbing to some audiences
> I strongly condemn Putin's war of aggression against the Ukraine.
> I support to deliver weapons to Ukraine's military.
> I support the NATO membership of the Ukraine.
> I support the EU membership of the Ukraine.
>
> https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
>

Re: [Matlab-emacs-discuss] [a mess of GPL versions]

[Uwe B. <ou...@ma...>]

>>> "UB" == Uwe Brauer <ou...@ma...> writes:

>>> "JC" == John Ciolfi <ci...@ma...> writes:
>> Hi

>> I should have some time the week after next to help organize what
>> files should be shipped with matlab mode. I'd like to get
>> https://github.com/mathworks/MATLAB-language-server setup as part of
>> this. 



Another comment, which I forgot. I clone that repository, as it seems
there is only one author, namely
dl...@ma...


If we merge his code into our repository, is he willing to sign the FSF
papers, because once we move matlab mode to ELPA, the FSF will insist on
this.

Sorry for any trouble that might cause.



-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: [Matlab-emacs-discuss] [a mess of GPL versions]

[Uwe B. <ou...@ma...>]

>>> "JC" == John Ciolfi <ci...@ma...> writes:


> Hi

> I should have some time the week after next to help organize what
> files should be shipped with matlab mode. I'd like to get
> https://github.com/mathwor ks/MATLAB-language-server setup as part of
> this. 

Ok let us make some plans then.

    1. Nate agreed to sign the papers, so in the coming days matlab
       emacs could go into ELPA

    2. I will inform the Debian person

    3. I am more or less free till the 8 of august, so it would be good
       to finish that move to github before that date, I might have some
       days free after the 24 but less so.


> Many of us have been using an internal version of this in Emacs
> and like it a lot. It provides featur es like "goto definition" which
> means that when you are on a function, you type a keybinding and you
> jump to the definition. CEDET also provides simil ar functionality,
> but I haven't had good success with CEDET because we work in a large
> code base and that can cause Emacs process size to be too large and
> slow. The other advantage of using the language server protocol is tha
> t there are numerous languages supported. Emacs provides two lsp
> clients, lisp-mode<https://github.com/emacs-lsp/lsp-mode>, and eglot.
> We have a lot of experience with lsp-mode and it works well.

    4. I am a bit confusded about this github repository you mention: is
       this a fork of ours, you just one providing different features?
       Would you like to merge it into ours?

    5. BTW I just found out that I already created a github repository
       when we moved to git. It is not actualised I do this soon
       https://github.com/matlab-mode/mirror
       last commit is from July 2021. I am not sure whether we should
       take this one, or create a new one with a better name?


Uwe 

Re: [Matlab-emacs-discuss] [a mess of GPL versions]

[John C. <ci...@ma...>]

Hi

I should have some time the week after next to help organize what files should be shipped with matlab mode. I'd like to get https://github.com/mathworks/MATLAB-language-server setup as part of this. Many of us have been using an internal version of this in Emacs and like it a lot. It provides features like "goto definition" which means that when you are on a function, you type a keybinding and you jump to the definition. CEDET also provides similar functionality, but I haven't had good success with CEDET because we work in a large code base and that can cause Emacs process size to be too large and slow. The other advantage of using the language server protocol is that there are numerous languages supported. Emacs provides two lsp clients, lsp-mode<https://github.com/emacs-lsp/lsp-mode>, and eglot. We have a lot of experience with lsp-mode and it works well.


Thanks
John

________________________________
From: Uwe Brauer <ou...@ma...>
Sent: Friday, July 14, 2023 3:50 AM
To: Uwe Brauer <ou...@ma...>
Cc: Matlab-emacs-discuss <mat...@li...>
Subject: Re: [Matlab-emacs-discuss] [a mess of GPL versions]

>>> "UB" == Uwe Brauer <ou...@ma...> writes:

>>> "EL" == Eric Ludlam <eri...@gm...> writes:
>> I'm not picky about what version of GPL we use as long as it is 2 or
>> greater.


>> I fixed things up on the semantic stuff recently, but I agree that I may be
>> the only one who uses that stuff. There's a bunch of esoteric options that
>> could move to a subdir, and if needed use something like (require
>> 'subir/srcfile) to get it. I'd recommend a "cedet" subdir, and/or leave it
>> out of the debian package.


BTW, did you receive my mails concerning the filling issue?

I created branch called filling-bug but still did not push it, to keep
the number of branches low.

So we can discuss this issue by email or I push the new branch, in which I
just applied your patch.


Uwe
--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/<https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view>

Re: [Matlab-emacs-discuss] [a mess of GPL versions]

[Uwe B. <ou...@ma...>]

>>> "UB" == Uwe Brauer <ou...@ma...> writes:

>>> "EL" == Eric Ludlam <eri...@gm...> writes:
>> I'm not picky about what version of GPL we use as long as it is 2 or
>> greater.


>> I fixed things up on the semantic stuff recently, but I agree that I may be
>> the only one who uses that stuff.  There's a bunch of esoteric options that
>> could move to a subdir, and if needed use something like (require
>> 'subir/srcfile) to get it.  I'd recommend a "cedet" subdir, and/or leave it
>> out of the debian package.


BTW, did you receive my mails concerning the filling issue? 

I created branch called filling-bug but still did not push it, to keep
the number of branches low.

So we can discuss this issue by email or I push the new branch, in which I
just applied your patch.


Uwe 
-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: [Matlab-emacs-discuss] [a mess of GPL versions]

[Uwe B. <ou...@ma...>]

>>> "EL" == Eric Ludlam <eri...@gm...> writes:

> I'm not picky about what version of GPL we use as long as it is 2 or
> greater.

I upgraded all headers to GPL3v+, save the .m files in the test
directory. No sure whether it is worth, to add a header there.

I also added a COPYING file, containing the License (the same the emacs
repository uses; that is a recommendation of RMS). Will push this also.

I might also add information to the README file more information about
the directory story (again based on the README file of the emacs repository)


> I fixed things up on the semantic stuff recently, but I agree that I may be
> the only one who uses that stuff.  There's a bunch of esoteric options that
> could move to a subdir, and if needed use something like (require
> 'subir/srcfile) to get it.  I'd recommend a "cedet" subdir, and/or leave it
> out of the debian package.


I leave this to you to decide 🙃

Concerning Debian and ELPA.

    1. I think when I finish the README file (I can wait, if you wish,
       after we settle the semantic stuff), I give the Debian guy a go.

    2. ELPA, there is one signature missing namely from
       Nathaniel Chodosh  nch...@an....
       I wrote him last year and he did not reply, but he still seems to be
       in that place and commits to github.
       I am not sure how to proceed. His patch can be found in the
       copyright branch, in the copyright directory. If he does not answer,
       we might

       1. consider to rewrite his patch

       2. To remove it

       3. Or give up to move Matlab to ELPA


Uwe 
-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

[Matlab-emacs-discuss] the filling patch and its problems

[Uwe B. <ou...@ma...>]

-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the NATO membership of the Ukraine.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: [Matlab-emacs-discuss] another bug with the filling alorithm

[Uwe B. <ou...@ma...>]

>>> "EL" == Eric Ludlam <el...@ma...> writes:

> I think you are correct that it isn’t quite right, but I understand why.  I get the column to indent the following lines under and set the fill prefix before handing it over to the built in fill-paragraph code.  Fill paragraph then moves the comment inward, but the fill prefix has already been defined.
> Do you think it should leave the original comment column alone?  That’s my guess.

I think what I posted seems to be one possibility


I tried just to run 
matlab-indent-region 
on 
#+begin_src 
    ev = 0; % el número de evaluaciones al inicio es cero, pues no ha
                                                                  % habido
                                                                  % ninguna
                                                                  % iteración
#+end_src

and I obtained an error I attach, something is not right here


> The comment specific part of matlab-fill-paragraph has a couple
> dubious things it’s doing that I’ll need to better understand to see
> if they are supporting some sort of edge cases. My intuition is that
> chunks of that code can be replaced with ‘fill-region’ instead of what
> it’s doing now but my first cut did something surprising instead.

> I’ll poke at it a little bit, but in theory I’m on vacation this week, so we’ll see.


Oops, by all means that is not urgent, enjoy your holidays...



-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: [Matlab-emacs-discuss] another bug with the filling alorithm

[Uwe B. <ou...@ma...>]

-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

Re: [Matlab-emacs-discuss] another bug with the filling alorithm

[Uwe B. <ou...@ma...>]

>>> "JC" == John Ciolfi <ci...@ma...> writes:
Hi John, Hi Eric
> Hi Uwe,
> Eric fixed the issue, see attached patches which apply against the
> current source forge tip, 3048e9. 

Thanks very much, especially Eric for the fix 😉, that is very much
appreciated from my side, since a bunch of matlab exams are waiting to
be corrected.


> I also tested it and have deployed
> it internally within MathWorks. Can you try the patches and if they
> are good, update source forge?


I try to test this as soon as possible, hopefully this evening. 

Maybe in two weeks I got also start the move to github (and renaming
master to default), right now, I am a bit to busy for this (exam period
started and *now* students are starting to study).


Uwe 


-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/