GNU bug report logs - #59691
29.0.60; typescript-ts-mode: any HTML-like elements causes fontification to become invalid and remaining parse-tree to become jsx-expression

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 59691 in the body.
You can then email your comments to 59691 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: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>,
 Theodor Thornhill <theo <at> thornhill.no>
Subject: 29.0.60; typescript-ts-mode: any HTML-like elements causes
 fontification to become invalid and remaining parse-tree to become
 jsx-expression
Date: Tue, 29 Nov 2022 21:02:47 +0100

When I:
=======

1. Create a new TS-file, activate typescript-ts-mode
2. Write any text or code with HTML-like qualities.
3. Write more text or code

I experience that:
==================

The fontification after this point is permanently incorrect.

Instead I expected that:
========================

Fontification to remain correct.

Examples:
=========

To trigger this bug you only need to include HTML-like constructs in
a string:

    const example = "<123>";

Or just use a TypeScript hard casts:

    const result = <IService>service;

After this point the remaining parse-tree becomes invalid, because the
remaining parse-tree is not reported as a jsx-expreesion.



--



In GNU Emacs 29.0.60 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.34, cairo version 1.16.0) of 2022-11-29 built on ThinkPad-T14s
Repository revision: c43cdfd639518c5f2e7e7cbbaf1eca40ac957eb0
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12201003
System Description: Ubuntu 22.10

Configured using:
 'configure --with-tree-sitter'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

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

Major mode: TypeScript

Minor modes in effect:
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  lsp-diagnostics-mode: t
  lsp-headerline-breadcrumb-mode: t
  lsp-modeline-workspace-status-mode: t
  lsp-modeline-diagnostics-mode: t
  lsp-modeline-code-actions-mode: t
  electric-pair-mode: t
  treesit-explore-mode: t
  lsp-completion-mode: t
  editorconfig-mode: t
  flycheck-mode: t
  which-function-mode: t
  nlinum-mode: t
  company-mode: t
  global-ede-mode: t
  dap-tooltip-mode: t
  dap-ui-many-windows-mode: t
  dap-ui-controls-mode: t
  dap-ui-mode: t
  treemacs-filewatch-mode: t
  treemacs-follow-mode: t
  treemacs-git-mode: t
  treemacs-fringe-indicator-mode: t
  dap-auto-configure-mode: t
  dap-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  doom-modeline-mode: t
  projectile-mode: t
  ido-yes-or-no-mode: t
  helm-mode: t
  helm-minibuffer-history-mode: t
  helm--remap-mouse-mode: t
  async-bytecomp-package-mode: t
  delete-selection-mode: t
  global-auto-revert-mode: t
  server-mode: t
  shell-dirtrack-mode: t
  global-hl-line-mode: t
  lsp-managed-mode: t
  lsp-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-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

Load-path shadows:
/home/jostein/.emacs.d/elpa/transient-20221127.2242/transient hides 
/home/jostein/build/emacs/lisp/transient
/home/jostein/.emacs.d/elpa/eglot-20221020.1010/eglot hides 
/home/jostein/build/emacs/lisp/progmodes/eglot

