This repository has been archived by the owner on Dec 13, 2018. It is now read-only.
Opening a folder? #3
Comments
|
Can confirm on OSX. This may be a silly Atom or package setting? Haven't found it yet though. |
|
This looks like it is listed under the nuclide-tree-view package as a TODO to override the default atom-package tree-view key-bindings... if you disable the default atom tree view package, the issue is resolved. I believe the key-binding that need removed/ overrided are: 'ctrl-alt-cmd-': 'tree-view:toggle' |
Closed
|
The tree-view package isn't disabled when nuclide-tree-view gets activated. I think it would be helpful to show a message on nuclide-tree-view activation that for best ux tree-view package should be disabled. Have not checked if disabling a package works via api from inside other packages. Maybe nuclide-tree-view could fire key pressed event to hide tree-view, then overwrite tree-view key bindings to hide/unhide nuclide-tree-view and fire this key pressed event. (thinking here about we couldn't always run ./scripts/dev/setup to enable nuclide packages). Does it makes sense? |
|
had the same issue |
|
same here |
|
Thanks for reporting! We have a fix coming to add a preference to disable tree-view on startup |
|
Same here I have disabled the default |
|
Confirm on OS X. Seems |
|
Same issue on OS X |
|
Fixed with 0942e4d |
|
Could someone bump the version so that Atom updates will pick up this fix? |
jgebhardt
pushed a commit
that referenced
this issue
Aug 31, 2015
ghost
pushed a commit
that referenced
this issue
Jun 23, 2016
…tion Summary: We want to be able to watch expressions that are given to the dummy connection, so we need to retrigger evaluation every time the user executes code in the console. Reviewed By: yinghuitan Differential Revision: D3413622 fbshipit-source-id: cf576bb83a0c8189ac2b828dad680bca8565e987
ghost
pushed a commit
that referenced
this issue
Aug 1, 2016
…troller Summary: pulls out the pause logic from the bridge to a separate class as per comments on D3625375. Also fixes the notification logic. Reviewed By: yinghuitan Differential Revision: D3642662 fbshipit-source-id: b7b9a4de230af446f1e648531f7b83f911db83a8
ghost
pushed a commit
that referenced
this issue
Sep 20, 2016
Summary: This increases Flow coverage for the file tree package by over a percentage point, and increases the overall Nuclide type coverage by nearly a tenth of a percentage point. It does not unseat file-tree from its spot at #3 in the type coverage hall of shame, though. Reviewed By: shushz Differential Revision: D3895906 fbshipit-source-id: 4b587ea457f3afb18e02e72c7087e6d11137d33e
facebook-github-bot
pushed a commit
that referenced
this issue
Oct 7, 2016
Summary: This gives a nicer architecture for the debugger, it mostly moves the prototype code from previous diffs around into their own classes/functions. A high-level overview is: 1. `IwdpService` spawns the `ios_webkit_debug_proxy` binary, and subscribes to a stream of its messages, which inform about what targets (ios devices) are available to debug on the host. 2. Whenever a target is discovered, we create a `DebugConnection` to the socket server hosted by the target, and chrome protocol debugger messages are sent over this connection. Things left to do in later diffs: 1. Right now we only support one `DebugConnection` at a time, but in the future we will want to expand this to support an arbitrary number of connections. 2. Right now the bundled js we are debugging is served by the target over a socket, and we download the whole bundle before we can debug it. This code also parses the bundle to find out where source maps are available. This code is gross and hacky and should be cleaned up -- I have some TODOs in `DebuggerConnection.js`. Reviewed By: jgebhardt Differential Revision: D3986328 fbshipit-source-id: 40f4a9f2d1bc48f8bfd0c3b2af740fe311ef529d
facebook-github-bot
pushed a commit
that referenced
this issue
Feb 3, 2017
Summary: Completes the logic for ENDED connections, making use of the onDispose API. Differential Revision: D4505708 fbshipit-source-id: acd2180d8482ff3eee98790fc2153d90256b4ce7
facebook-github-bot
pushed a commit
that referenced
this issue
Jun 5, 2017
Summary: Currently the "full description" checkbox accomplishes 3 things: 1) it displays all trace messages separately 2) it splits the original message by newline and preserves them 3) it link-ifys URLs But IMO #3 should be done even without the checkbox. This changes the standard display to use the same UI component, and updates the checkbox visibility accordingly. Reviewed By: wbinnssmith Differential Revision: D5184817 fbshipit-source-id: 4bada0f5895bc2724d4245095b8232f075a271a3
facebook-github-bot
pushed a commit
that referenced
this issue
Sep 28, 2017
Summary: This change will allow launching of a native binary under the debugger using the Terminal where available. The user can opt out of this via a new config setting. When launching in the terminal, STDIN and STDOUT will be redirected to the terminal, so the user can interact with the target app in addition to interacting with the debugger engine (which is still done via the Console pane). For Native targets, we support configuring the CWD as well as passing environment variables for the terminal to use when launching. Since Linux doesn't have a mechanism to create process suspended, if we just launch the target directly and then try to attach LLDB, there is a race where we risk missing initial breakpoints set early in the program's startup, this would not be acceptable. To make this work properly, a wrapper script and some synchronization is needed to ensure LLDB is attached to the process before it gets to start executing. The synchronization flow in this diff works like this: 1. Nuclide front-end (from LaunchProcessInfo) calls prepareForTerminalLaunch on the Nuclide native debugger RPC service 2. The backend determines the proper paths for python, the wrapper (launch.py in this diff) and the executable. 3. The backend spawns a TCP socket server that listens on a new port and waits. 4. The backend returns the values from step #2, and the port from step #3 to the front-end as launch instructions. 5. The front-end launches the wrapper script *in a new terminal pane* using the path and args the back end gave it. 6. The wrapper script connects to the listening TCP socket to talk to the debugger back end, and writes its own PID into the socke and then issues a read on the TCP socket - *this causes it to block* 7. The debugger backend receives the PID, attaches LLDB to the specified PID and then writes to the TCP socket to unblock the wrapper 8. The wrapper is unblocked from TCP read and issues an execv() syscall to replace itself with the target image, which is now free to begin execution with LLDB attached. 9. The backend closes the TCP sockets and cleans up the server. ... debugging continues as normal from here on. Reviewed By: rightparen Differential Revision: D5898651 fbshipit-source-id: 1c48b7eff53e0c9a2e665a42fe0de2f884c88b5b
facebook-github-bot
pushed a commit
that referenced
this issue
Aug 10, 2018
Summary: When the debugger client evaluates in the "hover" or "watch" contexts, if the expression cannot be evaluated, we should not be throwing PHP errors and printing a bunch of spew. This diff fixes a few issues: 1. Do not print an exception to the console for eval hover errors 2. In Nuclide, don't show a data tip with "N/A" or an expression evaluation error when the user hovers over something that is undefined, a keyword, or not valid code. 3. The SilentEvaluationContext shouldn't be setting the ExecutionContext output buffer to nullptr - this is causing the error not to be suppressed, but instead written to the TLS request transport fd. If the debugger is in webserver attach mode, this causes the error to be written to the browser, which corrupts the webpage output! Note re #3: As best I can tell, hphpd has the same bug due to null'ing the transport buffer during evalaution, but since the CLI doesn't have hover events, it's not noticable. Reviewed By: velocityboy Differential Revision: D9171487 fbshipit-source-id: c83ddde333cb43f40a9c56dd3bde0cf94dfdde3d
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This seems like a pretty basic issue but it seems that opening a folder with Nuclide opens a duplicate of the same project? I tried opening the same folder (i.e. 'atom [foldername]') with and without the nuclide packages. Had expected behavior with vanilla atom (one folder opened), but got the results above after installing the Nuclide packages.
On a side note, I think this issue also affects horizontally resizing the project pane sidebar. If you slightly adjust the sidebar when you have this problem, then the adjustments are very glitchy.
The text was updated successfully, but these errors were encountered: