simple-drag-drop-text插件仅支持编辑器内部文本拖拽，不处理跨文件、桌面文件或外部资源拖入，因其仅监听当前editor实例的dragstart/drop事件且限于文本节点。
simple-drag-drop-text 插件只支持文件内文本拖拽，不支持跨文件或拖入外部文件
很多人装了 simple-drag-drop-text 后发现拖不了资源管理器里的文件进来，或者拖不动代码块到另一个 tab —— 这不是配置问题，是插件能力边界。它只监听编辑器内部的 dragstart 和 drop 事件，且仅作用于当前 editor 实例的文本节点。Windows 原生拖放（如 WM_DROPFILES）或浏览器级文件拖入（event.dataTransfer.files）完全不在它的处理范围内。
如果你需要拖入 .py 文件、图片或从桌面拖文本进来，得靠系统级支持（比如 Atom 自身对 WM_DROPFILES 的有限响应）或额外插件，simple-drag-drop-text 不管这事。
启用后仍无法拖拽文本？检查 editor 是否处于可编辑状态和焦点位置
Atom 的 simple-drag-drop-text 默认依赖 editor.isTextEditor() 和 editor.hasFocus() 判断是否激活拖拽逻辑。常见失效场景：
- 当前 tab 是只读模式（比如 diff 视图、git-log 输出），
editor.isReadOnly()返回true，插件直接跳过监听 - 光标没落在编辑器内容区，而是停在行号栏、折叠箭头或空白侧边栏，
editor.element.contains(event.target)判定失败 - 用了第三方主题或样式覆盖了
.editor .line的user-select: none，导致 dragstart 事件根本触发不了
验证方法：打开开发者工具（Ctrl+Shift+I），在 console 执行 atom.workspace.getActiveTextEditor()?.hasFocus()，返回 true 再试拖拽。
拖拽行为不符合预期？关键参数藏在 config.cson 里
simple-drag-drop-text 没有图形化设置面板，所有行为控制都靠手动改 ~/.atom/config.cson。常用项包括：
-
"simple-drag-drop-text": {"enableOnReadOnly": false}—— 设为true才能在只读文件里拖拽（慎用，可能意外修改 git diff） -
"simple-drag-drop-text": {"preventDefaultOnDragStart": true}—— 默认true，禁用浏览器原生选中文本后的默认拖拽（避免和 Atom 内部逻辑冲突） -
"simple-drag-drop-text": {"dropPosition": "cursor"}—— 可选"cursor"或"mouse"，决定松手时插入位置按光标还是鼠标坐标算
改完记得重启 Atom 或执行 Atom: Reload Window（Ctrl+Alt+R），热重载不生效。
与其他插件冲突时优先级怎么调？别让 linter 或 beautify 拦截 drop 事件
某些插件（如 linter-flake8 或 atom-beautify）会在 onDidChange 或 onDidStopChanging 里主动调用 editor.setText()，这会重置 editor 的 selection 和 scroll position，间接导致 drop 后光标跳转、文本错位。更隐蔽的是 pigments —— 它给颜色字面量加 overlay 元素，可能让 event.target 指向非 textNode，使插件误判 drop 区域。
临时排查方法：禁用疑似插件 → 测试拖拽 → 逐个启用确认。长期方案是在 init.coffee 里加防抖逻辑，比如：
atom.packages.onDidActivatePackage (pack) ->
if pack.name is 'simple-drag-drop-text'
atom.commands.dispatch(atom.views.getView(atom.workspace), 'simple-drag-drop-text:enable')
复杂点在于，Atom 的事件流没有标准 stopPropagation 控制权，插件之间靠 timing 和 DOM 层级博弈 —— 这也是为什么简单拖拽在小项目里很顺，一加十几插件就出怪事。
