[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: could matlab-mode be in ELPA or the GNU emacs tree (like auctex and org-mode)?
Date: Sun, 21 Nov 2021 10:39:31 +0200

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

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

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

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

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

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

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

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]