write the ide support page and drop neovim

docs/getting-started/quick-start.md

@@ -51,7 +51,8 @@ the connection settings.
 Start your editor listening on port `9003`, set a breakpoint, and run your code.
 The debugger connects, pauses, and hands you the session.
 
-See [IDE Support](../integrations/ide-support.md) for PhpStorm, VS Code and Neovim.
+See [IDE Support](../integrations/ide-support.md) for PhpStorm, VS Code and other
+IDEs.
 
 ## Next steps
 

docs/integrations/ide-support.md

@@ -2,8 +2,49 @@
 title: IDE Support
 ---
 
-PHP Debugger works seamlessly with any IDE that supports the DBGp protocol, including PhpStorm, VS Code, and Neovim.
+If you have debugged PHP from your editor before, there is almost certainly nothing
+to change. PHP Debugger speaks the same [protocol](../reference/debug-protocol.md)
+your editor already knows, on the same port it already listens on. No plugin, no
+adapter, no new configuration.
 
-:::note
-This page is a work in progress — full documentation is coming soon.
-:::
+What does change is not the setup. It is a few habits.
+
+## Three habits worth adopting
+
+**Stop worrying about turning it on.** Out of the box the debugger is always
+available: every request starts a session and connects the moment your editor is
+listening. There is no trigger to set, no browser extension to click, no
+`?XDEBUG_SESSION_START=1` to remember, and no separate configuration to switch
+between "debugging" and "not debugging". If your existing setup has any of that in
+it, you can take it out.
+
+**Listen when you want to debug, and stop when you are done.** This is the switch
+now — your editor's, not the debugger's. Start listening when you want to step
+through something, stop listening when you have finished. With nothing listening
+the debugger tries once, finds no one, and costs you almost nothing for the rest of
+the request.
+
+**Remove your breakpoints once you are finished with them.** Every breakpoint left
+behind is checked on every request for as long as the session lasts. One forgotten
+breakpoint is nothing; twenty of them, accumulated over an afternoon, are a slow
+session that gets blamed on the debugger. Delete them rather than disabling them —
+a disabled breakpoint is cheaper, not free.
+
+Together these replace the old routine of enabling the debugger for the work and
+disabling it afterwards. Leave it on; control the session from your editor instead.
+
+## Editor guides
+
+The two editors most PHP developers use have a page each, covering how to use each
+one with the debugger:
+
+- [PhpStorm](./phpstorm.md)
+- [VS Code](./vs-code.md)
+
+## Everything else
+
+Any client that speaks DBGp works, and there is nothing specific to do for it.
+Point it at port `9003`, start listening, and debug exactly as you always have.
+
+If your editor's existing PHP debugging setup works today, it will keep working —
+the three habits above are all that is worth revisiting.

sidebars.js

@@ -61,7 +61,6 @@ const sidebars = {
         'integrations/ide-support',
         'integrations/phpstorm',
         'integrations/vs-code',
-        'integrations/neovim',
       ],
     },
     {

src/components/BenefitGrid/index.js

@@ -46,7 +46,7 @@ const benefits = [
   },
   {
     title: 'Works with your editor',
-    text: 'Full DBGp protocol support means any IDE or tool that speaks it just works — PhpStorm, VS Code, Neovim, and anything else in your setup.',
+    text: 'Full DBGp protocol support means any IDE or tool that speaks it just works — PhpStorm, VS Code, and anything else in your setup.',
     icon: (
       <svg {...iconProps}>
         <rect x="3" y="4" width="18" height="13" rx="2" />

src/components/HomeCards/index.js

@@ -17,7 +17,7 @@ const keyFeatures = [
   'Logging and error handling',
 ];
 
-const ides = ['PhpStorm', 'VS Code', 'Neovim'];
+const ides = ['PhpStorm', 'VS Code'];
 
 function Card({icon, title, children, linkTo, linkLabel}) {
   return (