emacs-typescript / typescript.el Goto Github PK

Description

Currently, in https://github.com/ananthakumaran/typescript.el/blob/c2d72b7d816a0ede209c507b1800f98b9d53559b/typescript-mode.el#L417-L531
there are some missing tags, e.g., @abstract, @async, @external, and @todo, ...
You can see those tags in http://usejsdoc.org/.
Could you complete tags in http://usejsdoc.org/? If it's hard, could you change those lists into custom variable so that user can change them easily?

The mode initialization code contains this hack:

  (let (font-lock-keywords)         ; leaves syntactic keywords intact
    ;; Avoid byte-compilation errors.  `font-lock-fontify-buffer' is
    ;; marked as interactive only in Emacs 25.
    (with-no-warnings
      (font-lock-fontify-buffer)))

The code above prevents users from having a typescript-mode-hook that immediately turns on flyspell-prog-mode and performs flyspell-buffer so that all spelling errors are immediately marked when typescript-mode starts. The problem with the code above is that it performs a fontification that only takes into account the syntactic classes of the text without applying the rules in font-lock-keywords. I've setup my flyspell predicate so that it requires the buffer to have been fontified at least up to the point it needs to examine. However, the first fontification triggered above does not contain the result of applying the rules in font-lock-keywords, which do matter for the predicate to work properly. So the initial flyspell-buffer run is running with incomplete fontification information, and ends up spell checking words that should not be spell-checked.

I worked around the problem by refontifying the buffer before starting flyspell-prog-mode and flyspell-buffer.

(Note: it would be possible to setup a predicate for flyspell that does not depend on fontification information. However, the predicate would get complicated fast. I'd rather avoid this if at all possible.)

I took a glance at js-mode and it looks like it used to perform an immediate fontification but that this immediate fontification was removed:

  ;; Important to fontify the whole buffer syntactically! If we don't,
  ;; then we might have regular expression literals that aren't marked
  ;; as strings, which will screw up parse-partial-sexp, scan-lists,
  ;; etc. and produce maddening "unbalanced parenthesis" errors.
  ;; When we attempt to find the error and scroll to the portion of
  ;; the buffer containing the problem, JIT-lock will apply the
  ;; correct syntax to the regular expression literal and the problem
  ;; will mysteriously disappear.
  ;; FIXME: We should instead do this fontification lazily by adding
  ;; calls to syntax-propertize wherever it's really needed.
  ;;(syntax-propertize (point-max))

So do we need that hack? I can run the test suite just fine without it (but that may not be saying much), and cannot point to a reason for the existence of the hack. I've removed it from my local copy of typescript-mode but I cannot tell whether removing it is actually causing issues because I do a full buffer fontification in my mode hook anyway to run the spell-checker.

If a function declaration is broken on multiple lines AND has a returned type AND the opening brace is not on a line by itself, then there is a very wide indentation on the following lines.

function foo(firstParam: string,
             secondParam: number,
             thirdParam: boolean): boolean {
               console.log('look where this is indented');
               console.log('it is very strange');
             }

Expected:

function foo(firstParam: string,
             secondParam: number,
             thirdParam: boolean): boolean {
  console.log('look where this is indented');
  console.log('it is very strange');
}

Under certain indentation scenarios such as within a class method, inserting a key bound to (typescript-insert-and-indent KEY) seems to move the cursor back 7 characters.

This problem does not appear in 0.2 available in melpa-stable

My steps to reproduce:
Prerequisites: emacs 25.1.1 from Fedora 25 repos (GNU Emacs 25.1.1 (x86_64-redhat-linux-gnu) of 2016-12-15)

1. Create empty .emacs.d/init.el containing

(require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))

2. M-x package-refresh-contents M-x package-install typescript-mode (should install version 20170526.239 as of right now)
3. Open new ts file containing a class with instance methods
4. Attempt to type something such as "const a = new Promise(" within an instance method
5. Observe that cursor has moved ~7 characters backwards

Quick gif of me reproducing steps 3 through 5:

My workaround for now is to just use typescript-mode from melpa-stable (0.2) which behaves as expected:

The problem seems to be in Cask (cask/cask#420) or in code that Cask depends on (melpa/package-build#17).

The upshot for us is that as long as the issue is not resolved, our Travis builds are going to end with an error.

Here's an example of what it looks like.

I see types in type aliasing (before =) being highlighted (font-lock-type-face), but not in other places when they are used (default). Would like to see types being highlighted wherever they are.

Now that prettier/prettier#13 supports typescript, would it make sense to offload formatting to that? It seems to be gaining traction as a defacto standard.

In example below, set and get keyword should be highlight.

class Employee {
    private _fullName: string;

    get fullName(): string {
//  ^^^ highlight here
        return this._fullName;
    }

    set fullName(newName: string) {
//  ^^^ and here
        if (passcode && passcode == "secret passcode") {
            this._fullName = newName;
        }
        else {
            console.log("Error: Unauthorized update of employee!");
        }
    }
}

I was trying to use helm-imenu-in-all-buffers which is a helm command which combines the imenu output of all buffers with the same mode, but part of the filtering process is to ensure that the buffer derives from prog-mode, so the resulting list is empty because typescript-mode is not considered to derive from prog-mode.

I noticed that this mode has an interesting way of defining the parent mode by aliasing either prog-mode or fundamental-mode to typescript-parent-mode:

https://github.com/ananthakumaran/typescript.el/blob/7a5c74d88e3c5513cc4431a837003736f905a75e/typescript-mode.el#L2588-L2593

I would have hoped that this would still mean that (derived-mode-p 'prog-mode) would be true, but it doesn't. Instead, (derived-mode-p 'typescript-parent-mode) yields true, although that's of little use.

Is there any chance we can explicitly set it to prog-mode, even if by a user-defined opt-in option? I think it would be desirable because for better or worse, a lot of packages and configuration seem to check that a buffer's mode is prog-mode derived, which can lead to functionality breaking in subtle ways.

Reference: emacs-helm/helm#2052

function f1(x) {
    return (
        x.then()
    )
}

function f2(x) {
    return (
        x.catch()
            )

(Sorry for all the issues! :-p)

I tried to use editorconfig-mode and typescript-el together and noticed that editorconfig indentation settings are not used in typescript mode. It would be nice to have these two working out of the box if possible.

This causes errors with both font-lock and indentation.

This can be demonstated in the indentation reference document where the following lines will be syntax-highlighted (and have syntax-properties) as if they were not commented:

        //     case "linux":
        //     case "android": {

I can reproduce this on Emacs 25.3 (Fedora) and Emacs git master.

When trying to pinpoint where it goes wrong using font-lock-studio it seems none of the expressions picked up by font-lock-studio contributes to this error-condition, but instead it is immediately reproduced after exiting it (but then only the line with "linux" in it).

Could this be related to something we explicitly override in our mode outside the regular font-lock and syntax constructs, like syntax-begin-function?

Edit: Can also reproduce on Emacs 25.1 on Windows.

typescript.el indents like this:

var x = 5,
y = 6;

I posit that it should indent like this:

var x = 5,
    y = 6;

const forwardSlashSourcePath = sourcePath.replace(/\\/g, '/');

To replicate this paste the above in an Emacs buffer with Typescript enabled. All the tokens after the /\\/ have the font face string.

We've figured it out for tide.

Maybe just adopt the same rules as tide? Or is there some other consideration I'm forgetting?

I plan to add Emacs 26.1 to the list of Emacs versions tested but I noticed 24.3 is still in the list and maybe should be removed.

// Good
foo.noteach()
bar()

// Bad
foo.each()
    bar()

I might look into it and submit a PR if I feel motivated! :-)

type Whatever<T> = T

type a = number
type b = number // this is fine

type c = Whatever<number>
    type d = number // huh!

The last line should not be indented.

Arrow functions should probably be indented like normal functions, though right now there is a difference:

    // OK
    function foofunc(param: string): void 
    {
        console.log('indented as expected');
    }

    // Double identation?
    const foo = (param: string): void =>
        {
            console.log('unexpected double indent');
        }

For me, expected output would be

    const foo = (param: string): void =>
    {
        console.log('Expect single indent');
    }

If the function name the same as the keyword, the function also get highlighted.

Screenshot

As of Emacs 25.1 the syntax-begin-function variable is obsolete. I am not sure what the replacement is.

Here is the compiler warning received:

typescript-mode.el:2052:10:Warning:
    `syntax-begin-function' is an obsolete variable (as of 25.1).

Consider the following code:

interface AB extends A, B {
}

In this example typescript-mode will only highlight "AB" and "A" using fontlock-type-face.

B is highlighted using default.

Thought I'd do an issue first before a PR, incase this isn't wanted.

undefined is both a value and a type. Currently the highlighting for the type will follow the colouring for the value (there is no special handling for undefined in a type position).

Should the type have a different colouring?

MELPA Stable finds tags in repos (such as 0.5.74) and uses those to create stable releases. For those of us who prefer to depend on stable code, this is a godsend. Please create a git tag for code you consider stable, thanks :)

