profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/aeschli/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Martin Aeschlimann aeschli Microsoft Switzerland

aeschli/atom-language-rust 0

Rust language support in Atom

aeschli/changelog 0

Finally see what's changed when you do npm update. Changelog generates a changelog for npm modules and github repos.

aeschli/content 0

The content behind MDN Web Docs

aeschli/CSS-tmLanguage 0

CSS syntax file primarly aimed for Sublime Text 2.

aeschli/eclipse.jdt.ls 0

Java language server

aeschli/eclipse.jdt.ui 0

JDT/UI project repository (eclipse.jdt.ui)

issue commentmicrosoft/vscode

Request adding new 'decorator' semantic token scopes for Javascript/Typescript

To verify:

  • open and run the semantic-tokens-sample
  • In the [Extension Development Host] window, open sample/sample.semanticLanguage in the editor
  • check that [decorator] gets the decorator semantic token (use the Inspect Editor Tokens and Scopes command
gaplo917

comment created time in 7 hours

push eventmicrosoft/vscode

Martin Aeschlimann

commit sha 8e7601d3a15175f6c82d40367e751f721580fceb

change decorator fallback to ['entity.name.decorator'], ['entity.name.function']

view details

push time in 7 hours

push eventmicrosoft/vscode-extension-samples

Martin Aeschlimann

commit sha 6429e7f0db67a01800d36418ae05cb108e0ca28d

add `decorator` ro semantic tokens sample

view details

Martin Aeschlimann

commit sha 116b0aa1ade25bfd3c6f3df0847200089b82b72f

improve typing of webpack.config.js

view details

push time in 7 hours

issue closedmicrosoft/node-jsonc-parser

Formalize with a specification

Per title. The world's crying out for JSON with Comments, all the dev world really needs is a spec.

closed time in 7 hours

SNDST00M

issue commentmicrosoft/node-jsonc-parser

Formalize with a specification

Sorry, we don't have any ambition to make a standard.

SNDST00M

comment created time in 7 hours

push eventmicrosoft/node-jsonc-parser

Martin Aeschlimann

commit sha 009d0a69c900e5cdaa956b39effe70660b1dac0c

Non-standard whitespace handling. Fixes #46

view details

push time in 7 hours

issue closedmicrosoft/node-jsonc-parser

Non-standard whitespace handling

The scanner in node-jsonc-parser allows multiple non-standard whitespace chars to be accepted as a whitespace:

https://github.com/microsoft/node-jsonc-parser/blob/ff813e9f741b2b35f8bea2dd7022a3a43156d04a/src/impl/scanner.ts#L392

However, JSON specification allows only a handful of whitespace chars:

  ws = *(
          %x20 /              ; Space
          %x09 /              ; Horizontal tab
          %x0A /              ; Line feed or New line
          %x0D )              ; Carriage return

Difference in whitespace handling leads to interop problems with other JSON parsers, where input successfully parsed by node-jsonc-parser would fail to parse in Node or Python.

closed time in 7 hours

ak1394

issue commentmicrosoft/node-jsonc-parser

Add dev container

Yes, sure, I'm happy to merge a PR.

stuartleeks

comment created time in 8 hours

issue commentmicrosoft/node-jsonc-parser

Feature request: visit() is not useable with modify()

Yes, we don't have the functionality to compute the changes of multiple modifications at once.

mcclure

comment created time in 8 hours

issue commentmicrosoft/node-jsonc-parser

Feature request: Add JSON path parameter to `JSONVisitor` functions

I'm open for a PR, if you are interested.

Marcono1234

comment created time in 8 hours

issue closedmicrosoft/node-jsonc-parser

Clarify whether / how `Edit[]` can be concatenated

The documentation currently does not make it clear whether or how Edit[] from multiple modify() or format() calls can be concatenated before being applied using applyEdits().

Both the documentation for modify() and format() contains the following:

Edits can be either inserts, replacements or removals of text segments. All offsets refer to the original state of the document. No two edits must change or remove the same range of text in the original document. However, multiple edits can have the same offset, for example multiple inserts, or an insert followed by a remove or replace. The order in the array defines which edit is applied first.

Personally I think this documentation should be moved to applyEdits() respectively to the documentation of the type Edit instead since it is more relevant there.

The issue is that the output of multiple modify() calls cannot be concatenated without risking to produce malformed JSON when calling applyEdits(). Here are two examples (from https://github.com/microsoft/node-jsonc-parser/issues/48#issuecomment-909646709):

  • Removing subsequent array elements / object properties. This will cause both elements / properties to remove the same ,, which in the end results in one character too much being removed:
    const json = '{"a":1,"b":2}'
    let edits = jsoncParser.modify(json, ["a"], undefined, {})
    edits = edits.concat(jsoncParser.modify(json, ["b"], undefined, {}))
    
    // Prints only `{`; the closing `}` is missing
    console.log(jsoncParser.applyEdits(json, edits))
    
  • Removing array elements / object properties in reverse order:
    const json = '{"a":1,"b":2,"c":3}'
    let edits = jsoncParser.modify(json, ["c"], undefined, {})
    edits = edits.concat(jsoncParser.modify(json, ["a"], undefined, {}))
    
    // Prints `{"b":2,"c":3`
    console.log(jsoncParser.applyEdits(json, edits))
    

So currently the only safe usage of modify() and applyEdits() is to call both functions for every modification you want to make. It is not safe to try concatenating the result of multiple modify() calls. This is rather inefficient when a user wants to remove multiple properties.

In case this is intended, then it should ideally be clarified in the documentation for the modify() (and format()?) function.

closed time in 8 hours

Marcono1234

issue commentmicrosoft/node-jsonc-parser

Clarify whether / how `Edit[]` can be concatenated

The results of multiple modify (and or format) operations can't be concatenated unless you are sure they don't impact each other.

A different API is needed that would let you compute the text operations for more than one JSON modification. I don't have plans to implement such functionality.

I tried to improve the spec around edit operations.

Marcono1234

comment created time in 8 hours

push eventmicrosoft/node-jsonc-parser

Martin Aeschlimann

commit sha 93fce4889c0c67a2bd5ce71b88547f581e077cd1

Improve spec areound edits. For #53.

view details

push time in 8 hours

issue commentmicrosoft/vscode-html-languageservice

`customData` attributes are not being picked up by IntelliSense

The completions from the first screenshots are textual proposals gathered from the words that occur in the document. They are used by VS Code as fallback when there are no proposals from the language service. We would have to reimplement that in the language service.

dumptyd

comment created time in 9 hours

push eventmicrosoft/vscode

Martin Aeschlimann

commit sha f3a14f6514a9b9194bdda1a690daa51ed72a65b0

[css/html/json] update services

view details

push time in 10 hours

pull request commentmicrosoft/node-jsonc-parser

Improve README

Thanks a lot, @Marcono1234 !

Marcono1234

comment created time in 10 hours

push eventmicrosoft/node-jsonc-parser

Marcono1234

commit sha f3158c7c8e0ff6c7f37cbc3b859964f980a96b5d

Add missing type definition for `JSONPath` to README

view details

Marcono1234

commit sha 98a453fca668dbed09e6e6cb2e473474c1c98f05

Consistently use 4 spaces as indentation for README code blocks

view details

Martin Aeschlimann

commit sha 81825b01e4751d7a33703283286e1c6c2f0d807c

Merge pull request #47 from Marcono1234/patch-1 Improve README

view details

push time in 10 hours

PR merged microsoft/node-jsonc-parser

Improve README
  • Add missing type definition for JSONPath; matching the content of src/main.ts
  • Consistently use 4 spaces as indentation for code blocks
+43 -41

1 comment

1 changed file

Marcono1234

pr closed time in 10 hours

pull request commentmicrosoft/node-jsonc-parser

Make final two arguments of modify() and format() optional

But thanks @mcclure for taking the time!

mcclure

comment created time in 10 hours

PR closed microsoft/node-jsonc-parser

Make final two arguments of modify() and format() optional

Both modify() and format(), the final two arguments could potentially be omitted because there are "obvious" defaults. In both cases, the next-to-last argument actually accepts "undefined", but they're not optional arguments so you have to type out "undefined".

This patch adds question marks? as appropriate in the typing, and explicitly turns an "undefined" argument for FormattingOptions/ModificationOptions into an empty table. I think this would be more convenient. I tested these changes with npm run test but did not write any new tests.

+6 -6

5 comments

2 changed files

mcclure

pr closed time in 10 hours

pull request commentmicrosoft/node-jsonc-parser

Make final two arguments of modify() and format() optional

I'd like to keep the current explicitness. It's not that these API are used super often, so having to add the parameters is not that big of a deal. I looked at making the format parameters optional, but then I realized that ModificationOptions.formattingOptions === undefined means 'leave unformatted' Allowing undefined for options in format would add an inconsistency. Again I think it's not a big deal to have to add all the parameters when calling the APIs. Closing as won't fix.

mcclure

comment created time in 10 hours

push eventmicrosoft/node-jsonc-parser

Martin Aeschlimann

commit sha db51ca1e4180f1383614dafe85f9ed1aca67ab1f

update dependencies

view details

push time in 12 hours

created tagmicrosoft/vscode-html-languageservice

tagv4.1.1

Language services for HTML

created time in 12 hours

push eventmicrosoft/vscode-html-languageservice

Martin Aeschlimann

commit sha 94e5422c7fe92d9a507533b4fc3a08277cf39733

4.1.1

view details

push time in 12 hours

issue closedmicrosoft/node-request-light

Provide a way to get binary data

It seems that the response is always given as data.join('') in node, but when dealing with binary data, the original data Buffers are needed (to then write them to a stream created by fs.createWriteStream).

closed time in 12 hours

fabioz

issue commentmicrosoft/node-request-light

Provide a way to get binary data

Fixed by https://github.com/microsoft/node-request-light/commit/62f6c363eeaac3b25995683bf425ee3684ef45cf

fabioz

comment created time in 12 hours

pull request commentmicrosoft/node-jsonc-parser

readme: improve ParseOptions documentation

Thanks @urish !

urish

comment created time in 12 hours

push eventmicrosoft/node-jsonc-parser

Uri Shaked

commit sha 807632f5bc6ff96fca9931e8960e8747e2c61152

readme: improve ParseOptions documentation add allowTrailingComma, allowEmptyContent

view details

Martin Aeschlimann

commit sha ce71bf6849d65a4fbf1627d6029c1138de961241

Merge pull request #54 from urish/patch-1 readme: improve ParseOptions documentation

view details

push time in 12 hours

PR merged microsoft/node-jsonc-parser

readme: improve ParseOptions documentation

add allowTrailingComma, allowEmptyContent

+2 -0

0 comment

1 changed file

urish

pr closed time in 12 hours

push eventmicrosoft/node-jsonc-parser

Martin Aeschlimann

commit sha d942ff6131fc05e524d4e019547244760d9153cb

Update .travis.yml

view details

push time in 12 hours