matlab-emacs-discuss — Discuss Emacs/MATLAB integration

Re: [Matlab-emacs-discuss] Move of matlab-mode from Source Forge to github

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

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


> Hi
> We'd like to move matlab-mode from Source Forge to github,
> https://github.com/MathWorks/Emacs-MATLAB-Mode, which gives us a good
> location for the "master" matlab-mode in github along with the
> benefits of github. Note, there are already many copies of matlab-mode
> in other github areas.

> The process for managing matlab-mode will remain the same - Uwe Brauer
> will be the primary maintainer.

> This proposal has mostly cleared internally within MathWorks. I'd like
> to ask non-MathWorker contributors to matlab-mode if this is, okay?
> Nidish and Uwe as recent non-MathWorker contributors can you reply to
> this with if you like or dislike this proposal.

Yes I am, but let me add two remarks, in order to be sure we are in the
same boat.

    1. The main dev branch will be renamed from master to default (that
       simplify things on my side). I would like to rename the branch
       before the move.

    2. The package is intended also to be in ELPA (there is still a
       problem with a signature from one author)

I think we agreed on this before, I just wanted  to be sure.

Uwe 
-- 
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] Move of matlab-mode from Source Forge to github

[Nidish <nid...@il...>]

Hello,

I'm perfectly okay with this move. 

Best, 
Nidish

On July 16, 2024 2:57:30 AM GMT+05:30, John Ciolfi <ci...@ma...> wrote:
>Hi
>
>We'd like to move matlab-mode from Source Forge to github, https://github.com/MathWorks/Emacs-MATLAB-Mode, which gives us a good location for the "master" matlab-mode in github along with the benefits of github. Note, there are already many copies of matlab-mode in other github areas.
>
>The process for managing matlab-mode will remain the same - Uwe Brauer will be the primary maintainer.
>
>This proposal has mostly cleared internally within MathWorks. I'd like to ask non-MathWorker contributors to matlab-mode if this is, okay? Nidish and Uwe as recent non-MathWorker contributors can you reply to this with if you like or dislike this proposal.
>
>Thanks
>John

[Matlab-emacs-discuss] Move of matlab-mode from Source Forge to github

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

Hi

We'd like to move matlab-mode from Source Forge to github, https://github.com/MathWorks/Emacs-MATLAB-Mode, which gives us a good location for the "master" matlab-mode in github along with the benefits of github. Note, there are already many copies of matlab-mode in other github areas.

The process for managing matlab-mode will remain the same - Uwe Brauer will be the primary maintainer.

This proposal has mostly cleared internally within MathWorks. I'd like to ask non-MathWorker contributors to matlab-mode if this is, okay? Nidish and Uwe as recent non-MathWorker contributors can you reply to this with if you like or dislike this proposal.

Thanks
John

[Matlab-emacs-discuss] matlab-mode-for-new-mfiles not working

[Muhali <mu...@ma...>]

I have set matlab-mode-for-new-mfiles to nil, which means that when opening a .m file matlab-mode will not be automatically invoked.

But .m files always open in matlab-mode.

Muhali

Re: [Matlab-emacs-discuss] [font-lock stopped working] [fixed]

[Nidish N. B. <nid...@il...>]

Hello all,


I just fixed the warnings in matlab-cell.el. To avoid a recursive 
require issue (matlab-cell.el requires matlab-shell.el, which requires 
matlab.el; so requiring matlab-cell.el in matlab.el was problematic), I 
have made the matlab-shell-send-region function in matlab-shell.el to be 
autoloaded.

I'll be happy to know if there are other, cleaner, solutions for this also.


Best,

Nidish


On 5/22/24 22:21, John Ciolfi wrote:
> Ah - I forgot we call the %% sections "cells". Perhaps a better name 
> would be code sections, 
> https://www.mathworks.com/help/matlab/matlab_prog/create-and-run-sections.html
>
> I'll re-look at this soon.
>
> Thanks
> John
>
>
> ------------------------------------------------------------------------
> *From:* Nidish Narayanaa Balaji <nid...@il...>
> *Sent:* Wednesday, May 22, 2024 2:18 PM
> *To:* John Ciolfi <ci...@ma...>; Uwe Brauer <ou...@ma...>
> *Cc:* mat...@li... 
> <mat...@li...>
> *Subject:* Re: [Matlab-emacs-discuss] [font-lock stopped working] [fixed]
>
> Hello John,
>
>
> Thank you for taking a look!
>
>
> By "Cells" I don't mean the matlab cell objects, but rather 
> "code-blocks" delimited by commented lines starting with "%%". I'm 
> attaching a short matlab script that can be used for trying it out.
>
> I recommend trying out the following (interactive) functions to get a 
> feel for the additions:
>
>  1. Move point to the beginning of the buffer and try out the function
>     `matlab-cell-forward-cell'.
>     This should take you to the next cell (while highlighting). Do it
>     a couple more times to navigate.
>
>  2. Then try out the function `matlab-cell-backward-cell'.
>
>  3. Go to the third cell and try the function `matlab-cell-move-cell-up'.
>     This should move the contents of this cell to occur before the
>     previous cell.
>
>  4. Try out `matlab-cell-move-cell-down' and this action will be
>     reversed.
>
>  5. Next (ensure you have matlab-shell running) try out the function
>     `matlab-cell-shell-run-cell' to run the contents of the cell in
>     the shell.
>     I rewrote this based on the matlab-cell environ to be consistent
>     although `matlab-shell-run-cell` does something similar.
>
> And yes, I am using pos-bol and pos-eol - my emacs was giving me 
> warnings actually so I changed them. But I did not know that these 
> were only introduced in emacs 29. It makes sense to continue using the 
> older functions - I'll fix it.
>
> Thanks for the suggestion on the keybinding, it would make sense to 
> have something based on the convention that doesn't clash with 
> anything else as default.
>
>
> I'll check with flycheck warnings before I push next! :)
>
>
> Best,
>
> Nidish
>
>
>
> On 5/22/24 20:07, John Ciolfi wrote:
>> Hi
>>
>> I like the idea of speedy navigation of cells.
>>
>> I took a brief look at the matlab-cell branch but wasn't sure what 
>> it's supposed to be used for. The first thing I tried was navigating 
>> a large cell argument to a function, something like:
>>
>>    a = fun( { .... Big cell ....}, {.... Another cell ....})
>>
>> Where the call to the function spanned many lines.
>>
>> M-x matlab-cell-foward-cell
>>
>> Jumped to the end of the file?
>>
>> Can you share use cases which could be used for testing?
>>
>> As for key bindings, it would be good to put them under C-c (take a 
>> look at the C-c C-c CHAR in matlab-cgen.el). Maybe add some 
>> additional C-c C-c CHARs?
>>
>> I saw you are using pos-eol instead of point-at-eol. pos-eol is new 
>> in Emacs 29, which now means we have a dependency on the compat 
>> library. Would be nice to not require that dependency for Emacs 27 
>> and later.
>>
>> Can you use flycheck to cleanup minor issues in the lisp files you've 
>> added?
>>
>> Thanks,
>> John
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Uwe Brauer via Matlab-emacs-discuss 
>> <mat...@li...> 
>> <mailto:mat...@li...>
>> *Sent:* Sunday, May 19, 2024 2:11 AM
>> *To:* Nidish Narayanaa Balaji <nid...@il...> 
>> <mailto:nid...@il...>
>> *Cc:* mat...@li... 
>> <mailto:mat...@li...> 
>> <mat...@li...> 
>> <mailto:mat...@li...>
>> *Subject:* Re: [Matlab-emacs-discuss] [font-lock stopped working] 
>> [fixed]
>> >>> "NNB" == Nidish Narayanaa Balaji <nid...@il...> 
>> <mailto:nid...@il...> writes:
>>
>> > Okay I've fixed the font-lock issue.
>> > Since I adapted the code from a pre-existing package that was meant to
>> > be stand-alone, it had some checks in place that were overriding the
>> > existing font-lock. I got rid of these and simplified it since we want
>> > this to be distributed as part of matlab-mode.el .
>>
>> > I've verified that the syntax highlighting now works identical to the
>> > master branch.
>>
>> Right, after a short testing, I can confirm that. Today however I have
>> not much time for further testing, but I would like to run some tests
>> more before merging and maybe somebody else might come back to us.
>>
>> Uwe
>>
>> -- 
>> 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] [font-lock stopped working] [fixed]

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

Ah - I forgot we call the %% sections "cells". Perhaps a better name would be code sections, https://www.mathworks.com/help/matlab/matlab_prog/create-and-run-sections.html

I'll re-look at this soon.

Thanks
John


________________________________
From: Nidish Narayanaa Balaji <nid...@il...>
Sent: Wednesday, May 22, 2024 2:18 PM
To: John Ciolfi <ci...@ma...>; Uwe Brauer <ou...@ma...>
Cc: mat...@li... <mat...@li...>
Subject: Re: [Matlab-emacs-discuss] [font-lock stopped working] [fixed]


Hello John,


Thank you for taking a look!


By "Cells" I don't mean the matlab cell objects, but rather "code-blocks" delimited by commented lines starting with "%%". I'm attaching a short matlab script that can be used for trying it out.

I recommend trying out the following (interactive) functions to get a feel for the additions:

  1.  Move point to the beginning of the buffer and try out the function `matlab-cell-forward-cell'.
This should take you to the next cell (while highlighting). Do it a couple more times to navigate.

  2.  Then try out the function `matlab-cell-backward-cell'.

  3.  Go to the third cell and try the function `matlab-cell-move-cell-up'.
This should move the contents of this cell to occur before the previous cell.

  4.  Try out `matlab-cell-move-cell-down' and this action will be reversed.

  5.  Next (ensure you have matlab-shell running) try out the function `matlab-cell-shell-run-cell' to run the contents of the cell in the shell.
I rewrote this based on the matlab-cell environ to be consistent although `matlab-shell-run-cell` does something similar.

And yes, I am using pos-bol and pos-eol - my emacs was giving me warnings actually so I changed them. But I did not know that these were only introduced in emacs 29. It makes sense to continue using the older functions - I'll fix it.

Thanks for the suggestion on the keybinding, it would make sense to have something based on the convention that doesn't clash with anything else as default.


I'll check with flycheck warnings before I push next! :)


Best,

Nidish



On 5/22/24 20:07, John Ciolfi wrote:
Hi

I like the idea of speedy navigation of cells.

I took a brief look at the matlab-cell branch but wasn't sure what it's supposed to be used for. The first thing I tried was navigating a large cell argument to a function, something like:

   a = fun( { .... Big cell ....}, {.... Another cell ....})

Where the call to the function spanned many lines.

M-x matlab-cell-foward-cell

Jumped to the end of the file?

Can you share use cases which could be used for testing?

As for key bindings, it would be good to put them under C-c (take a look at the C-c C-c CHAR in matlab-cgen.el). Maybe add some additional C-c C-c CHARs?

I saw you are using pos-eol instead of point-at-eol. pos-eol is new in Emacs 29, which now means we have a dependency on the compat library. Would be nice to not require that dependency for Emacs 27 and later.

Can you use flycheck to cleanup minor issues in the lisp files you've added?

Thanks,
John


________________________________
From: Uwe Brauer via Matlab-emacs-discuss <mat...@li...><mailto:mat...@li...>
Sent: Sunday, May 19, 2024 2:11 AM
To: Nidish Narayanaa Balaji <nid...@il...><mailto:nid...@il...>
Cc: mat...@li...<mailto:mat...@li...> <mat...@li...><mailto:mat...@li...>
Subject: Re: [Matlab-emacs-discuss] [font-lock stopped working] [fixed]

>>> "NNB" == Nidish Narayanaa Balaji <nid...@il...><mailto:nid...@il...> writes:

> Okay I've fixed the font-lock issue.
> Since I adapted the code from a pre-existing package that was meant to
> be stand-alone, it had some checks in place that were overriding the
> existing font-lock. I got rid of these and simplified it since we want
> this to be distributed as part of matlab-mode.el .

> I've verified that the syntax highlighting now works identical to the
> master branch.

Right, after a short testing, I can confirm that. Today however I have
not much time for further testing, but I would like to run some tests
more before merging and maybe somebody else might come back to us.

Uwe

--
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] [font-lock stopped working] [fixed]

[Nidish N. B. <nid...@il...>]

Hello John,


Thank you for taking a look!


By "Cells" I don't mean the matlab cell objects, but rather 
"code-blocks" delimited by commented lines starting with "%%". I'm 
attaching a short matlab script that can be used for trying it out.

