>>> "JC" == John C writes:
Hi John,
> Over the past few weeks, I've made progress on a matlab tree-sitter major
> mode, matlab-ts-mode.el, in the matlab-ts-mode branch. Tree-sitter,
> https://tree-sitter.github.io/tree-sitter/ is a major step forward from the
> classic technique for building a
>>> "JC" == John C writes:
> Hi
> I would suggest taking a little time to learn about tree-sitter
>- Watch this:
>
> https://www.thestrangeloop.com/2018/tree-sitter---a-new-parsing-system-for-programming-tools.html
>- Explore https://tree-sitter.github.io/tree-sitter/ In particular
Please consider the following trivial .m file called example.m
%%
fprintf('* Paso 2: Calculamos la región de aceptación $R_A$.\n\n')
What works
1. I open matlab indenpendent from emacs, and fire this command in
the command line. Everything works
2. I open emacs start matlab, m
>>> "UB" == Uwe Brauer writes:
> Hi
> currently make lisp works but
> make test fails with the error
Please ignore this message. I caused this problem by playing around with too
many different ways to define
matlab-mode-version
> ebugger entered--Lisp error: (void-variable matlab-m
Hi
currently make lisp works but
make test fails with the error
--8<---cut here---start->8---
ebugger entered--Lisp error: (void-variable matlab-mode-version)
(string= package-version matlab-mode-version)
(not (string= package-version matlab-mode-version
>>> "EL" == Eric Ludlam writes:
>> From: Uwe Brauer
> "EL" == Eric Ludlam writes:
>>> The command matlab-show-version was always there since before I
>>> adopted matlab-mode. I'm not attached to it and would not mind if it
>>> were removed.
>> According to git blame or mercurial annotate
> Makes sense - Matt emailed me the file, and I put it into version control. I
> think it was RCS at the time. 😊
I just checked, matlab-shell uses
matlab-show-version
So the question is do we want to keep it, maybe people want to see the
matlab-show-version when calling matlab-shell?
I
>>> "EL" == Eric Ludlam writes:
> The command matlab-show-version was always there since before I
> adopted matlab-mode. I'm not attached to it and would not mind if it
> were removed.
According to git blame or mercurial annotate, you are the author 😉
(however this functionality is not very reli
Hi
I am currently dealing to get matlab-mode into ELPA. I will also open an issue
in github (not sure what is better for most of you
The ELPA maintainer, told me
1. Why do we have still the function matlab-show-version
2. And matlab-version as a defconst
3. And where to put the
I just want to inform everyone, that soon matlab-mode will appear in ELPA. The
main difference is that in ELPA only a new version is released if we change
explicitely the version number, while MELPA release a new version for every
push.
We have then also to modify the file CONTRIBUTING.org si
> Uwe Brauer writes:
> You don't have to do anything*, I just have to add a package
> specification (similar to the "recipe file" for MELPA) to elpa.git.
> * As soon as it works. The main issues right now, are as you noticed
> that ELPA doesn't release a new tarball for every commit, but jus
> On 25.04.2024 21:55, martinoidar wrote:
Hi
> Update:
> I've just noticed that not everything is properly rendered in markdown
> form.
I just want to point out that we merged successfully our org-mode branch
into the main, the default branch, and now the native org supports works
flawlessly a
>>> "VC" == Vasco Cúrdia writes:
> Thanks.
> It was a local setting of mine using an old face name that no longer
> exists. I fixed it and it is all working now.
Thanks for reporting back and I am glad that it worked out for you.
However, I am a bit worried why this happened. Do you remember (o
>>> "JC" == John Ciolfi writes:
> --_000_mn2pr05mb6766aec9347374bef65023cbd1212mn2pr05mb6766namp_
> Content-type: text/plain; charset="windows-1252"
> Content-transfer-encoding: quoted-printable
> Hi
> I think we could keep the current settings for those that don't have issues=
> with the supe
>>> "EL" == Eric Ludlam writes:
> Thanks for the feedback.
> I was proposing adding a 2nd set of bindings. For folks with super-key,
> the current bindings will be faster. More obscure bindings won't get in
> their way.
> As for C-c % vs C-c C- - the Elisp manual is pretty specific saying
> t
>>> "JCvM" == John Ciolfi via Matlab-emacs-discuss
>>> writes:
> Yes, it's a good feature when working with scripts.
> The key binding is an issue I see too, though when using VNC.
> Sometimes the super key isn't passed through. It's also common for the
> windows super key to not work on Windows
>>> "NNB" == Nidish Narayanaa Balaji
>>> writes:
> Here's the issues on github where we did the renaming:
> https://github.com/mathworks/Emacs-MATLAB-Mode/issues/9
> Also see:
> https://github.com/mathworks/Emacs-MATLAB-Mode/issues/5#issuecomment-2429899974
> Hope this helps,
It does, I shou
>>> "VC" == Vasco Cúrdia writes:
Hello
> Hi,
> I just refreshed my packages using Melpa, and now I'm getting this error
> error: Invalid face, matlab-cellbreak-face
> Any thoughts on what may be causing this?
I am sorry, lately we merged several branches with new features into
the main branch
-type f -exec grep -l matlab-load {} \;
> ./Makefile
> ./README.org
> ./examples/matlab-and-org-mode/matlab-and-org-mode.html
> ./examples/matlab-and-org-mode/matlab-and-org-mode.org
> ./tests/mstest.el
> ./tests/metest.el
> ./DEBUGGING.org
Yes I know, I did not push though.
>
x27;d like to get to.
> Perhaps, for now, we just manually update them when the are touched.
> Thanks
> John
>
> From: Uwe Brauer via Matlab-emacs-discuss
>
> Sent: Friday, October 4, 2024 9:07 AM
> To: Matlab-emacs-discuss
> Subject: [
Hi all
I am not sure that everybody is following the discussion between Jonas
(the MELPA maintainer) and myself concerning the MELPA conventions.
Jonas proposed two things (besides changes in the recipe file, that
reflect the new repository and directory structure
1. To rename matlab-load
Hi
I just realised what we should upgrade the copyright dates in a couple of
files. I can do that but I am wondering whether the Makefile could take care of
that.
Then:
We still have
(defconst matlab-mode-version "5.0"
"Current version of MATLAB(R) mode.")
Shouldn't we upgrade at least
Hi all
I presume you all have seen Jonas email concerning the MELPA convention.
The most logical solution to this problem would be
1. Follow his advice
2. Also adapt the MELPA recipe file, so that refers to the Github
repository.
However since there are some changes concerning the d
>>> "JC" == John Ciolfi writes:
> I just added a make target to help with this (commit ccd2d06):
> make list-files-for-release
> which will display the following (notice matlab-load.el is excluded because
> this is generated and dependent on the version of Emacs):
Thanks!
That looks very
>>> "JC" == John Ciolfi writes:
> Hi
> This is fixed (commit 59bf9a9 - Update tests/mstest.el to work with R2024b).
Thanks, pulled tested and confirmed!!!
Uwe
--
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukrai
>>> "JC" == John Ciolfi writes:
> Hi
> We need the *.el files and all *.m files under the toolbox directory tree,
and the bin/*.sh file.
> cd Emacs-MATLAB-Mode
> ls *.el
> find toolbox -name '*.m' -print
> ls bin/*.sh
> Note, the bin/*.sh is used by one of the *.m
Hi John
I am about to update melpa, now besides changing the url, there is
another question:
You did a mayor cleanup in the github repository, so
Are theses files still relevant that are found in the directories listed
below?
Thanks
Uwe
(matlab-mode
:fetcher git
:url "https://git.code.
>>> "UBvM" == Uwe Brauer via Matlab-emacs-discuss
>>> writes:
> Hi all
> I upgraded to matlab 2024b and run
> make (using emacs 29.4) lisp
> That works. But make
> Leads to an error, whose backtrace I attach.
> I still have 2024a but
Hi all
I upgraded to matlab 2024b and run
make (using emacs 29.4) lisp
That works. But make
Leads to an error, whose backtrace I attach.
I still have 2024a but right now I cannot activate its license due to network
problems.
Any idea what is going on?
Uwe
--
I strongly condemn Ha
Hi
Given the recent discussion (and problems) with the Makefile, may I suggest the
following.
- make lisp (just byte compiles the .el files and generate
matlab-load) instead of make NOTESTS=1
- make matlab-test runs the matlab test
- make all runs lisp+matlab-test
Does
Hi
I am currently running Emacs 29.2 and I had problems with
commit a78b368387c8
because of
autoload-insert-section-header
More precisely
--8<---cut here---start->8---
Debugger entered--Lisp error: (error "cedet-matlab.el:0:0: error:
void-function: (autol
>>> "JC" == John Ciolfi writes:
> Hi
> I can investigate the issue below if you don't have time to get to it.
Thanks, I report back if I can't get it to work in the coming days.
> As for Emacs 26, yes, we could ask about this on the email list but
> we'd need someone to volunteer to test and he
>>> "VC" == Vasco Cúrdia writes:
Hi
> Hi,
> I'm using the nerd-icons package in emacs but for some reason it associates
> ".m" files with Apple, and shows a Mac/Apple symbol. So In Dired I have a
> bunch of folders will of Apple icons, rather than Matlab icons. I was able
> to switch it manuall
>>> "JC" == John Ciolfi writes:
Hi John
> Hi Uwe,
> This is unrelated to Emacs 29. I was able to reproduce the problem
> when running a version of MATLAB installed on a slow file server which
> slows down MATLAB startup. I increased the timeout in the test, so
> that should fix the issue.
Never
>>> "JC" == John Ciolfi writes:
> I’ll look at this in a couple of days. I can confirm the tests pass on
> Debian 12 with Emacs 28 using R2024a. The code should match source
> forge minus some stale code that no longer works. So, this is likely
> an existing issue
Yes, unfortunately. I just trie
>>> "JC" == John Ciolfi writes:
> Hi
> I setup https://github.com/mathworks/Emacs-MATLAB-Mode per your
> guidelines where I deleted the old branches, then mirrored. I then
> added a commit (reviewed a while back by Eric):
Maybe I should open an issue on github?
Here is the is the situation:
>>> "JC" == John Ciolfi writes:
Hi
> Hi
> I setup https://github.com/mathworks/Emacs-MATLAB-Mode per your
> guidelines where I deleted the old branches, then mirrored. I then
> added a commit (reviewed a while back by Eric):
thanks
> Cleanup stale files and setup to align with github MathWorks
>>> "JC" == John Ciolfi writes:
> Hi
> Sorry for the delay. I’m out on vacation but will try to finish this
> in the next day or so. It took a little longer than I expected to get
> things setup, but now I have the right permissions to do this.
Ok, great!
Sorry for the nagging but at the end of
>>> "JC" == John Ciolfi writes:
Hi John
> Thanks - soon (perhaps tomorrow), I'll try to set up the empty github
> area so you can push the history to it. I need to talk with some
> people in MathWorks on how to do this.
Any news?
Uwe
--
I strongly condemn Hamas heinous despicable pogroms/atro
> I have also quite a bit of clones, so no worries.
> Here is what I did on my local machine (I did not mess up with sourceforge)
> - git clone --bare git+ssh://o...@git.code.sf.net/p/matlab-emacs/src
matlab-sf-mirror-bare
> - cd matlab-sf-mirror-bare
> - delete t
>>> "JC" == John Ciolfi writes:
> I think Eric may be on vacation. I'm fairly confident that we've
> already taken the work from shellcomplete and put it in master. Just
> in case we haven't, I just made a git clone of matlab-emacs that
> contains all the current branches. I'll double check with
>>> "EL" == Eric Ludlam writes:
Hi all
> Regarding finding differences between a branch and main/master.
> I was trying to remind myself what the changes were. Thus, just a diff
> between branch tip and main/master from whence the branch was created. (ie
> - what did I change). Then I could che
>>> "EL" == Eric Ludlam writes:
> Regarding finding differences between a branch and main/master.
> I was trying to remind myself what the changes were. Thus, just a diff
> between branch tip and main/master from whence the branch was created. (ie
> - what did I change). Then I could check main
>>> "JC" == John Ciolfi writes:
> Hi
> I just double checked the fontlonkhang branch, downloaded zip
> *
> matlab-emacs-src-a78b368387c85437f8de187acf0a2b1cbeeacc3f/ (master)
> *
> matlab-emacs-src-ce22c697d06ece776cfd7a9a41b3704f1815823f/ (fontlockhang)
> And diff'd them - all changes ar
>>> "JC" == John Ciolfi writes:
> Regarding the fontlockhang, these have been merged in to the
> main/master branch already. I just manually compared matlab.el between
> and the fontlock improvements are in the tip.
> The fontlockhang branch can be deleted.
This is odd, (and this is why I don't
>>> "UB" == Uwe Brauer writes:
>>> "EL" == Eric Ludlam writes:
>> Removing those 3 items are fine with me. Here are some details.
>> * I'm pretty sure fontlockhang was used by John to solve problems at
>> MathWorks. I thought John then recommended the fixes be merged into
>> mainline after tha
>>> "EL" == Eric Ludlam writes:
> Removing those 3 items are fine with me. Here are some details.
> * I'm pretty sure fontlockhang was used by John to solve problems at
> MathWorks. I thought John then recommended the fixes be merged into
> mainline after that.
I would like to clarify these is
>>> "EL" == Eric Ludlam writes:
Hi
> Thanks for doing all this work Uwe. I appreciate it.
> For unmerged branches, I recognize some as branches that were merged via
> other avenues, and others are not relevant anymore or I don't recall what I
> might have been up to. Should be fine to ignore t
Hi all (especially Eric)
As you maybe aware of, we plan to move the development to github. That
is a good moment, to think about cleaning up a bit the repository, like
rebasing and deleting old merged branches.
The idea is once we agree, I would push a test, but public repository to my own
githu
>>> "JC" == John Ciolfi writes:
> Great, if you can help me get this in place (clean history and the 'default'
> branch), I will up get it uploaded to github.
Ok, let's to this calmly in the next few days.
Tomorrow I will write to the list and ask Eric specifically which merged
branch we can
>>> "JC" == John Ciolfi writes:
> Hi
> I'm proposing starting fresh meaning initially no history in github.
> You'd need to jump back to Source Forge for the older changes. They
> would not be lost. We'd freeze Source Forge and add a link to them.
> Part of the reason for doing this is that ther
>>> "JC" == John Ciolfi writes:
> Hi
> I haven't spent time looking into how to make the branch 'default'
> (too many other items on my plate).
I did this in the past, without problems, I am just retrying it again
and tell you the details later.
> Once that's done, I can upload the repo to gith
>>> "JC" == John Ciolfi writes:
> Okay, I'll look into seeing if we can call it default.
Any news?
I also would like before we move
1. Do some rebasing and make the graph a bit leaner
2. Delete some very old branches which are merged into master a long time
ago.
3. That most like
>>> "JC" == John Ciolfi writes:
Hi
> Hi
> For the main branch, the convention is to use "main" in github. I'm
> not sure if there's a way to switch from that. If possible, I'd like
> to use that. Here's an example of a MathWorks sponsored project,
> https://github.com/mathworks/MATLAB-language-
>>> "JC" == John Ciolfi writes:
hi
> Hi
> We'd like to move matlab-mode from Source Forge to github,
> https://github.com/MathWorks/Emacs-MATLAB-Mode, which gives us a good
> location for the "master" matlab-mode in github along with the
> benefits of github. Note, there are already many copie
> If you try
> M-x set-variable RET fill-column RET
> 150
Consider
#+begin_src
function [teuler,yeuler,ev]=mieulerimpfixpc(f,intv,y0,N,TOL,nmax) % se
implementa el tercer tipo de función dada por el enunciado
a = min(intv); % se
prep
>>> "JC" == John Ciolfi writes:
> If you try
> M-x set-variable RET fill-column RET
> 150
I was using 100, now I changed to 150.
> The two M-q commands will look better. I assume you were using a smaller
fill column.
I presume your M-q executes command matlab-fill-comment-line
>>> "JC" == John Ciolfi writes:
Hi John
> Hi Uwe,
> I don't think these fill-paragraph patches made it into master.
> Attached are the patches that work for me. Are there any reasons to
> not apply them?
In July last year Eric provided some patches for improving the filling.
I started a new b
>>> "MiEGr" == MATLAB in Emacs Git repository
>>> writes:
> ## Branch: master
> mlint: fix Emacs 29 issues
> Emacs 29 was giving "Unknown type: linemark-overlay" which exists for
> compatibility between XEmacs and Emacs. Since XEmacs is no longer
> maintaned from what we can tell, Eric remove
>>> "NNB" == Nidish Narayanaa Balaji
>>> writes:
> Okay I've fixed the font-lock issue.
> Since I adapted the code from a pre-existing package that was meant to
> be stand-alone, it had some checks in place that were overriding the
> existing font-lock. I got rid of these and simplified it sin
>>> "NNB" == Nidish Narayanaa Balaji
>>> writes:
> Okay I've fixed the font-lock issue.
> Since I adapted the code from a pre-existing package that was meant to
> be stand-alone, it had some checks in place that were overriding the
> existing font-lock. I got rid of these and simplified it sin
>>> "NNB" == Nidish Narayanaa Balaji
>>> writes:
> Wow that's interesting, thanks for noticing!
> I didn't catch this because I myself use tree-sitter for syntax
> highlighting and don't use the syntax highlighting from matlab-mode.
I have heard about this package but I have never used it mysel
>>> "NNB" == Nidish Narayanaa Balaji
>>> writes:
> I just finished the edits and pushed them.
> 1. I've defined a 'matlab-cell-shell-run-cell' function in
>matlab-cell.el which basically calls 'matlab-shell-run-region' from
>matlab-shell.el with the appropriate bounds of the current poin
> Yes this is true. This seems to be a restriction from
> matlab-shell-run-cell. I guess I'll just write a
> matlab-cell-shell-run-cell function that's more neatly integrated
> within the matlab-cell minor-mode.
I remember of having discussions with Eric, when that feature was
implemented, but a
> 1. Done. I've added it to the lisp_LISP variable in the Makefile and
>can confirm that it builds fine.
> 2. This is correct. I found no reason to rewrite matlab-shell-run-cell
>since it works fine as is. Let me know if you feel otherwise.
It still works fine, well with o
>>> "NNB" == Nidish Narayanaa Balaji
>>> writes:
Hi
> A few pointers:
> The main features that the new minor-mode enables are:
> * It redefines the page-break character to "%%" so an overline is
> drawn over those, making it visually look better.
> * The current cell that point is i
> On 5/14/24 17:39, Uwe Brauer wrote:
> Yes I do - my ID is: nidish96
Ok, so you should have write access now.
BTW, maybe it is better you create a branch for testing and then I (or
you merge that later into master)?
so that at least we can do some testing.
--
I strongly condemn Hamas heinou
>>> "NNB" == Nidish Narayanaa Balaji
>>> writes:
> Great!
> And yes, I had signed the FSF papers a while back.
Great, I would need your sourceforge userid.
In case you don't have one, please open a sourceforge account.
Uwe
> Best,
> Nidish
> On 5/14/24 17:08, Uwe Brauer wrote:
> "NNB"
>>> "NNB" == Nidish Narayanaa Balaji
>>> writes:
> No worries - I look forward to hearing back. If I get push rights by
> the weekend, I'll push directly. If not, I'll make a patch and send
> it.
Eric and John let me decide, (great).
Since I am trying since for more than a year to get the pack
>>> "NNB" == Nidish Narayanaa Balaji
>>> writes:
> Here's a screenshot of how I have it setup now. The cells are
> delimited by a string that defaults to a regexp that matches for
> commented lines starting with "%%". It supports sending cells one by
> one to the shell and provides some nif
>>> "NNB" == Nidish Narayanaa Balaji
>>> writes:
> All,
> I've implemented some additional cell block behavior that makes using
> cells in matlab through emacs smoother. It's similar to the stock
> matlab GUI experience but better (IMO ;) ).
I am not sure what the stock matlab GUI experience is
> On 25.04.2024 21:55, martinoidar wrote:
> Update:
> I've just noticed that not everything is properly rendered in markdown
> form.
Thanks, but I still do not understand why *fprintf* is not supported and
why the indenting should be important.
When I have a bit more time, I will ask John exp
>>> "m" == martinoidar writes:
Hi
I decided to start a new thread, since I made some progress and it seems
there are at least two ways to execute matlab from an org buffer and
insert the result back into that buffer.
1. Using the python engine matlab ships (I am not describing the
se
>>> "VC" == Vasco Cúrdia writes:
> I don't know how to contribute to this email discussions. So I'm not sure
> if replying to this email is the correct way.
> In response to latest "digest", regarding Github, I find that exchanging
> views in Github "issues" is very straightforward and clean, wh
> On 22.04.2024 14:52, Uwe Brauer wrote:
> 2 fprintf('|%d', x)
> Well...
> 1. After installing matlab-support you should be able to Matlab from
> bash by typing the command
Well, I am on tcsh, but this is not the point.
> Can you do that?
Yes I can, but mainly because during install
Hi
Some comments, since it did not work as expected.
> On 21.04.2024 19:40, Uwe Brauer wrote:
> Your approach is indeed cumbersome.
> In mine we need to:
> 1. Install `matlab-support` - a debian package that enables matlab
> integration within the system:
> sudo apt install matlab-support
> Well, I also prefer gitlab, especially after recent controversies with
> co-pilot
> (https://www.infoworld.com/article/3627319/github-copilot-is-unacceptable-and-unjust-says-free-software-foundation.html),
> though I'm not fervent about it...
> Yes, I do use org-babel and matlab. Until now,
> Everything's ok now.
> The confusion was caused by the fact that when I downloaded
> yesterday the latest snapshot from your master branch
> I was convinced that it included Nidish's patches
> (well, he had sent them almost half a year ago! :-))
yes. I wanted to test them, which I did and then
>>> "m" == martinoidar writes:
> Hello,
> thanks for maintaining the project.
> Nidish N., thank you for font-lock-reference-face fix.
> There are two issues regarding this fix:
> - melpa repository (https://melpa.org/#/matlab-mode) still contains
> version from July 2023. It would be nice if
>>> "m" == martinoidar writes:
Hello
> Hello,
> thanks for maintaining the project.
> Nidish N., thank you for font-lock-reference-face fix.
> There are two issues regarding this fix:
> - melpa repository (https://melpa.org/#/matlab-mode) still contains
> version from July 2023. It would be n
80 matches
Mail list logo
