emacs-typescript / typescript.el Goto Github PK
View Code? Open in Web Editor NEWTypeScript-support for Emacs
License: GNU General Public License v3.0
TypeScript-support for Emacs
License: GNU General Public License v3.0
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!");
}
}
}
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
.
Indenting the last line of this example with tab causes an infinite loop.
`
//`
//
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.)
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.
Example: the oops method gets double-indented.
class Foo {
bar() {
}
* oops() {
}
}
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:
typescript-function-call-face
) foo.bar()
^^^
typescript-function-name-face
)class Foo {
bar () {
^^^
}
}
typescript-variable-name-face
)class Foo {
private foo = 'bar'
^^^
}
typescript-decorator-face
)@Component({
^^^^^^^^^^
//
})
class Foo {
//
}
Typescript 1.3 adds "protected" as a keyword.
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 :)
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.
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).
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.
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.
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.
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;
};
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');
}
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.
The ELisp file says we should have received a copy of it.
Thanks! 😸
typescript.el
indents like this:
var x = 5,
y = 6;
I posit that it should indent like this:
var x = 5,
y = 6;
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');
}
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.
function f1(x) {
return (
x.then()
)
}
function f2(x) {
return (
x.catch()
)
(Sorry for all the issues! :-p)
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!)
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.
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
:
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
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?
// Good
foo.noteach()
bar()
// Bad
foo.each()
bar()
I might look into it and submit a PR if I feel motivated! :-)
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?
Maybe prog-indent-sexp should ignore the content of template strings ?
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.
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. :)
Something like:
test.replace(/\/g,"/");
nextlines are as if part of a string
Using : typescript-mode-20170324.1301
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)))
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.
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?
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).
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.
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).
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).
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.
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.
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.
[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:
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.)
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.
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.
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).
There is no support for syntax highlighting of the arrow function formal parameters, beginning-of-defun
etc.
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)
(require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))
M-x package-refresh-contents
M-x package-install typescript-mode
(should install version 20170526.239 as of right now)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:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.