matlab-emacs-discuss — Discuss Emacs/MATLAB integration

Re: [Matlab-emacs-discuss] [matlab-emacs:src] Merge request: Changed the path in matlab-shell-first-prompt-fcn

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

>>> "NNB" == Nidsh Narayanaa Balaji <nid...@us...> writes:

> Merge request: Changed the path in matlab-shell-first-prompt-fcn
> ---

> Nidsh Narayanaa Balaji has requested to merge changes from
> `ssh://@git.code.sf.net/u/nidish96/matlab-emacs` at commit `[6dff52]`
> into the branch `master`

> I was previously having issues running matlab interactively on a TRAMP session. 
> Changing the "run('.');" command to use the "~/" symbol for home
> allows loading the matlab-mode installation on the remote machine and
> thereby let me use matlab interactively through TRAMP.


Hi 

I am one of the maintainers of emacs-matlab.

For some bizarre reason I am unable to pull this merge request. Which
reminds me that we want to mirror that repository also at github, where
that might work better.

In the meantime: would you mind to send your request as an ordinary
patch to the corresponding mailing list.

BTW, did you send a merge request in summer? I had the same problem but
could not find any email address in order to write the author.

It seems to be you
Merge request: Changed font-lock-reference-face to font-lock-constant-face

So I presume both patches are against the 
current master commit: b49c86e5738f

Or.

Regards

Uwe Brauer 
-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 

Re: [Matlab-emacs-discuss] [matlab-emacs:src] Merge request: Changed font-lock-reference-face to font-lock-constant-face

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

>>> "NNB" == Nidsh Narayanaa Balaji <nid...@us...> writes:

Hi

> Merge request: Changed font-lock-reference-face to font-lock-constant-face
> ---

> Nidsh Narayanaa Balaji has requested to merge changes from
> `ssh://@git.code.sf.net/u/nidish96/matlab-emacs` at commit `[ce8044]`
> into the branch `master`

> In emacs 29.1, font-lock-reference-face has been removed. We are to
> use font-lock-constant-face instead. This was breaking the "help"
> calls from matlab shell.
> Changing these variables fixes this. 

Did you check that it does break backwards compatibility?

I am confused about this merge request.

commit `[ce8044]` must be a commit of your repository, right?

I never really liked merge requests, and I having trouble finding your commit.

Maybe it is easier you send a good old patch indicating against which
commit that is intended. I think we are faster that way.


Uwe Brauer 
> ---

> Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/matlab-emacs/src/merge-requests/3/>



> To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>

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

Re: [Matlab-emacs-discuss] issue with figure generated by a matlab org src block

[Shervin S. <neu...@gm...>]

Dear John and Uwe,

Thanks very much for sending your hint. I very much appreciate it.

It turns out it was a bug in org codes (I already report it).

In case someone else in this community is also dealing with it. Here’s the
solution:

In "ob-octave.el" line 94, instead of

(format "print -dpng %S\nans=%S" gfx-file gfx-file))

should be

(format "print -dpng %s" gfx-file))

otherwise, the figure is not saved (and thus an empty inline figure will
appear).

I already test it with MATLAB and can confirm it.

Lastly, thanks very much again for maintaining the emacs matlab-mode.

Best wishes,
Shervin
--------------------------------------------------------------------
Shervin Safavi
Postdoctoral fellow

:: Max Planck Institute for Biological Cybernetics
   Computational Neuroscience (Peter Dayan Lab)
:: University of Tübingen
   Department of Computer Science

Max-Planck-Ring 8, 72076 Tübingen, Germany
Web:     shervinsafavi.org
Twitter: @neuroprinciples
Tel:       +49 7071 601 1683
Fax:     +49 7071 601 652
--------------------------------------------------------------------


Shervin

On Thu 17. Aug 2023 at 20:29, John Ciolfi <ci...@ma...> wrote:

> Hi
>
> If you have the latest https://sourceforge.net/projects/matlab-emacs/,
> take a look at
> https://sourceforge.net/p/matlab-emacs/src/ci/master/tree/examples/matlab-and-org-mode/matlab-and-org-mode.org
>
> This should get matlab working with Emacs nicely (we use this with Emacs
> 27 and it works for us).
>
> I have had on my todo list for a while to send in change requests to
> org-mode to fix the integration problems.
> ------------------------------
> *From:* Shervin Safavi <neu...@gm...>
> *Sent:* Wednesday, August 16, 2023 4:33 PM
> *To:* Matlab-emacs-discuss <mat...@li...>
> *Subject:* [Matlab-emacs-discuss] issue with figure generated by a matlab
> org src block
>
> Dear everyone,
>
> I'm setting up matlab-mode on a new laptop with Ubuntu 22. Most things
> (related to matlab-mode) are working smoothly, but some don't. Most
> importantly the figure results of an org code block do not appear below the
> plot (just an empty box appear there). I had a similar issue, in an earlier
> version and I realized that I was using the wrong syntax. So, the last
> functioning syntax is the following:
>
> #+BEGIN_SRC matlab :file test2.png :results file graphics
> imagesc(rand(10))
> #+END_SRC
>
> But it doesn't work anymore. I guess just the syntax changed recently that
> I'm not aware of (and couldn't find it online). I was wondering if any of
> you know what wrong?
>
> Thanks very much in advance, and thanks also for keeping this wonderful
> community running.
>
> Best wishes,
> Shervin
>

Re: [Matlab-emacs-discuss] issue with figure generated by a matlab org src block

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

Hi

If you have the latest https://sourceforge.net/projects/matlab-emacs/, take a look at https://sourceforge.net/p/matlab-emacs/src/ci/master/tree/examples/matlab-and-org-mode/matlab-and-org-mode.org

This should get matlab working with Emacs nicely (we use this with Emacs 27 and it works for us).

I have had on my todo list for a while to send in change requests to org-mode to fix the integration problems.
________________________________
From: Shervin Safavi <neu...@gm...>
Sent: Wednesday, August 16, 2023 4:33 PM
To: Matlab-emacs-discuss <mat...@li...>
Subject: [Matlab-emacs-discuss] issue with figure generated by a matlab org src block

Dear everyone,

I'm setting up matlab-mode on a new laptop with Ubuntu 22. Most things (related to matlab-mode) are working smoothly, but some don't. Most importantly the figure results of an org code block do not appear below the plot (just an empty box appear there). I had a similar issue, in an earlier version and I realized that I was using the wrong syntax. So, the last functioning syntax is the following:

#+BEGIN_SRC matlab :file test2.png :results file graphics
imagesc(rand(10))
#+END_SRC

But it doesn't work anymore. I guess just the syntax changed recently that I'm not aware of (and couldn't find it online). I was wondering if any of you know what wrong?

Thanks very much in advance, and thanks also for keeping this wonderful community running.

Best wishes,
Shervin

[Matlab-emacs-discuss] issue with figure generated by a matlab org src block

[Shervin S. <neu...@gm...>]

Dear everyone,

I'm setting up matlab-mode on a new laptop with Ubuntu 22. Most things
(related to matlab-mode) are working smoothly, but some don't. Most
importantly the figure results of an org code block do not appear below the
plot (just an empty box appear there). I had a similar issue, in an earlier
version and I realized that I was using the wrong syntax. So, the last
functioning syntax is the following:

#+BEGIN_SRC matlab :file test2.png :results file graphics
imagesc(rand(10))
#+END_SRC

But it doesn't work anymore. I guess just the syntax changed recently that
I'm not aware of (and couldn't find it online). I was wondering if any of
you know what wrong?

Thanks very much in advance, and thanks also for keeping this wonderful
community running.

Best wishes,
Shervin

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/