GNU bug report logs - #66159
30.0.50; lua-ts-mode semantic indentation problems

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 66159 in the body.
You can then email your comments to 66159 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrey Listopadov <andreyorst <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; lua-ts-mode semantic indentation problems
Date: Fri, 22 Sep 2023 22:17:55 +0300

I've been editing Lua using the long-existing lua-mode[1] and it works
well enough for me, but it's indentation implementation is very slow.
Indenting a file with just 600 lines takes several seconds on my
machine.  So when I saw that Emacs now features a lua-ts-mode package in
its core, I tried to move to it, in hopes that it would be faster.

However, a lot of code is now indented differently, not how I used to,
and this creates a lot of noise in commits, as I often re-indent the
whole buffer before saving the file. Here are some examples.

lua-mode:

function foo (e)
    if e == nil
    then return 1000
    else return e
end end

lua-ts-mode:

function foo (e)
    if e == nil
        then return 1000
    else return e
    end end

My thoughts:

`then' is indented as the part of the block of code that is part of the
`true' branch itself. In lua-mode, it is indented the same as `if' itself,
and everything after `then' is indented if moved to a new line:

function foo (e)
    if e == nil
    then
        return 1000
    else
        return e
end end

In lua-ts-mode it is indented together with the body which isn't
idiomatic:

function foo (e)
    if e == nil
        then
        return 1000
    else
        return e
    end end

Another thing that bothers me is that I prefer Gassanenko-style packing
of `end' keywords so that they vertically align with the scope of the
opened block, as it saves so much vertical space and is easier for me to
read, but lua-ts-mode moves it to the latest innermost indentation
level, as opposed to the outermost depending on the count of ends in the
line itself:

function lowest_entropy_cell(world)
|   local lowest,res=math.huge,nil
|   for y=1,world.height do
|   |   for x=1,world.width do
|   |   |   local cell=world:get(x,y)
|   |   |   if cell.is_set then
|   |   |   |   local e=cell_enthropy(cell)
|   |   |   |   trace(e)
|   |   |   |   if e <= lowest then
|   |   |   |   |   lowest,res=e,{x,y}
|   end end end end
|   return res or {math.random(world.width),math.random(world.height)}
end

However, lua-ts-mode indents it like so:

function lowest_entropy_cell(world)
    local lowest,res=math.huge,nil
    for y=1,world.height do
        for x=1,world.width do
            local cell=world:get(x,y)
            if cell.is_set then
                local e=cell_enthropy(cell)
                trace(e)
                if e <= lowest then
                    lowest,res=e,{x,y}
                end end end end
    return res or {math.random(world.width),math.random(world.height)}
end

I noticed the difference in table indentations as well.

lua-mode:

local Recipe = {
    Floor={up={Floor=true,Wall=true},
           down={Floor=true,Wall=true},
           left={Floor=true,Wall=true},
           right={Floor=true,Wall=true}},
    Wall={up={Floor=true,Wall=true},
          down={Floor=true,Wall=true},
          left={Floor=true,Wall=true},
          right={Floor=true,Wall=true}},
    Corridor={up={Corridoor=true},
              down={Corridoor=true},
              left={Corridoor=true},
              right={Corridoor=true}}
}

lua-ts-mode:

local Recipe = {
    Floor={up={Floor=true,Wall=true},
        down={Floor=true,Wall=true},
        left={Floor=true,Wall=true},
        right={Floor=true,Wall=true}},
    Wall={up={Floor=true,Wall=true},
        down={Floor=true,Wall=true},
        left={Floor=true,Wall=true},
        right={Floor=true,Wall=true}},
    Corridor={up={Corridoor=true},
        down={Corridoor=true},
        left={Corridoor=true},
        right={Corridoor=true}}
}

The first one is more logical and obeys scope levels.

Should I expect this to be the default new way of indenting or the
indentation can be made to match the lua-mode where it is sensible?

Thanks!

