You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
(1) |
Jul
(1) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2009 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
(7) |
Aug
(1) |
Sep
(5) |
Oct
|
Nov
(6) |
Dec
(3) |
| 2010 |
Jan
|
Feb
(10) |
Mar
(12) |
Apr
(13) |
May
(2) |
Jun
(4) |
Jul
(4) |
Aug
(4) |
Sep
|
Oct
(4) |
Nov
(2) |
Dec
(4) |
| 2011 |
Jan
(11) |
Feb
|
Mar
(18) |
Apr
|
May
(1) |
Jun
(12) |
Jul
(10) |
Aug
(4) |
Sep
(4) |
Oct
(5) |
Nov
|
Dec
(10) |
| 2012 |
Jan
(4) |
Feb
(26) |
Mar
|
Apr
(1) |
May
|
Jun
(8) |
Jul
(3) |
Aug
(1) |
Sep
|
Oct
(14) |
Nov
(1) |
Dec
(2) |
| 2013 |
Jan
(5) |
Feb
(2) |
Mar
(2) |
Apr
(5) |
May
(3) |
Jun
|
Jul
(8) |
Aug
(4) |
Sep
|
Oct
(7) |
Nov
(2) |
Dec
(7) |
| 2014 |
Jan
(14) |
Feb
|
Mar
(6) |
Apr
|
May
(3) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(7) |
Oct
(9) |
Nov
(9) |
Dec
(5) |
| 2015 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
(10) |
Jul
(3) |
Aug
(4) |
Sep
(8) |
Oct
(1) |
Nov
(3) |
Dec
(3) |
| 2016 |
Jan
(12) |
Feb
(59) |
Mar
(23) |
Apr
(11) |
May
(4) |
Jun
(15) |
Jul
|
Aug
|
Sep
(9) |
Oct
(19) |
Nov
(12) |
Dec
(5) |
| 2017 |
Jan
(1) |
Feb
(5) |
Mar
(5) |
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
|
Sep
(3) |
Oct
(12) |
Nov
(15) |
Dec
|
| 2018 |
Jan
(7) |
Feb
(6) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(3) |
Aug
(2) |
Sep
(2) |
Oct
(4) |
Nov
|
Dec
|
| 2019 |
Jan
(2) |
Feb
(9) |
Mar
(4) |
Apr
(9) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
(2) |
Nov
(6) |
Dec
(5) |
| 2020 |
Jan
(9) |
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(28) |
Dec
(5) |
| 2021 |
Jan
(11) |
Feb
(2) |
Mar
(2) |
Apr
(2) |
May
(15) |
Jun
(9) |
Jul
(11) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
(3) |
| 2022 |
Jan
(1) |
Feb
|
Mar
|
Apr
(9) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
(4) |
Jun
|
Jul
(22) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
|
Dec
(14) |
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
(17) |
May
(35) |
Jun
(1) |
Jul
(18) |
Aug
(31) |
Sep
(5) |
Oct
(18) |
Nov
(20) |
Dec
(9) |
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(5) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
1
|
2
|
3
|
4
|
|
5
|
6
|
7
(2) |
8
(1) |
9
|
10
|
11
|
|
12
|
13
|
14
(3) |
15
|
16
(3) |
17
|
18
|
|
19
|
20
|
21
|
22
(1) |
23
(2) |
24
|
25
|
|
26
|
27
|
28
|
29
|
30
|
|
|
|
From: Cheng W. <cry...@gm...> - 2011-06-23 21:56:52
|
Hi guys, I've fixed it by setting the external editor option in 'Preference'. Thanks for your patience! Cheng |
|
From: Cheng W. <cry...@gm...> - 2011-06-23 19:42:05
|
Hi guys, I've been using matlab mode for emacs for quite some time. When I move to ubuntu 11.04 from 10.10, I find when you type the 'edit' function in matlab-shell will not open a new buffer anymore. So it's not possible to edit old m files which are in matlab path without C-x C-f. I'm not sure where is the problem and hope someone could give me some hints. As I just use this mode for editing, so the relevant configuration in my .emacs looks like this. ;; ------------------------------------------------------------ ;; matlab ;; ------------------------------------------------------------ ; after adding path (load-library "matlab-load") The current emacs version is 23.2.1, I don't remember what was the version in 10.10 and 10.04, maybe 23.0. The matlab.el is the same as before. matlab-mode-version "3.3.1" Thank you very much for you attention! Cheng |
|
From: Eric L. <Eri...@ma...> - 2011-06-16 14:59:04
|
Hi,
Sorry for the very tardy response.
You can always put MATLAB into a new frame by doing "C-x 5 2" and put the *MATLAB* buffer into that frame.
In matlab.el, look for a call to 'display-buffer'. In Emacs 23.2 at least, the 3rd input argument specifies the frame, so you could change that line to:
(display-buffer msbn nil "visible"))
around line 5034 to fix it for the cell case. save-and-go seems to do something similar already.
I don't understand the issue w/ the comment character you mention. The only parts that change are values in strings, so I don't see how the % could affect anything.
Eric
-----Original Message-----
From: Laurent Jacques [mailto:lau...@uc...]
Sent: Monday, May 16, 2011 3:45 AM
To: mat...@li...
Subject: [Matlab-emacs-discuss] Launch matlab in new frame ?
Dear all,
I have few requests on this great emacs-matlab mode.
Do you you know if:
- it is possible to launch matlab in a new emacs *frame* (rather than in a sub-window) and then prevent emacs to still reopen a new matlab sub-window (split
window) when a mfile cell is run (with "run cell").
I'd like to see "run cell" call the frame where matlab is inside.
- to program in LISP the "run current cell and jump to next" ?
Last point about svn:
In the last matlab.el of the SVN, the "run cell" is bugged (at least on my Carbon emacs running on Mac).
All lines are concatenated into a big line before to be run in matlab.
This cause a bug if at least one line of the cell has a "%" comment, i.e., all the text after it is considered as a comment by matlab.
I had to go back to a previous version of matlab.el to solve this issue.
Best regards,
Laurent
--
Dr. Laurent JACQUES
Postdoctoral Researcher, Return Grant, BELSPO, Belgium
Institute of Information and Communication Technologies,
Electronics and Applied Mathematics (ICTEAM-TELE) University of Louvain Batiment Stévin Place du Levant 2, PO Box L5.04.01
1348 Louvain-la-Neuve, Belgium
Office: a.133
Tel: +32 10 47 81 24
Fax: +32 10 47 20 89
http://perso.uclouvain.be/laurent.jacques
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Matlab-emacs-discuss mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss
|
|
From: Eric L. <Eri...@ma...> - 2011-06-16 14:47:48
|
Thanks for the feedback.
I've added a variant of my original simple suggestion into CVS.
Users can shut-off the HTML stuff by typing the following into MATLAB after it starts:
feature('HotLinks','off');
This won't catch all the hot-links, and shutting off the rendering via your matlab-shell-mode-hook with code like this:
(remove-hook 'comint-output-filter-functions 'matlab-shell-render-html-anchor t)
(remove-hook 'comint-output-filter-functions 'matlab-shell-render-errors-as-anchor t)
will result in some random messy html text in your buffer.
Eric
From: Ondra Kamenik [mailto:ond...@gm...]
Sent: Thursday, June 16, 2011 5:27 AM
To: Eric Ludlam
Cc: mat...@li...
Subject: Re: [Matlab-emacs-discuss] matlab-shell slows down when buffer is large
Eric,
I changed the line in matlab-shell-render-html-anchor as you suggested and emacs does not slow down. Many Thanks!
If you plan to address this in more systematic way, what about allowing the user to switch off html rendering completely?
Many thanks again!
Ondra K.
On Tue, Jun 14, 2011 at 4:34 PM, Eric Ludlam <Eri...@ma...<mailto:Eri...@ma...>> wrote:
Hi,
There were some bugs I fixed a while back relating to highlighting error messages so they are clickable, and can go to the source of the error. That could be the issue, since that code will look backwards to fixup boken error messages. Error text is broken if ½ comes out on the command line in one chunk, followed by another chunk later. When the second chunk comes out, you need to look back for the beginning of the chunk.
Since you already directly know it is size related, you could set comint-buffer-maximum-size in your matlab-shell-mode-hook for a quick fix.
In matlab-shell functions, I see 1 occurrence of re-search-backward with no bounds. (The second argument.) One is in matlab-shell-render-html-anchor. I'll guess it needs something similar to what is in matlab-shell-render-errors-as-anchor with that reverse search. It may be that the error and html highlighters should share a single variable to mark the last location of an error.
Anyway, as a quick hack, line 4522 (in the CVS version of matlab.el in the function matlab-shell-render-anchor) could be
(when (re-search-backward matlab-anchor-beg (max 0 (- (point-max) 5000) t)
just to put some random limit for performance testing. If that helps, we'll know what the issue is and can fix it more robustly.
Eric
From: Ondra Kamenik [mailto:ond...@gm...<mailto:ond...@gm...>]
Sent: Tuesday, June 14, 2011 10:02 AM
To: mat...@li...<mailto:mat...@li...>
Subject: [Matlab-emacs-discuss] matlab-shell slows down when buffer is large
Eric and others,
I have been a happy user of matlab-shell for years. Thanks Eric.
However, recently (I cannot recollect exactly when, one year ago?), I experience slowing down of matlab-shell. We run complex matlab programs which call various external programs. The output displayed in matlab-shell consists of messages of various format from matlab, latex, svn, rational expectations solvers, etc. It seems that if there is a lot of output in the matlab-shell buffer, emacs becomes unresponsive, or very slow. Looking at top output, emacs seems to take much of processor time doing effectively nothing. The situation seems to be worse, if there are some matlab errors in the output.
It seems to me that emacs does some processing of the whole buffer each time something happens on the command line. When the buffer gets large (say 20000 lines), emacs seems very busy (by processing the whole buffer?) and the interactive work becomes a real pain. If one executes the code in M-file using C-c r, it takes ages before the code is copied to the buffer and one can actually observe how the code is being added character by c-h-a-r-a-c-t-e-r.
If you tell me how I can debug it, I will be happy to replicate the behaviour and send you a further information.
I use matlab 2009b, various computers with fedora 12 through 14, emacs version 23.2.1 or 23.1.1, matlab-shell version 3.3.1 or 3.3.0. My colleague has the same problem on some ubuntu with newer matlab. On my fedora 12, emacs 23.1.1 and matlab shell 3.3.1 laptop, I do not experience the problem. On my desktop with the same versions I have the problem. The only difference I am aware of is that the laptop is 64, desktop is 32. But my other desktop is 64 and I have the error there.
I will be happy to provide you with more information if I know what.
Thanks!
Ondra K.
|
|
From: Ondra K. <ond...@gm...> - 2011-06-16 09:27:15
|
Eric, I changed the line in matlab-shell-render-html-anchor as you suggested and emacs does not slow down. Many Thanks! If you plan to address this in more systematic way, what about allowing the user to switch off html rendering completely? Many thanks again! Ondra K. On Tue, Jun 14, 2011 at 4:34 PM, Eric Ludlam <Eri...@ma...>wrote: > Hi,**** > > ** ** > > There were some bugs I fixed a while back relating to highlighting error > messages so they are clickable, and can go to the source of the error. That > could be the issue, since that code will look backwards to fixup boken error > messages. Error text is broken if ½ comes out on the command line in one > chunk, followed by another chunk later. When the second chunk comes out, > you need to look back for the beginning of the chunk.**** > > ** ** > > Since you already directly know it is size related, you could set > comint-buffer-maximum-size in your matlab-shell-mode-hook for a quick fix. > **** > > ** ** > > In matlab-shell functions, I see 1 occurrence of re-search-backward with no > bounds. (The second argument.) One is in matlab-shell-render-html-anchor. > I’ll guess it needs something similar to what is in > matlab-shell-render-errors-as-anchor with that reverse search. It may be > that the error and html highlighters should share a single variable to mark > the last location of an error.**** > > ** ** > > Anyway, as a quick hack, line 4522 (in the CVS version of matlab.el in the > function matlab-shell-render-anchor) could be**** > > ** ** > > (when (re-search-backward matlab-anchor-beg (max 0 (- (point-max) 5000) t) > **** > > ** ** > > just to put some random limit for performance testing. If that helps, > we’ll know what the issue is and can fix it more robustly.**** > > ** ** > > Eric**** > > ** ** > > *From:* Ondra Kamenik [mailto:ond...@gm...] > *Sent:* Tuesday, June 14, 2011 10:02 AM > *To:* mat...@li... > *Subject:* [Matlab-emacs-discuss] matlab-shell slows down when buffer is > large**** > > ** ** > > Eric and others, > > I have been a happy user of matlab-shell for years. Thanks Eric. > > However, recently (I cannot recollect exactly when, one year ago?), I > experience slowing down of matlab-shell. We run complex matlab programs > which call various external programs. The output displayed in matlab-shell > consists of messages of various format from matlab, latex, svn, rational > expectations solvers, etc. It seems that if there is a lot of output in the > matlab-shell buffer, emacs becomes unresponsive, or very slow. Looking at > top output, emacs seems to take much of processor time doing effectively > nothing. The situation seems to be worse, if there are some matlab errors in > the output. > > It seems to me that emacs does some processing of the whole buffer each > time something happens on the command line. When the buffer gets large (say > 20000 lines), emacs seems very busy (by processing the whole buffer?) and > the interactive work becomes a real pain. If one executes the code in M-file > using C-c r, it takes ages before the code is copied to the buffer and one > can actually observe how the code is being added character by > c-h-a-r-a-c-t-e-r. > > If you tell me how I can debug it, I will be happy to replicate the > behaviour and send you a further information. > > I use matlab 2009b, various computers with fedora 12 through 14, emacs > version 23.2.1 or 23.1.1, matlab-shell version 3.3.1 or 3.3.0. My colleague > has the same problem on some ubuntu with newer matlab. On my fedora 12, > emacs 23.1.1 and matlab shell 3.3.1 laptop, I do not experience the problem. > On my desktop with the same versions I have the problem. The only difference > I am aware of is that the laptop is 64, desktop is 32. But my other desktop > is 64 and I have the error there. > > I will be happy to provide you with more information if I know what. > > Thanks! > > Ondra K.**** > |
|
From: Ondra K. <ond...@gm...> - 2011-06-14 16:05:30
|
Many thanks. I will check it out. Ondra K. Sent from my wireless handheld On Jun 14, 2011 4:34 PM, "Eric Ludlam" <Eri...@ma...> wrote: > Hi, > > There were some bugs I fixed a while back relating to highlighting error messages so they are clickable, and can go to the source of the error. That could be the issue, since that code will look backwards to fixup boken error messages. Error text is broken if ½ comes out on the command line in one chunk, followed by another chunk later. When the second chunk comes out, you need to look back for the beginning of the chunk. > > Since you already directly know it is size related, you could set comint-buffer-maximum-size in your matlab-shell-mode-hook for a quick fix. > > In matlab-shell functions, I see 1 occurrence of re-search-backward with no bounds. (The second argument.) One is in matlab-shell-render-html-anchor. I'll guess it needs something similar to what is in matlab-shell-render-errors-as-anchor with that reverse search. It may be that the error and html highlighters should share a single variable to mark the last location of an error. > > Anyway, as a quick hack, line 4522 (in the CVS version of matlab.el in the function matlab-shell-render-anchor) could be > > (when (re-search-backward matlab-anchor-beg (max 0 (- (point-max) 5000) t) > > just to put some random limit for performance testing. If that helps, we'll know what the issue is and can fix it more robustly. > > Eric > > From: Ondra Kamenik [mailto:ond...@gm...] > Sent: Tuesday, June 14, 2011 10:02 AM > To: mat...@li... > Subject: [Matlab-emacs-discuss] matlab-shell slows down when buffer is large > > Eric and others, > > I have been a happy user of matlab-shell for years. Thanks Eric. > > However, recently (I cannot recollect exactly when, one year ago?), I experience slowing down of matlab-shell. We run complex matlab programs which call various external programs. The output displayed in matlab-shell consists of messages of various format from matlab, latex, svn, rational expectations solvers, etc. It seems that if there is a lot of output in the matlab-shell buffer, emacs becomes unresponsive, or very slow. Looking at top output, emacs seems to take much of processor time doing effectively nothing. The situation seems to be worse, if there are some matlab errors in the output. > > It seems to me that emacs does some processing of the whole buffer each time something happens on the command line. When the buffer gets large (say 20000 lines), emacs seems very busy (by processing the whole buffer?) and the interactive work becomes a real pain. If one executes the code in M-file using C-c r, it takes ages before the code is copied to the buffer and one can actually observe how the code is being added character by c-h-a-r-a-c-t-e-r. > > If you tell me how I can debug it, I will be happy to replicate the behaviour and send you a further information. > > I use matlab 2009b, various computers with fedora 12 through 14, emacs version 23.2.1 or 23.1.1, matlab-shell version 3.3.1 or 3.3.0. My colleague has the same problem on some ubuntu with newer matlab. On my fedora 12, emacs 23.1.1 and matlab shell 3.3.1 laptop, I do not experience the problem. On my desktop with the same versions I have the problem. The only difference I am aware of is that the laptop is 64, desktop is 32. But my other desktop is 64 and I have the error there. > > I will be happy to provide you with more information if I know what. > > Thanks! > > Ondra K. |
|
From: Eric L. <Eri...@ma...> - 2011-06-14 14:55:24
|
Hi, There were some bugs I fixed a while back relating to highlighting error messages so they are clickable, and can go to the source of the error. That could be the issue, since that code will look backwards to fixup boken error messages. Error text is broken if ½ comes out on the command line in one chunk, followed by another chunk later. When the second chunk comes out, you need to look back for the beginning of the chunk. Since you already directly know it is size related, you could set comint-buffer-maximum-size in your matlab-shell-mode-hook for a quick fix. In matlab-shell functions, I see 1 occurrence of re-search-backward with no bounds. (The second argument.) One is in matlab-shell-render-html-anchor. I'll guess it needs something similar to what is in matlab-shell-render-errors-as-anchor with that reverse search. It may be that the error and html highlighters should share a single variable to mark the last location of an error. Anyway, as a quick hack, line 4522 (in the CVS version of matlab.el in the function matlab-shell-render-anchor) could be (when (re-search-backward matlab-anchor-beg (max 0 (- (point-max) 5000) t) just to put some random limit for performance testing. If that helps, we'll know what the issue is and can fix it more robustly. Eric From: Ondra Kamenik [mailto:ond...@gm...] Sent: Tuesday, June 14, 2011 10:02 AM To: mat...@li... Subject: [Matlab-emacs-discuss] matlab-shell slows down when buffer is large Eric and others, I have been a happy user of matlab-shell for years. Thanks Eric. However, recently (I cannot recollect exactly when, one year ago?), I experience slowing down of matlab-shell. We run complex matlab programs which call various external programs. The output displayed in matlab-shell consists of messages of various format from matlab, latex, svn, rational expectations solvers, etc. It seems that if there is a lot of output in the matlab-shell buffer, emacs becomes unresponsive, or very slow. Looking at top output, emacs seems to take much of processor time doing effectively nothing. The situation seems to be worse, if there are some matlab errors in the output. It seems to me that emacs does some processing of the whole buffer each time something happens on the command line. When the buffer gets large (say 20000 lines), emacs seems very busy (by processing the whole buffer?) and the interactive work becomes a real pain. If one executes the code in M-file using C-c r, it takes ages before the code is copied to the buffer and one can actually observe how the code is being added character by c-h-a-r-a-c-t-e-r. If you tell me how I can debug it, I will be happy to replicate the behaviour and send you a further information. I use matlab 2009b, various computers with fedora 12 through 14, emacs version 23.2.1 or 23.1.1, matlab-shell version 3.3.1 or 3.3.0. My colleague has the same problem on some ubuntu with newer matlab. On my fedora 12, emacs 23.1.1 and matlab shell 3.3.1 laptop, I do not experience the problem. On my desktop with the same versions I have the problem. The only difference I am aware of is that the laptop is 64, desktop is 32. But my other desktop is 64 and I have the error there. I will be happy to provide you with more information if I know what. Thanks! Ondra K. |
|
From: Ondra K. <ond...@gm...> - 2011-06-14 14:01:44
|
Eric and others, I have been a happy user of matlab-shell for years. Thanks Eric. However, recently (I cannot recollect exactly when, one year ago?), I experience slowing down of matlab-shell. We run complex matlab programs which call various external programs. The output displayed in matlab-shell consists of messages of various format from matlab, latex, svn, rational expectations solvers, etc. It seems that if there is a lot of output in the matlab-shell buffer, emacs becomes unresponsive, or very slow. Looking at top output, emacs seems to take much of processor time doing effectively nothing. The situation seems to be worse, if there are some matlab errors in the output. It seems to me that emacs does some processing of the whole buffer each time something happens on the command line. When the buffer gets large (say 20000 lines), emacs seems very busy (by processing the whole buffer?) and the interactive work becomes a real pain. If one executes the code in M-file using C-c r, it takes ages before the code is copied to the buffer and one can actually observe how the code is being added character by c-h-a-r-a-c-t-e-r. If you tell me how I can debug it, I will be happy to replicate the behaviour and send you a further information. I use matlab 2009b, various computers with fedora 12 through 14, emacs version 23.2.1 or 23.1.1, matlab-shell version 3.3.1 or 3.3.0. My colleague has the same problem on some ubuntu with newer matlab. On my fedora 12, emacs 23.1.1 and matlab shell 3.3.1 laptop, I do not experience the problem. On my desktop with the same versions I have the problem. The only difference I am aware of is that the laptop is 64, desktop is 32. But my other desktop is 64 and I have the error there. I will be happy to provide you with more information if I know what. Thanks! Ondra K. |
|
From: <rp...@gm...> - 2011-06-08 12:39:41
|
On Tue, Jun 7, 2011 at 5:25 PM, <rp...@gm...> wrote: > On Tue, Jun 7, 2011 at 4:38 PM, Daniele Nicolodi <da...@gr...> wrote: >> On 07/06/11 15:06, rp...@gm... wrote: >>> Hello everyone, >>> >>> I noticed that when I insert a commented line right after the >>> 'methods'-statement in a class definition, the indentation fails >>> (starting at the comment, the indentation is reset to the beginning of >>> the line). >> >> Hello, >> >> I fixed a couple of bugs regarding comments indentation, especially help >> strings, in my copy of matlab-mode (I haven't found the time yet to send >> patches upstream). >> >> I'm not sure I following your description. Can you please provide a >> simple example of the problem you are experiencing, including the >> indentation you obtain from matlab-mode and the desired one? >> >> The solution should not be too difficult and I may found the time to >> look at it soon. >> >> Cheers, >> -- >> Daniele >> > > Hi Daniele, > > thanks for your help. What I would like to see is the following: > > classdef myclass > methods > %> comment style I use > function some = function(thing) > some = thing > end > end > end > > what I get is this: > > classdef myclass > methods > %> comment is indented to beginning of line > function some = function(thing) > % but relative indentation in class still works > some = thing > end > end > end > > This reproduces *most* of the time, but not always. I just came to > think that the issue might be that these files originally come from a > windows machine and this actually might be a > carriage-return-problem... > > best > Hans > I looked into the problem of different line endings on windows & linux - however, the problem appears also on files generated on linux. The problem must thus lie with matlab.el. Note that I have only observed this with the methods-keyword - comments+indentation after the properties-keyword work perfectly fine. Hans |
|
From: Daniele N. <da...@gr...> - 2011-06-07 14:56:28
|
On 07/06/11 15:06, rp...@gm... wrote: > Hello everyone, > > I noticed that when I insert a commented line right after the > 'methods'-statement in a class definition, the indentation fails > (starting at the comment, the indentation is reset to the beginning of > the line). Hello, I fixed a couple of bugs regarding comments indentation, especially help strings, in my copy of matlab-mode (I haven't found the time yet to send patches upstream). I'm not sure I following your description. Can you please provide a simple example of the problem you are experiencing, including the indentation you obtain from matlab-mode and the desired one? The solution should not be too difficult and I may found the time to look at it soon. Cheers, -- Daniele |
|
From: <rp...@gm...> - 2011-06-07 13:32:51
|
Hello everyone, I noticed that when I insert a commented line right after the 'methods'-statement in a class definition, the indentation fails (starting at the comment, the indentation is reset to the beginning of the line). Does anyone else observe this behaviour? This may seem as a side-issue, but I am trying to use a documentation generator (http://www.mathworks.com/matlabcentral/fileexchange/25925-using-doxygen-with-matlab) that needs the describing comment above the function definition. The weird thing is that it works just fine for the properties-keyword. Any help is greatly appreciated Thanks Hans |