matlab-emacs-discuss

[Matlab-emacs-discuss] Debugging in emacs is back !

[<dav...@fr...>]

Hi all,

 

First of all, I should probably say that I used to be a huge fan of the old matlab-emacs, back in the days when Matlab was supporting the External Editor Interface… So much so that for many years (probably until 2017) I kept using R2008b which was the last release to support EEI.

 

With the disappearance of EEI, things weren’t quite the same. It was no longer possible to debug within emacs. 

This week however, I decided to check again the latest version of matlab-emacs…. Oh joy !

 

Despite what the matlab-emacs documentation says (https://sourceforge.net/p/matlab-emacs/src/ci/master/tree/README.org), I discovered that debugging *.m files using Emacs as a debugger was possible again ! Add/remove breakpoints, step in and out ! That really made my day !

 

I think this should really be highlighted and advertised; I’m sure lots of people would love to learn it’s possible again !

 

Just a couple of question now.

 

The only thing that seems to be missing is tooltips showing the value of variables as the mouse hovers over the code.

I don’t expect that to happen overnight, but is there any hope ? is it technically possible ?

 

Also, to make previous outputs uneditable in shell/term-mode, I use the trick explained here https://emacs.stackexchange.com/a/2897

Although it fundamentally cohabitates with matlab-shell, there seems to be a number of side effects

 

The first one is that it seems to break (matlab-shell-tab). Instead of popping up a new window with completions, it dumps some stuff in the matlab shell buffer. For example typing ‘test’ TAB brings:

 

>> emacsdocomplete('test')

 

emacs_completions_output =

 

  java.lang.String[]:

    'testcholdout'

    'testckfold'

    'testconsole'

    'testGetInterface'

    'testpointCB'

    'testsort'

    'testsuite'

    'TestAndVerificationAutopilotExample'

 

The second one it seems, is that it breaks the hyperlinks normally created for error messages. For example, with

>> eye([1 1 1])

I now get:

 

<ERRORTXT>

Error using eye

N-dimensional arrays are not supported.

</ERRORTXT>

 

And the third one, is that the first time I step through any file, everything is nice and smooth.

One I quit the debug mode and start another stepping again, it becomes very sluggish.

At every step, emacs generates a message:

 

error in process filter: Text is read-only

 

Can anyone confirm these side effects, and does anyone know how to avoid them ?

If that’s the price to pay to debug in emacs, I am more than happy to renounce using the trick from https://emacs.stackexchange.com/a/2897 😊

 

PS: last note for anybody at Mathworks reading this.

The information found at https://blogs.mathworks.com/community/2009/09/14/matlab-emacs-integration-is-back/ seems a little out of date. For windows users it suggests using:

 

emacsinit('c:/applications/Emacs/lib-src/emacsclient -n');

 

But the current version of emacsinit doesn’t take any arguments….

 

Re: [Matlab-emacs-discuss] Debugging in emacs is back !

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

Hi David,

On 2/26/21 9:05 PM, dav...@fr... wrote:
> [...]
>
> With the disappearance of EEI, things weren’t quite the same. It was 
> no longer possible to debug within emacs.
>
> This week however, I decided to check again the latest version of 
> matlab-emacs…. Oh joy !
>

Glad you found it and it works for you!


> Despite what the matlab-emacs documentation says 
> (https://sourceforge.net/p/matlab-emacs/src/ci/master/tree/README.org 
> <https://sourceforge.net/p/matlab-emacs/src/ci/master/tree/README.org>), 
> I discovered that debugging *.m files using Emacs as a debugger was 
> possible again ! Add/remove breakpoints, step in and out ! That really 
> made my day !
>

Thanks for identifying the old statements in the README.  I had 
forgotten that was there.


> I think this should really be highlighted and advertised; I’m sure 
> lots of people would love to learn it’s possible again !
>

We can always use some help fixing up stuff like that.


> Just a couple of question now.
>
> The only thing that seems to be missing is tooltips showing the value 
> of variables as the mouse hovers over the code.
>
> I don’t expect that to happen overnight, but is there any hope ? is it 
> technically possible ?
>

You need to set `matlab-shell-debug-tooltips-p' to t to enable. They are 
off by default because it can flood the channel between Emacs and MATLAB 
and slow down.  But maybe they will work for you?

> Also, to make previous outputs uneditable in shell/term-mode, I use 
> the trick explained here https://emacs.stackexchange.com/a/2897 
> <https://emacs.stackexchange.com/a/2897>
>
> Although it fundamentally cohabitates with matlab-shell, there seems 
> to be a number of side effects
>

I have vague recollections of this.  I think there was just too much 
code around that assumed it could edit the buffer.  I also thought 
something with the prompt was broken, but maybe not anymore?

[...]
>
> Can anyone confirm these side effects, and does anyone know how to 
> avoid them ?
>
> If that’s the price to pay to debug in emacs, I am more than happy to 
> renounce using the trick from https://emacs.stackexchange.com/a/2897 
> <https://emacs.stackexchange.com/a/2897> 😊
>

MATLAB shell's process has to do a lot of gymnastics to do it's work.  
Some of the issue is related to MATLAB not always dumping it's output in 
contiguous blocks.  New output can result in needing to go back and 
modify old output.  Sometimes that's just about re-fonting, but we also 
go backward and delete old prompts and output once we know the output 
was designated from a command Emacs sent.


Each of the functions that does that needs to set inhibit-read-only. I 
think someone just needs to go in and find these cases and set 
inhibit-read-only to t.  I spend most of my days on Windows now so this 
sort of thing doesn't get in my way. Instead, there is a network based 
shell connection that works on Windows, but it doesn't support debugging 
due to the way K>> prompt & stack stuff works.  It does let you do some 
simple stuff, like running files you're working on from an Emacs keystroke.


> PS: last note for anybody at Mathworks reading this.
>
> The information found at 
> https://blogs.mathworks.com/community/2009/09/14/matlab-emacs-integration-is-back/ 
> <https://blogs.mathworks.com/community/2009/09/14/matlab-emacs-integration-is-back/> 
> seems a little out of date. For windows users it suggests using:
>
> emacsinit('c:/applications/Emacs/lib-src/emacsclient -n');
>
> But the current version of emacsinit doesn’t take any arguments….
>

We don't go back and modify old blog posts.  It might be time to post a 
new one though, and we could post a note on the old one to refer to the 
update.


If only work didn't keep me so busy... :)

Eric

Re: [Matlab-emacs-discuss] Debugging in emacs is back !

[<dav...@fr...>]

Hi Eric,

Thank you so much for the feedback and the amazing work you've done to resuscitate debugging in emacs !!

> You need to set `matlab-shell-debug-tooltips-p' to t to enable. They are 
> off by default because it can flood the channel between Emacs and MATLAB 
> and slow down.  But maybe they will work for you?

Yes indeed, that works for me !! This is really awesome !

Occasionally I've had issues with tooltips, used to show mlint warnings for example. 
I've had this for years, without understanding what the root cause is. It seems to come and go, perhaps depending on which machine I'm running on.
When tooltips don't work, I get " Error running timer `tooltip-timeout': (wrong-type-argument markerp nil) "

But I don't think this is related to matlab-emacs at all - this has been reported in other contexts:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2015-02/msg00946.html

Thanks !
David