Features:
(shadow sort emacsbug typescript-ts-mode js git-rebase vc-hg vc-bzr
vc-src vc-sccs vc-svn vc-cvs vc-rcs log-view vc bug-reference
magit-extras magit-bookmark magit-submodule magit-obsolete 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 magit-diff smerge-mode git-commit log-edit message
sendmail yank-media rfc822 mml mml-sec epa derived mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev
gmm-utils mailheader pcvs-util magit-core magit-autorevert magit-margin
magit-transient magit-process with-editor magit-mode transient magit-git
magit-base magit-section crm compat-27 compat-26 dired-aux ede/dired
flyspell ispell mule-util executable misearch multi-isearch
helm-bookmark helm-net helm-adaptive treemacs-bookmarks treemacs-tags
bookmark lsp-diagnostics lsp-headerline lsp-icons lsp-modeline
face-remap mail-extr helm-command helm-elisp helm-eval helm-info view
vc-git diff-mode vc-dispatcher disp-table elec-pair csharp-mode treesit
cc-langs cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs winner ffap tramp-archive tramp-gvfs
tramp-cache warnings time-stamp zeroconf dbus add-log lsp-zig lsp-steep
lsp-svelte lsp-sqls lsp-ruby-syntax-tree lsp-yaml lsp-xml lsp-vimscript
lsp-vhdl lsp-volar lsp-vetur lsp-html lsp-verilog lsp-vala lsp-v
lsp-typeprof lsp-ttcn3 lsp-toml lsp-terraform lsp-tex lsp-sorbet
lsp-solargraph lsp-rust lsp-rf lsp-remark lsp-racket lsp-r
lsp-purescript lsp-pylsp lsp-pyls lsp-php lsp-pls lsp-perlnavigator
lsp-perl lsp-openscad lsp-ocaml lsp-magik lsp-nix lsp-nim lsp-nginx
lsp-mint lsp-marksman lsp-markdown lsp-lua lsp-kotlin lsp-json
lsp-javascript lsp-idris lsp-haxe lsp-groovy lsp-hack lsp-graphql
lsp-gleam lsp-go lsp-completion lsp-gdscript lsp-fsharp lsp-fortran
lsp-eslint lsp-erlang lsp-emmet lsp-elixir lsp-elm lsp-dockerfile
lsp-dhall lsp-d lsp-css lsp-csharp gnutls lsp-crystal lsp-cmake
lsp-clojure lsp-semantic-tokens lsp-clangd lsp-beancount lsp-bash
lsp-astro lsp-ansible lsp-angular lsp-ada lsp-actionscript
ido-completing-read+ memoize minibuf-eldef elisp-slime-nav paredit
editorconfig editorconfig-core editorconfig-core-handle
editorconfig-fnmatch flycheck highlight-symbol which-func edebug debug
backtrace nlinum linum company-oddmuse company-keywords company-etags
etags fileloop generator company-gtags company-dabbrev-code
company-dabbrev company-files company-clang company-capf company-cmake
company-semantic company-template company-bbdb company-web-html
company-web company-css web-completion-data company eww url-queue shr
pixel-fill kinsoku url-file svg mm-url gnus nnheader gnus-util
mail-utils range mm-util mail-prsvr ede/speedbar ede/files ede
ede/detect ede/base ede/auto ede/source eieio-base eieio-speedbar
speedbar ezimage dframe eieio-custom cedet dap-mouse dap-ui lsp-treemacs
lsp-treemacs-generic lsp-treemacs-themes treemacs-treelib treemacs
treemacs-header-line treemacs-compatibility treemacs-mode
treemacs-interface treemacs-persistence treemacs-filewatch-mode
treemacs-follow-mode treemacs-rendering treemacs-annotations
treemacs-async treemacs-workspaces treemacs-dom treemacs-visuals
treemacs-fringe-indicator treemacs-scope pulse treemacs-faces
treemacs-icons treemacs-themes treemacs-core-utils pfuture
treemacs-logging treemacs-customization treemacs-macros gdb-mi bindat
gud bui bui-list bui-info bui-entry bui-core bui-history bui-button
bui-utils lsp-lens dap-gdb-lldb dap-netcore dap-node dap-utils dom xml
dap-pwsh lsp-pwsh dap-python dap-mode dap-tasks dap-launch lsp-docker
yaml posframe dap-overlays undo-tree diff queue doom-modeline
doom-modeline-segments doom-modeline-env doom-modeline-core
all-the-icons all-the-icons-faces data-material data-weathericons
data-octicons data-fileicons data-faicons data-alltheicons shrink-path
compat compat-macs projectile lisp-mnt grep ibuf-ext ibuffer
ibuffer-loaddefs helm-imenu ob-plantuml org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete
org-list org-faces org-entities org-version ob-emacs-lisp ob-core
ob-eval org-table oc-basic bibtex ol org-keys oc org-compat org-macs
org-loaddefs find-func cal-menu calendar cal-loaddefs ido-yes-or-no ido
helm-mode helm-misc helm-files image-dired image-dired-tags
image-dired-external image-dired-util xdg image-mode dired
dired-loaddefs exif tramp tramp-loaddefs trampver tramp-integration
cus-edit pp cus-load files-x tramp-compat parse-time iso8601 time-date
ls-lisp helm-buffers helm-occur helm-tags helm-locate helm-grep
helm-regexp format-spec helm-utils helm-help helm-types helm
helm-global-bindings helm-easymenu edmacro kmacro helm-core easy-mmode
async-bytecomp helm-source helm-multi-match helm-lib async helm-config
delsel cl-extra autorevert server powershell advice shell pcomplete
hl-line lsp-mode lsp-protocol yasnippet help-mode xref project
tree-widget wid-edit spinner pcase network-stream puny nsm markdown-mode
color thingatpt noutline outline icons lv inline imenu ht filenotify f
f-shortdoc shortdoc s ewoc epg rfc6068 epg-config dash dracula-theme
compile-eslint compile text-property-search comint ansi-osc ansi-color
ring cl finder-inf git-timemachine-autoloads rx
helm-projectile-autoloads expand-region-autoloads
all-the-icons-autoloads dracula-theme-autoloads eglot-autoloads
multiple-cursors-autoloads tree-sitter-langs-autoloads
projectile-autoloads nlinum-autoloads doom-modeline-autoloads
rust-mode-autoloads editorconfig-autoloads helm-autoloads
helm-core-autoloads async-autoloads assess-autoloads m-buffer-autoloads
cargo-autoloads package-lint-autoloads flycheck-autoloads
company-autoloads magit-autoloads magit-section-autoloads
web-mode-autoloads paredit-autoloads helpful-autoloads
elisp-refs-autoloads js2-mode-autoloads yaml-mode-autoloads
powershell-autoloads dap-mode-autoloads lsp-docker-autoloads
yaml-autoloads lsp-treemacs-autoloads treemacs-autoloads
posframe-autoloads hydra-autoloads pfuture-autoloads
ace-window-autoloads avy-autoloads lsp-mode-autoloads
markdown-mode-autoloads ht-autoloads git-commit-autoloads
with-editor-autoloads transient-autoloads compat-autoloads
pcache-autoloads f-autoloads popup-autoloads s-autoloads info
dash-autoloads macrostep-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/x-win x-win
term/common-win x-dnd 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 dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process emacs)

Memory information:
((conses 16 707483 89040)
 (symbols 48 57220 127)
 (strings 32 225052 10207)
 (string-bytes 1 6824489)
 (vectors 16 145796)
 (vector-slots 8 2442138 178412)
 (floats 8 1069 547)
 (intervals 56 14048 1723)
 (buffers 992 52))

-- 
Vennlig hilsen
*Jostein Kjønigsen*

jostein <at> kjonigsen.net 🍵 jostein <at> gmail.com
https://jostein.kjønigsen.no <https://jostein.kjønigsen.no>

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: 59691 <at> debbugs.gnu.org
Cc: casouri <at> gmail.com, jostein <at> kjonigsen.net, eliz <at> gnu.org
Subject: Html-like constructs fail in typescript
Date: Tue, 29 Nov 2022 22:01:01 +0100

Hi Jostein!

I already have a fix for this bug lined up, and will send the fix as
soon as I get my other stuff applied.  It relies on another patch that
is waiting.

The solution is to create two modes: typescript-ts-mode and
tsx-ts-mode. They have separate parsers, and should be treated as
separate languages.  That means that in a .ts file we enable the
'typescript' language, and in .tsx we enable the 'tsx' language.  This
exact issue is why they have two languages.

In other words, we cannot support this in typescript-ts-mode.

I hope to get this in pretty soon :)

Theo

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> kjonigsen.net,
 eliz <at> gnu.org
Subject: Re: Html-like constructs fail in typescript
Date: Tue, 29 Nov 2022 22:37:25 +0100

Nice!

Should we until further notice assume that js-ts-mode suffers from the same issues, and that a jsx-ts-mode might be needed too? To me it at least sounds plausible. 

Speaking of duplication… Now that we have tree-sitter wouldn’t it be possible to use the same parser and/or the same major-modes for JS/JSX as we already do for TS/TSX? JS/JSX is just Typescript without the type-annotations, right?

Or are there good reasons for having separate modes for these?

—
Jostein Kjønigsen
https://jostein.kjønigsen.net

