Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tide mode broken in temp buffers #378

Open
elibarzilay opened this issue May 15, 2020 · 3 comments · May be fixed by #380
Open

Tide mode broken in temp buffers #378

elibarzilay opened this issue May 15, 2020 · 3 comments · May be fixed by #380

Comments

@elibarzilay
Copy link
Collaborator

(Apologies if this is known, I can't look at where exactly this is coming from...)

When tide is used for a temp buffer (which means that there is no file that holds the content) I keep getting errors like the below. It's particularly bad since I'm using magit, which tends to create such buffers in many cases (ie, to show a file at a particular commit, which is not actually in the FS).

Error processing request. Cannot read property 'replace' of null
TypeError: Cannot read property 'replace' of null
    at normalizeSlashes (/home/eli/ts/ts/built/local/tsserver.js:6305:21)
    at Object.normalizePath (/home/eli/ts/ts/built/local/tsserver.js:6414:16)
    at Object.toNormalizedPath (/home/eli/ts/ts/built/local/tsserver.js:142034:23)
    at IOSession.Session.getFileAndProjectWorker (/home/eli/ts/ts/built/local/tsserver.js:149309:35)
    at IOSession.Session.getFileAndProject (/home/eli/ts/ts/built/local/tsserver.js:149293:29)
    at IOSession.Session.getQuickInfoWorker (/home/eli/ts/ts/built/local/tsserver.js:149368:31)
    at Session.handlers.ts.createMapFromTemplate._a.<computed> (/home/eli/ts/ts/built/local/tsserver.js:148365:61)
    at /home/eli/ts/ts/built/local/tsserver.js:150050:88
    at IOSession.Session.executeWithRequestId (/home/eli/ts/ts/built/local/tsserver.js:150041:28)
    at IOSession.Session.executeCommand (/home/eli/ts/ts/built/local/tsserver.js:150050:33)
    at IOSession.Session.onMessage (/home/eli/ts/ts/built/local/tsserver.js:150074:35)
    at Interface.<anonymous> (/home/eli/ts/ts/built/local/tsserver.js:151390:27)
    at Interface.emit (events.js:210:5)
    at Interface._onLine (readline.js:316:10)
    at Interface._normalWrite (readline.js:461:12)
    at Socket.ondata (readline.js:172:10)
    at Socket.emit (events.js:210:5)
    at addChunk (_stream_readable.js:326:12)
    at readableAddChunk (_stream_readable.js:301:11)
    at Socket.Readable.push (_stream_readable.js:235:10)
    at Pipe.onStreamRead (internal/stream_base_commons.js:182:23)
@ananthakumaran
Copy link
Owner

ananthakumaran commented May 16, 2020

yes, tide needs a buffer backed by real file. There is some support for indirect buffer like org-mode, where we send the full contents to tsserver instead of just the filename.

In magit case, it's better to not enable tide mode at all. But I can't find a reliable way to detect it's a magit buffer.

@lddubeau lddubeau linked a pull request May 17, 2020 that will close this issue
@M3kH
Copy link

M3kH commented Jun 2, 2020

Related, but not completely (tell me if needs a separate issue), I’m struggling in getting tide to work with org-mode.

More specific when I’m working with tangled files, which I know the destination path, so I declare buffer-filename and tide-active-buffer-file-name on org-babel-edit-prep:typescript.

It seems not working also because tide-require-manual-setup remains t even if I explicit set to nil in the hook mention above.

Is there a way to get full featured tide when knowing the destination path of a tanglable (not sure that is a correct word) buffer?

Seems that this is somehow possible with lsp-mode but I didn’t give it a try.

Thanks for making tide!

@ananthakumaran
Copy link
Owner

@M3kH looks like a regression, I can't get it to work either. Could you open a separate issue to track this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants