1 Release 8.1.0 Feb-16-2026
═══════════════════════════

  1. The behavior of TAB and RET in matlab-ts-mode to electric
     indent/code-format adjacent lines of code.  There is no change in
     the indent/code-format rules. The goal of this change is to improve
     editing interactions with the MATLAB indent/code-format engine.


  • TAB behavior example. Given

    ┌────
    │ a = 1;
    │ foo = 2;
    │ foobar = 3;
    └────

    A TAB on any these code lines results in:

    ┌────
    │ a      = 1;
    │ foo    = 2;
    │ foobar = 3;
    └────

  • RET behavior example. Given

    ┌────
    │ v1=1;
    │ var2= [1,1];
    └────

    Typing the 4 characters, `x=3;', on the 3rd line (without typing
    RET) gives us:

    ┌────
    │ v1=1;
    │ var2= [1,1];
    │ x=3;
    └────

    When we type the RET, we get:

    ┌────
    │ v1   = 1;
    │ var2 = [1, 1];
    │ x    = 3;
    │ 
    └────

    Now, if we type a RET at the end of the 2nd line, we get the
    following. Notice that the alignment of x assignment has changed.

    ┌────
    │ v1   = 1;
    │ var2 = [1, 1];
    │ 
    │ x = 3;
    │ 
    └────

  1. An "electric ends" edge case issues in matlab-ts-mode has been
     fixed. When typing a statement that is terminated by an end,
     e.g. "if", "function", "classdef", etc. the "end" keyword is
     automatically added for you. For example, given:

     ┌────
     │ if a
     └────

     typing RET at the end of the "if a" line results in:

     ┌────
     │ if a
     │ 
     │ end
     └────

     where the point is left on the 2nd line, indented to 4 spaces.

     There were some edge cases where an end-statement was being
     incorrectly inserted. This primarily occurred with continued
     (ellipsis) conditions following the "if" and similar
     statements. For example, given the following, typing RET at the end
     of the first line will not add an end-statement whereas previously
     we were incorrectly adding and end-statement.

     ┌────
     │ if a && ...
     │ 
     │ end
     └────


2 Release 8.0.5 Feb-14-2026
═══════════════════════════

  This release fixes a build issue when using matlab-mode with Emacs
  that doesn't have tree-sitter. In addition, several lisp cleanups were
  performed (no behavior changes).


3 Release 8.0.4 Feb-7-2026
══════════════════════════

  This release fixes a minor issue when using matlab-ts-mode with point
  location when indenting (TAB) a multi-output variable line of the
  form:

  ┌────
  │ a([   1, 2], :) = ...
  │     [  3,   4,   5; ...
  │      300, 400, 500];
  └────

  If point is on the `1' and we indent the line (TAB), the point will
  remain on the `1' and the result will be:

  ┌────
  │ a([1, 2], :) = ...
  │     [  3,   4,   5; ...
  │      300, 400, 500];
  └────


4 Release 8.0.3 Feb-5-2026
══════════════════════════

  This release updates to the latest tree-sitter-matlab grammar which
  addresses a couple issues in matlab-ts-mode related to indent and
  font-lock.


5 Release 8.0.2 Jan-31-2026
═══════════════════════════

  This release:

  1. Improves robustness of matlab-ts-mode electric indent in Emacs 30.1
     build 1 v.s. build 2.

     Electric indent is now robust to varying behavior from tree-sitter
     matlab parse tree access.  Two different builds of Emacs 30.1 on
     Debian 12 are producing different results for the identical parse
     trees created using the same libtree-sitter-matlab.so. We see cases
     where treesit-node-next-sibling and treesit-node-parent return
     different results on same parse tree.

  2. Updates to tree-sitter-matlab grammar from 2026-01-31.


6 Release 8.0.1 Jan-30-2026
═══════════════════════════

  Minor /electric indent/ fix to correct comma placement in struct field
  alignment and also to fix non-positional name = value arguments and
  attributes.


7 Release 8.0.0 Jan-29-2026
═══════════════════════════

  This release updates matlab-ts-mode indent to /electric indent
  code/. This is sometimes called pretty printing code or formatting
  code.  …  …