> On 29 Nov 2022, at 22:04, Theodor Thornhill <theo <at> thornhill.no> wrote:
> 
> 
> Hi Jostein!
> 
> I already have a fix for this bug lined up, and will send the fix as
> soon as I get my other stuff applied.  It relies on another patch that
> is waiting.
> 
> The solution is to create two modes: typescript-ts-mode and
> tsx-ts-mode. They have separate parsers, and should be treated as
> separate languages.  That means that in a .ts file we enable the
> 'typescript' language, and in .tsx we enable the 'tsx' language.  This
> exact issue is why they have two languages.
> 
> In other words, we cannot support this in typescript-ts-mode.
> 
> I hope to get this in pretty soon :)
> 
> Theo

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> kjonigsen.net,
 eliz <at> gnu.org
Subject: Re: Html-like constructs fail in typescript
Date: Tue, 29 Nov 2022 22:47:38 +0100

On 29 November 2022 22:37:25 CET, "Jostein Kjønigsen" <jostein <at> secure.kjonigsen.net> wrote:
>Nice!
>
>Should we until further notice assume that js-ts-mode suffers from the same issues, and that a jsx-ts-mode might be needed too? To me it at least sounds plausible. 

No, because there are no ambiguities in the grammar with types and jsx.

>
>Speaking of duplication… Now that we have tree-sitter wouldn’t it be possible to use the same parser and/or the same major-modes for JS/JSX as we already do for TS/TSX? JS/JSX is just Typescript without the type-annotations, right?
>
>Or are there good reasons for having separate modes for these?
>

Not sure. I like that a mode maps to a tree-sitter grammar, and personally I don't want to intertwine things to early.

>

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

From: Yuan Fu <casouri <at> gmail.com>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59691 <at> debbugs.gnu.org, eliz <at> gnu.org,
 Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>,
 jostein <at> kjonigsen.net
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements 
 causes fontification to become invalid and remaining parse-tree to become 
 jsx-expression
Date: Wed, 30 Nov 2022 02:22:06 -0800

Theodor Thornhill <theo <at> thornhill.no> writes:

> On 29 November 2022 22:37:25 CET, "Jostein Kjønigsen" <jostein <at> secure.kjonigsen.net> wrote:
>>Nice!
>>
>>Should we until further notice assume that js-ts-mode suffers from
>> the same issues, and that a jsx-ts-mode might be needed too? To me
>> it at least sounds plausible.
>
> No, because there are no ambiguities in the grammar with types and jsx.
>
>>
>>Speaking of duplication… Now that we have tree-sitter wouldn’t it be
>> possible to use the same parser and/or the same major-modes for
>> JS/JSX as we already do for TS/TSX? JS/JSX is just Typescript
>> without the type-annotations, right?
>>
>>Or are there good reasons for having separate modes for these?
>>
>
> Not sure. I like that a mode maps to a tree-sitter grammar, and personally I don't want to intertwine things to early.

No strong opinions here, but currently a user could install
tree-sitter-js, and find and enable js-ts-mode, which is
straightforward, which is good. Since these four modes doesn’t require
too much boilerplate, I think it’s pretty good right now.

Yuan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> kjonigsen.net
Subject: Re: Html-like constructs fail in typescript
Date: Wed, 30 Nov 2022 14:35:49 +0200

> From: Theodor Thornhill <theo <at> thornhill.no>
> Cc: jostein <at> kjonigsen.net, casouri <at> gmail.com, eliz <at> gnu.org
> Date: Tue, 29 Nov 2022 22:01:01 +0100
> 
> The solution is to create two modes: typescript-ts-mode and
> tsx-ts-mode. They have separate parsers, and should be treated as
> separate languages.  That means that in a .ts file we enable the
> 'typescript' language, and in .tsx we enable the 'tsx' language.  This
> exact issue is why they have two languages.

This means the script posted by Yuan, which only creates a single grammar
library for Typescript (the one for tsx), should be changed to instead
produce two libraries, right?

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Theodor Thornhill <theo <at> thornhill.no>, Yuan Fu <casouri <at> gmail.com>,
 59691 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: Html-like constructs fail in typescript
Date: Wed, 30 Nov 2022 13:59:20 +0100

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

On 29.11.2022 23:20, Jostein Kjønigsen wrote:
>
>> On 29 Nov 2022, at 22:48, Theodor Thornhill<theo <at> thornhill.no>  wrote:
>>
>> 
>>
>>> On 29 November 2022 22:37:25 CET, "Jostein Kjønigsen"<jostein <at> secure.kjonigsen.net>  wrote:
>>> Nice!
>>>
>>> Should we until further notice assume that js-ts-mode suffers from the same issues, and that a jsx-ts-mode might be needed too? To me it at least sounds plausible.
>> No, because there are no ambiguities in the grammar with types and jsx.
>>
> Note this behaviour was triggered even when a HTML-tag was contained inside a plain string.
>
> Even without hard typescript casts, there are places where I suspect the same issues can bleed into js-ts-mode.
>
> I’ll try to do more testing tomorrow.

First of all - good news!

Contrary to my expectations, I've tested and I cannot reproduce this 
issue in js-ts-mode.

Even more good news:

Looking deeper into this using treesit-explorer-mode (an extremely 
helpful tool, Yuan!), I found I may have misinterpreted the state of the 
parse-tree in previous report.

Based on that, I would like to revise this bug report:

 * HTML-like constructs inside strings are --/not/-- treated at
   jsx_opening_elements,
 * only angle-bracket "hard" casts (which isn't present in Javascript)
   is causing issues for fontification.

Also, reading up, from what I can tell "hard casts" using angle-brackets 
are no longer encouraged as the default way to cast:

    const service = <IService>object;

This is because the above code will cause a compiler error if used in 
TSX-files (as opposed to TS-files). Instead "as" expressions are 
preferred, because they work equally well for both TS & TSX-files:

    const service = object as IService;

That means that writing idiomatic TypeScript with typescrip-ts-mode 
should produce the expected behaviour, while one may encounter issues 
with older code.

I'm not sure introducing a new major-mode for this 1 aspect of 
TypeScript development is worth it?

Does anyone else have an opinion on this?

--
Jostein

[Message part 2 (text/html, inline)]

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> kjonigsen.net
Subject: Re: Html-like constructs fail in typescript
Date: Wed, 30 Nov 2022 14:00:49 +0100

On 30 November 2022 13:35:49 CET, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Theodor Thornhill <theo <at> thornhill.no>
>> Cc: jostein <at> kjonigsen.net, casouri <at> gmail.com, eliz <at> gnu.org
>> Date: Tue, 29 Nov 2022 22:01:01 +0100
>> 
>> The solution is to create two modes: typescript-ts-mode and
>> tsx-ts-mode. They have separate parsers, and should be treated as
>> separate languages.  That means that in a .ts file we enable the
>> 'typescript' language, and in .tsx we enable the 'tsx' language.  This
>> exact issue is why they have two languages.
>
>This means the script posted by Yuan, which only creates a single grammar
>library for Typescript (the one for tsx), should be changed to instead
>produce two libraries, right?

Yes, I can fix that when the two modes are in :)

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>,
 Yuan Fu <casouri <at> gmail.com>, 59691 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: Html-like constructs fail in typescript
Date: Wed, 30 Nov 2022 14:16:14 +0100

On 30 November 2022 13:59:20 CET, "Jostein Kjønigsen" <jostein <at> secure.kjonigsen.net> wrote:
>On 29.11.2022 23:20, Jostein Kjønigsen wrote:
>> 
>>> On 29 Nov 2022, at 22:48, Theodor Thornhill<theo <at> thornhill.no>  wrote:
>>> 
>>> 
>>> 
>>>> On 29 November 2022 22:37:25 CET, "Jostein Kjønigsen"<jostein <at> secure.kjonigsen.net>  wrote:
>>>> Nice!
>>>> 
>>>> Should we until further notice assume that js-ts-mode suffers from the same issues, and that a jsx-ts-mode might be needed too? To me it at least sounds plausible.
>>> No, because there are no ambiguities in the grammar with types and jsx.
>>> 
>> Note this behaviour was triggered even when a HTML-tag was contained inside a plain string.
>> 
>> Even without hard typescript casts, there are places where I suspect the same issues can bleed into js-ts-mode.
>> 
>> I’ll try to do more testing tomorrow.
>
>First of all - good news!
>
>Contrary to my expectations, I've tested and I cannot reproduce this issue in js-ts-mode.
>

Yeah, that's what I've seen as well.

>Even more good news:
>
>Looking deeper into this using treesit-explorer-mode (an extremely helpful tool, Yuan!), I found I may have misinterpreted the state of the parse-tree in previous report.
>
>Based on that, I would like to revise this bug report:
>
> * HTML-like constructs inside strings are --/not/-- treated at
>   jsx_opening_elements,

That's correct!

> * only angle-bracket "hard" casts (which isn't present in Javascript)
>   is causing issues for fontification.
>
>Also, reading up, from what I can tell "hard casts" using angle-brackets are no longer encouraged as the default way to cast:
>
>    const service = <IService>object;
>
>This is because the above code will cause a compiler error if used in TSX-files (as opposed to TS-files). Instead "as" expressions are preferred, because they work equally well for both TS & TSX-files:
>
>    const service = object as IService;
>
>That means that writing idiomatic TypeScript with typescrip-ts-mode should produce the expected behaviour, while one may encounter issues with older code.
>
>I'm not sure introducing a new major-mode for this 1 aspect of TypeScript development is worth it?
>
>Does anyone else have an opinion on this?
>
>--
>Jostein

I think that because this is an actual feature it makes sense to have two modes. But defaulting to tsx as the language of choice until now is ok too.

Theo

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: jostein <at> secure.kjonigsen.net, theo <at> thornhill.no, jostein <at> kjonigsen.net,
 59691 <at> debbugs.gnu.org
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements 
 causes fontification to become invalid and remaining parse-tree to become 
 jsx-expression
Date: Wed, 30 Nov 2022 16:09:44 +0200

> From: Yuan Fu <casouri <at> gmail.com>
> Date: Wed, 30 Nov 2022 02:22:06 -0800
> Cc: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>,
>  59691 <at> debbugs.gnu.org,
>  jostein <at> kjonigsen.net,
>  eliz <at> gnu.org
> 
> No strong opinions here, but currently a user could install
> tree-sitter-js, and find and enable js-ts-mode, which is
> straightforward, which is good. Since these four modes doesn’t require
> too much boilerplate, I think it’s pretty good right now.

Can we do that automatically?  For example, can typescript-ts-mode call
js-ts-mode when it detects that it is necessary?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> kjonigsen.net
Subject: Re: Html-like constructs fail in typescript
Date: Wed, 30 Nov 2022 16:25:05 +0200

> Date: Wed, 30 Nov 2022 14:00:49 +0100
> From: Theodor Thornhill <theo <at> thornhill.no>
> CC: 59691 <at> debbugs.gnu.org, jostein <at> kjonigsen.net, casouri <at> gmail.com
> 
> 
> 
> On 30 November 2022 13:35:49 CET, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> From: Theodor Thornhill <theo <at> thornhill.no>
> >> Cc: jostein <at> kjonigsen.net, casouri <at> gmail.com, eliz <at> gnu.org
> >> Date: Tue, 29 Nov 2022 22:01:01 +0100
> >> 
> >> The solution is to create two modes: typescript-ts-mode and
> >> tsx-ts-mode. They have separate parsers, and should be treated as
> >> separate languages.  That means that in a .ts file we enable the
> >> 'typescript' language, and in .tsx we enable the 'tsx' language.  This
> >> exact issue is why they have two languages.
> >
> >This means the script posted by Yuan, which only creates a single grammar
> >library for Typescript (the one for tsx), should be changed to instead
> >produce two libraries, right?
> 
> Yes, I can fix that when the two modes are in :)

Thanks.  But now I hear that the original analysis could be incomplete, and
there actually is no problem, according to Jostein's last messages?

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> kjonigsen.net
Subject: Re: Html-like constructs fail in typescript
Date: Wed, 30 Nov 2022 15:47:56 +0100

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