P.S. I know that stacking `end' isn't really idiomatic Lua style, but it
works in old-lua mode sensible enough that it is actually surprising,
and transforms Lua into code that is easy to parse just by looking on
the indentation level, much like Lisps.

[1] https://github.com/immerrr/lua-mode


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.17.8) of 2023-09-18 built on toolbox
Repository revision: 861f9cb78370e2b78f852e5ccde9b63c94486ca8
Repository branch: master
System Description: Fedora Linux 38 (Container Image)

Configured using:
 'configure --without-compress-install --with-native-compilation=aot
 --with-pgtk --with-mailutils --with-xwidgets
 --prefix=/var/home/alist/.local'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER XIM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lua

Minor modes in effect:
  repeat-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  electric-pair-mode: t
  hl-todo-mode: t
  savehist-mode: t
  delete-selection-mode: t
  pixel-scroll-precision-mode: t
  global-auto-revert-mode: t
  corfu-popupinfo-mode: t
  global-corfu-mode: t
  corfu-mode: t
  global-region-bindings-mode: t
  recentf-mode: t
  gcmh-mode: t
  server-mode: t
  marginalia-mode: t
  vertico-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  context-menu-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  abbrev-mode: t
  hs-minor-mode: t

Load-path shadows:
/var/home/alist/.config/emacs/elpa/transient-20230915.1911/transient hides /var/home/alist/.local/share/emacs/30.0.50/lisp/transient
/var/home/alist/.config/emacs/elpa/modus-themes-20230916.905/theme-loaddefs hides /var/home/alist/.local/share/emacs/30.0.50/lisp/theme-loaddefs

Features:
(shadow emacsbug dabbrev lua-ts-mode rect lua-mode modus-operandi-theme
python geiser-mode geiser-xref geiser-compile geiser-guile tramp
trampver tramp-integration tramp-message tramp-compat tramp-loaddefs
info-look geiser geiser-debug geiser-repl geiser-image geiser-capf
geiser-doc geiser-menu geiser-autodoc geiser-edit etags fileloop
geiser-completion geiser-eval geiser-connection tq geiser-syntax
geiser-log geiser-popup geiser-impl help-fns radix-tree geiser-custom
geiser-base scheme find-dired grep display-line-numbers css-mode treesit
smie mu4e-alert advice time ht alert log4e notifications gntp mu4e
mu4e-org mu4e-main mu4e-view mu4e-headers mu4e-compose mu4e-draft
mu4e-actions smtpmail mu4e-search mu4e-lists mu4e-bookmarks mu4e-mark
mu4e-message flow-fill hl-line mu4e-contacts mu4e-update mu4e-folders
mu4e-server mu4e-context mu4e-vars mu4e-helpers mu4e-config ido tabify
cus-start repeat files-x org-archive puni pulse color consult ox-odt
rng-loc rng-uri rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse
nxml-ns nxml-enc xmltok nxml-util ox-icalendar org-agenda ox-ascii
ox-latex ox-hugo ox-hugo-deprecated ffap ox-blackfriday ox-md ox-html
table ox-publish tomelr ox sgml-mode facemenu xwidget magit-bookmark
bookmark goto-addr vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs
log-view vc bug-reference vc-git vc-dispatcher misearch multi-isearch
dired-aux face-remap magit-extras orderless flyspell ispell org-element
org-persist org-id org-refile avl-tree generator oc-basic ol-eww eww xdg
url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect
gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr
pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start
gnus-dbus gnus-cloud nnimap nnmail mail-source utf7 nnoo parse-time
gnus-spec gnus-int gnus-range gnus-win gnus nnheader range ol-docview
doc-view jka-compr image-mode exif ol-bibtex bibtex iso8601 ol-bbdb
ol-w3m ol-doi org-link-doi org-tempo tempo ob-fennel fennel-proto-repl
fennel-mode inf-lisp xref magit-submodule magit-blame magit-stash
magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone
magit-remote magit-commit magit-sequence magit-notes magit-worktree
magit-tag magit-merge magit-branch magit-reset magit-files magit-refs
magit-status magit magit-repos magit-apply magit-wip magit-log
which-func imenu magit-diff smerge-mode diff diff-mode git-commit
log-edit message sendmail yank-media puny dired dired-loaddefs rfc822
mml mml-sec epa epg rfc6068 epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log
magit-core magit-autorevert magit-margin magit-transient magit-process
with-editor magit-mode transient magit-git magit-base magit-section
cursor-sensor crm project ob-lua ob-shell shell org ob ob-tangle ob-ref
ob-lob ob-table ob-exp org-macro org-src ob-comint org-pcomplete
pcomplete org-list org-footnote org-faces org-entities ob-emacs-lisp
ob-core ob-eval org-cycle org-table org-keys oc org-loaddefs find-func
cal-menu calendar cal-loaddefs vertico-directory mule-util time-date
noutline outline elec-pair isayt disp-table hideshow hl-todo savehist
delsel pixel-scroll cua-base autorevert filenotify corfu-popupinfo cape
corfu region-bindings recentf tree-widget gcmh init proxy gsettings s
gvariant parsec dash zig-compilation-mode fennel-compilation-mode
clojure-compilation-mode derived compile text-property-search server
ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init
ediff-util sql-indent sql view thingatpt comint ansi-osc ring zig-mode
reformatter ansi-color ol org-fold org-fold-core org-compat org-version
org-macs format-spec blog marginalia vertico compat use-package-delight
formfeed modus-vivendi-theme modus-themes dbus xml common-lisp-modes
novice cus-edit pp cus-load wid-edit font mode-line edmacro kmacro
messages use-package-bind-key bind-key defaults functions local-config
delight comp comp-cstr warnings icons rx use-package-ensure cl-extra
help-mode use-package-core early-init cape-autoloads
clj-decompiler-autoloads clj-refactor-autoloads cider-autoloads
clojure-mode-autoloads common-lisp-modes-autoloads consult-autoloads
corfu-terminal-autoloads corfu-autoloads csv-mode-autoloads
delight-autoloads dumb-jump-autoloads eat-autoloads elfeed-autoloads
expand-region-autoloads fennel-mode-autoloads gcmh-autoloads
geiser-guile-autoloads geiser-autoloads gsettings-autoloads
gvariant-autoloads hl-todo-autoloads inflections-autoloads
isayt-autoloads jdecomp-autoloads lisp-extra-font-lock-autoloads
lsp-java-autoloads lsp-metals-autoloads dap-mode-autoloads
lsp-docker-autoloads bui-autoloads lsp-treemacs-autoloads
lsp-mode-autoloads f-autoloads lua-mode-autoloads marginalia-autoloads
markdown-mode-autoloads message-view-patch-autoloads magit-autoloads
pcase magit-section-autoloads git-commit-autoloads
modus-themes-autoloads mu4e-alert-autoloads alert-autoloads
log4e-autoloads gntp-autoloads multiple-cursors-autoloads
orderless-autoloads org-modern-autoloads org-tree-slide-autoloads
ox-hugo-autoloads package-lint-flymake-autoloads package-lint-autoloads
paredit-autoloads parsec-autoloads parseedn-autoloads parseclj-autoloads
phi-search-autoloads poly-org-autoloads polymode-autoloads
popon-autoloads popup-autoloads puni-autoloads easy-mmode finder-inf
queue-autoloads racket-mode-autoloads region-bindings-autoloads
request-autoloads scala-mode-autoloads separedit-autoloads
edit-indirect-autoloads sesman-autoloads sly-autoloads spinner-autoloads
sql-indent-autoloads tomelr-autoloads transient-autoloads
treemacs-autoloads cfrs-autoloads posframe-autoloads ht-autoloads
hydra-autoloads lv-autoloads pfuture-autoloads ace-window-autoloads
avy-autoloads s-autoloads dash-autoloads vertico-autoloads
vundo-autoloads with-editor-autoloads info compat-autoloads
yaml-autoloads yaml-mode-autoloads yasnippet-autoloads
zig-mode-autoloads reformatter-autoloads package browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
term/common-win pgtk-dnd touch-screen tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads xwidget-internal dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
gtk pgtk lcms2 multi-tty move-toolbar make-network-process
native-compile emacs)

Memory information:
((conses 16 1147781 1425356) (symbols 48 52742 50)
 (strings 32 272573 78657) (string-bytes 1 9908365)
 (vectors 16 119200) (vector-slots 8 2827929 951125)
 (floats 8 888 21739) (intervals 56 40788 17575) (buffers 992 46))

-- 
Andrey Listopadov

Message #8 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrey Listopadov <andreyorst <at> gmail.com>, john muhl <jm <at> pub.pink>
Cc: 66159 <at> debbugs.gnu.org
Subject: Re: bug#66159: 30.0.50; lua-ts-mode semantic indentation problems
Date: Fri, 22 Sep 2023 22:49:35 +0300

> From: Andrey Listopadov <andreyorst <at> gmail.com>
> Date: Fri, 22 Sep 2023 22:17:55 +0300
> 
> 
> I've been editing Lua using the long-existing lua-mode[1] and it works
> well enough for me, but it's indentation implementation is very slow.
> Indenting a file with just 600 lines takes several seconds on my
> machine.  So when I saw that Emacs now features a lua-ts-mode package in
> its core, I tried to move to it, in hopes that it would be faster.
> 
> However, a lot of code is now indented differently, not how I used to,
> and this creates a lot of noise in commits, as I often re-indent the
> whole buffer before saving the file. Here are some examples.

John, could you please look into this?

Message #11 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: john muhl <jm <at> pub.pink>
To: Andrey Listopadov <andreyorst <at> gmail.com>
Cc: 66159 <at> debbugs.gnu.org
Subject: Re: bug#66159: 30.0.50; lua-ts-mode semantic indentation problems
Date: Sun, 24 Sep 2023 10:06:50 -0500

[Message part 1 (text/plain, inline)]

Andrey Listopadov <andreyorst <at> gmail.com> writes:

> I've been editing Lua using the long-existing lua-mode[1] and it works
> well enough for me, but it's indentation implementation is very slow.
> Indenting a file with just 600 lines takes several seconds on my
> machine.  So when I saw that Emacs now features a lua-ts-mode package
> in its core, I tried to move to it, in hopes that it would be faster.

Thanks for trying.

> However, a lot of code is now indented differently, not how I used to,
> and this creates a lot of noise in commits, as I often re-indent the
> whole buffer before saving the file. Here are some examples.

The "then" and table examples should indent how you like with the
attached patch. Arguments and parameters now also work like your table
example so you can have:

  local function fn(a, b, c,
                    another) end

  fn(1,
     2,
     3,
     {a="first",
      b="second"})

> Another thing that bothers me is that I prefer Gassanenko-style packing
> of `end' keywords so that they vertically align with the scope of the
> opened block, as it saves so much vertical space and is easier for me to
> read, but lua-ts-mode moves it to the latest innermost indentation
> level, as opposed to the outermost depending on the count of ends in the
> line itself:
>
> function lowest_entropy_cell(world)
> |   local lowest,res=math.huge,nil
> |   for y=1,world.height do
> |   |   for x=1,world.width do
> |   |   |   local cell=world:get(x,y)
> |   |   |   if cell.is_set then
> |   |   |   |   local e=cell_enthropy(cell)
> |   |   |   |   trace(e)
> |   |   |   |   if e <= lowest then
> |   |   |   |   |   lowest,res=e,{x,y}
> |   end end end end
> |   return res or {math.random(world.width),math.random(world.height)}
> end

