function return type breaks `beginning-of-defun` and `end-of-defun` about typescript.el HOT 9 CLOSED

In csharp-mode we are experimenting on a complete rewrite based on tree-sitter-mode, which gives us a real AST to work with.

The results there have been very promising.

If we were to fix all those small issues we have here, without creating some insane complexity in the lisp-code, I believe we may have to consider doing the same.

from typescript.el.

Yeah, I noticed that they are broken a while back. I thought I might need to fix them in order to fix an indentation issue but it turned out that I did not need them. I've not spent time fixing them because their brokenness does not have an actual impact on my work.

Using git blame it looks like nobody spent any time on them. They are probably exactly like their counterpart in js-mode and so have no TypeScript-specific knowledge.

I suspect they are going to get fixed when they become a real obstacle to someone's work. When that happens, whoever fixes them may want to think about biting the bullet to get the mode to use an AST. The fact of the matter is that TS allows for really complex code structures that would probably throw off the kind of logic that just looks around (point) to figure what is going on. I mean, stuff like this is legit, except for the return undefined (I did not feel like writing a proper return value):

class Q<X> {
}

function glerb(a: any = new class extends Object {
    private x = 1;

    moo(): void {
    }
}): Q<{
    a: 1,   
    b: () => void,  
}> {
    return undefined;
}

And I'm just scratching the surface of what TS allows.

from typescript.el.

Makes sense. Thanks for the details.

from typescript.el.

I encountered same issue. Is there anybody who is working on fixing this issue?

from typescript.el.

I have similar problems, using the beginning-of-defun and end-of-defun implicitly with narrow-to-defun.
Another place where beginning/end of defun completely fails is lambda functions () => "I'm a a result" or named lambda functions const getTheAnswer = () => 42.
I don't know enough emacs lisp to be of any help, though...

from typescript.el.

@josteink from what I understand tree-sitter only supports highlighting? does it support other functions like mark-sexp, end-of-defun etc? which is more related to movement. I actually want to use tree-sitter for movement functionality, but can't find any reference or how to use it.

from typescript.el.

@josteink from what I understand tree-sitter only supports highlighting? does it support other functions like mark-sexp, end-of-defun etc? which is more related to movement. I actually want to use tree-sitter for movement functionality, but can't find any reference or how to use it.

Tree-sitter supports navigation based on AST knowledge.

Based on this it is fairly trivial to create move-to-beginning-of-defun functions.

See this issue in csharp-mode for an example: emacs-csharp/csharp-mode#219

The discovery there though was that pretty much all of those functions can be generalised for all tree-sitter based major-modes so we decided we should try to get such functions upstreamed rather than implement it in a major-mode specific way.

from typescript.el.

sweet, tree-sitter-node-at-point this is what I am looking for.

from typescript.el.

So... We're rewriting typescript-mode to be tree-sitter-mode based too now? 😁

If so, I would suggest taking a look at csharp-tree-sitter-mode as a whole, and start from scratch based on something like that (sans grammar-portion), instead of incrementally trying to rewrite what we have.

Edit: it seems like tree-sitter-langs-package already contains typescript-grammar.

So ... What's left for us to do then? 😄

from typescript.el.