>> Date: Wed, 30 Nov 2022 14:00:49 +0100
>> From: Theodor Thornhill <theo <at> thornhill.no>
>> CC: 59691 <at> debbugs.gnu.org, jostein <at> kjonigsen.net, casouri <at> gmail.com
>> 
>> 
>> 
>> On 30 November 2022 13:35:49 CET, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> >> From: Theodor Thornhill <theo <at> thornhill.no>
>> >> Cc: jostein <at> kjonigsen.net, casouri <at> gmail.com, eliz <at> gnu.org
>> >> Date: Tue, 29 Nov 2022 22:01:01 +0100
>> >> 
>> >> The solution is to create two modes: typescript-ts-mode and
>> >> tsx-ts-mode. They have separate parsers, and should be treated as
>> >> separate languages.  That means that in a .ts file we enable the
>> >> 'typescript' language, and in .tsx we enable the 'tsx' language.  This
>> >> exact issue is why they have two languages.
>> >
>> >This means the script posted by Yuan, which only creates a single grammar
>> >library for Typescript (the one for tsx), should be changed to instead
>> >produce two libraries, right?
>> 
>> Yes, I can fix that when the two modes are in :)
>
> Thanks.  But now I hear that the original analysis could be incomplete, and
> there actually is no problem, according to Jostein's last messages?

I don't think I agree with him. There are other constructs such as
generics that also can cause these ambiguities, IIRC

Theo

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>, Yuan Fu <casouri <at> gmail.com>
Cc: 59691 <at> debbugs.gnu.org, jostein <at> secure.kjonigsen.net, jostein <at> kjonigsen.net
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements  causes fontification to become invalid and remaining parse-tree to become  jsx-expression
Date: Wed, 30 Nov 2022 16:21:37 +0100

On 30 November 2022 15:09:44 CET, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Wed, 30 Nov 2022 02:22:06 -0800
>> Cc: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>,
>>  59691 <at> debbugs.gnu.org,
>>  jostein <at> kjonigsen.net,
>>  eliz <at> gnu.org
>> 
>> No strong opinions here, but currently a user could install
>> tree-sitter-js, and find and enable js-ts-mode, which is
>> straightforward, which is good. Since these four modes doesn’t require
>> too much boilerplate, I think it’s pretty good right now.
>
>Can we do that automatically?  For example, can typescript-ts-mode call
>js-ts-mode when it detects that it is necessary?

That's not what we want. 

There are three languages here from treesitters pov.

Typescript
Tsx
JavaScript

They are all different, and should be treated as such, imo :)

Theo

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> secure.kjonigsen.net,
 jostein <at> kjonigsen.net
Subject: Re: bug#59691: 29.0.60;
 typescript-ts-mode: any HTML-like elements causes fontification to
 become invalid and remaining parse-tree to become jsx-expression
Date: Wed, 30 Nov 2022 18:05:59 +0200

> Date: Wed, 30 Nov 2022 16:21:37 +0100
> From: Theodor Thornhill <theo <at> thornhill.no>
> CC: jostein <at> secure.kjonigsen.net, 59691 <at> debbugs.gnu.org, jostein <at> kjonigsen.net
> 
> >> No strong opinions here, but currently a user could install
> >> tree-sitter-js, and find and enable js-ts-mode, which is
> >> straightforward, which is good. Since these four modes doesn’t require
> >> too much boilerplate, I think it’s pretty good right now.
> >
> >Can we do that automatically?  For example, can typescript-ts-mode call
> >js-ts-mode when it detects that it is necessary?
> 
> That's not what we want. 
> 
> There are three languages here from treesitters pov.
> 
> Typescript
> Tsx
> JavaScript
> 
> They are all different, and should be treated as such, imo :)

Our automatic turning-on of major-modes looks at the file-name extension and
little else (magic-mode-alist is not useful here).  So if a file whose
extension is XYZ can have more than one applicable major-mode, we should try
to do something to turn on the correct mode automatically.  What can we do?

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> secure.kjonigsen.net,
 jostein <at> kjonigsen.net
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements  causes fontification to become invalid and remaining parse-tree to become  jsx-expression
Date: Wed, 30 Nov 2022 19:10:04 +0100

On 30 November 2022 17:05:59 CET, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Wed, 30 Nov 2022 16:21:37 +0100
>> From: Theodor Thornhill <theo <at> thornhill.no>
>> CC: jostein <at> secure.kjonigsen.net, 59691 <at> debbugs.gnu.org, jostein <at> kjonigsen.net
>> 
>> >> No strong opinions here, but currently a user could install
>> >> tree-sitter-js, and find and enable js-ts-mode, which is
>> >> straightforward, which is good. Since these four modes doesn’t require
>> >> too much boilerplate, I think it’s pretty good right now.
>> >
>> >Can we do that automatically?  For example, can typescript-ts-mode call
>> >js-ts-mode when it detects that it is necessary?
>> 
>> That's not what we want. 
>> 
>> There are three languages here from treesitters pov.
>> 
>> Typescript
>> Tsx
>> JavaScript
>> 
>> They are all different, and should be treated as such, imo :)
>
>Our automatic turning-on of major-modes looks at the file-name extension and
>little else (magic-mode-alist is not useful here).  So if a file whose
>extension is XYZ can have more than one applicable major-mode, we should try
>to do something to turn on the correct mode automatically.  What can we do?

We are lucky because the extensions in question are ts, tsx and js. So we don't need any smartness :)

Theo

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> secure.kjonigsen.net,
 jostein <at> kjonigsen.net
Subject: Re: bug#59691: 29.0.60;
 typescript-ts-mode: any HTML-like elements causes fontification to
 become invalid and remaining parse-tree to become jsx-expression
Date: Wed, 30 Nov 2022 20:19:04 +0200

> Date: Wed, 30 Nov 2022 19:10:04 +0100
> From: Theodor Thornhill <theo <at> thornhill.no>
> CC: casouri <at> gmail.com, jostein <at> secure.kjonigsen.net, 59691 <at> debbugs.gnu.org,
>  jostein <at> kjonigsen.net
> 
> >Our automatic turning-on of major-modes looks at the file-name extension and
> >little else (magic-mode-alist is not useful here).  So if a file whose
> >extension is XYZ can have more than one applicable major-mode, we should try
> >to do something to turn on the correct mode automatically.  What can we do?
> 
> We are lucky because the extensions in question are ts, tsx and js. So we don't need any smartness :)