I don't see any reason not to support that style but I'm not sure how to
do it. A patch would be welcome but I'll try to figure it out sometime.

> Should I expect this to be the default new way of indenting or the
> indentation can be made to match the lua-mode where it is sensible?

Sure. It's a new mode so nothing is really set in stone. Let me know if
you have other suggestions.

[0001-Improve-indentation-in-lus-ts-mode-Bug-66159.patch (text/x-patch, attachment)]

Message #14 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: john muhl <jm <at> pub.pink>
Cc: andreyorst <at> gmail.com, 66159 <at> debbugs.gnu.org
Subject: Re: bug#66159: 30.0.50; lua-ts-mode semantic indentation problems
Date: Sun, 24 Sep 2023 18:44:54 +0300

> Cc: 66159 <at> debbugs.gnu.org
> Date: Sun, 24 Sep 2023 10:06:50 -0500
> From:  john muhl via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> > Another thing that bothers me is that I prefer Gassanenko-style packing
> > of `end' keywords so that they vertically align with the scope of the
> > opened block, as it saves so much vertical space and is easier for me to
> > read, but lua-ts-mode moves it to the latest innermost indentation
> > level, as opposed to the outermost depending on the count of ends in the
> > line itself:
> >
> > function lowest_entropy_cell(world)
> > |   local lowest,res=math.huge,nil
> > |   for y=1,world.height do
> > |   |   for x=1,world.width do
> > |   |   |   local cell=world:get(x,y)
> > |   |   |   if cell.is_set then
> > |   |   |   |   local e=cell_enthropy(cell)
> > |   |   |   |   trace(e)
> > |   |   |   |   if e <= lowest then
> > |   |   |   |   |   lowest,res=e,{x,y}
> > |   end end end end
> > |   return res or {math.random(world.width),math.random(world.height)}
> > end
> 
> I don't see any reason not to support that style but I'm not sure how to
> do it. A patch would be welcome but I'll try to figure it out sometime.

Maybe introduce indentation styles into lua-ts-mode, like CC Mode and
c-ts-mode have?

Message #17 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: Andrey Listopadov <andreyorst <at> gmail.com>
To: john muhl <jm <at> pub.pink>
Cc: 66159 <at> debbugs.gnu.org
Subject: Re: bug#66159: 30.0.50; lua-ts-mode semantic indentation problems
Date: Sun, 24 Sep 2023 19:38:38 +0300

Thanks! The patch seems to work as I would expect for most cases.

> I don't see any reason not to support that style but I'm not sure how to
> do it. A patch would be welcome but I'll try to figure it out sometime.

A far as I understand it, in the `lua-mode' the overall line indentation
is computed via subtracting indentation for every `end' in that line,
e.g. `end end end' subtracts `lua-indent-level three times from current
indent level.

> Sure. It's a new mode so nothing is really set in stone. Let me know if
> you have other suggestions.

I also noticed that `lua-ts-inferior-lua` for some reason starts itself
in a new frame instead of just a new window. I haven't seen this
behavior with other inferior-*-modes, and the `lua-start-process'
function from `lua-mode' doesn't spawn a new frame either.

Looking at the code, it seems that it was a deliberate choice, as I see
the use of `display-buffer-pop-up-frame' in the `display-buffer' ACTION
arg.

--
Andrey Listopadov

Message #20 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: john muhl <jm <at> pub.pink>
To: Andrey Listopadov <andreyorst <at> gmail.com>
Cc: 66159 <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#66159: 30.0.50; lua-ts-mode semantic indentation problems
Date: Sun, 24 Sep 2023 13:20:23 -0500

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> > Another thing that bothers me is that I prefer Gassanenko-style packing
>> > of `end' keywords so that they vertically align with the scope of the
>> > opened block, as it saves so much vertical space and is easier for me to
>> > read, but lua-ts-mode moves it to the latest innermost indentation
>> > level, as opposed to the outermost depending on the count of ends in the
>> > line itself:
>> 
>> I don't see any reason not to support that style but I'm not sure how to
>> do it. A patch would be welcome but I'll try to figure it out sometime.
>
> Maybe introduce indentation styles into lua-ts-mode, like CC Mode and
> c-ts-mode have?

I’ll have a look at what the c-ts-mode styles do and see what might be
applicable. In this case the changes can be accommodated by default.

Andrey Listopadov <andreyorst <at> gmail.com> writes:

> Thanks! The patch seems to work as I would expect for most cases.
>
>> I don't see any reason not to support that style but I'm not sure how to
>> do it. A patch would be welcome but I'll try to figure it out sometime.
>
> A far as I understand it, in the `lua-mode' the overall line indentation
> is computed via subtracting indentation for every `end' in that line,
> e.g. `end end end' subtracts `lua-indent-level three times from current
> indent level.

Thanks for the explanation. The attached patch should make end packing
work now.

>> Sure. It's a new mode so nothing is really set in stone. Let me know if
>> you have other suggestions.
>
> I also noticed that `lua-ts-inferior-lua` for some reason starts itself
> in a new frame instead of just a new window. I haven't seen this
> behavior with other inferior-*-modes, and the `lua-start-process'
> function from `lua-mode' doesn't spawn a new frame either.
>
> Looking at the code, it seems that it was a deliberate choice, as I see
> the use of `display-buffer-pop-up-frame' in the `display-buffer' ACTION
> arg.

It did use a window originally but I was asked to change it:

>> +    (pop-to-buffer buffer)))
>
> I believe that `display-buffer-pop-up-frame' is the preferred alternative
> to `pop-to-buffer' these days.

Maybe I misunderstood and it was only about not using ‘pop-to-buffer’
and should have been ‘display-buffer-pop-up-window’. CC’d Philip for
clarification.

If you customize where you want it with ‘display-buffer-alist’ that
should be respected.

[0001-Improve-indentation-in-lus-ts-mode-Bug-66159.patch (text/x-patch, attachment)]

Message #23 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: Andrey Listopadov <andreyorst <at> gmail.com>
To: john muhl <jm <at> pub.pink>
Cc: 66159 <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#66159: 30.0.50; lua-ts-mode semantic indentation problems
Date: Tue, 26 Sep 2023 22:21:35 +0300

john muhl <jm <at> pub.pink> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> > Another thing that bothers me is that I prefer Gassanenko-style packing
>>> > of `end' keywords so that they vertically align with the scope of the
>>> > opened block, as it saves so much vertical space and is easier for me to
>>> > read, but lua-ts-mode moves it to the latest innermost indentation
>>> > level, as opposed to the outermost depending on the count of ends in the
>>> > line itself:
>>>
>>> I don't see any reason not to support that style but I'm not sure how to
>>> do it. A patch would be welcome but I'll try to figure it out sometime.
>>
>> Maybe introduce indentation styles into lua-ts-mode, like CC Mode and
>> c-ts-mode have?
>
> I’ll have a look at what the c-ts-mode styles do and see what might be
> applicable. In this case the changes can be accommodated by default.

In my opinion, this isn't distinct enough to introduce a new style.
But it's up to you to decide, of course - I'm all for better editing
experience for Lua!

>> A far as I understand it, in the `lua-mode' the overall line indentation
>> is computed via subtracting indentation for every `end' in that line,
>> e.g. `end end end' subtracts `lua-indent-level three times from current
>> indent level.
>
> Thanks for the explanation. The attached patch should make end packing
> work now.

I've tried your latest patch and indeed `end' now pack themselves as in
the lua-mode.  Thank you very much!

>>> Sure. It's a new mode so nothing is really set in stone. Let me know if
>>> you have other suggestions.

I noticed that the `do' keyword is indented similarly to `then' before
the patch when put on the new line:

for i=1,10
    do
    print(i)
end

I'm not sure if that's a proper way to indent it or not though, but `do'
usually signifies start of the scope, so perhaps it shouldn't be
indented in this case.

There are also some weirdness in semantic navigation, but it's more
likely that I'm just not used to new ts-backed navigation yet.

Thanks for your work on lua-ts-mode, it's much more snappy editing
experience now!

If you're willing to dig into some (pretty crazy) involved examples, I
can send here some really convoluted nested anonymous functions that
currently are indented in a weird way in both modes. Neither does it
exactly right in my opiion, but I also don't know if there is the right
way to indent this.  I can send these examples later this week once I
finish an article I'm working on rightnow.

--
Andrey Listopadov

Message #26 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: john muhl <jm <at> pub.pink>
To: Andrey Listopadov <andreyorst <at> gmail.com>
Cc: 66159 <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#66159: 30.0.50; lua-ts-mode semantic indentation problems
Date: Tue, 26 Sep 2023 20:18:07 -0500

[Message part 1 (text/plain, inline)]

Andrey Listopadov <andreyorst <at> gmail.com> writes:

> john muhl <jm <at> pub.pink> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> > Another thing that bothers me is that I prefer Gassanenko-style packing
>>>> > of `end' keywords so that they vertically align with the scope of the
>>>> > opened block, as it saves so much vertical space and is easier for me to
>>>> > read, but lua-ts-mode moves it to the latest innermost indentation
>>>> > level, as opposed to the outermost depending on the count of ends in the
>>>> > line itself:
>>>>
>>>> I don't see any reason not to support that style but I'm not sure how to
>>>> do it. A patch would be welcome but I'll try to figure it out sometime.
>>>
>>> Maybe introduce indentation styles into lua-ts-mode, like CC Mode and
>>> c-ts-mode have?
>>
>> I’ll have a look at what the c-ts-mode styles do and see what might be
>> applicable. In this case the changes can be accommodated by default.
>
> In my opinion, this isn't distinct enough to introduce a new style.
> But it's up to you to decide, of course - I'm all for better editing
> experience for Lua!

I agree there’s no immediate need.

Could you explain what the lua-indent-* options do in lua-mode? I tried
toggling them but didn’t see any difference between on/off.

>>> A far as I understand it, in the `lua-mode' the overall line indentation
>>> is computed via subtracting indentation for every `end' in that line,
>>> e.g. `end end end' subtracts `lua-indent-level three times from current
>>> indent level.
>>
>> Thanks for the explanation. The attached patch should make end packing
>> work now.
>
> I've tried your latest patch and indeed `end' now pack themselves as in
> the lua-mode.  Thank you very much!
>
>>>> Sure. It's a new mode so nothing is really set in stone. Let me know if
>>>> you have other suggestions.
>
> I noticed that the `do' keyword is indented similarly to `then' before
> the patch when put on the new line:
>
> for i=1,10
>     do
>     print(i)
> end
>
> I'm not sure if that's a proper way to indent it or not though, but `do'
> usually signifies start of the scope, so perhaps it shouldn't be
> indented in this case.

Fixed in the attached.

> There are also some weirdness in semantic navigation, but it's more
> likely that I'm just not used to new ts-backed navigation yet.

I’m sure there is room for improvement here too. Suggestions welcome.

> Thanks for your work on lua-ts-mode, it's much more snappy editing
> experience now!

Glad to hear it.

> If you're willing to dig into some (pretty crazy) involved examples, I
> can send here some really convoluted nested anonymous functions that
> currently are indented in a weird way in both modes. Neither does it
> exactly right in my opiion, but I also don't know if there is the right
> way to indent this.  I can send these examples later this week once I
> finish an article I'm working on rightnow.

Sure. Whenever you have the time.

[0001-Improve-indentation-in-lus-ts-mode-Bug-66159.patch (text/x-patch, attachment)]

Message #29 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: john muhl <jm <at> pub.pink>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 66159 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#66159: 30.0.50; lua-ts-mode semantic indentation problems
Date: Sat, 30 Sep 2023 07:52:34 +0000

john muhl <jm <at> pub.pink> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> > Another thing that bothers me is that I prefer Gassanenko-style packing
>>> > of `end' keywords so that they vertically align with the scope of the
>>> > opened block, as it saves so much vertical space and is easier for me to
>>> > read, but lua-ts-mode moves it to the latest innermost indentation
>>> > level, as opposed to the outermost depending on the count of ends in the
>>> > line itself:
>>> 
>>> I don't see any reason not to support that style but I'm not sure how to
>>> do it. A patch would be welcome but I'll try to figure it out sometime.
>>
>> Maybe introduce indentation styles into lua-ts-mode, like CC Mode and
>> c-ts-mode have?
>
> I’ll have a look at what the c-ts-mode styles do and see what might be
> applicable. In this case the changes can be accommodated by default.
>
> Andrey Listopadov <andreyorst <at> gmail.com> writes:
>
>> Thanks! The patch seems to work as I would expect for most cases.
>>
>>> I don't see any reason not to support that style but I'm not sure how to
>>> do it. A patch would be welcome but I'll try to figure it out sometime.
>>
>> A far as I understand it, in the `lua-mode' the overall line indentation
>> is computed via subtracting indentation for every `end' in that line,
>> e.g. `end end end' subtracts `lua-indent-level three times from current
>> indent level.
>
> Thanks for the explanation. The attached patch should make end packing
> work now.
>
>>> Sure. It's a new mode so nothing is really set in stone. Let me know if
>>> you have other suggestions.
>>
>> I also noticed that `lua-ts-inferior-lua` for some reason starts itself
>> in a new frame instead of just a new window. I haven't seen this
>> behavior with other inferior-*-modes, and the `lua-start-process'
>> function from `lua-mode' doesn't spawn a new frame either.
>>
>> Looking at the code, it seems that it was a deliberate choice, as I see
>> the use of `display-buffer-pop-up-frame' in the `display-buffer' ACTION
>> arg.
>
> It did use a window originally but I was asked to change it:
>
>>> +    (pop-to-buffer buffer)))
>>
>> I believe that `display-buffer-pop-up-frame' is the preferred alternative
>> to `pop-to-buffer' these days.
>
> Maybe I misunderstood and it was only about not using ‘pop-to-buffer’
> and should have been ‘display-buffer-pop-up-window’. CC’d Philip for
> clarification.

