matlab-emacs-discuss — Discuss Emacs/MATLAB integration

[Matlab-emacs-discuss] Fwd: Missing execution line pointer after upgrading Matlab

[Odd A. <odd...@gm...>]

In case anybody is interested, here is the "patch" I wrote that enables the
debugger to update the instruction line pointer with newer versions of
Matlab.
The m-file should go in the toolbox directory, the other file describes the
changes I made to matlab.el.

Odd A.

On Fri, Jan 29, 2016 at 11:29 PM, Eric Ludlam <Eri...@ma...>
wrote:

> Hi,
>
>
>
> That looks like a great idea for a simple fix.   You might be able to
> shadow “dbstep” in the Matlab-emacs toolbox directory, and have it call
>
>
>
> builtin(‘dbstep’,...)
>
>
>
> to dispatch, then fprintf items out.
>
>
>
> I’m not sure why it wouldn’t remove the hotlink text.   That will need
> some time in the Emacs debugger around matlab-shell-render-anchor to know.
>
>
>
> Eric
>
>
>
> *From:* Odd Andersen [mailto:odd...@gm...]
> *Sent:* Friday, January 29, 2016 12:10 PM
> *To:* mat...@li...
> *Subject:* Re: [Matlab-emacs-discuss] Missing execution line pointer
> after upgrading Matlab
>
>
>
> Hi Eric, and thanks for answering.
>
> I have looked a bit at the problem myself.
>
> I was able to find a relatively nonintrusive (but hacky) workaround by
> writing a function that emulates the "bug"/"feature" of earlier Matlab
> versions, putting it in the "toolbox" folder, and calling it alongside with
> the db-commands that are specified for gud in matlab.el.
>
> In other words, placing the following file in 'toolbox':
>
> function dbhotlink()
>    [ST, I] = dbstack('-completenames');
>    fprintf('<a href="matlab: opentoline(''%s'',%i,1)">%i </a>\n',
> ST(2).file, ST(2).line, ST(2).line);
> end
>
>
>
> and then modifying lines 4542 and 4543 in matlab.el to read:
>
> (gud-def gud-step   "dbstep in;\ndbhotlink();\n"           "\C-s" "Step
> one source line, possibly into a function.")
> (gud-def gud-next   "dbstep %p;\ndbhotlink();\n"           "\C-n" "Step
> over one source line.")
>
> This sort of works, but with some drawbacks:
>
> - The text line generated by 'dbhotlink' is not properly removed from the
> pty (could perhaps be fixed with some modification of the relevant
> regexes..)
>
> - The stack pointer is only updated when using the "next" (C-n) or "step
> in" (C-s) functions.
>
> Odd A.
>
> [image: Image removed by sender.]
>
>
>
> On Fri, Jan 29, 2016 at 6:08 PM, Odd Andersen <odd...@gm...>
> wrote:
>
> Hi Eric, and thanks for answering.
>
> I have looked a bit at the problem myself.
>
> I was able to find a relatively nonintrusive (but hacky) workaround by
> writing a function that emulates the "bug"/"feature" of earlier Matlab
> versions, putting it in the "toolbox" folder, and calling it alongside with
> the db-commands that are specified for gud in matlab.el.
>
> In other words, placing the following file in 'toolbox':
>
> function dbhotlink()
>    [ST, I] = dbstack('-completenames');
>    fprintf('<a href="matlab: opentoline(''%s'',%i,1)">%i </a>\n',
> ST(2).file, ST(2).line, ST(2).line);
> end
>
>
>
> and then modifying lines 4542 and 4543 in matlab.el to read:
>
> (gud-def gud-step   "dbstep in;\ndbhotlink();\n"           "\C-s" "Step
> one source line, possibly into a function.")
> (gud-def gud-next   "dbstep %p;\ndbhotlink();\n"           "\C-n" "Step
> over one source line.")
>
> This sort of works, but with some drawbacks:
>
> - The text line generated by 'dbhotlink' is not properly removed from the
> pty (could perhaps be fixed with some modification of the relevant
> regexes..)
>
> - The stack pointer is only updated when using the "next" (C-n) or "step
> in" (C-s) functions.
>
> Odd A.
>
>
>
> On Fri, Jan 29, 2016 at 3:30 PM, Eric Ludlam <Eri...@ma...>
> wrote:
>
> Hi,
>
>
>
> I have looked into this, and in Earlier MATLABs I used to take advantage
> of a “bug”, which I thought was a feature, that allowed MATLAB to send me
> html like anchors which I could interpret.  MATLAB is now correctly
> identifying that it is not pointing at a device that supports anchors
> (since it is a plain pty), so I don’t have the data.
>
>
>
> I asked a couple folks about this and I don’t believe there is a trick I
> can pull to get this data to be output to Emacs with the newer MATLABs,
> which leaves things kind of broken.
>
>
>
> Before the links, I used to interpret the plaintext, but this was buggy,
> and simple output tweaks from MATLAB, or locale changes would mess it up,
> so it doesn’t seem too good either, but could be resurrected.  I don’t
> really have the bandwidth for that kind of refactoring project though. L
>
>
>
> Eric
>
>
>
> *From:* Odd Andersen [mailto:odd...@gm...]
> *Sent:* Wednesday, January 27, 2016 8:21 AM
> *To:* mat...@li...
> *Subject:* [Matlab-emacs-discuss] Missing execution line pointer after
> upgrading Matlab
>
>
>
>
>
> Hi,
>
> After I upgraded my Matlab version from R2014a to R2015b, I can no longer
> see the little arrow that indicates the current execution line while
> debugging matlab code using matlab-emacs.  Moreover, debugging seems to
> work poorly in other ways: it apparently no longer brings up the relevant
> code buffer while debugging (possibly tied to the problem above), and when
> arriving at a multi-line function call (i.e. where each line of text is
> continued with '...'), it no longer treats this as one line but insists on
> stepping over each text line separately.
>
> I saw someone else (Tunc Aydin) mentioned the missing execution line
> pointer on this mailing list last fall, and was answered by Eric Ludlam
> that apparently the "output Emacs was interpreting for the debugger has
> changed" and that this .  (
> http://sourceforge.net/p/matlab-emacs/mailman/message/34601964/)
>
> Has anyone looked into this since then?  matlab-emacs has worked wonders
> for me in the past, and it's very sad if it stops providing a practical
> debugging tool  as people upgrade to newer versions of Matlab.
>
> Best,
>
> Odd Andersen
>
>
>
>
>

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

[Eric L. <Eri...@ma...>]

I am not opposed to a move to some other DVCS.  I just don't do much development anymore, and I don't really get time at work to work on this sort of thing anymore.

If those active on this list would like to do a move, I can facilitate access, setup a new maintainer on SF, and will always be happy to research things from the MATLAB side to help out when I can.

In any move, a thing to watch out for is that in the past, many users don't have access to a CVS program, or any other VC software, so the special matlab download script was created to enable that.   Changes have been small and few, so full releases were not worthwhile to do.

Eric

-----Original Message-----
From: Uwe Brauer [mailto:ou...@ma...] 
Sent: Wednesday, February 03, 2016 9:24 AM
To: dl <fri...@ho...>
Cc: Uwe Brauer <ou...@ma...>; Eric Ludlam <Eri...@ma...>; matlab-emacs <mat...@li...>
Subject: Re: [Matlab-emacs-discuss] execute matlab in a different directory. GNU vs Xemacs

>>> "dl" == dl  <fri...@ho...> writes:

   > i will just add all the matlab-mode repos in github (there r several
   > branches additionally). thus i guess the project belongs there and
   > not on bitbucket

If they are actively maintained, then maybe, if they are orphaned packages then I think the question HG vs Git should be independent. In any case my feeling is there will be no transition from CVS to neither HG nor GIT.

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

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

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

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

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

>>> "dl" == dl  <fri...@ho...> writes:

   > i will just add all the matlab-mode repos in github (there r several
   > branches additionally). thus i guess the project belongs there and
   > not on bitbucket

If they are actively maintained, then maybe, if they are orphaned
packages then I think the question HG vs Git should be independent. In
any case my feeling is there will be no transition from CVS to neither
HG nor GIT.

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

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

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


Oh, that looks to me like a lot repeated work and effort. Does the first
of these packages provide a matlab shell and debugging?

I am not sure what do you mean by company-mode.

   > i think the existence of 2 github repos suggests that probably we
   > could gain from contributions of different people, if their
   > contributions get merged, and that would alleviate Eric from the
   > task.

The starting point of this discussion was to apply depending patches to
the matlab-emacs version in sourceforge.

Concerning the 2 other packages, Well I think in principle it would be
good to merge them , but 

    -  first one has to see the code, maybe a merge could be very complicated.

    -  I think it also depends very much whether these packages are
       actively maintained. 


Uwe Brauer 

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

[dl <fri...@ho...>]

i will just add all the matlab-mode repos in github (there r several
branches additionally). thus i guess the project belongs there and not on
bitbucket



   - pronobis/*matlab-mode* <https://github.com/pronobis/matlab-mode> Emacs
   Lisp 12 <https://github.com/pronobis/matlab-mode/stargazers> 4
   <https://github.com/pronobis/matlab-mode/network>

   Unofficial port of the CVS version of *matlab*-*mode* with fixes and new
   features.

   Updated on Jul 24, 2015

   - Emacs Lisp 1 <https://github.com/yuhonglin/matlab-mode/stargazers> 0
   <https://github.com/yuhonglin/matlab-mode/network>
   yuhonglin/*matlab-mode* <https://github.com/yuhonglin/matlab-mode>

   An emacs *matlab* *mode* based on the project http://*matlab*-
   emacs.sourceforge.net/

   Updated on Dec 1, 2015
   - Emacs Lisp 18 <https://github.com/ruediger/matlab-emacs/stargazers> 7
   <https://github.com/ruediger/matlab-emacs/network>
   ruediger/*matlab*-emacs <https://github.com/ruediger/matlab-emacs>

   (Unofficial GIT Import of the Official CVS Repo!) Major *mode* for Emacs
   for editing *MATLAB* code, and running *MATLAB* in an inferior shell.

   Updated on Jan 14, 2012
   - Emacs Lisp 0 <https://github.com/chachi/matlab-emacs/stargazers> 0
   <https://github.com/chachi/matlab-emacs/network>
   chachi/*matlab*-emacs <https://github.com/chachi/matlab-emacs>

   A clone of the Sourceforge CVS-based *matlab*-emacs *mode*.

   Updated on Oct 21, 2013
   - Emacs Lisp 1 <https://github.com/emacsmirror/matlab/stargazers> 0
   <https://github.com/emacsmirror/matlab/network>
   emacsmirror/*matlab* <https://github.com/emacsmirror/matlab>

   Major *mode* for *MATLAB*(R) dot-m files





On Wed, Feb 3, 2016 at 2:01 PM, dl <fri...@ho...> wrote:

> 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 think the existence of 2 github repos suggests that probably we could
> gain from contributions of different people, if their contributions get
> merged, and that would alleviate Eric from the task.
>
> d
>
>
>
>
>
> On Wed, Feb 3, 2016 at 12:43 PM, Uwe Brauer <ou...@ma...> wrote:
>
>> >>> "Eric" == Eric Ludlam <Eri...@ma...> writes:
>>
>>     > Thanks for the offer Uwe, help would be great.
>>     > I have not moved from CVS to git because:
>>
>>     > 1) I'm only vaguely familiar with git, and not at all w/ mercurial
>>     > 2) the matlab-emacs project is in maintenance mode, and doesn't seem
>>     > to need the richness of a DVCS at this time.
>>
>>
>> Right. I think the user would just need to do
>>
>>  clone  https://lu...@bi.../ludlam/matlab-emacs
>>
>> Or any other account we want to set up.
>>
>> The coder/maintainer would do
>>
>>  clone  https://lu...@bi.../ludlam/matlab-emacs
>> (some simple setting in the $HOME/.hgrc file and then)
>>
>>  provide new exciting code,
>>  apply patches
>>  hg commit -m "Patch applied"
>>  hg push
>>
>> Things get complicated if branching and merging is concerned, but this
>> seems not to be our case.
>>
>>     > 3) Lazy.
>>
>>     > If there was some compelling development going on that needed a DVCS
>>     > then I think it would be worth considering a migration. Is CVS just
>> a
>>     > non-starter for you, or is hg just more fun?
>>
>>
>> Well I have been a regular RCS user for years, but used CVS very
>> sparsely years ago when I was contributing to the Xemacs pkg system (the
>> xemacs team finally changed from CVS to, guess what, HG). So I don't
>> recall any commands for CVS whatsoever sorry.
>>
>> Since I found to manage my Latex projects with RCS cumbersome, and some
>> people advised me against the use of CVS or subversion because of
>> performance issues, I gave  git and hg a try.
>>
>> At the end I decided to use hg, because:
>>
>>     -  it supports MaC Linux Windows without a problem (some time ago
>>        git only ran on Mac or  Linux)
>>
>>     -  it comes with a graphical interface which I don't use but some
>>        people might prefer.
>>
>>     -  it was easy to import my RCS files
>>
>>     -  it has more intuitive features (at least for me) than git.
>>
>>     -  bitbucket turned out to be great for collaboration.
>>
>> So here is my proposal:
>>
>>
>>     -  I will set up a bitbucket account with the imported CVS
>>        matlab-emacs and you have a look (BTW it seems not possible to
>>        import the mailing list to bitbucket and all the other addons, at
>>        least not as long as matlab-emacs is under CVS, it seems that
>>        sourceforge now also supports git/HG but I don't know how to
>>        proceed there. Bitbucket claims that it can import a sourceforge
>>        project which is under HG control (But once it is under HG in
>>        sourceforge  why then importing it to bitbucket you might ask)
>>
>>     -  I will do the same for git and use the git-hg plugin which allows
>>        me to have locally a HG repo which I push to a local GIT repo
>>        which I push then to the server, in theory, I admit I have never
>>        done this in practice.
>>
>>     -  ignore my idea, because if we make that change but then somehow I
>>        disappear you will be left with a new mess. But in order to help
>>        I would then need a couple of commands to commit and push
>>        changes.
>>
>> Uwe
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>> _______________________________________________
>> Matlab-emacs-discuss mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss
>>
>>
>

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

[dl <fri...@ho...>]

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 think the existence of 2 github repos suggests that probably we could
gain from contributions of different people, if their contributions get
merged, and that would alleviate Eric from the task.

d





On Wed, Feb 3, 2016 at 12:43 PM, Uwe Brauer <ou...@ma...> wrote:

> >>> "Eric" == Eric Ludlam <Eri...@ma...> writes:
>
>     > Thanks for the offer Uwe, help would be great.
>     > I have not moved from CVS to git because:
>
>     > 1) I'm only vaguely familiar with git, and not at all w/ mercurial
>     > 2) the matlab-emacs project is in maintenance mode, and doesn't seem
>     > to need the richness of a DVCS at this time.
>
>
> Right. I think the user would just need to do
>
>  clone  https://lu...@bi.../ludlam/matlab-emacs
>
> Or any other account we want to set up.
>
> The coder/maintainer would do
>
>  clone  https://lu...@bi.../ludlam/matlab-emacs
> (some simple setting in the $HOME/.hgrc file and then)
>
>  provide new exciting code,
>  apply patches
>  hg commit -m "Patch applied"
>  hg push
>
> Things get complicated if branching and merging is concerned, but this
> seems not to be our case.
>
>     > 3) Lazy.
>
>     > If there was some compelling development going on that needed a DVCS
>     > then I think it would be worth considering a migration. Is CVS just a
>     > non-starter for you, or is hg just more fun?
>
>
> Well I have been a regular RCS user for years, but used CVS very
> sparsely years ago when I was contributing to the Xemacs pkg system (the
> xemacs team finally changed from CVS to, guess what, HG). So I don't
> recall any commands for CVS whatsoever sorry.
>
> Since I found to manage my Latex projects with RCS cumbersome, and some
> people advised me against the use of CVS or subversion because of
> performance issues, I gave  git and hg a try.
>
> At the end I decided to use hg, because:
>
>     -  it supports MaC Linux Windows without a problem (some time ago
>        git only ran on Mac or  Linux)
>
>     -  it comes with a graphical interface which I don't use but some
>        people might prefer.
>
>     -  it was easy to import my RCS files
>
>     -  it has more intuitive features (at least for me) than git.
>
>     -  bitbucket turned out to be great for collaboration.
>
> So here is my proposal:
>
>
>     -  I will set up a bitbucket account with the imported CVS
>        matlab-emacs and you have a look (BTW it seems not possible to
>        import the mailing list to bitbucket and all the other addons, at
>        least not as long as matlab-emacs is under CVS, it seems that
>        sourceforge now also supports git/HG but I don't know how to
>        proceed there. Bitbucket claims that it can import a sourceforge
>        project which is under HG control (But once it is under HG in
>        sourceforge  why then importing it to bitbucket you might ask)
>
>     -  I will do the same for git and use the git-hg plugin which allows
>        me to have locally a HG repo which I push to a local GIT repo
>        which I push then to the server, in theory, I admit I have never
>        done this in practice.
>
>     -  ignore my idea, because if we make that change but then somehow I
>        disappear you will be left with a new mess. But in order to help
>        I would then need a couple of commands to commit and push
>        changes.
>
> Uwe
>
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Matlab-emacs-discuss mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss
>
>

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

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

>>> "Eric" == Eric Ludlam <Eri...@ma...> writes:

    > Thanks for the offer Uwe, help would be great.
    > I have not moved from CVS to git because:

    > 1) I'm only vaguely familiar with git, and not at all w/ mercurial
    > 2) the matlab-emacs project is in maintenance mode, and doesn't seem
    > to need the richness of a DVCS at this time.


Right. I think the user would just need to do 

 clone  https://lu...@bi.../ludlam/matlab-emacs

Or any other account we want to set up.

The coder/maintainer would do

 clone  https://lu...@bi.../ludlam/matlab-emacs
(some simple setting in the $HOME/.hgrc file and then)

 provide new exciting code,
 apply patches
 hg commit -m "Patch applied"
 hg push

Things get complicated if branching and merging is concerned, but this
seems not to be our case.

    > 3) Lazy.

    > If there was some compelling development going on that needed a DVCS
    > then I think it would be worth considering a migration. Is CVS just a
    > non-starter for you, or is hg just more fun?


Well I have been a regular RCS user for years, but used CVS very
sparsely years ago when I was contributing to the Xemacs pkg system (the
xemacs team finally changed from CVS to, guess what, HG). So I don't
recall any commands for CVS whatsoever sorry.

Since I found to manage my Latex projects with RCS cumbersome, and some
people advised me against the use of CVS or subversion because of
performance issues, I gave  git and hg a try.

At the end I decided to use hg, because:

    -  it supports MaC Linux Windows without a problem (some time ago
       git only ran on Mac or  Linux)

    -  it comes with a graphical interface which I don't use but some
       people might prefer.

    -  it was easy to import my RCS files

    -  it has more intuitive features (at least for me) than git.

    -  bitbucket turned out to be great for collaboration.

So here is my proposal:


    -  I will set up a bitbucket account with the imported CVS
       matlab-emacs and you have a look (BTW it seems not possible to
       import the mailing list to bitbucket and all the other addons, at
       least not as long as matlab-emacs is under CVS, it seems that
       sourceforge now also supports git/HG but I don't know how to
       proceed there. Bitbucket claims that it can import a sourceforge
       project which is under HG control (But once it is under HG in
       sourceforge  why then importing it to bitbucket you might ask)

    -  I will do the same for git and use the git-hg plugin which allows
       me to have locally a HG repo which I push to a local GIT repo
       which I push then to the server, in theory, I admit I have never
       done this in practice.

    -  ignore my idea, because if we make that change but then somehow I
       disappear you will be left with a new mess. But in order to help
       I would then need a couple of commands to commit and push
       changes.

Uwe 

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

[Eric L. <Eri...@ma...>]

Thanks for the offer Uwe, help would be great.

I have not moved from CVS to git because:

1) I'm only vaguely familiar with git, and not at all w/ mercurial
2) the matlab-emacs project is in maintenance mode, and doesn't seem to need the richness of a DVCS at this time.
3) Lazy.

If there was some compelling development going on that needed a DVCS then I think it would be worth considering a migration.  Is CVS just a non-starter for you, or is hg just more fun?

Eric

-----Original Message-----
From: Uwe Brauer [mailto:ou...@ma...] 
Sent: Saturday, January 30, 2016 12:32 PM
To: Eric Ludlam <Eri...@ma...>
Cc: Uwe Brauer <ou...@ma...>; Torben Knudsen <tk...@es...>; matlab-emacs <mat...@li...>
Subject: Re: [Matlab-emacs-discuss] execute matlab in a different directory. GNU vs Xemacs

>>> "Eric" == Eric Ludlam <Eri...@ma...> writes:

    > I have some pending patches I haven't gotten around to pushing up into
    > CVS. I don't like pushing patches without checking the results myself,
    > and things have been busy lately.

    > I could definitely use help for this sort of thing.

    > Eric

Hi

I would not mind to volunteer, but CVS? Couldn't we convert it to a more modern system, git or mercurial? I propose the later, because

      - I am acquainted with HG, I also use bitbucket which would be a
        natural site then.

      - I have successfully converted various CVS/RCS repos to
        mercurial but don't know how to do this for git.

Tell me what you think.

Uwe 

Re: [Matlab-emacs-discuss] Missing execution line pointer after upgrading Matlab

[Odd A. <odd...@gm...>]

Hi, I have sent my changes to the admin, in case he wants to review/test it
and post a patch to the website.

Odd A.

On Mon, Feb 1, 2016 at 4:13 PM, Tunc Aydin <tun...@gm...> wrote:

> Hi guys, this sounds promising! Any chance of pushing the workaround to
> the repository? After fighting for a couple of weeks to configure
> matlab-emacs on my spacemacs I unfortunately had to go back to matlab's
> IDE, mainly because debugging is very tedious in emacs atm.
>
> Best,
> -tunc
> On Fri, Jan 29, 2016 at 11:29 PM Eric Ludlam <Eri...@ma...>
> wrote:
>
>> Hi,
>>
>>
>>
>> That looks like a great idea for a simple fix.   You might be able to
>> shadow “dbstep” in the Matlab-emacs toolbox directory, and have it call
>>
>>
>>
>> builtin(‘dbstep’,...)
>>
>>
>>
>> to dispatch, then fprintf items out.
>>
>>
>>
>> I’m not sure why it wouldn’t remove the hotlink text.   That will need
>> some time in the Emacs debugger around matlab-shell-render-anchor to know.
>>
>>
>>
>> Eric
>>
>>
>>
>> *From:* Odd Andersen [mailto:odd...@gm...]
>> *Sent:* Friday, January 29, 2016 12:10 PM
>> *To:* mat...@li...
>> *Subject:* Re: [Matlab-emacs-discuss] Missing execution line pointer
>> after upgrading Matlab
>>
>>
>>
>> Hi Eric, and thanks for answering.
>>
>> I have looked a bit at the problem myself.
>>
>> I was able to find a relatively nonintrusive (but hacky) workaround by
>> writing a function that emulates the "bug"/"feature" of earlier Matlab
>> versions, putting it in the "toolbox" folder, and calling it alongside with
>> the db-commands that are specified for gud in matlab.el.
>>
>> In other words, placing the following file in 'toolbox':
>>
>> function dbhotlink()
>>    [ST, I] = dbstack('-completenames');
>>    fprintf('<a href="matlab: opentoline(''%s'',%i,1)">%i </a>\n',
>> ST(2).file, ST(2).line, ST(2).line);
>> end
>>
>>
>>
>> and then modifying lines 4542 and 4543 in matlab.el to read:
>>
>> (gud-def gud-step   "dbstep in;\ndbhotlink();\n"           "\C-s" "Step
>> one source line, possibly into a function.")
>> (gud-def gud-next   "dbstep %p;\ndbhotlink();\n"           "\C-n" "Step
>> over one source line.")
>>
>> This sort of works, but with some drawbacks:
>>
>> - The text line generated by 'dbhotlink' is not properly removed from the
>> pty (could perhaps be fixed with some modification of the relevant
>> regexes..)
>>
>> - The stack pointer is only updated when using the "next" (C-n) or "step
>> in" (C-s) functions.
>>
>> Odd A.
>>
>> [image: Image removed by sender.]
>>
>>
>>
>> On Fri, Jan 29, 2016 at 6:08 PM, Odd Andersen <odd...@gm...>
>> wrote:
>>
>> Hi Eric, and thanks for answering.
>>
>> I have looked a bit at the problem myself.
>>
>> I was able to find a relatively nonintrusive (but hacky) workaround by
>> writing a function that emulates the "bug"/"feature" of earlier Matlab
>> versions, putting it in the "toolbox" folder, and calling it alongside with
>> the db-commands that are specified for gud in matlab.el.
>>
>> In other words, placing the following file in 'toolbox':
>>
>> function dbhotlink()
>>    [ST, I] = dbstack('-completenames');
>>    fprintf('<a href="matlab: opentoline(''%s'',%i,1)">%i </a>\n',
>> ST(2).file, ST(2).line, ST(2).line);
>> end
>>
>>
>>
>> and then modifying lines 4542 and 4543 in matlab.el to read:
>>
>> (gud-def gud-step   "dbstep in;\ndbhotlink();\n"           "\C-s" "Step
>> one source line, possibly into a function.")
>> (gud-def gud-next   "dbstep %p;\ndbhotlink();\n"           "\C-n" "Step
>> over one source line.")
>>
>> This sort of works, but with some drawbacks:
>>
>> - The text line generated by 'dbhotlink' is not properly removed from the
>> pty (could perhaps be fixed with some modification of the relevant
>> regexes..)
>>
>> - The stack pointer is only updated when using the "next" (C-n) or "step
>> in" (C-s) functions.
>>
>> Odd A.
>>
>>
>>
>> On Fri, Jan 29, 2016 at 3:30 PM, Eric Ludlam <Eri...@ma...>
>> wrote:
>>
>> Hi,
>>
>>
>>
>> I have looked into this, and in Earlier MATLABs I used to take advantage
>> of a “bug”, which I thought was a feature, that allowed MATLAB to send me
>> html like anchors which I could interpret.  MATLAB is now correctly
>> identifying that it is not pointing at a device that supports anchors
>> (since it is a plain pty), so I don’t have the data.
>>
>>
>>
>> I asked a couple folks about this and I don’t believe there is a trick I
>> can pull to get this data to be output to Emacs with the newer MATLABs,
>> which leaves things kind of broken.
>>
>>
>>
>> Before the links, I used to interpret the plaintext, but this was buggy,
>> and simple output tweaks from MATLAB, or locale changes would mess it up,
>> so it doesn’t seem too good either, but could be resurrected.  I don’t
>> really have the bandwidth for that kind of refactoring project though. L
>>
>>
>>
>> Eric
>>
>>
>>
>> *From:* Odd Andersen [mailto:odd...@gm...]
>> *Sent:* Wednesday, January 27, 2016 8:21 AM
>> *To:* mat...@li...
>> *Subject:* [Matlab-emacs-discuss] Missing execution line pointer after
>> upgrading Matlab
>>
>>
>>
>>
>>
>> Hi,
>>
>> After I upgraded my Matlab version from R2014a to R2015b, I can no longer
>> see the little arrow that indicates the current execution line while
>> debugging matlab code using matlab-emacs.  Moreover, debugging seems to
>> work poorly in other ways: it apparently no longer brings up the relevant
>> code buffer while debugging (possibly tied to the problem above), and when
>> arriving at a multi-line function call (i.e. where each line of text is
>> continued with '...'), it no longer treats this as one line but insists on
>> stepping over each text line separately.
>>
>> I saw someone else (Tunc Aydin) mentioned the missing execution line
>> pointer on this mailing list last fall, and was answered by Eric Ludlam
>> that apparently the "output Emacs was interpreting for the debugger has
>> changed" and that this .  (
>> http://sourceforge.net/p/matlab-emacs/mailman/message/34601964/)
>>
>> Has anyone looked into this since then?  matlab-emacs has worked wonders
>> for me in the past, and it's very sad if it stops providing a practical
>> debugging tool  as people upgrade to newer versions of Matlab.
>>
>> Best,
>>
>> Odd Andersen
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>> _______________________________________________
>> Matlab-emacs-discuss mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss
>>
>

[Matlab-emacs-discuss] [Success: CVS2HG] (was: execute matlab in a different directory. GNU vs Xemacs)

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

>>> "Eric" == Eric Ludlam <Eri...@ma...> writes:

   > I have some pending patches I haven't gotten around to pushing up into
   > CVS. I don't like pushing patches without checking the results myself,
   > and things have been busy lately.

   > I could definitely use help for this sort of thing.

«Just for fun» I converted the actual CVS to Mercurial, without any
apparent problem. I just wanted to let you know this, in case you are
considering a change to a more modern version control system seriously.

Ah BTW, since people argue, changing to git is preferrable since it
attracts more developers, here is an interesting analysis by Lars
Ingebrigsten, the author of gnus, about GNU emacs when switching to git.

http://lars.ingebrigtsen.no/2015/04/23/the-effect-of-version-control-systems-on-emacs-developers/

conclusion: no benefit.

Re: [Matlab-emacs-discuss] Missing execution line pointer after upgrading Matlab

[Tunc A. <tun...@gm...>]

Hi guys, this sounds promising! Any chance of pushing the workaround to the
repository? After fighting for a couple of weeks to configure matlab-emacs
on my spacemacs I unfortunately had to go back to matlab's IDE, mainly
because debugging is very tedious in emacs atm.

Best,
-tunc
On Fri, Jan 29, 2016 at 11:29 PM Eric Ludlam <Eri...@ma...>
wrote:

> Hi,
>
>
>
> That looks like a great idea for a simple fix.   You might be able to
> shadow “dbstep” in the Matlab-emacs toolbox directory, and have it call
>
>
>
> builtin(‘dbstep’,...)
>
>
>
> to dispatch, then fprintf items out.
>
>
>
> I’m not sure why it wouldn’t remove the hotlink text.   That will need
> some time in the Emacs debugger around matlab-shell-render-anchor to know.
>
>
>
> Eric
>
>
>
> *From:* Odd Andersen [mailto:odd...@gm...]
> *Sent:* Friday, January 29, 2016 12:10 PM
> *To:* mat...@li...
> *Subject:* Re: [Matlab-emacs-discuss] Missing execution line pointer
> after upgrading Matlab
>
>
>
> Hi Eric, and thanks for answering.
>
> I have looked a bit at the problem myself.
>
> I was able to find a relatively nonintrusive (but hacky) workaround by
> writing a function that emulates the "bug"/"feature" of earlier Matlab
> versions, putting it in the "toolbox" folder, and calling it alongside with
> the db-commands that are specified for gud in matlab.el.
>
> In other words, placing the following file in 'toolbox':
>
> function dbhotlink()
>    [ST, I] = dbstack('-completenames');
>    fprintf('<a href="matlab: opentoline(''%s'',%i,1)">%i </a>\n',
> ST(2).file, ST(2).line, ST(2).line);
> end
>
>
>
> and then modifying lines 4542 and 4543 in matlab.el to read:
>
> (gud-def gud-step   "dbstep in;\ndbhotlink();\n"           "\C-s" "Step
> one source line, possibly into a function.")
> (gud-def gud-next   "dbstep %p;\ndbhotlink();\n"           "\C-n" "Step
> over one source line.")
>
> This sort of works, but with some drawbacks:
>
> - The text line generated by 'dbhotlink' is not properly removed from the
> pty (could perhaps be fixed with some modification of the relevant
> regexes..)
>
> - The stack pointer is only updated when using the "next" (C-n) or "step
> in" (C-s) functions.
>
> Odd A.
>
> [image: Image removed by sender.]
>
>
>
> On Fri, Jan 29, 2016 at 6:08 PM, Odd Andersen <odd...@gm...>
> wrote:
>
> Hi Eric, and thanks for answering.
>
> I have looked a bit at the problem myself.
>
> I was able to find a relatively nonintrusive (but hacky) workaround by
> writing a function that emulates the "bug"/"feature" of earlier Matlab
> versions, putting it in the "toolbox" folder, and calling it alongside with
> the db-commands that are specified for gud in matlab.el.
>
> In other words, placing the following file in 'toolbox':
>
> function dbhotlink()
>    [ST, I] = dbstack('-completenames');
>    fprintf('<a href="matlab: opentoline(''%s'',%i,1)">%i </a>\n',
> ST(2).file, ST(2).line, ST(2).line);
> end
>
>
>
> and then modifying lines 4542 and 4543 in matlab.el to read:
>
> (gud-def gud-step   "dbstep in;\ndbhotlink();\n"           "\C-s" "Step
> one source line, possibly into a function.")
> (gud-def gud-next   "dbstep %p;\ndbhotlink();\n"           "\C-n" "Step
> over one source line.")
>
> This sort of works, but with some drawbacks:
>
> - The text line generated by 'dbhotlink' is not properly removed from the
> pty (could perhaps be fixed with some modification of the relevant
> regexes..)
>
> - The stack pointer is only updated when using the "next" (C-n) or "step
> in" (C-s) functions.
>
> Odd A.
>
>
>
> On Fri, Jan 29, 2016 at 3:30 PM, Eric Ludlam <Eri...@ma...>
> wrote:
>
> Hi,
>
>
>
> I have looked into this, and in Earlier MATLABs I used to take advantage
> of a “bug”, which I thought was a feature, that allowed MATLAB to send me
> html like anchors which I could interpret.  MATLAB is now correctly
> identifying that it is not pointing at a device that supports anchors
> (since it is a plain pty), so I don’t have the data.
>
>
>
> I asked a couple folks about this and I don’t believe there is a trick I
> can pull to get this data to be output to Emacs with the newer MATLABs,
> which leaves things kind of broken.
>
>
>
> Before the links, I used to interpret the plaintext, but this was buggy,
> and simple output tweaks from MATLAB, or locale changes would mess it up,
> so it doesn’t seem too good either, but could be resurrected.  I don’t
> really have the bandwidth for that kind of refactoring project though. L
>
>
>
> Eric
>
>
>
> *From:* Odd Andersen [mailto:odd...@gm...]
> *Sent:* Wednesday, January 27, 2016 8:21 AM
> *To:* mat...@li...
> *Subject:* [Matlab-emacs-discuss] Missing execution line pointer after
> upgrading Matlab
>
>
>
>
>
> Hi,
>
> After I upgraded my Matlab version from R2014a to R2015b, I can no longer
> see the little arrow that indicates the current execution line while
> debugging matlab code using matlab-emacs.  Moreover, debugging seems to
> work poorly in other ways: it apparently no longer brings up the relevant
> code buffer while debugging (possibly tied to the problem above), and when
> arriving at a multi-line function call (i.e. where each line of text is
> continued with '...'), it no longer treats this as one line but insists on
> stepping over each text line separately.
>
> I saw someone else (Tunc Aydin) mentioned the missing execution line
> pointer on this mailing list last fall, and was answered by Eric Ludlam
> that apparently the "output Emacs was interpreting for the debugger has
> changed" and that this .  (
> http://sourceforge.net/p/matlab-emacs/mailman/message/34601964/)
>
> Has anyone looked into this since then?  matlab-emacs has worked wonders
> for me in the past, and it's very sad if it stops providing a practical
> debugging tool  as people upgrade to newer versions of Matlab.
>
> Best,
>
> Odd Andersen
>
>
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Matlab-emacs-discuss mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss
>

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

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

>>> "Eric" == Eric Ludlam <Eri...@ma...> writes:

    > I have some pending patches I haven't gotten around to pushing up into
    > CVS. I don't like pushing patches without checking the results myself,
    > and things have been busy lately.

    > I could definitely use help for this sort of thing.

    > Eric

Hi

I would not mind to volunteer, but CVS? Couldn't we convert it to a more
modern system, git or mercurial? I propose the later, because

      - I am acquainted with HG, I also use bitbucket which would be a
        natural site then.

      - I have successfully converted various CVS/RCS repos to
        mercurial but don't know how to do this for git.

Tell me what you think.

Uwe 

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

[Eric L. <Eri...@ma...>]

I have some pending patches I haven't gotten around to pushing up into CVS.   I don't like pushing patches without checking the results myself, and things have been busy lately.

I could definitely use help for this sort of thing.

Eric

-----Original Message-----
From: Uwe Brauer [mailto:ou...@ma...] 
Sent: Monday, January 25, 2016 5:49 AM
To: Torben Knudsen <tk...@es...>
Cc: matlab-emacs <mat...@li...>
Subject: Re: [Matlab-emacs-discuss] execute matlab in a different directory. GNU vs Xemacs

>>> "Torben" == Torben Knudsen <tk...@es...> writes:

    > Dear Uwe

> Maybe I misunderstand the problem. If I make sure the diectories are 
> on the search path using e.g. addpath and maybe genpath I have no 
> problems when running m-files from different directories using


I am afraid I did not explain this well enough.

I don't want to set a path.

Rationale:

I have to correct a bunch of .m files of my students which they wrote in an exam. Although I tell them to add their familiar name to each file, some of them forget that and I end up with files like examn.m

So if I set paths I could never be sure which file I execute.

However I found two solutions to my problem:

    -  I just boldly used the function from Xemacs dired.el

    -  even better the variable  matlab-change-current-directory which I
       had set to t in Xemacs and nil in GNU emacs solves completely my problem.

@Eric: I obtainted that variable from a patch I found in the matlab newsgroup.
It is applied to main I trust?

Regards

Uwe Brauer 

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Matlab-emacs-discuss mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss

Re: [Matlab-emacs-discuss] Missing execution line pointer after upgrading Matlab

[Eric L. <Eri...@ma...>]

Hi,

That looks like a great idea for a simple fix.   You might be able to shadow “dbstep” in the Matlab-emacs toolbox directory, and have it call

builtin(‘dbstep’,...)

to dispatch, then fprintf items out.

I’m not sure why it wouldn’t remove the hotlink text.   That will need some time in the Emacs debugger around matlab-shell-render-anchor to know.

Eric

From: Odd Andersen [mailto:odd...@gm...]
Sent: Friday, January 29, 2016 12:10 PM
To: mat...@li...
Subject: Re: [Matlab-emacs-discuss] Missing execution line pointer after upgrading Matlab

Hi Eric, and thanks for answering.
I have looked a bit at the problem myself.
I was able to find a relatively nonintrusive (but hacky) workaround by writing a function that emulates the "bug"/"feature" of earlier Matlab versions, putting it in the "toolbox" folder, and calling it alongside with the db-commands that are specified for gud in matlab.el.
In other words, placing the following file in 'toolbox':
function dbhotlink()
   [ST, I] = dbstack('-completenames');
   fprintf('<a href="matlab: opentoline(''%s'',%i,1)">%i </a>\n', ST(2).file, ST(2).line, ST(2).line);
end

and then modifying lines 4542 and 4543 in matlab.el to read:
(gud-def gud-step   "dbstep in;\ndbhotlink();\n"           "\C-s" "Step one source line, possibly into a function.")
(gud-def gud-next   "dbstep %p;\ndbhotlink();\n"           "\C-n" "Step over one source line.")
This sort of works, but with some drawbacks:
- The text line generated by 'dbhotlink' is not properly removed from the pty (could perhaps be fixed with some modification of the relevant regexes..)
- The stack pointer is only updated when using the "next" (C-n) or "step in" (C-s) functions.
Odd A.
[Image removed by sender.]

On Fri, Jan 29, 2016 at 6:08 PM, Odd Andersen <odd...@gm...<mailto:odd...@gm...>> wrote:
Hi Eric, and thanks for answering.
I have looked a bit at the problem myself.
I was able to find a relatively nonintrusive (but hacky) workaround by writing a function that emulates the "bug"/"feature" of earlier Matlab versions, putting it in the "toolbox" folder, and calling it alongside with the db-commands that are specified for gud in matlab.el.
In other words, placing the following file in 'toolbox':
function dbhotlink()
   [ST, I] = dbstack('-completenames');
   fprintf('<a href="matlab: opentoline(''%s'',%i,1)">%i </a>\n', ST(2).file, ST(2).line, ST(2).line);
end

and then modifying lines 4542 and 4543 in matlab.el to read:
(gud-def gud-step   "dbstep in;\ndbhotlink();\n"           "\C-s" "Step one source line, possibly into a function.")
(gud-def gud-next   "dbstep %p;\ndbhotlink();\n"           "\C-n" "Step over one source line.")
This sort of works, but with some drawbacks:
- The text line generated by 'dbhotlink' is not properly removed from the pty (could perhaps be fixed with some modification of the relevant regexes..)
- The stack pointer is only updated when using the "next" (C-n) or "step in" (C-s) functions.
Odd A.

On Fri, Jan 29, 2016 at 3:30 PM, Eric Ludlam <Eri...@ma...<mailto:Eri...@ma...>> wrote:
Hi,

I have looked into this, and in Earlier MATLABs I used to take advantage of a “bug”, which I thought was a feature, that allowed MATLAB to send me html like anchors which I could interpret.  MATLAB is now correctly identifying that it is not pointing at a device that supports anchors (since it is a plain pty), so I don’t have the data.

I asked a couple folks about this and I don’t believe there is a trick I can pull to get this data to be output to Emacs with the newer MATLABs, which leaves things kind of broken.

Before the links, I used to interpret the plaintext, but this was buggy, and simple output tweaks from MATLAB, or locale changes would mess it up, so it doesn’t seem too good either, but could be resurrected.  I don’t really have the bandwidth for that kind of refactoring project though. ☹

Eric

From: Odd Andersen [mailto:odd...@gm...<mailto:odd...@gm...>]
Sent: Wednesday, January 27, 2016 8:21 AM
To: mat...@li...<mailto:mat...@li...>
Subject: [Matlab-emacs-discuss] Missing execution line pointer after upgrading Matlab


Hi,
After I upgraded my Matlab version from R2014a to R2015b, I can no longer see the little arrow that indicates the current execution line while debugging matlab code using matlab-emacs.  Moreover, debugging seems to work poorly in other ways: it apparently no longer brings up the relevant code buffer while debugging (possibly tied to the problem above), and when arriving at a multi-line function call (i.e. where each line of text is continued with '...'), it no longer treats this as one line but insists on stepping over each text line separately.
I saw someone else (Tunc Aydin) mentioned the missing execution line pointer on this mailing list last fall, and was answered by Eric Ludlam that apparently the "output Emacs was interpreting for the debugger has changed" and that this .  (http://sourceforge.net/p/matlab-emacs/mailman/message/34601964/)
Has anyone looked into this since then?  matlab-emacs has worked wonders for me in the past, and it's very sad if it stops providing a practical debugging tool  as people upgrade to newer versions of Matlab.
Best,
Odd Andersen

Re: [Matlab-emacs-discuss] Missing execution line pointer after upgrading Matlab

[Odd A. <odd...@gm...>]

Hi Eric, and thanks for answering.

I have looked a bit at the problem myself.
I was able to find a relatively nonintrusive (but hacky) workaround by
writing a function that emulates the "bug"/"feature" of earlier Matlab
versions, putting it in the "toolbox" folder, and calling it alongside with
the db-commands that are specified for gud in matlab.el.

In other words, placing the following file in 'toolbox':

function dbhotlink()
   [ST, I] = dbstack('-completenames');
   fprintf('<a href="matlab: opentoline(''%s'',%i,1)">%i </a>\n',
ST(2).file, ST(2).line, ST(2).line);
end

and then modifying lines 4542 and 4543 in matlab.el to read:
(gud-def gud-step   "dbstep in;\ndbhotlink();\n"           "\C-s" "Step one
source line, possibly into a function.")
(gud-def gud-next   "dbstep %p;\ndbhotlink();\n"           "\C-n" "Step
over one source line.")

This sort of works, but with some drawbacks:
- The text line generated by 'dbhotlink' is not properly removed from the
pty (could perhaps be fixed with some modification of the relevant
regexes..)
- The stack pointer is only updated when using the "next" (C-n) or "step
in" (C-s) functions.

Odd A.

On Fri, Jan 29, 2016 at 6:08 PM, Odd Andersen <odd...@gm...>
wrote:

> Hi Eric, and thanks for answering.
>
> I have looked a bit at the problem myself.
> I was able to find a relatively nonintrusive (but hacky) workaround by
> writing a function that emulates the "bug"/"feature" of earlier Matlab
> versions, putting it in the "toolbox" folder, and calling it alongside with
> the db-commands that are specified for gud in matlab.el.
>
> In other words, placing the following file in 'toolbox':
>
> function dbhotlink()
>    [ST, I] = dbstack('-completenames');
>    fprintf('<a href="matlab: opentoline(''%s'',%i,1)">%i </a>\n',
> ST(2).file, ST(2).line, ST(2).line);
> end
>
> and then modifying lines 4542 and 4543 in matlab.el to read:
> (gud-def gud-step   "dbstep in;\ndbhotlink();\n"           "\C-s" "Step
> one source line, possibly into a function.")
> (gud-def gud-next   "dbstep %p;\ndbhotlink();\n"           "\C-n" "Step
> over one source line.")
>
> This sort of works, but with some drawbacks:
> - The text line generated by 'dbhotlink' is not properly removed from the
> pty (could perhaps be fixed with some modification of the relevant
> regexes..)
> - The stack pointer is only updated when using the "next" (C-n) or "step
> in" (C-s) functions.
>
> Odd A.
>
> On Fri, Jan 29, 2016 at 3:30 PM, Eric Ludlam <Eri...@ma...>
> wrote:
>
>> Hi,
>>
>>
>>
>> I have looked into this, and in Earlier MATLABs I used to take advantage
>> of a “bug”, which I thought was a feature, that allowed MATLAB to send me
>> html like anchors which I could interpret.  MATLAB is now correctly
>> identifying that it is not pointing at a device that supports anchors
>> (since it is a plain pty), so I don’t have the data.
>>
>>
>>
>> I asked a couple folks about this and I don’t believe there is a trick I
>> can pull to get this data to be output to Emacs with the newer MATLABs,
>> which leaves things kind of broken.
>>
>>
>>
>> Before the links, I used to interpret the plaintext, but this was buggy,
>> and simple output tweaks from MATLAB, or locale changes would mess it up,
>> so it doesn’t seem too good either, but could be resurrected.  I don’t
>> really have the bandwidth for that kind of refactoring project though. L
>>
>>
>>
>> Eric
>>
>>
>>
>> *From:* Odd Andersen [mailto:odd...@gm...]
>> *Sent:* Wednesday, January 27, 2016 8:21 AM
>> *To:* mat...@li...
>> *Subject:* [Matlab-emacs-discuss] Missing execution line pointer after
>> upgrading Matlab
>>
>>
>>
>>
>>
>> Hi,
>>
>> After I upgraded my Matlab version from R2014a to R2015b, I can no longer
>> see the little arrow that indicates the current execution line while
>> debugging matlab code using matlab-emacs.  Moreover, debugging seems to
>> work poorly in other ways: it apparently no longer brings up the relevant
>> code buffer while debugging (possibly tied to the problem above), and when
>> arriving at a multi-line function call (i.e. where each line of text is
>> continued with '...'), it no longer treats this as one line but insists on
>> stepping over each text line separately.
>>
>> I saw someone else (Tunc Aydin) mentioned the missing execution line
>> pointer on this mailing list last fall, and was answered by Eric Ludlam
>> that apparently the "output Emacs was interpreting for the debugger has
>> changed" and that this .  (
>> http://sourceforge.net/p/matlab-emacs/mailman/message/34601964/)
>>
>> Has anyone looked into this since then?  matlab-emacs has worked wonders
>> for me in the past, and it's very sad if it stops providing a practical
>> debugging tool  as people upgrade to newer versions of Matlab.
>>
>> Best,
>>
>> Odd Andersen
>>
>
>

Re: [Matlab-emacs-discuss] Missing execution line pointer after upgrading Matlab

[Eric L. <Eri...@ma...>]

Hi,

I have looked into this, and in Earlier MATLABs I used to take advantage of a “bug”, which I thought was a feature, that allowed MATLAB to send me html like anchors which I could interpret.  MATLAB is now correctly identifying that it is not pointing at a device that supports anchors (since it is a plain pty), so I don’t have the data.

I asked a couple folks about this and I don’t believe there is a trick I can pull to get this data to be output to Emacs with the newer MATLABs, which leaves things kind of broken.

Before the links, I used to interpret the plaintext, but this was buggy, and simple output tweaks from MATLAB, or locale changes would mess it up, so it doesn’t seem too good either, but could be resurrected.  I don’t really have the bandwidth for that kind of refactoring project though. ☹

Eric

From: Odd Andersen [mailto:odd...@gm...]
Sent: Wednesday, January 27, 2016 8:21 AM
To: mat...@li...
Subject: [Matlab-emacs-discuss] Missing execution line pointer after upgrading Matlab


Hi,
After I upgraded my Matlab version from R2014a to R2015b, I can no longer see the little arrow that indicates the current execution line while debugging matlab code using matlab-emacs.  Moreover, debugging seems to work poorly in other ways: it apparently no longer brings up the relevant code buffer while debugging (possibly tied to the problem above), and when arriving at a multi-line function call (i.e. where each line of text is continued with '...'), it no longer treats this as one line but insists on stepping over each text line separately.
I saw someone else (Tunc Aydin) mentioned the missing execution line pointer on this mailing list last fall, and was answered by Eric Ludlam that apparently the "output Emacs was interpreting for the debugger has changed" and that this .  (http://sourceforge.net/p/matlab-emacs/mailman/message/34601964/)
Has anyone looked into this since then?  matlab-emacs has worked wonders for me in the past, and it's very sad if it stops providing a practical debugging tool  as people upgrade to newer versions of Matlab.
Best,
Odd Andersen

[Matlab-emacs-discuss] Missing execution line pointer after upgrading Matlab

[Odd A. <odd...@gm...>]

Hi,

After I upgraded my Matlab version from R2014a to R2015b, I can no longer
see the little arrow that indicates the current execution line while
debugging matlab code using matlab-emacs.  Moreover, debugging seems to
work poorly in other ways: it apparently no longer brings up the relevant
code buffer while debugging (possibly tied to the problem above), and when
arriving at a multi-line function call (i.e. where each line of text is
continued with '...'), it no longer treats this as one line but insists on
stepping over each text line separately.

I saw someone else (Tunc Aydin) mentioned the missing execution line
pointer on this mailing list last fall, and was answered by Eric Ludlam
that apparently the "output Emacs was interpreting for the debugger has
changed" and that this .  (
http://sourceforge.net/p/matlab-emacs/mailman/message/34601964/)

Has anyone looked into this since then?  matlab-emacs has worked wonders
for me in the past, and it's very sad if it stops providing a practical
debugging tool  as people upgrade to newer versions of Matlab.

Best,
Odd Andersen

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

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

>>> "Torben" == Torben Knudsen <tk...@es...> writes:

    > Dear Uwe

> Maybe I misunderstand the problem. If I make sure the diectories are
> on the search path using e.g. addpath and maybe genpath I have no
> problems when running m-files from different directories using


I am afraid I did not explain this well enough.

I don't want to set a path.

Rationale:

I have to correct a bunch of .m files of my students which they wrote in
an exam. Although I tell them to add their familiar name to each file,
some of them forget that and I end up with files like examn.m

So if I set paths I could never be sure which file I execute.

However I found two solutions to my problem:

    -  I just boldly used the function from Xemacs dired.el

    -  even better the variable  matlab-change-current-directory which I
       had set to t in Xemacs and nil in GNU emacs solves completely my problem.

@Eric: I obtainted that variable from a patch I found in the matlab
newsgroup.
It is applied to main I trust?

Regards

Uwe Brauer 

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

[Torben K. <tk...@es...>]

Dear Uwe

Maybe I misunderstand the problem.  If I make sure the diectories are on the search path using e.g. addpath and maybe genpath I have no problems when running m-files from different directories using 

matlab-mode, version 3.3.2
GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.10.7) of 2014-03-07 on lamiak, modified by Debian
 
Associate Prof. Ph.D Torben Knudsen    Mobile    : (+45) 2787 9826
Section of Automation and Control,
Department of Electronic Systems,    Email    : tk...@es...
Aalborg University              Web    : es.aau.dk/staff/tk
Fredrik Bajersvej 7
DK-9220 Aalborg Ø
Denmark

________________________________________
Fra: Uwe Brauer [ou...@ma...]
Sendt: 23. januar 2016 19:41
Til: matlab-emacs
Emne: [Matlab-emacs-discuss] execute matlab in a different directory. GNU       vs Xemacs

Hi

Here is the scenario.



    -  I open a matlab file in dir1,

    -  start the matlab shell,

    -  open a matlab file in dir2, now I cannot run matlab directly but
       have to change the shell:

In xemacs the following code worked

(defun matlab-cd-dir-actual ()
  (interactive)
  (setq saved-default-directory default-directory)
  (matlab-shell-run-command
   (concat "cd " (file-name-directory (buffer-file-name))))
  (message (concat "*MATLAB* (& lisp) dir: " (default-directory)))
  (setq command-line-default-directory (file-name-directory (buffer-file-name)))
  (cd (file-name-directory (buffer-file-name)))
  (setq default-directory saved-default-directory)
  (message (concat "Xemacs dir should be: " (default-directory))))

But in GNU emacs it does not, because of default-directory which is a
function in xemacs but not in GNU emacs and I don't want to import all
the code from the Xemacs dired version to GNU emacs.

Anybody has a better solution, that actually works in GNU emacs

Regards

Uwe Brauer

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Matlab-emacs-discuss mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss

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

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

Hi

Here is the scenario.



    -  I open a matlab file in dir1, 

    -  start the matlab shell, 

    -  open a matlab file in dir2, now I cannot run matlab directly but
       have to change the shell:

In xemacs the following code worked

(defun matlab-cd-dir-actual ()
  (interactive)
  (setq saved-default-directory default-directory)
  (matlab-shell-run-command
   (concat "cd " (file-name-directory (buffer-file-name))))
  (message (concat "*MATLAB* (& lisp) dir: " (default-directory)))
  (setq command-line-default-directory (file-name-directory (buffer-file-name)))
  (cd (file-name-directory (buffer-file-name)))
  (setq default-directory saved-default-directory)
  (message (concat "Xemacs dir should be: " (default-directory))))

But in GNU emacs it does not, because of default-directory which is a
function in xemacs but not in GNU emacs and I don't want to import all
the code from the Xemacs dired version to GNU emacs.

Anybody has a better solution, that actually works in GNU emacs

Regards

Uwe Brauer 

Re: [Matlab-emacs-discuss] GNU emacs 25/24 and "3.3.1" problem with the shell

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

>>> "Eric" == Eric Ludlam <Eri...@ma...> writes:

   > Hi Uwe,
   > The stack has "my-matlab-shell-keys", which I assume is a hook you
   > have? I'm guessing it has some XEmacs syntax keybindings in it.

You are right. I was 100 sure that all my keybinding are GNU/Xemacs
compatible but I had a binding to 'up which is understood by Xemacs but
not by GNU emacs. Correcting it, solved my problem.


   > As for ELPA, I don't have a legal trail on all the contributors enough
   > to know if it would qualify, so I hadn't looked into it. I also don't
   > really have the bandwidth to work on it. If someone would like to take
   > on that packaging task, I would be happy to support.

Ok that is a problem. However there is MALPA which contains packages
which are not copyright assign to the FSF but supported by the
GNU emacs package manager. I will try to find out how the packing task
has to be done and report back.

Uwe 
   > Eric

   > -----Original Message-----
   > From: Uwe Brauer [mailto:ou...@ma...] 
   > Sent: Thursday, January 07, 2016 12:15 PM
   > To: matlab-emacs <mat...@li...>
   > Cc: Eric Ludlam <Eri...@ma...>
   > Subject: GNU emacs 25/24 and "3.3.1" problem with the shell

   > Hello

   > So far I have tried out matlab 3.3.1 without problems in Xemacs 21.5.34.
   > However after I switched to GNU emacs with the same matlab version I
   > run into a small problem when using the matlab-shell commmand. An
   > error buffer pops up, whose content I attach, later matlab starts as
   > usual and the shell seems to be ok.

   > The message however is annoying.

   > BTW is there a change to add matlab to MELPA/ELPA?

   > Regards

   > Uwe Brauer 

Re: [Matlab-emacs-discuss] GNU emacs 25/24 and "3.3.1" problem with the shell

[Eric L. <Eri...@ma...>]

Hi Uwe,

The stack has "my-matlab-shell-keys", which I assume is a hook you have?   I'm guessing it has some XEmacs syntax keybindings in it.

As for ELPA, I don't have a legal trail on all the contributors enough to know if it would qualify, so I hadn't looked into it.  I also don't really have the bandwidth to work on it.   If someone would like to take on that packaging task, I would be happy to support.

Eric

-----Original Message-----
From: Uwe Brauer [mailto:ou...@ma...] 
Sent: Thursday, January 07, 2016 12:15 PM
To: matlab-emacs <mat...@li...>
Cc: Eric Ludlam <Eri...@ma...>
Subject: GNU emacs 25/24 and "3.3.1" problem with the shell

Hello

So far I have tried out matlab 3.3.1 without problems in Xemacs 21.5.34.
However after I switched to GNU emacs with the same matlab version I run into a small problem when using the matlab-shell commmand. An error buffer pops up, whose content I attach, later matlab starts as usual and the shell seems to be ok.

The message however is annoying.

BTW is there a change to add matlab to MELPA/ELPA?

Regards

Uwe Brauer 

[Matlab-emacs-discuss] GNU emacs 25/24 and "3.3.1" problem with the shell

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

Hello

So far I have tried out matlab 3.3.1 without problems in Xemacs 21.5.34.
However after I switched to GNU emacs with the same matlab version I run
into a small problem when using the matlab-shell commmand. An error
buffer pops up, whose content I attach, later matlab starts as usual and
the shell seems to be ok.

The message however is annoying.

BTW is there a change to add matlab to MELPA/ELPA?

Regards

Uwe Brauer 

[Matlab-emacs-discuss] regarding gud

[Priapus HK <pri...@gm...>]

On Dec 2, Eric confirmed a Mr. Tunc Aydin's observation that gud no longer
seems to behave correctly with emacs.

I too am experiencing similar symptoms on ubuntu emacs 24.3.1.

I am unaware of having upgraded my emacs so I don't know precisely what
changed.  Perhaps my periodic running of "sudo apt-get upgrade" has indeed
changed a submodule of emacs causing what Eric has described as a change in
the debugger output format.