And the extensions always say unequivocally what mode to use?  Then yes, we
are lucky, and need just one more major mode (and one more grammar library).

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> secure.kjonigsen.net,
 jostein <at> kjonigsen.net
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements  causes fontification to become invalid and remaining parse-tree to become  jsx-expression
Date: Wed, 30 Nov 2022 19:20:31 +0100

On 30 November 2022 19:19:04 CET, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Wed, 30 Nov 2022 19:10:04 +0100
>> From: Theodor Thornhill <theo <at> thornhill.no>
>> CC: casouri <at> gmail.com, jostein <at> secure.kjonigsen.net, 59691 <at> debbugs.gnu.org,
>>  jostein <at> kjonigsen.net
>> 
>> >Our automatic turning-on of major-modes looks at the file-name extension and
>> >little else (magic-mode-alist is not useful here).  So if a file whose
>> >extension is XYZ can have more than one applicable major-mode, we should try
>> >to do something to turn on the correct mode automatically.  What can we do?
>> 
>> We are lucky because the extensions in question are ts, tsx and js. So we don't need any smartness :)
>
>And the extensions always say unequivocally what mode to use?  Then yes, we
>are lucky, and need just one more major mode (and one more grammar library).

That's right!

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> secure.kjonigsen.net,
 jostein <at> kjonigsen.net
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements  causes fontification to become invalid and remaining parse-tree to become  jsx-expression
Date: Wed, 30 Nov 2022 19:21:58 +0100

On 30 November 2022 19:19:04 CET, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Wed, 30 Nov 2022 19:10:04 +0100
>> From: Theodor Thornhill <theo <at> thornhill.no>
>> CC: casouri <at> gmail.com, jostein <at> secure.kjonigsen.net, 59691 <at> debbugs.gnu.org,
>>  jostein <at> kjonigsen.net
>> 
>> >Our automatic turning-on of major-modes looks at the file-name extension and
>> >little else (magic-mode-alist is not useful here).  So if a file whose
>> >extension is XYZ can have more than one applicable major-mode, we should try
>> >to do something to turn on the correct mode automatically.  What can we do?
>> 
>> We are lucky because the extensions in question are ts, tsx and js. So we don't need any smartness :)
>
>And the extensions always say unequivocally what mode to use?  Then yes, we
>are lucky, and need just one more major mode (and one more grammar library).

I have already made that commit, but it is waiting on the  indent style patch :)

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> secure.kjonigsen.net,
 jostein <at> kjonigsen.net
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements
 causes fontification to become invalid and remaining parse-tree to become
 jsx-expression
Date: Thu, 01 Dec 2022 07:01:55 +0100

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

Theodor Thornhill <theo <at> thornhill.no> writes:

> On 30 November 2022 19:19:04 CET, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>> Date: Wed, 30 Nov 2022 19:10:04 +0100
>>> From: Theodor Thornhill <theo <at> thornhill.no>
>>> CC: casouri <at> gmail.com, jostein <at> secure.kjonigsen.net, 59691 <at> debbugs.gnu.org,
>>>  jostein <at> kjonigsen.net
>>> 
>>> >Our automatic turning-on of major-modes looks at the file-name extension and
>>> >little else (magic-mode-alist is not useful here).  So if a file whose
>>> >extension is XYZ can have more than one applicable major-mode, we should try
>>> >to do something to turn on the correct mode automatically.  What can we do?
>>> 
>>> We are lucky because the extensions in question are ts, tsx and js. So we don't need any smartness :)
>>
>>And the extensions always say unequivocally what mode to use?  Then yes, we
>>are lucky, and need just one more major mode (and one more grammar library).
>
> I have already made that commit, but it is waiting on the  indent style patch :)

Ok, because it seems we didn't want the indent style patch let's fix
this bug instead :)

Attached is the new major mode.

What do you think?

Theo