Yes, you are right, I meant `display-buffer-pop-up-window'.

> If you customize where you want it with ‘display-buffer-alist’ that
> should be respected.

Message #32 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: Andrey Listopadov <andreyorst <at> gmail.com>
To: john muhl <jm <at> pub.pink>
Cc: 66159 <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#66159: 30.0.50; lua-ts-mode semantic indentation problems
Date: Sat, 30 Sep 2023 12:59:28 +0300

john muhl <jm <at> pub.pink> writes:

> I agree there’s no immediate need.
>
> Could you explain what the lua-indent-* options do in lua-mode? I tried
> toggling them but didn’t see any difference between on/off.

I don't really know it myself, sorry. There seem to be some specifics
regarding how the content inside parenthesis is indented, but I'm not
using these either.

>> There are also some weirdness in semantic navigation, but it's more
>> likely that I'm just not used to new ts-backed navigation yet.
>
> I’m sure there is room for improvement here too. Suggestions welcome.

Here are a few examples. the █ represents the point:

█(function (x) return x + 1 end)(41)

Pressing C-M-f (forward-sexp) puts the point here:

 (function (x)█return x + 1 end)(41)

I would expect it to go over the whole parenthesized expression:

 (function (x) return x + 1 end)█(41)

Another weird thing here:

 function foo (x)
     if false then
         print "foo"
     elseif true then
         print "bar"
     end
 end█

Pressing C-M-b (backward-sexp) puts the point here:

 function foo (x)
    █if false then
         print "foo"
     elseif true then
         print "bar"
     end
 end

I would expect it to go before the `function' instead:

█function foo (x)
     if false then
         print "foo"
     elseif true then
         print "bar"
     end
 end

>> If you're willing to dig into some (pretty crazy) involved examples, I
>> can send here some really convoluted nested anonymous functions that
>> currently are indented in a weird way in both modes. Neither does it
>> exactly right in my opiion, but I also don't know if there is the right
>> way to indent this.  I can send these examples later this week once I
>> finish an article I'm working on rightnow.
>
> Sure. Whenever you have the time.

I've tried a couple of Lua formatters available, and as far as I can
see, most of them indent my code in a weird way too, so perhaps it's not
really a problem, although I'm not sure.

For example, here's a piece of code that implements an iterator wrapper
with anonymous functions only:

1  function partitioning (n, collect)
2      return function (iterator)
3          return function (...)
4              return (
5                  function (next1, ...)
6                      local count, arr, last = 0, {}
7                      return (function (f, ...)
8                          return (function (i, ...) return i(i, ...) end)(
9                              function (i, ...)
10                                 return f(function (x, ...)
11                                     return i(i, ...)(x, ...)
12                                 end, ...)
13                             end)
14                     end)(function (step)
15                         return function(iterable, ...)
16                             return (function (recur, iterable, ...)
17                                 if nil ~= ... then
18                                     if n-1 == count then
19                                         local arr1, count1 = arr, count
20                                         arr, count = {}, 0
21                                         return (function (...)
22                                             last = ...
23                                             return ...
24                                         end)(collect(arr1, count1+1, ...))
25                                     else
26                                         count = count + 1
27                                         return recur(iterable,
28                                                      (function (...)
29                                                          last = ...
30                                                          return ...
31                                                      end)(collect(arr, count, ...)))
32                                     end
33                                 elseif count ~= 0 then
34                                     count = 0
35                                     return last, arr
36                                 end
37                             end)(step, iterable, next1(iterable, ...))
38                         end
39                     end), ...
40                 end)(iterator(...))
41         end
42     end
43 end


Here are the lines I find strange.

First, the Immediately Invoked Function Expression (IIFE) indentation is
all over the place:

8                          return (function (i, ...) return i(i, ...) end)(
9                              function (i, ...)
10                                 return f(function (x, ...)
11                                     return i(i, ...)(x, ...)
12                                 end, ...)
13                             end)

The I would expect the inner IIFE to be indented like this:

8                          return (function (i, ...) return i(i, ...) end)(
9                              function (i, ...)
10                                 return f(function (x, ...)
11                                              return i(i, ...)(x, ...)
12                                          end, ...)
13                             end)


Another strange snippet:

21                                         return (function (...)
22                                             last = ...
23                                             return ...
24                                         end)(collect(arr1, count1+1, ...))

The `last' and `return' statements are not properly indented to the
function's scope. I expected it to be indented like this:

21                                         return (function (...)
22                                                     last = ...
23                                                     return ...
24                                                 end)(collect(arr1, count1+1, ...))

And, weirdly, enough, a bit further in the code there's a similar
expression, but it is indented correctly:

27                                         return recur(iterable,
28                                                      (function (...)
29                                                          last = ...
30                                                          return ...
31                                                      end)(collect(arr, count, ...)))

I know, that this code is convoluted, and probably no one writes like
this, it was done on purpose for an article about the power of anonymous
functions, so perhaps it isn't really a problem for most Lua
programmers. But it makes reading code a bit harder in rare cases like
this. I have more examples in the article, feel free to grab them if you
need code snippets for testing:

https://andreyor.st/posts/2023-09-26-iterator-based-transducers-in-lua/

Other than that, and the navigation issues I've mentioned above, the
mode works solidly. I've also noticed that some of the `lua-mode'
default shortcuts are missing, like `C-c C-f' (lua-search-documentation)
and `C-c C-l' (lua-send-buffer), but these may be out of the scope of
this module, so let me know if I should just define these myself.

Thanks!


--
Andrey Listopadov

Message #37 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: john muhl <jm <at> pub.pink>
To: Andrey Listopadov <andreyorst <at> gmail.com>
Cc: 66159 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#66159: 30.0.50; lua-ts-mode semantic indentation problems
Date: Sat, 30 Sep 2023 08:57:06 -0500

[Message part 1 (text/plain, inline)]

Andrey Listopadov <andreyorst <at> gmail.com> writes:

> john muhl <jm <at> pub.pink> writes:
>
>> I agree there’s no immediate need.
>>
>> Could you explain what the lua-indent-* options do in lua-mode? I tried
>> toggling them but didn’t see any difference between on/off.
>
> I don't really know it myself, sorry. There seem to be some specifics
> regarding how the content inside parenthesis is indented, but I'm not
> using these either.

I found <https://github.com/immerrr/lua-mode/pull/151> with the
explanation of those options.

>>> There are also some weirdness in semantic navigation, but it's more
>>> likely that I'm just not used to new ts-backed navigation yet.
>>
>> I’m sure there is room for improvement here too. Suggestions welcome.
>
> Here are a few examples. the █ represents the point:

Fixed in the attached.

>>> If you're willing to dig into some (pretty crazy) involved examples, I
>>> can send here some really convoluted nested anonymous functions that
>>> currently are indented in a weird way in both modes. Neither does it
>>> exactly right in my opiion, but I also don't know if there is the right
>>> way to indent this.  I can send these examples later this week once I
>>> finish an article I'm working on rightnow.
>>
>> Sure. Whenever you have the time.
>
> I know, that this code is convoluted, and probably no one writes like
> this, it was done on purpose for an article about the power of anonymous
> functions, so perhaps it isn't really a problem for most Lua
> programmers. But it makes reading code a bit harder in rare cases like
> this. I have more examples in the article, feel free to grab them if you
> need code snippets for testing:
>
> https://andreyor.st/posts/2023-09-26-iterator-based-transducers-in-lua/