I recommend trying out the following (interactive) functions to get a 
feel for the additions:

 1. Move point to the beginning of the buffer and try out the function
    `matlab-cell-forward-cell'.
    This should take you to the next cell (while highlighting). Do it a
    couple more times to navigate.

 2. Then try out the function `matlab-cell-backward-cell'.

 3. Go to the third cell and try the function `matlab-cell-move-cell-up'.
    This should move the contents of this cell to occur before the
    previous cell.

 4. Try out `matlab-cell-move-cell-down' and this action will be reversed.

 5. Next (ensure you have matlab-shell running) try out the function
    `matlab-cell-shell-run-cell' to run the contents of the cell in the
    shell.
    I rewrote this based on the matlab-cell environ to be consistent
    although `matlab-shell-run-cell` does something similar.

And yes, I am using pos-bol and pos-eol - my emacs was giving me 
warnings actually so I changed them. But I did not know that these were 
only introduced in emacs 29. It makes sense to continue using the older 
functions - I'll fix it.

Thanks for the suggestion on the keybinding, it would make sense to have 
something based on the convention that doesn't clash with anything else 
as default.


I'll check with flycheck warnings before I push next! :)


Best,

Nidish



On 5/22/24 20:07, John Ciolfi wrote:
> Hi
>
> I like the idea of speedy navigation of cells.
>
> I took a brief look at the matlab-cell branch but wasn't sure what 
> it's supposed to be used for. The first thing I tried was navigating a 
> large cell argument to a function, something like:
>
>    a = fun( { .... Big cell ....}, {.... Another cell ....})
>
> Where the call to the function spanned many lines.
>
> M-x matlab-cell-foward-cell
>
> Jumped to the end of the file?
>
> Can you share use cases which could be used for testing?
>
> As for key bindings, it would be good to put them under C-c (take a 
> look at the C-c C-c CHAR in matlab-cgen.el). Maybe add some additional 
> C-c C-c CHARs?
>
> I saw you are using pos-eol instead of point-at-eol. pos-eol is new in 
> Emacs 29, which now means we have a dependency on the compat library. 
> Would be nice to not require that dependency for Emacs 27 and later.
>
> Can you use flycheck to cleanup minor issues in the lisp files you've 
> added?
>
> Thanks,
> John
>
>
> ------------------------------------------------------------------------
> *From:* Uwe Brauer via Matlab-emacs-discuss 
> <mat...@li...>
> *Sent:* Sunday, May 19, 2024 2:11 AM
> *To:* Nidish Narayanaa Balaji <nid...@il...>
> *Cc:* mat...@li... 
> <mat...@li...>
> *Subject:* Re: [Matlab-emacs-discuss] [font-lock stopped working] [fixed]
> >>> "NNB" == Nidish Narayanaa Balaji <nid...@il...> writes:
>
> > Okay I've fixed the font-lock issue.
> > Since I adapted the code from a pre-existing package that was meant to
> > be stand-alone, it had some checks in place that were overriding the
> > existing font-lock. I got rid of these and simplified it since we want
> > this to be distributed as part of matlab-mode.el .
>
> > I've verified that the syntax highlighting now works identical to the
> > master branch.
>
> Right, after a short testing, I can confirm that. Today however I have
> not much time for further testing, but I would like to run some tests
> more before merging and maybe somebody else might come back to us.
>
> Uwe
>
> -- 
> 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] [font-lock stopped working] [fixed]

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

Hi

I like the idea of speedy navigation of cells.

I took a brief look at the matlab-cell branch but wasn't sure what it's supposed to be used for. The first thing I tried was navigating a large cell argument to a function, something like:

   a = fun( { .... Big cell ....}, {.... Another cell ....})

Where the call to the function spanned many lines.

M-x matlab-cell-foward-cell

Jumped to the end of the file?

Can you share use cases which could be used for testing?

As for key bindings, it would be good to put them under C-c (take a look at the C-c C-c CHAR in matlab-cgen.el). Maybe add some additional C-c C-c CHARs?

I saw you are using pos-eol instead of point-at-eol. pos-eol is new in Emacs 29, which now means we have a dependency on the compat library. Would be nice to not require that dependency for Emacs 27 and later.

Can you use flycheck to cleanup minor issues in the lisp files you've added?

Thanks,
John


________________________________
From: Uwe Brauer via Matlab-emacs-discuss <mat...@li...>
Sent: Sunday, May 19, 2024 2:11 AM
To: Nidish Narayanaa Balaji <nid...@il...>
Cc: mat...@li... <mat...@li...>
Subject: Re: [Matlab-emacs-discuss] [font-lock stopped working] [fixed]

>>> "NNB" == Nidish Narayanaa Balaji <nid...@il...> writes:

> Okay I've fixed the font-lock issue.
> Since I adapted the code from a pre-existing package that was meant to
> be stand-alone, it had some checks in place that were overriding the
> existing font-lock. I got rid of these and simplified it since we want
> this to be distributed as part of matlab-mode.el .

> I've verified that the syntax highlighting now works identical to the
> master branch.

Right, after a short testing, I can confirm that. Today however I have
not much time for further testing, but I would like to run some tests
more before merging and maybe somebody else might come back to us.

Uwe

--
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] [another problem] (was: the filling patch and its problems)

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

Ouch, that's bad, we'll need to keep this as an open issue.

Thanks
John


________________________________
From: Uwe Brauer
Sent: Wednesday, May 22, 2024 4:28 AM
To: John Ciolfi
Cc: Uwe Brauer; Matlab-emacs-discuss; Eric Ludlam
Subject: [another problem] (was: [Matlab-emacs-discuss] the filling patch and its problems)


> If you try
>   M-x set-variable RET fill-column RET
>   150

Consider

#+begin_src

function [teuler,yeuler,ev]=mieulerimpfixpc(f,intv,y0,N,TOL,nmax)  % se implementa el tercer tipo de función dada por el enunciado
    a = min(intv);                                                 % se preparan los datos de la mísma forma como se ha comentado en la anterior función
    b = max(intv);
    h = (a + b)/N;

    tk = a;
    yk = y0;

    teuler = a;
    yeuler = y0;

    ev = 0;

    faux = @(t, y, f, h, z) [y + h*f(t, z)];
#+end_src

Put the cursor on the word «mismo» in the second line run the M-q and I obtain

#+begin_src

function [teuler,yeuler,ev]=mieulerimpfixpc(f,intv,y0,N,TOL,nmax) % se implementa el tercer tipo de función dada por el
                                                                   % enunciado a = min(intv); % se preparan los datos de
                                                                   % la mísma forma como se ha comentado en la anterior
                                                                   % función b = max(intv); h = (a + b)/N; tk = a; yk =
                                                                   % y0; teuler = a; yeuler = y0; ev = 0; faux = @(t, y,
                                                                   % f, h, z) [y + h*f(t, z)]; for i = 1:N % la
                                                                   % diferencia fundamental con respecto a la función
                                                                   % anterior es que en este caso se va a utilizar para
                                                                   % la iteración simple como valor inicial 'y' el
                                                                   % calculado por el método de euler explícito t = tk +
                                                                   % h; y_pred = yk + h*f(tk, yk); % aquí se calcula
                                                                   % dicha 'y' que se va a utilizar en la iteración
                                                                   % simple ev = ev + 1; y = y_pred; k = 0; diff = 100;
                                                                   % while diff > TOL && k <= nmax % se hace la
                                                                   % iteración simple como en la anterior función pero
                                                                   % teniendo en cuenta ahora que la 'y' de valor
                                                                   % inicial es el calculado por el método de euler
                                                                   % explícito anteriormente obtenido k = k + 1; z =
                                                                   % faux(t, yk, f, h, y); diff = max(max(abs(z - y)));
                                                                   % y = z; ev = ev + 1; end


#+end_src


That is a disaster, code has changed into comments

--
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.

[Matlab-emacs-discuss] [another problem] (was: the filling patch and its problems)

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

> If you try
>   M-x set-variable RET fill-column RET
>   150

Consider 

#+begin_src 

function [teuler,yeuler,ev]=mieulerimpfixpc(f,intv,y0,N,TOL,nmax)  % se implementa el tercer tipo de función dada por el enunciado 
    a = min(intv);                                                 % se preparan los datos de la mísma forma como se ha comentado en la anterior función
    b = max(intv);
    h = (a + b)/N;
    
    tk = a;
    yk = y0;
    
    teuler = a;
    yeuler = y0;
    
    ev = 0;
    
    faux = @(t, y, f, h, z) [y + h*f(t, z)];
#+end_src

Put the cursor on the word «mismo» in the second line run the M-q and I obtain

#+begin_src 

function [teuler,yeuler,ev]=mieulerimpfixpc(f,intv,y0,N,TOL,nmax) % se implementa el tercer tipo de función dada por el
                                                                   % enunciado a = min(intv); % se preparan los datos de
                                                                   % la mísma forma como se ha comentado en la anterior
                                                                   % función b = max(intv); h = (a + b)/N; tk = a; yk =
                                                                   % y0; teuler = a; yeuler = y0; ev = 0; faux = @(t, y,
                                                                   % f, h, z) [y + h*f(t, z)]; for i = 1:N % la
                                                                   % diferencia fundamental con respecto a la función
                                                                   % anterior es que en este caso se va a utilizar para
                                                                   % la iteración simple como valor inicial 'y' el
                                                                   % calculado por el método de euler explícito t = tk +
                                                                   % h; y_pred = yk + h*f(tk, yk); % aquí se calcula
                                                                   % dicha 'y' que se va a utilizar en la iteración
                                                                   % simple ev = ev + 1; y = y_pred; k = 0; diff = 100;
                                                                   % while diff > TOL && k <= nmax % se hace la
                                                                   % iteración simple como en la anterior función pero
                                                                   % teniendo en cuenta ahora que la 'y' de valor
                                                                   % inicial es el calculado por el método de euler
                                                                   % explícito anteriormente obtenido k = k + 1; z =
                                                                   % faux(t, yk, f, h, y); diff = max(max(abs(z - y)));
                                                                   % y = z; ev = ev + 1; end


#+end_src


That is a disaster, code has changed into comments

-- 
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] the filling patch and its problems

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

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

   > If you try
   >   M-x set-variable RET fill-column RET
   >   150

I was using 100, now I changed to 150.

   > The two M-q commands will look better. I assume you were using a smaller fill column.

I presume your M-q executes command matlab-fill-comment-line, right?




#+begin_src 
        while diff > TOL && k <= nmax                             % por una parte se condiciona al while con un valor de tolerancia para el error diff, error de una iteración (de la iteración simple), y, por otra parte, se toma un numero máximo de iteraciones porque puede perfectamente el error de iteración no ser menor que la tolerancia, provocando un bucle infinito

#+end_src


Results in 

#+begin_src 

        while diff > TOL && k <= nmax % por una parte se condiciona al while con un valor de tolerancia para el error diff, error de una iteración (de
                                                                  % la iteración simple), y, por otra parte, se toma un numero máximo de iteraciones
                                                                  % porque puede perfectamente el error de iteración no ser menor que la tolerancia,
                                                                  % provocando un bucle infinito

#+end_src


Which looks bad with or without truncation line on or off.



So I am not sure who is the culprit here set-fill-column 100 seems
reasonable to me.

I will try to run more tests

-- 
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] the filling patch and its problems

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

If you try

  M-x set-variable RET fill-column RET
  150

The two M-q commands will look better. I assume you were using a smaller fill column.

Perhaps, this is good enough to update SourceForge? The missing item is that it should only take one fill (M-q) command, which we could do as a follow-up. I tried M-q in a *.cpp file for a similar case and it requires only one M-q.

Are there any other cases that behave poorly?

Thanks


________________________________
From: John Ciolfi via Matlab-emacs-discuss <mat...@li...>
Sent: Tuesday, May 21, 2024 10:35 AM
To: Uwe Brauer <ou...@ma...>
Cc: Matlab-emacs-discuss <mat...@li...>; Eric Ludlam <el...@ma...>
Subject: Re: [Matlab-emacs-discuss] the filling patch and its problems

It looks like we have more work to do and they are not ready. Thanks


________________________________
From: Uwe Brauer
Sent: Tuesday, May 21, 2024 9:39 AM
To: John Ciolfi
Cc: Eric Ludlam; Uwe Brauer; Matlab-emacs-discuss
Subject: Re: [Matlab-emacs-discuss] the filling patch and its problems

"JC" == John Ciolfi <ci...@ma...> writes:
Hi John
Hi Uwe, I don't think these fill-paragraph patches made it into master. Attached are the patches that work for me. Are there any reasons to not apply them?

In July last year Eric provided some patches for improving the filling.

I started a new branch and run some test and sooner or later them there were corner cases where it did not work as expected or made the filling worse.

Your patch differ from all the commits, so I just applied it to master and start testing. However there also cases where there problems.

The following is taken from files from Students who wrote their code using the native matlab editor in MS Windows. I give you some examples, now. But if you wish I push your patch as a different branch, and add a directory tests-for-new-filling or so.

Number 1

    j_func = @(t, y_1, jfunc, h, y_2) [h*jfunc(t, y_2) - jfunc(t, y_2)\jfunc(t, y_2)]; % UB:03.05.2024:18:08: no entiendo esta linea
                                                                                       % explicalo por favor lo utilizo para calcular la derivada de @func; debería poder usar 1 en lugar de la segunda parte de la ecuacion pero me da error y no logro ver por qué, como así me funcionaba no lo he tocado



When running matlab-fill-comment-line cursor is at the end of the first line I obtain

 j_func = @(t, y_1, jfunc, h, y_2) [h*jfunc(t, y_2) - jfunc(t, y_2)\jfunc(t, y_2)]; %
                                                                                       % UB:03.05.2024:18:08:
                                                                                       % no entiendo
                                                                                       % esta linea
                                                                                       % explicalo por favor lo utilizo para calcular la derivada de @func; debería poder usar 1 en lugar de la segunda parte de la ecuacion pero me da error y no logro ver por qué, como así me funcionaba no lo he tocado



When applying the function after the word «tocado», I obtain

    j_func = @(t, y_1, jfunc, h, y_2) [h*jfunc(t, y_2) - jfunc(t, y_2)\jfunc(t, y_2)]; %
                                                                                       % UB:03.05.2024:18:08:
                                                                                       % no entiendo
                                                                                       % esta linea
                                                                                       % explicalo
                                                                                       % por favor
                                                                                       % lo utilizo
                                                                                       % para
                                                                                       % calcular la
                                                                                       % derivada de
                                                                                       % @func;
                                                                                       % debería
                                                                                       % poder usar
                                                                                       % 1 en lugar
                                                                                       % de la
                                                                                       % segunda
                                                                                       % parte de la
                                                                                       % ecuacion
                                                                                       % pero me da
                                                                                       % error y no
                                                                                       % logro ver
                                                                                       % por qué,
                                                                                       % como así me
                                                                                       % funcionaba
                                                                                       % no lo he
                                                                                       % tocado



And this looks wired to me, don't you think?

Uwe

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

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

It looks like we have more work to do and they are not ready. Thanks


________________________________
From: Uwe Brauer
Sent: Tuesday, May 21, 2024 9:39 AM
To: John Ciolfi
Cc: Eric Ludlam; Uwe Brauer; Matlab-emacs-discuss
Subject: Re: [Matlab-emacs-discuss] the filling patch and its problems

"JC" == John Ciolfi <ci...@ma...> writes:
Hi John
Hi Uwe, I don't think these fill-paragraph patches made it into master. Attached are the patches that work for me. Are there any reasons to not apply them?

In July last year Eric provided some patches for improving the filling.

I started a new branch and run some test and sooner or later them there were corner cases where it did not work as expected or made the filling worse.

Your patch differ from all the commits, so I just applied it to master and start testing. However there also cases where there problems.

The following is taken from files from Students who wrote their code using the native matlab editor in MS Windows. I give you some examples, now. But if you wish I push your patch as a different branch, and add a directory tests-for-new-filling or so.

Number 1

    j_func = @(t, y_1, jfunc, h, y_2) [h*jfunc(t, y_2) - jfunc(t, y_2)\jfunc(t, y_2)]; % UB:03.05.2024:18:08: no entiendo esta linea
                                                                                       % explicalo por favor lo utilizo para calcular la derivada de @func; debería poder usar 1 en lugar de la segunda parte de la ecuacion pero me da error y no logro ver por qué, como así me funcionaba no lo he tocado



When running matlab-fill-comment-line cursor is at the end of the first line I obtain

 j_func = @(t, y_1, jfunc, h, y_2) [h*jfunc(t, y_2) - jfunc(t, y_2)\jfunc(t, y_2)]; %
                                                                                       % UB:03.05.2024:18:08:
                                                                                       % no entiendo
                                                                                       % esta linea
                                                                                       % explicalo por favor lo utilizo para calcular la derivada de @func; debería poder usar 1 en lugar de la segunda parte de la ecuacion pero me da error y no logro ver por qué, como así me funcionaba no lo he tocado



When applying the function after the word «tocado», I obtain

    j_func = @(t, y_1, jfunc, h, y_2) [h*jfunc(t, y_2) - jfunc(t, y_2)\jfunc(t, y_2)]; %
                                                                                       % UB:03.05.2024:18:08:
                                                                                       % no entiendo
                                                                                       % esta linea
                                                                                       % explicalo
                                                                                       % por favor
                                                                                       % lo utilizo
                                                                                       % para
                                                                                       % calcular la
                                                                                       % derivada de
                                                                                       % @func;
                                                                                       % debería
                                                                                       % poder usar
                                                                                       % 1 en lugar
                                                                                       % de la
                                                                                       % segunda
                                                                                       % parte de la
                                                                                       % ecuacion
                                                                                       % pero me da
                                                                                       % error y no
                                                                                       % logro ver
                                                                                       % por qué,
                                                                                       % como así me
                                                                                       % funcionaba
                                                                                       % no lo he
                                                                                       % tocado



And this looks wired to me, don't you think?

Uwe

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

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

-- 
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] New commit [5d221b] by John Ciolfi

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

>>> "MiEGr" == MATLAB in Emacs Git repository <no...@sr...> writes:

> ## Branch: master  
> mlint: fix Emacs 29 issues

> Emacs 29 was giving "Unknown type: linemark-overlay" which exists for
> compatibility between XEmacs and Emacs. Since XEmacs is no longer
> maintaned from what we can tell, Eric removed the support for XEmacs
> thus enabling mlint in Emacs 29. This change was done by Eric and
> tested by me.


Thanks, although I was a die hard fan of Xemacs, development stopped in
2015 (very few people might still use it) I gave it up years ago,
and almost all packages I know of, have removed Xemacs support, so yes
this was overdue (sorry for not having paid attention)

thanks



-- 
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] the filling patch and its problems

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

Hi Uwe,

I don't think these fill-paragraph patches made it into master. Attached are the patches that work for me. Are there any reasons to not apply them?

Thanks,
John



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

>>> "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/<https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view>

Re: [Matlab-emacs-discuss] [font-lock stopped working] [fixed]

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

>>> "NNB" == Nidish Narayanaa Balaji <nid...@il...> writes:

> Okay I've fixed the font-lock issue.
> Since I adapted the code from a pre-existing package that was meant to 
> be stand-alone, it had some checks in place that were overriding the 
> existing font-lock. I got rid of these and simplified it since we want 
> this to be distributed as part of matlab-mode.el .

> I've verified that the syntax highlighting now works identical to the 
> master branch.

Right, after a short testing, I can confirm that. Today however I have
not much time for further testing, but I would like to run some tests
more before merging and maybe somebody else might come back to us.

Uwe 

-- 
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] [font-lock stopped working] [fixed]

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

>>> "NNB" == Nidish Narayanaa Balaji <nid...@il...> writes:

> Okay I've fixed the font-lock issue.
> Since I adapted the code from a pre-existing package that was meant to 
> be stand-alone, it had some checks in place that were overriding the 
> existing font-lock. I got rid of these and simplified it since we want 
> this to be distributed as part of matlab-mode.el .

> I've verified that the syntax highlighting now works identical to the 
> master branch.

Thanks I just pulled and will have a look.

> Best,
> Nidish

> On 5/16/24 11:09, Nidish Narayanaa Balaji wrote:
>>> I have heard about this package but I have never used it myself.
>> I highly recommend checking it out! I use tree-sitter-hl for 
>> highlighting, and ts-fold for code folding.
>>>   I have a feeling that something got mixed up when I refreshed the
>>> matlab-load.el - I'd recommend retrying by using the matlab-load.el
>>> from master to see if that's the issue. I'll also look into this
>>> today.
>>> Right. The strange thing is.
>>> 
>>> 1. The graph is linear
>>> 
>>> 2. Git does not complain when switching branches.
>>> 
>>> 3. But when I use mercurial (and the hg-git plugin) mercurial
>>> notices a conflict!
>>> 
>>> 4. So I did what you proposed, but it does not help: one your branch
>>> the traditional font-locking is broken. Good that we are testing
>>> 
>>> Uwe
>> 
>> Strange indeed. Fair enough, I'm happy we're still testing. I'll have 
>> more time this evening to do a deep dive (git bisect should help, I 
>> guess). I'll let you know if I manage to catch it.
>> 
>> Best,
>> Nidish
>> 
>> 
>> 
>> _______________________________________________
>> Matlab-emacs-discuss mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss

> _______________________________________________
> Matlab-emacs-discuss mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss


-- 
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] [font-lock stopped working] [fixed]

[Nidish N. B. <nid...@il...>]

Okay I've fixed the font-lock issue.

Since I adapted the code from a pre-existing package that was meant to 
be stand-alone, it had some checks in place that were overriding the 
existing font-lock. I got rid of these and simplified it since we want 
this to be distributed as part of matlab-mode.el .

I've verified that the syntax highlighting now works identical to the 
master branch.

Best,
Nidish

On 5/16/24 11:09, Nidish Narayanaa Balaji wrote:
>> I have heard about this package but I have never used it myself.
> I highly recommend checking it out! I use tree-sitter-hl for 
> highlighting, and ts-fold for code folding.
>>>   I have a feeling that something got mixed up when I refreshed the
>>> matlab-load.el - I'd recommend retrying by using the matlab-load.el
>>> from master to see if that's the issue. I'll also look into this
>>> today.
>> Right. The strange thing is.
>>
>>      1. The graph is linear
>>
>>      2. Git does not complain when switching branches.
>>
>>      3. But when I use mercurial (and the hg-git plugin) mercurial
>>         notices a conflict!
>>
>>      4. So I did what you proposed, but it does not help: one your branch
>>         the traditional font-locking is broken. Good that we are testing
>>
>> Uwe
>
> Strange indeed. Fair enough, I'm happy we're still testing. I'll have 
> more time this evening to do a deep dive (git bisect should help, I 
> guess). I'll let you know if I manage to catch it.
>
> Best,
> Nidish
>
>
>
> _______________________________________________
> Matlab-emacs-discuss mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss

Re: [Matlab-emacs-discuss] [font-lock stopped working]

[Nidish N. B. <nid...@il...>]

> I have heard about this package but I have never used it myself.
I highly recommend checking it out! I use tree-sitter-hl for 
highlighting, and ts-fold for code folding.
>>   I have a feeling that something got mixed up when I refreshed the
>> matlab-load.el - I'd recommend retrying by using the matlab-load.el
>> from master to see if that's the issue. I'll also look into this
>> today.
>
> Right. The strange thing is.
>
>      1. The graph is linear
>
>      2. Git does not complain when switching branches.
>
>      3. But when I use mercurial (and the hg-git plugin) mercurial
>         notices a conflict!
>
>      4. So I did what you proposed, but it does not help: one your branch
>         the traditional font-locking is broken. Good that we are testing
>
> Uwe

Strange indeed. Fair enough, I'm happy we're still testing. I'll have 
more time this evening to do a deep dive (git bisect should help, I 
guess). I'll let you know if I manage to catch it.

Best,
Nidish

Re: [Matlab-emacs-discuss] [font-lock stopped working]

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

>>> "NNB" == Nidish Narayanaa Balaji <nid...@il...> writes:

> Wow that's interesting, thanks for noticing!
> I didn't catch this because I myself use tree-sitter for syntax
> highlighting and don't use the syntax highlighting from matlab-mode.

I have heard about this package but I have never used it myself.

>  I have a feeling that something got mixed up when I refreshed the
> matlab-load.el - I'd recommend retrying by using the matlab-load.el
> from master to see if that's the issue. I'll also look into this
> today.


Right. The strange thing is. 

    1. The graph is linear

    2. Git does not complain when switching branches.

    3. But when I use mercurial (and the hg-git plugin) mercurial
       notices a conflict!

    4. So I did what you proposed, but it does not help: one your branch
       the traditional font-locking is broken. Good that we are testing 

Uwe 
-- 
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] [font-lock stopped working] (was: [matlab-cell])

[Nidish N. B. <nid...@il...>]

Wow that's interesting, thanks for noticing!

I didn't catch this because I myself use tree-sitter for syntax 
highlighting and don't use the syntax highlighting from matlab-mode.

  I have a feeling that something got mixed up when I refreshed the 
matlab-load.el - I'd recommend retrying by using the matlab-load.el from 
master to see if that's the issue. I'll also look into this today.

Thanks!
Nidish

On 5/16/24 10:36, Uwe Brauer wrote:
>>>> "NNB" == Nidish Narayanaa Balaji <nid...@il...> writes:
>> I just finished the edits and pushed them.
>> 1. I've defined a 'matlab-cell-shell-run-cell' function in
>>     matlab-cell.el which basically calls 'matlab-shell-run-region' from
>>     matlab-shell.el with the appropriate bounds of the current point.
>> 2. I also simplified the cellbreak regexp to: (rx line-start (* space)
>>     (group "%%" (* (not (any "\n"))) line-end))
>>     This evaluates to: "^[[:space:]]*\\(%%.*$\\)"
>>     As mentioned before, I've removed the requirement of having a
>>     blank-space character after "%%" since I think this is more intuitive.
>> 3. I also refreshed 'matlab-load.el'.
> Hi
>
> I sometimes mix functions with scripts (that uses cell).
>
> I noticed that the font-lock for functions does not work anymore using
> your branch, even with matlab-cell-mode disabled and even in a function
> without cell as the attached screenshots shows.
>
> I also attach the screenshot with the fontlocking from master.
>
> Not sure who is the culprit here.
>
>
> Uwe
>
>

Re: [Matlab-emacs-discuss] [matlab-cell]

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

>>> "NNB" == Nidish Narayanaa Balaji <nid...@il...> writes:

> I just finished the edits and pushed them.
> 1. I've defined a 'matlab-cell-shell-run-cell' function in
>    matlab-cell.el which basically calls 'matlab-shell-run-region' from
>    matlab-shell.el with the appropriate bounds of the current point.

> 2. I also simplified the cellbreak regexp to: (rx line-start (* space)
>    (group "%%" (* (not (any "\n"))) line-end))
>    This evaluates to: "^[[:space:]]*\\(%%.*$\\)"
>    As mentioned before, I've removed the requirement of having a
>    blank-space character after "%%" since I think this is more intuitive.

> 3. I also refreshed 'matlab-load.el'.

Thanks. I just pulled, and compiled. I will run test and report back
later this evening. 

Thanks a lot
> Best,
> Nidish

> On 5/15/24 13:58, Uwe Brauer wrote:
>> 
>>> Yes this is true. This seems to be a restriction from
>>> matlab-shell-run-cell. I guess I'll just write a
>>> matlab-cell-shell-run-cell function that's more neatly integrated
>>> within the matlab-cell minor-mode.
>> I remember of having discussions with Eric, when that feature was
>> implemented, but alas I don't recall any details.
>> 
>> 
>>> The real restriction with matlab-cell is that I'm assuming that the
>>> cell header is "%%" followed by at least a space character - if
>>> there's no character right after the "%%", then this is not recognized
>>> as a cell header. This comes from the matlab-cell-cellbreak-regexp
>>> variable (which can be customized, of course).
>> But that seems fine to me, because that is (or at least was till
>> recently) the convention of the native matlab editor.
>> 
>> 
>>> I will change it to default to not requiring the space character after
>>> the "%%" since this makes more sense.
>>> I've added the list of navigation functions to the docstring.
>>> I'll try to have the above edits done by then!
>> 
>> Thanks, I just saw it. More testing, later
>> 
>> Thanks
>> 
>> Uwe
>> 
>> 

-- 
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-cell]

[Nidish N. B. <nid...@il...>]

I just finished the edits and pushed them.

 1. I've defined a 'matlab-cell-shell-run-cell' function in
    matlab-cell.el which basically calls 'matlab-shell-run-region' from
    matlab-shell.el with the appropriate bounds of the current point.

 2. I also simplified the cellbreak regexp to: (rx line-start (* space)
    (group "%%" (* (not (any "\n"))) line-end))
    This evaluates to: "^[[:space:]]*\\(%%.*$\\)"
    As mentioned before, I've removed the requirement of having a
    blank-space character after "%%" since I think this is more intuitive.

 3. I also refreshed 'matlab-load.el'.

Best,
Nidish

On 5/15/24 13:58, Uwe Brauer wrote:
>
>> Yes this is true. This seems to be a restriction from
>> matlab-shell-run-cell. I guess I'll just write a
>> matlab-cell-shell-run-cell function that's more neatly integrated
>> within the matlab-cell minor-mode.
> I remember of having discussions with Eric, when that feature was
> implemented, but alas I don't recall any details.
>
>
>> The real restriction with matlab-cell is that I'm assuming that the
>> cell header is "%%" followed by at least a space character - if
>> there's no character right after the "%%", then this is not recognized
>> as a cell header. This comes from the matlab-cell-cellbreak-regexp
>> variable (which can be customized, of course).
> But that seems fine to me, because that is (or at least was till
> recently) the convention of the native matlab editor.
>
>
>> I will change it to default to not requiring the space character after
>> the "%%" since this makes more sense.
>> I've added the list of navigation functions to the docstring.
>> I'll try to have the above edits done by then!
>
> Thanks, I just saw it. More testing, later
>
> Thanks
>
> Uwe
>
>

Re: [Matlab-emacs-discuss] [matlab-cell]

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

> Yes this is true. This seems to be a restriction from
> matlab-shell-run-cell. I guess I'll just write a
> matlab-cell-shell-run-cell function that's more neatly integrated
> within the matlab-cell minor-mode.

I remember of having discussions with Eric, when that feature was
implemented, but alas I don't recall any details.


> The real restriction with matlab-cell is that I'm assuming that the
> cell header is "%%" followed by at least a space character - if
> there's no character right after the "%%", then this is not recognized
> as a cell header. This comes from the matlab-cell-cellbreak-regexp
> variable (which can be customized, of course).

But that seems fine to me, because that is (or at least was till
recently) the convention of the native matlab editor.


> I will change it to default to not requiring the space character after
> the "%%" since this makes more sense.

> I've added the list of navigation functions to the docstring.
> I'll try to have the above edits done by then!


Thanks, I just saw it. More testing, later

Thanks

Uwe 


-- 
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.