Re: [Matlab-emacs-discuss] completion and goto-function in matlab-mode (Doom emacs)

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

Hi Uwe,

Some items to test:


  *   The handling of *.m files. matlab.el used to contain:

(add-to-list 'auto-mode-alist '("\\.m$" . matlab-mode))

which overrides the Emacs default of associating *.m files with objc-mode. This setting means it isn't possible to edit in objc-mode for *.m objective-c files and matlab-mode for *.m matlab files in the same session.

I switched it to use

(add-to-list 'magic-mode-alist '(matlab-is-matlab-file . matlab-mode))

this way Linux distributions can setup Emacs such that it will work correctly when the content of a *.m file is matlab and in the same emacs session when the content of a *.m is objective-c.

After deploying the latest updates to matlab-mode, I wonder if you could ping the Linux distributions, e.g. Debian to make the above change?

  *   The tab completion capability in *.m files when matlab-shell is running
  *   Improved block comments %{ %}
  *   Handling of events and arguments keyword "blocks"
  *   When leaving matlab-mode, mlint is turned off, e.g. change a file in matlab-mode to text-mode (not common).
  *   Most of the other changes are bug fixes, e.g. comment fill, hanlding of "..." at EOF, mlint handling when mlint path is invalid, etc.

Thanks
John



________________________________
From: Uwe Brauer <ou...@ma...>
Sent: Monday, November 30, 2020 2:53 AM
To: Eric Ludlam <eri...@gm...>
Cc: mat...@li... <mat...@li...>
Subject: Re: [Matlab-emacs-discuss] completion and goto-function in matlab-mode (Doom emacs)

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

> On 11/29/20 10:45 AM, Uwe Brauer wrote:
>>>>> "EL" == Eric Ludlam <eri...@gm...> writes:
>>> Hi Uwe,
>>> There are a bunch of old misc fixes over in the usage1 branch that we
>>> should probably merge into master.  The save-and-go work I was doing
>>> never became as robust as I wanted, but it should be transparent if no
>>> one tries to activate the feature.  It also includes my patch for
>>> completion I posted yesterday.
>>> Doing the merge will let us retire usage1.
>>
>> The last commit on that branch seems to be
>> c22998376b623f79b196cc30273d1ae5c8218e16
>> which is of today.
>> I merge that one into master, ok?
>>
> Yes, I put in some patches from John into usage1 that fixes some
> hangs, and also a first cut at a piece of the completion using the
> shell patch I posted a bit earlier.

> We've been using a majority of those patches deployed at MW for a
> while, so they should be good to go.  If the completion bit seems too
> risky, feel free to leave it out.

I compiled, is it ok to test it for one day before pushing?

Is there anything specific I should test? Sorry I did not pay too much
attention to the completion issue as I should have.

Uwe