Add support for indirect buffers #203

robbert-vdh · 2017-10-15T19:18:13Z

This allows tide to be used in e.g. template files. The only caveat is that the file has to be manually added to tsconfig.json, as the globs in the include array ignore non-typescript files (see microsoft/TypeScript#8328). Otherwise the file will be added to an inferred project with default compiler settings. This fixes #198.

josteink · 2017-10-15T20:46:30Z

This looks like an amazing (and a little big) pull.

I’ll try to get it tested, reviewed and provide comments over the next few days.

Anyway, I have to say already now: Awesome. Glad to see you pulled through on this one!

robbert-vdh · 2017-10-15T21:35:33Z

I was surprised that this actually worked as well as it does. I expected that we'd have to manually send changes in the buffer to the server process, but somehow everything works out of the box. The only problem is that TypeScript doesn't include non-typescript files in the project unless you manually tell it to.

josteink · 2017-10-15T21:37:51Z

Is that something we can fix in the configure-command?

robbert-vdh · 2017-10-15T21:49:23Z

I don't think so. I tried manually specifying the location of tsconfig.json through the projectRootName parameter, but then tsserver starts throwing exceptions around because it doesn't see the file as part of that project. Until TypeScript supports custom file extensions/globs, I think the only options are either automatically adding the file to the files array (though that might not always be what you want) or telling the user to do it themselves.

ananthakumaran · 2017-10-16T04:15:04Z

Thanks for the PR. I haven't gone through entire patch, I just want to point out some issues that might occur

replacing buffer-file-name with tide-buffer-file-name will not work in all the cases. The first one is a value that is kept up to date by emacs. It could be changed by file rename operation. tide-buffer-file-name on the other hand is a snapshot of buffer-file-name. Currently, tide automatically re-configure the buffer if the file is renamed(grep for tide-active-buffer-file-name), This would likely break that functionality. Probably a function would do the trick
does it work if there are more than one indirect buffers in the same file?
how do we handle cases like refactor/rename-symbol etc where tsserver will give us the filename/pos and ask us to change. Does it work correctly now? because I guess we would be trying to apply it in the parent file and it might not work

robbert-vdh · 2017-10-16T08:28:51Z

replacing buffer-file-name with tide-buffer-file-name will not work in all the cases. The first one is a value that is kept up to date by emacs. It could be changed by file rename operation. tide-buffer-file-name on the other hand is a snapshot of buffer-file-name. Currently, tide automatically re-configure the buffer if the file is renamed(grep for tide-active-buffer-file-name), This would likely break that functionality. Probably a function would do the trick

Good catch! I'll move it to a function.

does it work if there are more than one indirect buffers in the same file?

I was worried about that, but it shouldn't be a problem as the actual major mode hooks are only executed when the indirect buffer gets opened through edit-indirect-region. Org-mode is an exception, but that also shouldn't be a problem as multiple source blocks would just overwrite eachother (ob-typescript doesn't let you share state between multiple blocks anyway).

how do we handle cases like refactor/rename-symbol etc where tsserver will give us the filename/pos and ask us to change. Does it work correctly now? because I guess we would be trying to apply it in the parent file and it might not work

I just tried it. Right now tide-apply-refactor does indeed try to edit the parent buffer instead of the opened indirect buffer, so that might need some work to get working.

I also noticed that this approach doesn't work for org-mode documents yet as they don't use edit-indirect.el and tide-setup doesn't execute, but that should be an easy fix.

ananthakumaran · 2017-10-16T08:57:18Z

could you also add a minimal vuejs/org file inside the example folder, so it would be easier to test? I have never used vuejs myself.

robbert-vdh · 2017-10-19T16:08:47Z

I haven't had the time to properly test everything yet, but refactoring should now work in temporary and indirect buffers, and there should be no more errors in org-mode.

ananthakumaran · 2017-10-19T16:31:51Z

It seems like we take care of rename that originates from the indirect buffer. What happens when we rename symbols in different ts file, that is also referenced by .vue file. I tried it in different scenarios and get mixed results

rename Person class in test.ts, it works surprisingly. I guess tsserver is still able to parse the file as typescript and it considers all the tags as syntax errors..
edit the ts code in .vue file and commit the result. Now tsserver thinks that .vue file contains only ts code. If you go to test.ts and do the rename again, the refactor is applied at the wrong place in .vue file.

All these issues might go away if tsserver is aware of the .vue file. Have you tried https://github.com/sandersn/vue-ts-plugin

robbert-vdh · 2017-10-21T10:23:51Z

I hadn't heard of vue-ts-plugin before. It looks like it extracts the script part of the component. That would allow for cross-file refactoring and imports without a shim (you'd normally use a shim for importing .vue components and let webpack do all the compilation), but using it will probably break editing as the plugin assumes tsserver is looking at the entire file, not just the script part. The official VsCode plugin seems to solve it by bundling an actual language server, but that's way seems way out of scope. It would be much better if we could somehow associate a file with a TypeScript project without having to add it to tsconfig.json. That would still not fix cross-file renaming, but it would at least not break anything. You'd probably want to keep your components as simple as possible anyway, and some refactors could potentially break the template part of the component.

josteink · 2017-10-21T10:28:34Z

tide.el


 (defvar tide-servers (make-hash-table :test 'equal))
 (defvar tide-response-callbacks (make-hash-table :test 'equal))

-(defvar tide-source-root-directory (file-name-directory (or load-file-name buffer-file-name)))
+(defvar tide-source-root-directory (file-name-directory (or load-file-name (tide-buffer-file-name))))


In this particular case, aren't we actually interested in the buffer-file-name (since the buffer is going to be tide.el, not something the user is editing)?

If we're actually interested in (tide-buffer-file-name), this defvar has one issue: it's introduced in the source before tide-buffer-file-name is, meaning evaluating this statement interactively from scratch will fail.

For a tide-developer, that's pretty annoying, not to mention something I just fixed, so I'd like for it not to get broken again immediately :)

Good catch, that's what you get for carelessly find-replacing.

You forgot to fix this one :)

josteink · 2017-10-21T10:36:36Z

tide.el

@@ -194,6 +195,16 @@ above."
  (let ((full-path (directory-file-name (tide-project-root))))
    (concat (file-name-nondirectory full-path) "-" (substring (md5 full-path) 0 10))))

+(defun tide-buffer-file-name ()
+  "Returns either the path to the currently open file. This is
+  needed to support indirect buffers, as they don't set


This function seems to work as intended, but the docstring has some issues.

Returns either {something} ... or what?

josteink · 2017-10-21T10:40:19Z

tide.el

+  (if (equal file (tide-buffer-file-name))
+      (current-buffer)
+    (find-file-noselect file)))
+


This is going to leave buffers lying around after we're done editing them.

I'm not saying that is wrong per se, but I'm just wondering if it's intentional.

How would you propose closing unneeded buffers?

Looking around the code other places, we are pretty careless about usage of find-file-noselect ourselves already.

I don't have any issues with this per se, and from inspecting my buffer list after working with this, I can't say I see Emacs literred with new, additional leftover buffers.

I guess you can disregard this comment. This is fine as it is.

josteink · 2017-10-21T10:41:06Z

tide.el

+                     (if tide-require-manual-sync
+                         `(:file
+                           ,(tide-buffer-file-name)
+                           ;; TODO: Set this according to a variable or an alist


Is this still something which needs to be done, or is this just a leftover comment from when you worked on it?

It would only be needed to support TSX in a an indirect buffer. Maybe a simple variable that could be overridden in the dir-local variables would suffice?

As far as I understand (not developing React/JSX/TSX myself), our JSX/TSX-support is already a little spotty.

Not having 100% support out of the box for literate TSX is IMO not going to be a big deal, and especially if we don't have an easy way to reliably establish what kind of scripting-kind this is.

Unless anyone else objects or has a way to properly determine this, I say TS as a default is fine for now.

josteink · 2017-10-21T10:46:40Z

tide.el

@@ -170,11 +170,12 @@ above."
 (tide-def-permanent-buffer-local tide-buffer-dirty nil)
 (tide-def-permanent-buffer-local tide-buffer-tmp-file nil)
 (tide-def-permanent-buffer-local tide-active-buffer-file-name nil)
+(tide-def-permanent-buffer-local tide-require-manual-sync nil)


I can tell we're not exactly leading by example in the existing code...

But not yet being fully familiar with this code, I'd really appreciate a docstring for when I do a apropos lookup. (Like the very descriptive code-comments in tide-setup)

Feel free to extend the tide-def-permanent-buffer-local to add an option for such docstrings.

I originally thought that we'd have to manually synchronize the buffer's contents to tsserver (through ChangeRequest), but it turns out that tsserver is smart enough to use diffs after you pass it the initial file contents, so right now that variable is only needed for setting up the buffer. I'll add docstrings so we can document that!

it turns out that tsserver is smart enough to use diffs after you pass it the initial file contents

Should this in theory also apply to flycheck? Because flycheck is not heaving properly in interactive editing mode, only on initial buffer-load.

but it turns out that tsserver is smart enough to use diffs after you pass it the initial file contents,

No tsserver doesn't do anything. Once we open a file using open command, tide is supposed to keep the file in sync. Tide currently reloads the entire file see tide-sync-buffer-contents.

Should this in theory also apply to flycheck? Because flycheck is not heaving properly in interactive editing mode, only on initial buffer-load.

if you have the config in readme (setq flycheck-check-syntax-automatically '(save mode-enabled)), flycheck is triggered only on save and mode-enabled. You probably need to add newline to the list I guess.

josteink · 2017-10-21T10:50:13Z

tide.el

+          ;; buffer
+          (when (equal buffer-file-name file)
+            (basic-save-buffer))
+          (basic-save-buffer)


I really appreciate comments in code-sections like this. It helps guide the intent behind the code in ways the code alone doesn't fully convey.

That said: Here the comment says saving may not work... And then immediately after the (when)-guard... we save anyway (and potentially ending up saving twice).

This looks fishy or it needs even better documentation to explain why this isn't wrong.

Good catch, that wasn't intended.

it would be even better to create a function with a proper name, like

(unless (tide-indirect-buffer-p file) (basic-save-buffer))

The intent is not clear when you read the code

josteink · 2017-10-21T10:51:32Z

tide.el

+        ;; Saving won't work if the current buffer is temporary or an indirect
+        ;; buffer
+        (when (equal buffer-file-name file)
+          (basic-save-buffer))
        (length (plist-get location :locs))))))


And here you don't save twice. Basically this is code-repetition where we introduce the possibility of inconsistencies and bugs.

Maybe this could be extracted into a helper-function to avoid such errors in the future?

josteink · 2017-10-21T10:53:47Z

tide.el

+         (when (string-prefix-p "/dev/null/inferredProject"
+                                (tide-plist-get response :body :configFileName))
+           (message (format "'%s' is not part of a project, add it to the files array in tsconfig.json"
+                            (tide-buffer-file-name)))))))))



I really appreciate code like this which guides the user when there's nothing we can do about to situation, not to mention the code-comments helping us decide when things like this can possibly be obsoleted it in the future.

Very nice.

josteink · 2017-10-21T10:58:14Z

Hey Robbert!

I haven't had time to do very much interactive testing yet, but at least now I've looked over the code to see what kind of changes was done.

All in all I have to say I really like it, and for several reasons:

Lot's of comments. Lot's of trying to do the right thing.
You've been very good at isolating your changes from the remaining parts of the code.

That's also quite a diff, and despite what may look like lots of comment, I wasn't able to find much in terms of things I thought were wrong or needed severe changes.

This is clearly 10 out of 10 for an initial contribution!

Let me know what you think about my comments so far, and I can try to do some actual end-user testing too :)

robbert-vdh · 2017-10-21T11:28:53Z

Thank you very much for the help! 'm quite new to elisp and Emacs' inner workings in general, so a little guidance comes very welcome.

josteink · 2017-10-21T11:32:24Z

Now I've done some functional testing, and it's clearly much better than it used to be :)

That said, I seem to be having some issues compared to what I expected. When diving into the typescript babel-section in literate.org I get no warning about file not being "supported". As such, I expect most things to work.

And most things did work like wonders (like eldoc, highlighting, navigation, etc). Amazing stuff. Amazing improvement. Let's just say that before diving into the issues :)

I'm not sure whether you are at fault here or not, but I did find some things which did not work entirely.

Some of these issues are not really so bad in themselves, but they get compounded by one single issue which has potential for causing a lot of confusion: seemingly delayed flycheck reports/errors.

Basically errors in my code are not reported as errors until I finish my editing (as in close the indirect buffer) and re-open it.

As an example, adding a new variable named x at the end of literate.org:

let x = new Snake("boo");
x.|

With the cursor at x. I expect company-completions for the type Snake, but I get nothing. How so?

If I save the buffer, close it and re-open it, I now get the flycheck error telling me that x is already defined and I can't redefine it now...

Empowered by this knowledge, I rename the variable to x1 (manually, no refactor) and voila, everything works! But flycheck didn't tell me until I fully closed the buffer and re-opened it.

Do you think this is something you can fix? Is this related to your concept of manually synched buffers?

Also: where did tsserver pick up x as a variable? If I remove the let so we're just left with basic assignment... And I try to navigate... I get to this in another.js:

var x = {
    another: 'name'
};

Well that's certainly interesting! Maybe tsserver compounds all literate and non-module files into one giant global namespace?

To test out this theory I created another literate section above your's and added the following to it:

#+BEGIN_SRC typescript
  abstract class AnimalBase {
      canMove: boolean;
  }
#+END_SRC

And after that I changed your Animal-class (in the other section) to derive from it. But then tsserver complained that AnimalBase was not defined... So clearly that is not in a global namespace.

(Not sure if this is your fault or not though. But just mentioning it as a finding.)

Anyone have any idea what we should call "expected behaviour" in this case? With some things automatically imported and others not... This can quickly get confusing for the average org-user.

That said... All in all, I'm very much for these changes and you have my full support for getting this PR merged once we get all the small details settled :)

robbert-vdh · 2017-10-21T11:49:31Z

That's weird, I'll look into it this weekend. I haven't experienced any such issues (screencast), but I might be using the version of tsserver that comes bundled with tsc 2.5.3 instead of the one included in the tide repo.

josteink · 2017-10-21T12:06:23Z

Sounds good.

No rush. Take whatever time you need. :)

josteink · 2017-11-20T07:26:44Z

Hey there. Any news on this one? :)

robbert-vdh · 2017-11-21T14:22:31Z

I kind of forgot about it! I'll look into it this evening.

robbert-vdh · 2017-11-21T15:15:40Z

I've fixed some minor things, but I could not reproduce your issues @josteink. Are they still happening? I did notice that it took a newline for flycheck to update when switching between blocks in the .org file as tsserver doesn't know the file's 'contents' have been changed.

I think the only big remaining issue is cross file refactoring (#203 (comment)). Not sure how you'd tackle that one though.

josteink · 2017-11-22T06:47:46Z

I'm now at work where I use windows... And while I'm not sure that matters, I can't get any literate examples to work at all now.

I'm just getting lots of errors inside tsserver:

Error processing request. Cannot read property 'replace' of null
TypeError: Cannot read property 'replace' of null
    at normalizeSlashes (d:\Throwaway\test-tide\node_modules\typescript\lib\tsserver.js:2452:20)
    at normalizePathAndParts (d:\Throwaway\test-tide\node_modules\typescript\lib\tsserver.js:2507:16)
    at Object.normalizePath (d:\Throwaway\test-tide\node_modules\typescript\lib\tsserver.js:2503:16)
    at Object.toNormalizedPath (d:\Throwaway\test-tide\node_modules\typescript\lib\tsserver.js:81176:23)
    at IOSession.Session.getFileAndProjectWorker (d:\Throwaway\test-tide\node_modules\typescript\lib\tsserver.js:86054:35)
    at IOSession.Session.getFileAndProject (d:\Throwaway\test-tide\node_modules\typescript\lib\tsserver.js:86040:29)
    at IOSession.Session.getQuickInfoWorker (d:\Throwaway\test-tide\node_modules\typescript\lib\tsserver.js:86100:31)
    at Session.handlers.ts.createMapFromTemplate._a.(anonymous function) (d:\Throwaway\test-tide\node_modules\typescript\lib\tsserver.js:85269:61)
....

I guess I can double-check if this works better on Linux when I get home, I guess.

In the meantime, we did leave some comments behind on your former commits, and I can't see them having been addressed. (Simple-to-fix stuff like double-saving, etc)

Could you just take a look over those comments again? :)

robbert-vdh · 2017-11-22T09:35:02Z

I've gotten that error before, that seems to happen when tsserver does not receive a valid filename (i.e. when (tide-buffer-file-name) returns nil).

Oh and sorry for that! I was sure I had already fixed those things, but I might have forgotten to push the changes.

josteink · 2017-11-22T20:44:13Z

Just reporting in that I've now tested on Linux and that seems to work fine,

I'm still having issues with flycheck though, but even if we can't figure that one out/or get it fully resolved, I'd still consider this a massive improvement.

I'll see if I can figure out why this doesn't seem to work on my Windows-machine at work though. Not having proper cross-platform support would be quite a bummer.

josteink · 2017-12-05T06:56:25Z

As far as I can diagnose this right now, it seems like this fails on Windows because the value we send in for file is null:

    {"seq":0,"type":"response","command":"semanticDiagnosticsSync","request_seq":"28","success":false,"message":"Error processing request. Cannot read property 'replace' of null\nTypeError: Cannot read property 'replace' of null\n    at normalizeSlashes (d:\\Git\\tstestcase\\node_modules\\typescript\\lib\\tsserver.js:2461:20)\n    at normalizePathAndParts (d:\\Git\\tstestcase\\node_modules\\typescript\\lib\\tsserver.js:2516:16)\n    at Object.normalizePath (d:\\Git\\tstestcase\\node_modules\\typescript\\lib\\tsserver.js:2512:16)\n    at Object.toNormalizedPath (d:\\Git\\tstestcase\\node_modules\\typescript\\lib\\tsserver.js:81455:23)\n    at IOSession.Session.getConfigFileAndProject (d:\\Git\\tstestcase\\node_modules\\typescript\\lib\\tsserver.js:86018:35)\n    at IOSession.Session.getSemanticDiagnosticsSync (d:\\Git\\tstestcase\\node_modules\\typescript\\lib\\tsserver.js:86163:31)\n    at Session.handlers.ts.createMapFromTemplate._a.(anonymous function) (d:\\Git\\tstestcase\\node_modules\\typescript\\lib\\tsserver.js:85695:61)\n    at d:\\Git\\tstestcase\\node_modules\\typescript\\lib\\tsserver.js:87022:88\n    at IOSession.Session.executeWithRequestId (d:\\Git\\tstestcase\\node_modules\\typescript\\lib\\tsserver.js:87013:28)\n    at IOSession.Session.executeCommand (d:\\Git\\tstestcase\\node_modules\\typescript\\lib\\tsserver.js:87022:33)\n    at IOSession.Session.onMessage (d:\\Git\\tstestcase\\node_modules\\typescript\\lib\\tsserver.js:87042:35)\n    at Interface.<anonymous> (d:\\Git\\tstestcase\\node_modules\\typescript\\lib\\tsserver.js:88234:27)\n    at emitOne (events.js:96:13)\n    at Interface.emit (events.js:188:7)\n    at Interface._onLine (readline.js:239:10)\n    at Interface.<anonymous> (readline.js:376:12)\n    at Array.forEach (native)\n    at Interface._normalWrite (readline.js:375:11)\n    at Socket.ondata (readline.js:107:10)\n    at emitOne (events.js:96:13)\n    at Socket.emit (events.js:188:7)\n    at readableAddChunk (_stream_readable.js:176:18)\n    at Socket.Readable.push (_stream_readable.js:134:10)\n    at Pipe.onread (net.js:548:20)"}
Info 16   [7:51:30.349] request:
    {"command":"navtree","seq":"29","arguments":{"file":null}}
Err 17    [7:51:30.350] Exception on executing command {"command":"navtree","seq":"29","arguments":{"file":null}}:

    Cannot read property 'replace' of null

    TypeError: Cannot read property 'replace' of null
    at normalizeSlashes (d:\Git\tstestcase\node_modules\typescript\lib\tsserver.js:2461:20)
    at normalizePathAndParts (d:\Git\tstestcase\node_modules\typescript\lib\tsserver.js:2516:16)
    at Object.normalizePath (d:\Git\tstestcase\node_modules\typescript\lib\tsserver.js:2512:16)
    at Object.toNormalizedPath (d:\Git\tstestcase\node_modules\typescript\lib\tsserver.js:81455:23)
    at IOSession.Session.getFileAndLanguageServiceForSyntacticOperation (d:\Git\tstestcase\node_modules\typescript\lib\tsserver.js:86396:35)
    at IOSession.Session.getNavigationTree (d:\Git\tstestcase\node_modules\typescript\lib\tsserver.js:86724:31)
    at Session.handlers.ts.createMapFromTemplate._a.(anonymous function) (d:\Git\tstestcase\node_modules\typescript\lib\tsserver.js:85750:61)
    at d:\Git\tstestcase\node_modules\typescript\lib\tsserver.js:87022:88

I guess I'll have to verify what the behaviour is on Linux, and see if there's something in our path-handling logic which acts differently there.

I'd love to get this fixed before landing it proper.

josteink · 2017-12-11T13:01:07Z

@robbert-vdh : I feel like I'm the slowest reviewer and tester on earth, but I'd like to ensure things works properly before I merge. Sorry about the delay, and I hope you're still with me.

Running (an old) Emacs 24.5.1 on Ubuntu 16.04 I can reproduce the same exact same issues as I did on Windows (where I'm running 25.3.1). This leads me to believe that this is somehow dependant on other external factors (org-version?) to function 100% correctly, and that it's not tied to Windows being Windows per se.

From what I can tell, it all boils down to tide-buffer-file-name always returning nil in babel-buffers. Should it return something else? What should it return in a org-babel source-code buffer?

Inspecting its implementation and trying to edebug it, I keep finding all the (org) "overlay" parts undefined. Should they be defined? I can't find them in the org source-code.

Care to give me some leads? I'd hate to see this effort go wasted :)

robbert-vdh · 2017-12-11T13:43:10Z

No problem at all, I've been very busy as well. I think you might be onto something. (overlay-buffer org-src--overlay) is supposed to return the buffer the src block was opened from (i.e. the parent buffer) and it works as expected with the latest melpa version of org-plus-contrib (tested in Spacemacs). I quickly looked at org-mode's git history and the variable seems to be renamed from org-edit-src-overlay back in 2014, meaning that Org 8.x uses the old org-edit-src-overlay. Adding backwards compatibility should be trivial unless other parts are also broken.

Then there's still the issue of cross-file refactoring writing the wrong parts of files, though I'm not sure if there's anything we can do about that without modifying tsserver.

josteink · 2017-12-11T13:51:44Z

Adding backwards compatibility should be trivial unless other parts are also broken.

Good good. Make it so.

Then there's still the issue of cross-file refactoring writing the wrong parts of files, though I'm not sure if there's anything we can do about that without modifying tsserver.

That's not a show-stopper by any means. I'm fairly certain most people will understand that this not working 100% correctly is not a shortcoming of tide, and that working with complex refactorings outside "regular" typescript-projects has limitations.

If you can fix that org-compatibility-issue, and I can verify it working on my "boring" Windows install, I think we can consider this good to go and ready for merge!

The only caveat is that the file has to be manually added to tsconfig.json, as the globs in the include array ignore non-typescript files. Try to read the file name org org src blocks Move tide-buffer-file-name to a function, otherwise tide will ignore file renames TODO: - Apply refactors to the correct buffer. - Check why tide-setup doesn't fire in org-mode files.

To test this you should install 'vue-mode' and run `vue-edit-indirect-at-point` inside the TypeScript code.

Source blocks on org-mode won't have their parent buffer set until after major mode hooks have fired, meaning we can't retrieve the file name until after `tide-setup` has ran.

Synchronization of buffers was already done manually, in `tide-sync-buffer-contents`.

`org-edit-src-overlay` got renamed to `org-edit-src-overlay` in org-mode 9.0, but Emacs still ships with org-mode 8.3.

robbert-vdh · 2017-12-11T14:41:40Z

I've rebased and added the fix, hopefully it works now!

josteink · 2017-12-11T19:07:39Z

That's a confirmed fix on my end. Consider it merged!

Thanks for taking time to develop and contribute this awesome feature! Feel free to stay around and send us patches whenever you see something which can be improved.

Contributions are always welcome, and I promise next time around I won't spend this long reviewing :)

robbert-vdh force-pushed the feature/indirect-buffer-support branch from 1a12cf0 to 753444f Compare October 16, 2017 08:41

robbert-vdh force-pushed the feature/indirect-buffer-support branch from 753444f to c888fc0 Compare October 16, 2017 10:41

josteink reviewed Oct 21, 2017

View reviewed changes

robbert-vdh force-pushed the feature/indirect-buffer-support branch from 2b1f481 to ef8716a Compare November 21, 2017 15:15

robbert-vdh force-pushed the feature/indirect-buffer-support branch from ef8716a to 570d21f Compare November 22, 2017 09:34

robbert-vdh added 8 commits December 11, 2017 15:38

Add an example .vue component

5f4177e

To test this you should install 'vue-mode' and run `vue-edit-indirect-at-point` inside the TypeScript code.

Add an org mode example

f79bf5b

Enable renaming and refactoring in indirect and temporary buffers

35e896e

Fix org-mode support

11e6a0e

Source blocks on org-mode won't have their parent buffer set until after major mode hooks have fired, meaning we can't retrieve the file name until after `tide-setup` has ran.

Add a variable for setting the default mode for indirect buffers

3e379f7

Reword manual-sync variable to manual-setup for clarity

8bc9234

Synchronization of buffers was already done manually, in `tide-sync-buffer-contents`.

Fix compatibility with org-mode 8.x

181184a

`org-edit-src-overlay` got renamed to `org-edit-src-overlay` in org-mode 9.0, but Emacs still ships with org-mode 8.3.

robbert-vdh force-pushed the feature/indirect-buffer-support branch from 570d21f to 181184a Compare December 11, 2017 14:41

josteink merged commit 5fb082c into ananthakumaran:master Dec 11, 2017

ananthakumaran mentioned this pull request Oct 7, 2020

Error message in Vue buffers #400

Open

Add support for indirect buffers #203

Add support for indirect buffers #203

Conversation

robbert-vdh commented Oct 15, 2017

josteink commented Oct 15, 2017

robbert-vdh commented Oct 15, 2017

josteink commented Oct 15, 2017

robbert-vdh commented Oct 15, 2017

ananthakumaran commented Oct 16, 2017 • edited Loading

robbert-vdh commented Oct 16, 2017

ananthakumaran commented Oct 16, 2017

robbert-vdh commented Oct 19, 2017

ananthakumaran commented Oct 19, 2017 • edited Loading

robbert-vdh commented Oct 21, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

josteink commented Oct 21, 2017

robbert-vdh commented Oct 21, 2017

josteink commented Oct 21, 2017 • edited Loading

robbert-vdh commented Oct 21, 2017 • edited Loading

josteink commented Oct 21, 2017

josteink commented Nov 20, 2017

robbert-vdh commented Nov 21, 2017

robbert-vdh commented Nov 21, 2017

josteink commented Nov 22, 2017

robbert-vdh commented Nov 22, 2017

josteink commented Nov 22, 2017 • edited Loading

josteink commented Dec 5, 2017

josteink commented Dec 11, 2017

robbert-vdh commented Dec 11, 2017

josteink commented Dec 11, 2017

robbert-vdh commented Dec 11, 2017

josteink commented Dec 11, 2017

ananthakumaran commented Oct 16, 2017 •

edited

Loading

ananthakumaran commented Oct 19, 2017 •

edited

Loading

josteink commented Oct 21, 2017 •

edited

Loading

robbert-vdh commented Oct 21, 2017 •

edited

Loading

josteink commented Nov 22, 2017 •

edited

Loading