As far as I know, TypeScript tends to be documented like this:

/**
 * Run the provided promise, and call process.exit with an appropriate code.
 */
export function runPromise<T>(promise: Promise<T>): void {

In js2-mode, I can type:

/**

and press C-M-j, to get:

/**
 * 
 */

with point at the end of the second line. This would be a nice feature to have in typescript.el, as well.

Maybe I am doing something wrong, but it seems that there are quite a few elements still unthemed:

keywords, declarations of both functions and variables, definitions of types/interfaces all works pretty well. But the actual usage of previously declared objects / function calls,seems to result in default faces.

Another one:

new Date(.. looks great, but SimulatedTransaction is a type too. Shouldn't it receive the same highlighting? That is to say: font-lock-type-face

I'm relatively new to Emacs (1.5 months), but more then willing to put in work to help achieve this (, or to receive scorn for assuming this is easily accomplished).

There is chance that negated types will be added to TypeScript, requiring a new keyword. I have a PR here #98 waiting, but this would be a good first issue.

If anyone would like to grab a contributor badge please feel free to submit a PR (assuming the feature does get added).

yield and yield* are not highlighted as keywords. It's an easy workaround (below), but should probably be in this package

(font-lock-add-keywords 'typescript-mode
                        '(("\\<\\(yield\\(\\*\\|\\>\\)\\)" . 'font-lock-keyword-face)))