Thanks. The patch gets pretty close on the partitioning function from
your article (the mapping, filtering and taking functions indent
correctly now). The trouble is that you end up with a tree like:

  (return_statement
   (expression_list
    (function_call
     (parenthesized_expression
      (function_definition
       (end))))))

with two different indent styles.

  return (function (f, ...)                  -- L7
  end)(function (step)                       -- L14

  return (function (...)                     -- L21
          end)(collect(arr1, count1+1, ...)) -- L24

Is there some pattern for deciding that I’m missing?

> Other than that, and the navigation issues I've mentioned above, the
> mode works solidly. I've also noticed that some of the `lua-mode'
> default shortcuts are missing, like `C-c C-f'
> (lua-search-documentation)

The opening a browser to look at the docs approach isn’t very Emacs-y so
didn’t make the cut. Ideally it should integrate with info and/or eldoc
but I haven’t gotten to it yet. This should get you by in the meantime:

[lua-ts-dap.el (text/plain, inline)]

(defun jm~lua-ts-documentation-at-point ()
  "Show documentation of function at point in the Lua manual."
  (interactive)
  (save-excursion
    ;; When point is mid-word `treesit-thing-at-point' may return
    ;; the parent node of the thing at point. Go to the beginning
    ;; of the line or word to make sure we have the right thing.
    (unless (or (bolp)
                (not (string-match-p "[[:alnum:]]"
                                     (char-to-string (char-before)))))
      (backward-word))
    (when-let* ((node (treesit-thing-at-point 'sentence nil))
                ((equal "function_call" (treesit-node-type node)))
                (child (treesit-node-child-by-field-name node "name"))
                (name (treesit-node-text child t))
                (id (if (string-match-p ":" name)
                        (replace-regexp-in-string "^.*:" "file:" name)
                      name))
                ((string-match-p (rx-to-string `(: (? "file:")
                                                   (or ,@lua-ts--builtins)))
                                 id)))
      (browse-url (concat "file:///usr/share/doc/lua/manual.html"
                          "#pdf-" id)))))

[Message part 3 (text/plain, inline)]

> and `C-c C-l' (lua-send-buffer), but these may be out of the scope of
> this module, so let me know if I should just define these myself.

The attached patch includes lua-ts-send-{buffer,file,region}
commands with bindings for:

  C-c C-n start inferior Lua
  C-c C-c send buffer
  C-c C-l send file
  C-c C-r send region

I’ve been using a send-thing but wasn’t sure it’s worth including. What
do you think?

[lua-ts-st.el (text/plain, inline)]

(defun jm~lua-ts-send-thing (point)
  "Send thing near POINT to the inferior Lua process."
  (interactive "d")
  (when-let* ((node (treesit-node-at point))
              (parent (treesit-parent-until
                       node
                       (lambda (p)
                         (string-match-p (rx (or "do_statement"
                                                 "for_statement"
                                                 "function_call"
                                                 "function_declaration"
                                                 "if_statement"
                                                 "repeat_statement"
                                                 "while_statement"))
                                         (treesit-node-type p)))
                       t)))
    (lua-ts-send-region (treesit-node-start parent)
                        (treesit-node-end parent))))

[Message part 5 (text/plain, inline)]

It looks at the tree around point and tries to find something to eval;
e.g.

  function fun[1](n)
      if n > 1
      th[2]en print(1)
      else p[3]rint(0)
      end
  end

Point at [1] sends the function, [2] the if statement, [3] the print
statement.

[0001-Various-improvements-in-lus-ts-mode-Bug-66159.patch (text/x-patch, attachment)]

Message #40 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: john muhl <jm <at> pub.pink>
To: Andrey Listopadov <andreyorst <at> gmail.com>
Cc: 66159 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#66159: 30.0.50; lua-ts-mode semantic indentation problems
Date: Tue, 03 Oct 2023 10:04:56 -0500

[Message part 1 (text/plain, inline)]

Whoops. Looks like I forgot to update the patch before sending. This one
should be better.

[0001-Various-improvements-in-lus-ts-mode-Bug-66159.patch (text/x-patch, attachment)]

Message #43 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: Andrey Listopadov <andreyorst <at> gmail.com>
To: john muhl <jm <at> pub.pink>
Cc: 66159 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#66159: 30.0.50; lua-ts-mode semantic indentation problems
Date: Tue, 03 Oct 2023 22:13:23 +0300

john muhl <jm <at> pub.pink> writes:

> Whoops. Looks like I forgot to update the patch before sending. This one
> should be better.
>
> [2. text/x-patch; 0001-Various-improvements-in-lus-ts-mode-Bug-66159.patch]...

Thanks! I tried the patch, and it works great! I noticed a small
indentation problem:

function (...)
    return (function (x)
        return x
            end)(foo(...))
end

probably this should be:

function (...)
    return (function (x)
                return x
            end)(...)
end

The movement now works great, thanks.

--
Andrey Listopadov

Message #46 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: john muhl <jm <at> pub.pink>
To: 66159 <at> debbugs.gnu.org
Cc: Andrey Listopadov <andreyorst <at> gmail.com>
Subject: [PATCH] Various improvements to lua-ts-mode (Bug#66159)
Date: Fri, 06 Oct 2023 14:44:42 -0500

[Message part 1 (text/plain, inline)]

Tags: patch

Here is a cleaned up patch. A couple of small additions unrelated to
this bug are included but I can separate them if anyone prefers. The
additions are:

- Make lua-ts-mode-hook a defcustom.
- Add an option to use a history file for inferior process input.

Andrey if you could test this one it’d be appreciated. Thanks for your
help.

[0001-Various-improvements-to-lua-ts-mode-Bug-66159.patch (text/x-patch, attachment)]

Message #49 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: john muhl <jm <at> pub.pink>, 66159 <at> debbugs.gnu.org
Cc: Andrey Listopadov <andreyorst <at> gmail.com>
Subject: Re: bug#66159: [PATCH] Various improvements to lua-ts-mode (Bug#66159)
Date: Sat, 7 Oct 2023 07:11:42 -0300

On 6/10/23 16:44, john muhl via Bug reports for GNU Emacs, the Swiss 
army knife of text editors wrote:

> +(defcustom lua-ts-inferior-history nil
> +  "File used to save command history of the inferior Lua process."
> +  :type '(choice (const nil) file)

Please, give a :tag for the const option.  IMO, it makes for a better
Customize UI.

Message #52 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: Andrey Listopadov <andreyorst <at> gmail.com>
To: john muhl <jm <at> pub.pink>
Cc: 66159 <at> debbugs.gnu.org
Subject: Re: [PATCH] Various improvements to lua-ts-mode (Bug#66159)
Date: Sat, 07 Oct 2023 19:15:44 +0300

john muhl <jm <at> pub.pink> writes:

> Tags: patch
>
> Here is a cleaned up patch. A couple of small additions unrelated to
> this bug are included but I can separate them if anyone prefers. The
> additions are:
>
> - Make lua-ts-mode-hook a defcustom.
> - Add an option to use a history file for inferior process input.
>
> Andrey if you could test this one it’d be appreciated. Thanks for your
> help.
>
> [2. text/x-patch; 0001-Various-improvements-to-lua-ts-mode-Bug-66159.patch]...

It seems the last patch broke the movement.

--
Andrey Listopadov

Message #55 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: john muhl <jm <at> pub.pink>
To: Andrey Listopadov <andreyorst <at> gmail.com>
Cc: 66159 <at> debbugs.gnu.org
Subject: Re: [PATCH] Various improvements to lua-ts-mode (Bug#66159)
Date: Sat, 07 Oct 2023 13:10:31 -0500

Andrey Listopadov <andreyorst <at> gmail.com> writes:

> john muhl <jm <at> pub.pink> writes:
>
>> Tags: patch
>>
>> Here is a cleaned up patch. A couple of small additions unrelated to
>> this bug are included but I can separate them if anyone prefers. The
>> additions are:
>>
>> - Make lua-ts-mode-hook a defcustom.
>> - Add an option to use a history file for inferior process input.
>>
>> Andrey if you could test this one it’d be appreciated. Thanks for your
>> help.
>>
>> [2. text/x-patch; 0001-Various-improvements-to-lua-ts-mode-Bug-66159.patch]...
>
> It seems the last patch broke the movement.

The tests for those pass and are still working here. Maybe you found
another case that needs to be improved. What is the specific problem?

Message #58 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: Andrey Listopadov <andreyorst <at> gmail.com>
To: john muhl <jm <at> pub.pink>
Cc: 66159 <at> debbugs.gnu.org
Subject: Re: [PATCH] Various improvements to lua-ts-mode (Bug#66159)
Date: Sun, 08 Oct 2023 12:43:50 +0300

john muhl <jm <at> pub.pink> writes:

>> It seems the last patch broke the movement.
>
> The tests for those pass and are still working here. Maybe you found
> another case that needs to be improved. What is the specific problem?

It seems so, sorry for not including this, I thought I sent this before.
Here's an example:


█for i=1,10 do
     print(x)
 end

Pressing Pressing C-M-f (forward-sexp) puts the point here:

 for i=1,10 do
     print(x)█
 end

I think it should go over the `for' loop right to the `end'.

Pressing Pressing C-M-b (backward-sexp), however, puts the point here:

 for i=1,10 do
    █print(x)
 end

Pressing C-M-b again doesn't move the point anymore.

Same thing happens with for-each style loop:

█for k,v in pairs({1,2,3}) do
     print(x)
 end

C-M-f:

 for k,v in pairs({1,2,3})█do
     print(x)
 end

C-M-f:

 for k,v in pairs({1,2,3}) do
     print(x)█
 end

Backward movement manages to take the point way back to the pairs:

C-M-b, C-M-b:

 for k,v in pairs█({1,2,3}) do
     print(x)
 end

I went to https://devhints.io/lua and copied a bunch of examples of
other loops to the scratch buffer, and the movement is as follows:

█while condition do
 end

 for i = 1,5 do
 end

 for i = start,finish,delta do
 end

 for k,v in pairs(tab) do
 end

 repeat
 until condition

 -- Breaking out:
 while x do
   if condition then break end
 end

C-M-f:

 while condition do
 end

 for i = 1,5 do
 end

 for i = start,finish,delta do
 end

 for k,v in pairs(tab)█do
 end

 repeat
 until condition

 -- Breaking out:
 while x do
   if condition then break end
 end

C-M-f:

 while condition do
 end

 for i = 1,5 do
 end

 for i = start,finish,delta do
 end

 for k,v in pairs(tab) do
 end

 repeat
 until condition

 -- Breaking out:
 while x do
   if condition then break end█
 end


--
Andrey Listopadov

Message #61 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: john muhl <jm <at> pub.pink>
To: 66159 <at> debbugs.gnu.org
Cc: Andrey Listopadov <andreyorst <at> gmail.com>,
 Mauro Aranda <maurooaranda <at> gmail.com>
Subject: Re: [PATCH] Various improvements to lua-ts-mode (Bug#66159)
Date: Sun, 08 Oct 2023 22:28:02 -0500

[Message part 1 (text/plain, inline)]

Mauro Aranda <maurooaranda <at> gmail.com> writes:

> On 6/10/23 16:44, john muhl via Bug reports for GNU Emacs, the Swiss
> army knife of text editors wrote:
>
>> +(defcustom lua-ts-inferior-history nil
>> +  "File used to save command history of the inferior Lua process."
>> +  :type '(choice (const nil) file)
>
> Please, give a :tag for the const option.  IMO, it makes for a better
> Customize UI.

Fixed here and for the other choices.

Andrey Listopadov <andreyorst <at> gmail.com> writes:

> john muhl <jm <at> pub.pink> writes:
>
>>> It seems the last patch broke the movement.
>>
>> The tests for those pass and are still working here. Maybe you found
>> another case that needs to be improved. What is the specific problem?
>
> It seems so, sorry for not including this, I thought I sent this before.
> Here's an example:
>
>
> █for i=1,10 do
>      print(x)
>  end
>
> Pressing Pressing C-M-f (forward-sexp) puts the point here:
>
>  for i=1,10 do
>      print(x)█
>  end
>
> I think it should go over the `for' loop right to the `end'.
>
> Pressing Pressing C-M-b (backward-sexp), however, puts the point here:
>
>  for i=1,10 do
>     █print(x)
>  end
>
> Pressing C-M-b again doesn't move the point anymore.
>
> Same thing happens with for-each style loop:
>
> █for k,v in pairs({1,2,3}) do
>      print(x)
>  end
>
> C-M-f:
>
>  for k,v in pairs({1,2,3})█do
>      print(x)
>  end
>
> C-M-f:
>
>  for k,v in pairs({1,2,3}) do
>      print(x)█
>  end
>
> Backward movement manages to take the point way back to the pairs:
>
> C-M-b, C-M-b:
>
>  for k,v in pairs█({1,2,3}) do
>      print(x)
>  end
>
> I went to https://devhints.io/lua and copied a bunch of examples of
> other loops to the scratch buffer, and the movement is as follows:
>
> █while condition do
>  end
>
>  for i = 1,5 do
>  end
>
>  for i = start,finish,delta do
>  end
>
>  for k,v in pairs(tab) do
>  end
>
>  repeat
>  until condition
>
>  -- Breaking out:
>  while x do
>    if condition then break end
>  end
>
> C-M-f:
>
>  while condition do
>  end
>
>  for i = 1,5 do
>  end
>
>  for i = start,finish,delta do
>  end
>
>  for k,v in pairs(tab)█do
>  end
>
>  repeat
>  until condition
>
>  -- Breaking out:
>  while x do
>    if condition then break end
>  end
>
> C-M-f:
>
>  while condition do
>  end
>
>  for i = 1,5 do
>  end
>
>  for i = start,finish,delta do
>  end
>
>  for k,v in pairs(tab) do
>  end
>
>  repeat
>  until condition
>
>  -- Breaking out:
>  while x do
>    if condition then break end█
>  end

Navigation should be all around improved now. Let me know if I missed something.

[0001-Various-improvements-to-lua-ts-mode-Bug-66159.patch (text/x-patch, attachment)]

Message #64 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: john muhl <jm <at> pub.pink>
To: 66159 <at> debbugs.gnu.org
Cc: Andrey Listopadov <andreyorst <at> gmail.com>,
 Mauro Aranda <maurooaranda <at> gmail.com>
Subject: Re: [PATCH] Various improvements to lua-ts-mode (Bug#66159)
Date: Mon, 16 Oct 2023 22:26:00 -0500

[Message part 1 (text/plain, inline)]

john muhl <jm <at> pub.pink> writes:

> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>
>> On 6/10/23 16:44, john muhl via Bug reports for GNU Emacs, the Swiss
>> army knife of text editors wrote:
>>
>>> +(defcustom lua-ts-inferior-history nil
>>> +  "File used to save command history of the inferior Lua process."
>>> +  :type '(choice (const nil) file)
>>
>> Please, give a :tag for the const option.  IMO, it makes for a better
>> Customize UI.
>
> Fixed here and for the other choices.
>
> Andrey Listopadov <andreyorst <at> gmail.com> writes:
>
>> john muhl <jm <at> pub.pink> writes:
>>
>>>> It seems the last patch broke the movement.
>>>
>>> The tests for those pass and are still working here. Maybe you found
>>> another case that needs to be improved. What is the specific problem?
>>
>> It seems so, sorry for not including this, I thought I sent this before.
>> Here's an example:
>>
>>
>> █for i=1,10 do
>>      print(x)
>>  end
>>
>> Pressing Pressing C-M-f (forward-sexp) puts the point here:
>>
>>  for i=1,10 do
>>      print(x)█
>>  end
>>
>> I think it should go over the `for' loop right to the `end'.
>>
>> Pressing Pressing C-M-b (backward-sexp), however, puts the point here:
>>
>>  for i=1,10 do
>>     █print(x)
>>  end
>>
>> Pressing C-M-b again doesn't move the point anymore.
>>
>> Same thing happens with for-each style loop:
>>
>> █for k,v in pairs({1,2,3}) do
>>      print(x)
>>  end
>>
>> C-M-f:
>>
>>  for k,v in pairs({1,2,3})█do
>>      print(x)
>>  end
>>
>> C-M-f:
>>
>>  for k,v in pairs({1,2,3}) do
>>      print(x)█
>>  end
>>
>> Backward movement manages to take the point way back to the pairs:
>>
>> C-M-b, C-M-b:
>>
>>  for k,v in pairs█({1,2,3}) do
>>      print(x)
>>  end
>>
>> I went to https://devhints.io/lua and copied a bunch of examples of
>> other loops to the scratch buffer, and the movement is as follows:
>>
>> █while condition do
>>  end
>>
>>  for i = 1,5 do
>>  end
>>
>>  for i = start,finish,delta do
>>  end
>>
>>  for k,v in pairs(tab) do
>>  end
>>
>>  repeat
>>  until condition
>>
>>  -- Breaking out:
>>  while x do
>>    if condition then break end
>>  end
>>
>> C-M-f:
>>
>>  while condition do
>>  end
>>
>>  for i = 1,5 do
>>  end
>>
>>  for i = start,finish,delta do
>>  end
>>
>>  for k,v in pairs(tab)█do
>>  end
>>
>>  repeat
>>  until condition
>>
>>  -- Breaking out:
>>  while x do
>>    if condition then break end
>>  end
>>
>> C-M-f:
>>
>>  while condition do
>>  end
>>
>>  for i = 1,5 do
>>  end
>>
>>  for i = start,finish,delta do
>>  end
>>
>>  for k,v in pairs(tab) do
>>  end
>>
>>  repeat
>>  until condition
>>
>>  -- Breaking out:
>>  while x do
>>    if condition then break end█
>>  end
>
> Navigation should be all around improved now. Let me know if I missed something.
>
> [2. text/x-patch; 0001-Various-improvements-to-lua-ts-mode-Bug-66159.patch]...

Here is the latest version. Fixed a missing declare-function
and other minor omissions.

[0001-Various-improvements-to-lua-ts-mode-Bug-66159.patch (text/x-patch, attachment)]

Message #67 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: john muhl <jm <at> pub.pink>, 66159 <at> debbugs.gnu.org
Cc: Andrey Listopadov <andreyorst <at> gmail.com>,
 Mauro Aranda <maurooaranda <at> gmail.com>
Subject: Re: bug#66159: [PATCH] Various improvements to lua-ts-mode (Bug#66159)
Date: Fri, 20 Oct 2023 13:40:17 -0700

john muhl via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> Here is the latest version. Fixed a missing declare-function
> and other minor omissions.

Thanks.  Is this ready for installing on master, or is there anything
else that needs doing first?

Message #70 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: Andrey <andreyorst <at> gmail.com>
To: john muhl <jm <at> pub.pink>, 66159 <at> debbugs.gnu.org
Cc: Mauro Aranda <maurooaranda <at> gmail.com>
Subject: Re: [PATCH] Various improvements to lua-ts-mode (Bug#66159)
Date: Sat, 21 Oct 2023 08:15:06 +0300

>Here is the latest version. Fixed a missing declare-function
>and other minor omissions.
>

Thanks! Unfortunately, I'm on the trip right now and can't check the patch.
Sorry for delay. The last patch was great, so I have no objections from my part.

-- 
Andrey Listopadov

Message #73 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: Andrey <andreyorst <at> gmail.com>
To: john muhl <jm <at> pub.pink>, 66159 <at> debbugs.gnu.org
Cc: Mauro Aranda <maurooaranda <at> gmail.com>
Subject: Re: [PATCH] Various improvements to lua-ts-mode (Bug#66159)
Date: Sat, 21 Oct 2023 14:37:57 +0300

>Here is the latest version. Fixed a missing declare-function
>and other minor omissions.
>

Thanks! Unfortunately, I'm on the trip right now and can't check the patch.
Sorry for delay. The last patch was great, so I have no objections from my part.

-- 
Andrey Listopadov
-- 
Andrey Listopadov

Message #76 received at 66159 <at> debbugs.gnu.org (full text, mbox):

From: john muhl <jm <at> pub.pink>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 66159 <at> debbugs.gnu.org, Andrey Listopadov <andreyorst <at> gmail.com>,
 Mauro Aranda <maurooaranda <at> gmail.com>
Subject: Re: bug#66159: [PATCH] Various improvements to lua-ts-mode (Bug#66159)
Date: Sun, 22 Oct 2023 15:03:47 -0500

Stefan Kangas <stefankangas <at> gmail.com> writes:

> john muhl via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> Here is the latest version. Fixed a missing declare-function
>> and other minor omissions.
>
> Thanks.  Is this ready for installing on master, or is there anything
> else that needs doing first?

It should be ok to install.

Message #81 received at 66159-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: john muhl <jm <at> pub.pink>
Cc: 66159-done <at> debbugs.gnu.org, Andrey Listopadov <andreyorst <at> gmail.com>,
 Mauro Aranda <maurooaranda <at> gmail.com>
Subject: Re: bug#66159: [PATCH] Various improvements to lua-ts-mode (Bug#66159)
Date: Mon, 23 Oct 2023 01:11:57 -0700

Version: 30.1

john muhl <jm <at> pub.pink> writes:

> It should be ok to install.

Thanks, installed on master.  I'm consequently closing this bug.

[1: 1c261e0a6ca]: 2023-10-23 10:07:52 +0200
  Various improvements to lua-ts-mode (Bug#66159)
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1c261e0a6cae09e3ff36930442f2c9da44bccd6d

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.