Re: [Matlab-emacs-discuss] execute matlab in a different directory. GNU vs Xemacs

[Andrzej P. <a.p...@gm...>]

Hi,

Thanks for letting me know about this discussion.

My original goal was to "modernize" the matlab-mode a bit by adding
compatibility with new popular packages and some fixes. Were the original
mode on github, I would have simply made a pull request afterwards. I've
made the following changes (as listed in the github readme):
- New company-matlab.el backend that works both inside the Matlab shell and
in Matlab files
- New flycheck-mlint back-end for flycheck which uses mlint to highlight
warnings in Matlab files.
- Fixed additional newlines and incorrect formatting of prompt after
completion
- Fixed version parsing for new Matlab versions
- Re-enabled HTML parsing

In the current situation I suggest one of the following options:
- Creating a new repo on github and merging my changes there
- Using my repo as a starting point and moving forward from there, I'm not
going to do much development myself anymore, but can take pull requests.

In general, since I don't know what the current situation of the original
matlab-mode is, I'll let you guys decide and say that I'm fine with
anything that moves matlab-mode to github (to facilitate future
development) and brings in the features I added.

Best,
Andrzej


On Wed, Feb 3, 2016 at 8:43 AM dl <fri...@ho...> wrote:

> i added the independent matlab-mode github contributers to this mail.
> maybe they read it.
>
> just to make myself clear. Im not saying we (or they) should merge their
> packages, although that would be good. what i meant is:
>
> if the official project was in github originally, these people would have
> just branched the original repo, and possibly suggested pull requests to
> the official project. if Eric can't work on it, its ok, other people might
> work on it.
>
> thus if it is to start anew, i would say better do it in github to
> facilitate these sporadic developers that we known are using github to
> contribute their work.
>
> ps to uwe:
> company-mode is an autocompletion framework. its very good when it works
>
> On Wed, Feb 3, 2016 at 3:35 PM, Uwe Brauer <ou...@ma...> wrote:
>
>> >>> "dl" == dl  <fri...@ho...> writes:
>>
>>    > since this conversation is now active, i would just like to comment
>>    > that the following repo in github, https://github.com/pronobis/
>>    > matlab-mode (not sure the owner is in this list) provides a modified
>>    > matlab-mode with very good company-mode support. As an emacs newbie
>>    > (~ 2 years of use and no elisp skills) that was easier to setup with
>>    > autocompletion than the original cvs matlab-mode.
>>
>>    > besides there's at least one other modified version of matlab-mode in
>>    > github, https://github.com/yuhonglin/matlab-mode, which i havent
>>    > tried, but its worked out company-mode and matlab documentation
>>    > support according to the description.
>>
>>
>> I checked them both (they use the same name matlab-mode, which makes
>> cloning fun)
>>
>> The first one had his last entry Jul 24:
>>
>> ,----
>> |
>> | commit dfd935346f6fd204b132f9b0b1d048308d77ef72
>> | Author: Andrzej Pronobis <a.p...@gm...>
>> | Date:   Fri Jul 24 13:52:46 2015 -0700
>> |
>> |     Fixed error when no matlab found.
>> `----
>>
>> And a lot of entries Mar 19, most likely the day he made the
>> immigration. Just of these entries reads as:
>> ,----
>> | commit 8618a2b530a23df54751d6e4a5ba3d7c8cbda824
>> | Author: Andrzej Pronobis <a.p...@gm...>
>> | Date:   Thu Mar 19 21:00:24 2015 -0700
>> |
>> |     Readme
>> `----
>>
>> The other are similar, before that
>> ,----
>> | commit f7594986a685882bbe856b99be1cb4ea1eab91a6
>> | Author: Eric M. Ludlam <>
>> | Date:   Sat Dec 27 12:44:52 2014 +0000
>> `----
>>
>> So it does not look like a very active development.
>>
>> Yuhonglin is more active:
>> Last commit:
>>
>> ,----
>> | commit b9bf51f54539293fef843721852d4b5bb4210e74
>> | Author: Honglin Yu <yuh...@gm...>
>> | Date:   Tue Dec 1 15:32:53 2015 +1100
>> |
>> |     fix bug in jtd-matlab-process-received-data
>> |
>> |     In determining whether rawreturn ends with '.m', should not
>> |     just compare result of s-shared-end and empty string. Since
>> |     if the rawreturn ends with 'm' but not '.m', it will not "".
>> `----
>> but his mode seems quite a bit different.
>>
>> So I think it would be best to ask the authors,
>>
>>     -  what there fork is about (which are the new features)
>>
>>     -  whether they are willing to merge back (if that is possible)
>>
>> Uwe Brauer
>>
>>
>