There is no support for syntax highlighting of the arrow function formal parameters, beginning-of-defun etc.

Hi, in js2-mode I see defface variables

(defface js2-function-call
  '((t :inherit default))
  "Face used to highlight function name in calls."
  :group 'js2-mode)

and in my themes file I added
(js2-function-call (:foreground ,green))
to make the function call green.

Is there any similar way to add my theme specific colors for typescript. Thanks.

Hi,

i tried with http://typedoc.org/guides/doccomments/

whenever i type "/**" and then hit enter, emacs freezes and becomes unusable.
I've got to kill/restart it.

i can actually make that comment, but i must not push enter on that code-line.

Any hints?

Example: the oops method gets double-indented.

class Foo { 
    bar() { 
    }
        * oops() { 
        }
}

TypeScript added support for JSX:
microsoft/TypeScript#3203

Briefly, this adds support for HTML-like literals in code:

var foo = <div style="foo">blah</div>;

typescript-mode currently doesn't indent such literals properly, in contexts like this:

var foo = <div style="foo"
  attr2="bar">      <- should indent matching "style"
  <div>
    <div>              <- should indent due to opening tag above
      ...

Currently I use web-mode (which understands JSX) for typescript files, but that doesn't work with tide (which wants to work with typescript-mode, not web-mode).

[Opening an issue for a problem discovered while discussing #20 .]

Template strings allow expressions in string and strings to nest. For instance:

`a${1+2}b`

equals "a3b". And since expressions can be strings, then this is valid:

`a${`b`}c`

and equals "abc"

Problematic areas:

1. The highlighter fails to handle anything in ${} as an expression. (Trying the same in plain JS code: js-mode is just as broken as typescript-mode. js2-mode, however, handles it fine.)

2. typescript--re-search-backward-inner completely ignores expressions in strings or the fact that strings can nest. Same for typescript--re-search-forward-inner. These are used for movement across syntactic features and for indentation.

3. syntax-ppss, which is also used for movement across syntactic features and for indentation, ignores string nesting. js2-mode appears to have solved the issue though because I get meaningful results from checking the values of syntax-ppss in nested strings in a JS file with js2-mode.

There may be yet other problematic areas I've not identified.

The mode currently operates so that

const x = `abc
    def`;

Will be indented to:

const x = `abc
def`;

However, tide-format leaves it as in the first snippet.

It is possible to do this as a workaround:

const x = `abc
\    def`;

The escaped space is treated as a space, and typescript-mode won't try to remove the spaces, but yuck!

I'm thinking of modifying the indentation code so that typescript-mode leaves the leading space in lines of multiline strings like the one above intact. I'm wondering though whether this should be configurable. If I just "fix" it, that's going to change the previous behavior that some people may rely on. (That behavior appears flat out bad to me, so I don't know why anyone would rely on that behavior, but maybe I'm missing something.)

Maybe prog-indent-sexp should ignore the content of template strings ?

Typescript 1.3 adds "protected" as a keyword.

Between TS 2.6 and 2.7 (so maybe around May 2018) they changed the format of the error messages, resulting in next-error not always working in compilation-mode.
I believe this needs to be updated: https://github.com/ananthakumaran/typescript.el/blob/a922c27e95948a13e6a72e2620ca592a744721a7/typescript-mode.el#L2529.

Hi.

I've noticed problems using functionality that depends on beginning-of-defun. So I had a closer look and it looks like function return types are throwing it off.

With this code:

const x = 10;

function foo() {
  return "nothing";
}

doing beginning-of-defun from inside the function takes me to the function declaration.

On the other hand, with this code:

const x = 10;

function foo(): string {
  return "nothing";
}

it takes me to the top of the file (the const declaration).

The same problem happens with end-of-defun (if the function has a return type, it takes me to the end of the file). I wouldn't be surprised if the same problem underlies both of them failing.

Thanks, and my apologies if I've misunderstood the expected behavior or if this is a problem in another package (not too familiar with which functions belong where).

Having proper highlighting of typedoc/jsdoc comments, besides providing visual help, would allow skipping things that don't need spell-checking when using flyspell-prog-mode.

For instance, in the following:

/**
 * @param {SomeType} blah something
 */

The only thing that needs spell checking is "something". The rest is either a typedoc/jsdoc tag (@param), a type reference (SomeType) or a parameter name (blah). Flyspell determines whether a piece of text should be spell-checked by seeing whether it has any of the faces in flyspell-prog-text-faces. Right now typescript-mode assigns font-lock-comment-face to the whole comment and thus everything is subject to spell checking.

As usual, js-mode has no support for this, whereas js2-mode distinguishes the various parts appropriately.

Given the following regexp:

/[a/b]/

The regexp will be highlighted as a regexp from the first forward slash, until the 2nd forward slash. However, the regexp really ends at the last forward slash. (For the benefit of readers who may not know: a forward slash appearing in [...] is treated as part of the regexp instead of treated as terminating the regexp. The regex above matches the characters a, / and b.)

I guess it is the twin of #34.

This issue does not annoy me enough to get to work on a solution in the short term so anyone is welcome to fix it and reap the glory. :)

GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.1)
of 2019-02-26