[0001-Add-new-TypeScript-mode-tsx-ts-mode.patch (text/x-diff, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> secure.kjonigsen.net,
 jostein <at> kjonigsen.net
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements
 causes fontification to become invalid and remaining parse-tree to become
 jsx-expression
Date: Thu, 01 Dec 2022 09:44:49 +0200

> From: Theodor Thornhill <theo <at> thornhill.no>
> Cc: casouri <at> gmail.com, jostein <at> secure.kjonigsen.net, 59691 <at> debbugs.gnu.org,
>  jostein <at> kjonigsen.net
> Date: Thu, 01 Dec 2022 07:01:55 +0100
> 
> diff --git a/etc/NEWS b/etc/NEWS
> index 4e091a5fed..439d20960b 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -2972,7 +2972,12 @@ A major mode based on the tree-sitter library for editing programs
>  in the TypeScript language.  It includes support for font-locking,
>  indentation, and navigation.
>  
> -** New major mode 'c-ts-mode'.
> +** New mode 'tsx-ts-mode'.
> +A major mode based on the tree-sitter library for editing programs
> +in the TypeScript language, with support for TSX.  It includes
> +support for font-locking, indentation, and navigation.
> +
> +** New mode 'c-ts-mode'.

Looks like some "git merge" snafu?  You are in fact reverting a change I
made in NEWS yesterday.

> diff --git a/lisp/progmodes/typescript-ts-mode.el b/lisp/progmodes/typescript-ts-mode.el
> index 6c926a4e3e..c1beaf3134 100644
> --- a/lisp/progmodes/typescript-ts-mode.el
> +++ b/lisp/progmodes/typescript-ts-mode.el

I don't see a change to auto-mode-alist to turn on each mode for the files
it supports?  I thought this was the idea?  Or is this because we don't want
tree-sitter based modes to be turned on by default?  In that case, how do we
explain to users that they should use each mode in the relevant cases?

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> secure.kjonigsen.net,
 jostein <at> kjonigsen.net
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements
 causes fontification to become invalid and remaining parse-tree to become
 jsx-expression
Date: Thu, 01 Dec 2022 09:12:58 +0100

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

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

>> From: Theodor Thornhill <theo <at> thornhill.no>
>> Cc: casouri <at> gmail.com, jostein <at> secure.kjonigsen.net, 59691 <at> debbugs.gnu.org,
>>  jostein <at> kjonigsen.net
>> Date: Thu, 01 Dec 2022 07:01:55 +0100
>> 
>> diff --git a/etc/NEWS b/etc/NEWS
>> index 4e091a5fed..439d20960b 100644
>> --- a/etc/NEWS
>> +++ b/etc/NEWS
>> @@ -2972,7 +2972,12 @@ A major mode based on the tree-sitter library for editing programs
>>  in the TypeScript language.  It includes support for font-locking,
>>  indentation, and navigation.
>>  
>> -** New major mode 'c-ts-mode'.
>> +** New mode 'tsx-ts-mode'.
>> +A major mode based on the tree-sitter library for editing programs
>> +in the TypeScript language, with support for TSX.  It includes
>> +support for font-locking, indentation, and navigation.
>> +
>> +** New mode 'c-ts-mode'.
>
> Looks like some "git merge" snafu?  You are in fact reverting a change I
> made in NEWS yesterday.
>

You're right - I think I fixed it now.

>> diff --git a/lisp/progmodes/typescript-ts-mode.el b/lisp/progmodes/typescript-ts-mode.el
>> index 6c926a4e3e..c1beaf3134 100644
>> --- a/lisp/progmodes/typescript-ts-mode.el
>> +++ b/lisp/progmodes/typescript-ts-mode.el
>
> I don't see a change to auto-mode-alist to turn on each mode for the files
> it supports?  I thought this was the idea?  Or is this because we don't want
> tree-sitter based modes to be turned on by default?  In that case, how do we
> explain to users that they should use each mode in the relevant cases?

I think there should be


;;;###autoload
(add-to-list 'auto-mode-alist '("\\.ts\\'" . typescript-ts-mode))

;;;###autoload
(add-to-list 'auto-mode-alist '("\\.tsx\\'" . tsx-ts-mode))

No?  If not, then I'm confused.

Theo

[0001-Add-new-TypeScript-mode-tsx-ts-mode.patch (text/x-diff, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> secure.kjonigsen.net,
 jostein <at> kjonigsen.net
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements
 causes fontification to become invalid and remaining parse-tree to become
 jsx-expression
Date: Thu, 01 Dec 2022 12:05:01 +0200

> From: Theodor Thornhill <theo <at> thornhill.no>
> Cc: casouri <at> gmail.com, jostein <at> secure.kjonigsen.net, 59691 <at> debbugs.gnu.org,
>  jostein <at> kjonigsen.net
> Date: Thu, 01 Dec 2022 09:12:58 +0100
> 
> > Looks like some "git merge" snafu?  You are in fact reverting a change I
> > made in NEWS yesterday.
> >
> 
> You're right - I think I fixed it now.

Yes, thanks.

> > I don't see a change to auto-mode-alist to turn on each mode for the files
> > it supports?  I thought this was the idea?  Or is this because we don't want
> > tree-sitter based modes to be turned on by default?  In that case, how do we
> > explain to users that they should use each mode in the relevant cases?
> 
> I think there should be
> 
> 
> ;;;###autoload
> (add-to-list 'auto-mode-alist '("\\.ts\\'" . typescript-ts-mode))
> 
> ;;;###autoload
> (add-to-list 'auto-mode-alist '("\\.tsx\\'" . tsx-ts-mode))

Yes, I missed that, sorry.  But the NEWS entry should clearly say that one
mode is the default for *.ts files, the other for *.tsx files.

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> secure.kjonigsen.net,
 jostein <at> kjonigsen.net
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements
 causes fontification to become invalid and remaining parse-tree to become
 jsx-expression
Date: Thu, 01 Dec 2022 11:52:00 +0100

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

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

>> From: Theodor Thornhill <theo <at> thornhill.no>
>> Cc: casouri <at> gmail.com, jostein <at> secure.kjonigsen.net, 59691 <at> debbugs.gnu.org,
>>  jostein <at> kjonigsen.net
>> Date: Thu, 01 Dec 2022 09:12:58 +0100
>> 
>> > Looks like some "git merge" snafu?  You are in fact reverting a change I
>> > made in NEWS yesterday.
>> >
>> 
>> You're right - I think I fixed it now.
>
> Yes, thanks.
>
>> > I don't see a change to auto-mode-alist to turn on each mode for the files
>> > it supports?  I thought this was the idea?  Or is this because we don't want
>> > tree-sitter based modes to be turned on by default?  In that case, how do we
>> > explain to users that they should use each mode in the relevant cases?
>> 
>> I think there should be
>> 
>> 
>> ;;;###autoload
>> (add-to-list 'auto-mode-alist '("\\.ts\\'" . typescript-ts-mode))
>> 
>> ;;;###autoload
>> (add-to-list 'auto-mode-alist '("\\.tsx\\'" . tsx-ts-mode))
>
> Yes, I missed that, sorry.  But the NEWS entry should clearly say that one
> mode is the default for *.ts files, the other for *.tsx files.

No worries :)

Is this patch suitable?

Theo

[0001-Add-new-TypeScript-mode-tsx-ts-mode.patch (text/x-diff, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59691 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> secure.kjonigsen.net,
 jostein <at> kjonigsen.net
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements
 causes fontification to become invalid and remaining parse-tree to become
 jsx-expression
Date: Thu, 01 Dec 2022 14:10:23 +0200

> From: Theodor Thornhill <theo <at> thornhill.no>
> Cc: casouri <at> gmail.com, jostein <at> secure.kjonigsen.net, 59691 <at> debbugs.gnu.org,
>  jostein <at> kjonigsen.net
> Date: Thu, 01 Dec 2022 11:52:00 +0100
> 
> > Yes, I missed that, sorry.  But the NEWS entry should clearly say that one
> > mode is the default for *.ts files, the other for *.tsx files.
> 
> No worries :)
> 
> Is this patch suitable?

LGTM, thanks.

Yuan, if you are okay with this, please install.

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

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>,
 Theodor Thornhill <theo <at> thornhill.no>, jostein <at> kjonigsen.net,
 59691 <at> debbugs.gnu.org
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements
 causes fontification to become invalid and remaining parse-tree to become
 jsx-expression
Date: Thu, 1 Dec 2022 20:44:59 -0800

> On Dec 1, 2022, at 4:10 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Theodor Thornhill <theo <at> thornhill.no>
>> Cc: casouri <at> gmail.com, jostein <at> secure.kjonigsen.net, 59691 <at> debbugs.gnu.org,
>> jostein <at> kjonigsen.net
>> Date: Thu, 01 Dec 2022 11:52:00 +0100
>> 
>>> Yes, I missed that, sorry.  But the NEWS entry should clearly say that one
>>> mode is the default for *.ts files, the other for *.tsx files.
>> 
>> No worries :)
>> 
>> Is this patch suitable?
> 
> LGTM, thanks.
> 
> Yuan, if you are okay with this, please install.

Cool. I applied the patch, thanks Theo! I changed typescript-ts-mode—base-mode to typescript-ts-base-mode, since I don’t think anyone has strong opinions about its naming, and typescript-ts-base-mode is more consistent with other tree-sitter base modes.

Yuan

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Yuan Fu <casouri <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 59691 <at> debbugs.gnu.org,
 Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>,
 jostein <at> kjonigsen.net
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements
 causes fontification to become invalid and remaining parse-tree to become
 jsx-expression
Date: Fri, 02 Dec 2022 21:29:28 +0100

Yuan Fu <casouri <at> gmail.com> writes:

>> On Dec 1, 2022, at 4:10 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> 
>>> From: Theodor Thornhill <theo <at> thornhill.no>
>>> Cc: casouri <at> gmail.com, jostein <at> secure.kjonigsen.net, 59691 <at> debbugs.gnu.org,
>>> jostein <at> kjonigsen.net
>>> Date: Thu, 01 Dec 2022 11:52:00 +0100
>>> 
>>>> Yes, I missed that, sorry.  But the NEWS entry should clearly say that one
>>>> mode is the default for *.ts files, the other for *.tsx files.
>>> 
>>> No worries :)
>>> 
>>> Is this patch suitable?
>> 
>> LGTM, thanks.
>> 
>> Yuan, if you are okay with this, please install.
>
> Cool. I applied the patch, thanks Theo! I changed typescript-ts-mode—base-mode to typescript-ts-base-mode, since I don’t think anyone has strong opinions about its naming, and typescript-ts-base-mode is more consistent with other tree-sitter base modes.
>
> Yuan

Thanks!  I believe this can be closed.  What do you think, Jostein?

Theo

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Theodor Thornhill <theo <at> thornhill.no>, Yuan Fu <casouri <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 59691 <at> debbugs.gnu.org, jostein <at> kjonigsen.net
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements
 causes fontification to become invalid and remaining parse-tree to become
 jsx-expression
Date: Fri, 2 Dec 2022 22:28:36 +0100

>> Cool. I applied the patch, thanks Theo! I changed 
>> typescript-ts-mode—base-mode to typescript-ts-base-mode, since I 
>> don’t think anyone has strong opinions about its naming, and 
>> typescript-ts-base-mode is more consistent with other tree-sitter 
>> base modes.
>> Yuan
> Thanks!  I believe this can be closed.  What do you think, Jostein?
>
> Theo

Hey guys.

Amazing work! Sorry for being somewhat slow wrt to testing.

I had to rebuild some tree-sitter libraries, and the build-code in 
admin/notes/tree-sitter/ seemingly didn't work out of the box for both 
plain typescript and tsx. Yadda, yadda, yadda. I've modified the scripts 
to also build for typescript/tsx. Do you wan't me to send in a patch for 
that, Yuan?

Back to the point: Either way, I've tested both TS-code and TSX-code 
now, and it seems to work much better.

I still see some errors in TSX-code I can't recall seing in the old mode 
(and I might report those issues, once I have time to collect more 
accurate data on them), but for now I definitely think what we have here 
warrants marking this particular bug as closed. :)

--
Jostein

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: jostein <at> kjonigsen.net,
 Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>,
 Yuan Fu <casouri <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 59691 <at> debbugs.gnu.org
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements causes fontification to become invalid and remaining parse-tree to become jsx-expression
Date: Fri, 02 Dec 2022 23:54:40 +0100

On 2 December 2022 22:28:36 CET, "Jostein Kjønigsen" <jostein <at> secure.kjonigsen.net> wrote:
>
>>> Cool. I applied the patch, thanks Theo! I changed typescript-ts-mode—base-mode to typescript-ts-base-mode, since I don’t think anyone has strong opinions about its naming, and typescript-ts-base-mode is more consistent with other tree-sitter base modes.
>>> Yuan
>> Thanks!  I believe this can be closed.  What do you think, Jostein?
>> 
>> Theo
>
>Hey guys.
>
>Amazing work! Sorry for being somewhat slow wrt to testing.
>
>I had to rebuild some tree-sitter libraries, and the build-code in admin/notes/tree-sitter/ seemingly didn't work out of the box for both plain typescript and tsx. Yadda, yadda, yadda. I've modified the scripts to also build for typescript/tsx. Do you wan't me to send in a patch for that, Yuan?
>

I've already sent a patch for that :)


>Back to the point: Either way, I've tested both TS-code and TSX-code now, and it seems to work much better.
>

Yay!

>I still see some errors in TSX-code I can't recall seing in the old mode (and I might report those issues, once I have time to collect more accurate data on them), but for now I definitely think what we have here warrants marking this particular bug as closed. :)

Great news! We'll get to the other stuff in due time :)

Theo

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: jostein <at> kjonigsen.net
Cc: casouri <at> gmail.com, 59691-done <at> debbugs.gnu.org, theo <at> thornhill.no
Subject: Re: bug#59691: 29.0.60; typescript-ts-mode: any HTML-like elements
 causes fontification to become invalid and remaining parse-tree to become
 jsx-expression
Date: Sat, 03 Dec 2022 08:38:21 +0200

> Date: Fri, 2 Dec 2022 22:28:36 +0100
> Cc: 59691 <at> debbugs.gnu.org, jostein <at> kjonigsen.net
> From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
> 
> I still see some errors in TSX-code I can't recall seing in the old mode 
> (and I might report those issues, once I have time to collect more 
> accurate data on them), but for now I definitely think what we have here 
> warrants marking this particular bug as closed. :)

Closing.

Btw, you can always close yourself, by sending to the NNN-done address, as I
did here.

Previous Next

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