Leaving directory ‘/home/thomas/.emacs.d/elpa/typescript-mode-20181221.905’

Compiling file /home/thomas/.emacs.d/elpa/typescript-mode-20181221.905/typescript-mode-test-utilities.el at Thu Feb 28 19:29:48 2019
Entering directory ‘/home/thomas/.emacs.d/elpa/typescript-mode-20181221.905/’

Compiling file /home/thomas/.emacs.d/elpa/typescript-mode-20181221.905/typescript-mode.el at Thu Feb 28 19:29:48 2019

Compiling internal form(s) at Thu Feb 28 19:29:48 2019
Warning (bytecomp): ‘font-lock-fontify-buffer’ is for interactive use only; use ‘font-lock-ensure’ or ‘font-lock-flush’ instead. [2 times]
Warning (bytecomp): ‘syntax-begin-function’ is an obsolete variable (as of 25.1).

The ELisp file says we should have received a copy of it.

Thanks! 😸

The following comment breaks syntax highlighting for all lines following

// some comment :/

Example:

Indenting the last line of this example with tab causes an infinite loop.

`
//`
 //

Something like:

test.replace(/\/g,"/");
nextlines are as if part of a string

Using : typescript-mode-20170324.1301

Follow up to #32 which requests customizable faces specific to typescript mode.

This is addressed by PR #78, and allows the currently highlighted faces by typescript mode to be customized.

However, it does not address adding additional highlighting rules. In fact, the example given by @it6 in #32 is for function-call, which is not currently given a face at all.

I am proposing to add additional highlighting for the following cases, each with an example, and the face name it would be given:

• function calls (typescript-function-call-face)

    foo.bar()
        ^^^

• function definitions in classes (typescript-function-name-face)

class Foo {
    bar () {
    ^^^
      
    }
}

• variable names definitionitions in classes (typescript-variable-name-face)

class Foo {
    private foo = 'bar'
            ^^^
}

• decorators (typescript-decorator-face)

@Component({
^^^^^^^^^^
    //
})
class Foo {
    //
}

Below are examples of 3 types of functions with single line parameters (S suffix) or double line parameters (D suffix). One would expect the behavior of single and multi-line parameters to behave the same between arrow functions and traditional named (or anonymous) functions but that does not appear to be the case. Is something possibly wrong with my settings?

Typescript-mode: v0.2

function fooS(a: string, b: string) {
  return a + b;
}

function fooD(a: string,
              b: string) {
  return a + b;
}

const barS = function(a: string, b: string) {
  return a + b;
};

const barD = function (a: string,
                       b: string) {
  return a + b;
};

const bazS = (a: string, b: string) => {
  return a + b;
};

const bazD = (a: string,
              b: string) => {
                return a + b;
              };

This isn't a bug so much as a request / query. I'm just wondering about syntax highlighting for functions that are exported.

Given the following example:

function foo() {

}

export function bar() {

}

foo will be coloured but bar wont. Was the a conscious choice? Personally I'd like both function names to be coloured (probably using the same colour). I have a hacky solution that changes typescript--function-heading-1-re to include an optional export string in the regex, however I'm really not knowledgeable enough to know if this is the wrong approach.

(And thanks for the great work on the mode!)

typescript.el does not indent case statements in a switch, while tsserver, and by extension Tide, do indent it. And even though I prefer the not indented version, it's really awkward when the major mode and the official formatter disagree.