T之家 8 月 6 日消息 微軟今天宣布發布 Visual Studio Code 七月更新(v1.59),其中包括幾個新功能,包括 Live HTML Preview 擴展 w/JS 調試支持、測試運行程序的本地支持、跨窗口拖放終端的能力等等。
微軟中國 MSDN 表示,歡迎使用 2021 年 7 月版的 Visual Studio Code。我們希望您會喜歡此版本中的許多更新與改進,以下是其中的一些亮點:
* 擴展視圖的改進 - 豐富的擴展詳細信息懸停,新的運行狀態標簽頁。
* 設置編輯器驗證 - 快速查找到對象設置的編輯錯誤。
* 拖放終端 - 將終端跨窗口移動到編輯器和面板區域。
* 擴展的主題定制 - 一次定制多個顏色主題。
* Jupyter 筆記本的內建支持 - 直接在 VS Code 中打開 .ipynb 文件。
* 筆記本 UI 的改進 - 顯示折疊單元格的第一行,每個單元格的撤消/重做。
* 測試 API 的最終確定 - 原生支持 VS Code 中使用測試資源管理器運行測試。
* 調試反匯編視圖預覽 - 在 VS Code 中顯示反匯編的 C++ 代碼。
* 實時預覽擴展 - VS Code 中的實時的 HTML 預覽,支持 JavaScript 調試。
* 遠程 - 容器 devcontainer CLI - 用于開發容器的命令行界面。
如果您想在線閱讀這些發行說明,請訪問 code.visualstudio.com 上的更新。
更多關于 VS Code 的資料請訪問微軟 MS Learn 平臺:http://aka.ms/vscodelearn
內部搶先版:想更先一步體驗新功能嗎?您可以下載每晚的 Insiders 版本,并在最新更新可用時立即試用。
code.visualstudio.com:
https://code.visualstudio.com/
更新:
https://code.visualstudio.com/updates/v1_58
http://aka.ms/vscodelearn:
https://docs.microsoft.com/zh-cn/users/nathanxue/collections/3jxsyzg0epdj3?WT.mc_id=VSCode_457601
Insiders:
https://code.visualstudio.com/insiders/
擴展插件:
改進了調整大小后的擴展視圖。在下面的動圖中,你可以看到默認寬度的擴展視圖顯示了所有詳細信息(以前未顯示圖標、評分和安裝計數)。當它縮小時,會顯示較小的擴展圖標,當其寬度進一步減小時,圖標和評分將被隱藏。
主題:GitHub Light
擴展視圖現在會顯示自定義懸停信息。這個豐富的懸停包括擴展的完整描述和其他有用的信息,例如為什么禁用或推薦擴展。
主題:GitHub Light
您現在可以在插件面板中看到更多的插件運行狀態,例如其激活時間、是否在啟動時激活,以及擴展編輯器中新引入的 運行時狀態 選項卡中是否生成了任何警告或錯誤。當然,你也可以懸停在插件試圖上看到部分的運行狀態信息。
主題:GitHub Light
插件面板的詳細信息標簽頁現在會顯示分類信息,資源鏈接,和諸如插件發布時間和更新時間的其他信息。選擇某個分類會顯示當前分類下的所有插件。
主題:GitHub Light
GitHub Light:
https://marketplace.visualstudio.com/items?itemName=GitHub.github-vscode-theme
設置編輯器:
設置編輯器現在支持對象驗證功能。驗證會涵蓋直接編輯 JSON 文件時可能引入的類型錯誤。
非編輯模式下,數組設置現在具有了拖放功能的支持。
此外,將 uniqueItems 屬性設置為 true 的枚舉數組設置現在僅顯示剩余選項,而不是下拉列表中的所有選項。
設置編輯器現在還支持多行字符串設置,其中值呈現在多行文本區域而不是單行輸入框中:
擴展的主題自定義語法:
顏色自定義設置允許用戶自定義當前主題的顏色:
workbench.colorCustomizations
editor.tokenColorCustomizations
editor.semanticTokenColorCustomizations
以下語法可以用來一次自定義多個主題的顏色:
您可以列出多個主題,或者,在名稱的開頭或者結尾使用 * 通配符來選取多個主題。
Jupyter 筆記本文件的支持:
本月,我們把支援 *.ipynb 文件的代碼從 Jupyter 筆記本 插件吸收為了內建插件。這意味著你現在可以在一個全新安裝的 VS Code 環境中得到 Jupyter 筆記本的原生支持。你甚至都不用安裝 Jupyter 的插件。需要注意的是,如果你想要執行 ipywidgets 或者其他復雜渲染類型的代碼單元或者查看運行結果時,你依然需要完整安裝 Jupyter 插件。
Jupyter 筆記本:
https://marketplace.visualstudio.com/items?itemName=ms-toolsai.jupyter
筆記本布局的改進:
我們在本次迭代中對筆記本布局進行了一些改進:
我們現在將會在折疊時渲染代碼單元的第一行。
當窗口寬度不足以呈現所有主要操作時,筆記本編輯器工具欄上的操作將移至溢出區。
notebook.undoRedoPerCell 的默認值現在更改為 true。
我們還更新了代碼單元格的默認樣式,顯示背景顏色以幫助區分單元格。主題可以使用 notebook.cellEditorBackground 來自定義這個顏色。
最后,您現在可以使用 notebook.globalToolbarShowLabel 設置在筆記本工具欄上切換文本標簽:
“復制相對路徑”配置路徑分隔符:
在調用“復制相關路徑”操作時,新設置 explorer.copyRelativePathSeparator 允許顯式設置使用路徑分隔符。以下為可用選項:
Auto(默認) - 使用操作系統特定的路徑分隔符
/- 使用斜線作為路徑分隔符
\ - 使用反斜杠作為路徑分隔符
跨編輯器組共享視圖狀態:
添加了一個新設置 workbench.editor.sharedViewState 以配置編輯器視圖狀態(例如,編輯器中的滾動位置)在編輯器組之間共享的方式。
默認情況下,此設置被禁用以保留當前設置。如果您在靠邊打開編輯器并稍后關閉該編輯器組,只是為了再次打開編輯器到靠邊,則不會恢復視圖狀態,因為您正在打開一個新的編輯器組。但是,當您啟用此設置時,除非為編輯器組找到更具體的視圖狀態,否則將在所有編輯器組中保留并使用最新的編輯器視圖狀態。
在不同的折疊范圍之間切換:
以下的新指令可以將光標位置設置為相應的折疊:
轉到下一個折疊 (editor.gotoNextFold)
轉到上一個折疊 (editor.gotoPreviousFold)
轉到父級折疊 (editor.gotoParentFold)
這些命令目前沒有默認鍵綁定,但是你可以通過以下方法添加自己的鍵盤快捷鍵:
** 首選項:打開鍵盤快捷鍵 ** (kb (workbench.action.openGlobalKeybindings))
自動折疊 Import 語句:
通過設置 editor.foldingImportsByDefault 來自動折疊 Import 語句。
當文件被打開后,折疊的狀態將會被保存。
TypeScript,JavaScript,Java,C#,C++ 和其他具備折疊范圍提供程序的編程語言都支持這項新功能。注:折疊范圍提供程序特指將 Import 語句標注為 FoldingRangeKind.Imports 的提供程序。
選擇項的種子搜索字符串:
Find Widget 設置 editor.find.seedSearchStringFromSelection 已支持從非空選擇中播種搜索字符串。默認情況下,當顯示小部件時,編輯器將使用以下兩項作為搜索關鍵詞:1. 選擇項。2. 空選擇周圍的單詞。
內聯建議的改進:
我們改變了內聯建議的呈現方式。這不僅修復了許多錯誤,而且還使自動換行識別了內聯建議。
此外,現在支持了非尾隨位置的多行內聯建議。
嵌入提示的改進:
我們還改變了嵌入提示的呈現方式。通過使用與內聯建議相同的機制,嵌入提示現在也被用于自動換行。
這種機制還實現了嵌入提示周圍的單獨光標停靠。
在窗口之間拖拽終端:
現在,您可以任意地從標簽頁或一個窗口的編輯區域,拖拽終端到標簽頁,編輯區域,或者另一個窗口的面板。
子進程跟蹤和關閉警告:
當用戶嘗試關閉一個有子進程的終端時,terminal.integrated.confirmOnExit 和新的設置 terminal.integrated.confirmOnKill 會警告用戶。默認情況下,這僅影響編輯器區域中的終端,但用戶可以配置為顯示所有的(面板區域中)終端警告。
設置所提供的終端配置文件為默認:
現在用戶可以將插件所提供的終端配置文件設為默認的配置文件。
下劃線和刪除線支持:
終端現在支持下劃線和刪除線屬性。例如,用可以可以配置 git 來使用這些新屬性:
主題: Sapphire
上述的例子使用了下列 .gitconfig 參數:
配置 git:
https://git-scm.com/docs/git-config#Documentation/git-config.txt-color
Sapphire:
https://marketplace.visualstudio.com/items?itemName=Tyriar.theme-sapphire
編輯區域靠邊創建終端:
現在,用戶可以在活動編輯區域使用新指令 workbench.action.createTerminalEditorSide 來創建一個靠邊新的終端。
活動終端標簽頁指示器:
主題現在可以使用主題鍵 terminal.tab.activeBorder 設置垂直線的顏色,用以指示活動的終端選項卡。
如果沒有設置 terminal.tab.activeBorder,顏色將回退到 tab.activeBorder。
禁用終端標簽頁動畫圖標:
terminal.integrated.tabs.enableAnimation 會禁用終端標簽頁動畫圖標。如果是針對任務而不是微調器,播放按鈕會被使用:
改進了編輯器標題區域內的 播放/調試 按鍵:
在 2 月的版本中,我們引入了一個下拉按鈕,用以在編輯器標題區域的中央(緊湊)位置對運行和調試命令進行分組。根據一些用戶反饋,我們嘗試通過記憶上次執行的操作來改進下拉按鈕。下拉按鈕現在將會擁有兩個單擊區域,一個用于默認動作(左),另一個用于下拉(右),其中,所選運行操作將被記憶并存為新的默認值。
請注意:
如果只有一個運行或調試操作,則會省略下拉菜單。
如果有多個運行或調試操作,所有操作都會出現在下拉菜單中,并且默認操作設置為下拉菜單中的第一個操作(前提是沒有記住的操作)。
VS Code 重新啟動時,會為特定工作區保留默認操作;它不會為編輯器內容保留。
2 月的版本:
https://code.visualstudio.com/updates/v1_54#_limits-for-editor-title-menu-and-run-submenu
實時預覽:
實時預覽擴展插件本月出現了一些令人興奮的新功能!這包括:
內建 JavaScript 調試器兼容性的外部預覽。
請使用 `Live Preview: Show Debug Preview` 來嘗鮮使用!
對嵌入式瀏覽器的改進,例如“在頁面中查找”的支持和快速訪問 `webvivew` DevTools。
文件系統監視自動生成文件。
期待更多!
要查看有關本月進度的更多詳細信息,請參閱擴展的發行說明。
主題:GitHub Dark
實時預覽擴展插件:
https://marketplace.visualstudio.com/items?itemName=ms-vscode.live-server
發行說明:
https://github.com/microsoft/vscode-livepreview/blob/main/release_notes/july-2021.md
GitHub Dark:
https://marketplace.visualstudio.com/items?itemName=GitHub.github-vscode-theme
GitHub 拉取請求和問題:
GitHub 拉取請求和問題 擴展插件的工作仍在繼續,它允許您響應、創建和管理拉取請求和問題。本月重點:
對問題的“開始工作”進行了擴展,讓您可以處理當前打開的存儲庫之外的問題。
要了解所有新功能和更新,您可以查看 0.29.0 版擴展的完整變更日志。
GitHub 拉取請求和問題:
https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github
0.29.0 版擴展的完整變更日志:
https://github.com/microsoft/vscode-pull-request-github/blob/main/CHANGELOG.md#0290
Jupyter:
Jupyter 擴展插件的工作仍在繼續。要了解所有的新功能和更新,您可以查看 7 月版本的完整更新日志。
Jupyter:
https://marketplace.visualstudio.com/items?itemName=ms-toolsai.jupyter
7 月版本的完整更新日志:
https://github.com/microsoft/vscode-jupyter/blob/main/CHANGELOG.md#202189-3-august-2021
互動窗口:
Jupyter 交互窗口提供了另一種構建和使用 Jupyter 筆記本的方法,使用文本文件而不是筆記本界面。上個月,我們預覽了 Jupyter 交互式窗口的升級版本,現在我們提供了具有更深入的工作臺集成,包括對主題的支持、自定義鍵綁定、片段、與擴展的兼容性等!非常感謝我們的用戶通過 GitHub 問題提供有關預覽體驗版的反饋。內置交互窗口現在已經成為了 1.59 版本中的默認界面。之前的界面在 "jupyter.enableNativeInteractiveWindow": false 后將仍然可用,并會在即將發布的版本中刪除。我們期待您的反饋!
您的反饋:
https://github.com/microsoft/vscode-jupyter/issues
逐行運行:
我們一直致力于支持 Jupyter 筆記本中的“逐行運行”功能。此功能本質上是一種簡化的調試模式,可讓您逐行執行單元代碼,而無需任何復雜的調試 UI。這依然是實驗性的,您可以通過設置 "jupyter.experimental.debugging": true,在您選擇的內核中安裝 ipykernel 的第 6 版,然后選擇單元格工具欄中的“按行運行”按鈕來嘗鮮一下。
遠程容器 devcontainer CLI:
遠程 - 容器 擴展適用于在 VS Code 中使用 Docker 容器。它現在包含 devcontainer 命令行界面,讓您可以輕松地打開容器中的文件夾 (devcontainer open) 或者構建開發容器映像 (devcontainer build)。
您可以在 遠程開發 發行說明中了解新的功能和錯誤修復。
遠程 - 容器:
https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers
遠程開發:
https://github.com/microsoft/vscode-docs/blob/main/remote-release-notes/v1_59.md
無標題文件的自動語言檢測:
我們很高興地宣布無標題文件的自動語言檢測的初始預覽版,它使用機器學習來檢測您正在編碼的語言并自動設置無標題文件的語言模式。此功能利用了開源 ML 庫 Tensorflow.js 和 GitHub 用戶 @yoeo 來自 Guesslang 的 ML 模型。
在此版本中,該功能將默認關閉,但我們計劃將其設為下一次迭代版本的默認設置。如果您想要啟用它,請應用以下設置:
```json "workbench.editor.untitled.experimentalLanguageDetection": true ``` "workbench.editor.untitled.experimentalLanguageDetection": true
舉個例子,您可以打開一個無標題文件并將一段代碼粘貼到您的編輯器中。
以下是一段自動識別的 Python 代碼段:
主題:Panda
此外,您可以通過打開語言選擇器查看正在檢測的語言。
主題:Panda
注意:如果語言檢測結果不夠確信,那么您將保持當前的語言模式,語言選擇器中不會顯示任何結果,直到語言檢測結果更有把握。
該設置還允許您提供語言覆蓋,可用于指定您不想自動關閉的語言模式。
以下的例子展示了如何關閉 .md 文件自動檢測:
在您編輯無標題的 Markdown 文件時,自動語言檢測功能 * 不會 * 運行。但是,如果您正在修改任何其他類型的無標題文件,自動語言檢測功能 * 將 * 會檢測這些文件的內容。
我們已經將與 ML 模型交互的代碼分離并合并到它自己的代碼庫中,作為 npm 包發布,該包存在于 vscode-languagedetection 存儲庫中。
請讓我們知道無標題文件的自動語言檢測功能是否幫助到了您的日常工作!
Tensorflow.js:
https://www.tensorflow.org/js/
@yoeo:
https://github.com/yoeo
Guesslang:
https://github.com/yoeo/guesslang
Panda:
https://marketplace.visualstudio.com/items?itemName=tinkertrain.theme-panda
vscode-languagedetection:
https://github.com/Microsoft/vscode-languagedetection
TypeScript 4.4:
此版本包括對 TypeScript 4.4 版本的支持。您可以在 TypeScript 博客上閱讀有關 TypeScript 4.4 中新語言功能和改進的更多信息。一些工具亮點:
在 JavaScript 和 TypeScript 文件中嵌入參數名稱和類型的提示。
純 JS 文件中的基本拼寫建議。只有當我們對錯誤和修復有把握時才會顯示這些。
要開始使用 TypeScript 4.4 內測版本,請安裝 TypeScript Nightly 擴展。
如果您在使用 TypeScript 4.4 時遇到任何錯誤,請分享您的反饋并告訴我們。
TypeScript 博客:
https://devblogs.microsoft.com/typescript/announcing-typescript-4-4-beta/
TypeScript Nightly 擴展:
https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-typescript-next
反匯編試圖:
感謝微軟 C++ 團隊貢獻的大量代碼,我們很高興在這個里程碑版本中包括了 ** 反匯編視圖 ** 的預覽功能。
反匯編視圖可以從編輯器的上下文菜單中打開,用以顯示活動堆棧幀的反匯編源碼,它支持單步執行匯編指令,并且可以在單個指令上設置斷點。
反匯編視圖僅在活動的調試會話中可用。注意,底層調試擴展插件也需要有相應的支持。
目前,只有 C++ 和 Mock Debug 可以支持反匯編視圖。
從技術角度而言,VS Code 的反匯編視圖實現了 DAP (Debug Adapter Protocol) 協議另外四個功能:
disassembly 請求,用以提供基于內存位置的反匯編源碼。
堆棧幀上的 instructionPointerReference 屬性。
步進請求的 granularity 屬性。
指令斷點和 setInstructionBreakpoints 請求。
貢獻的大量代碼:
https://github.com/microsoft/vscode/pull/125737
C++:
https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools
Mock Debug:
https://marketplace.visualstudio.com/items?itemName=andreweinand.mock-debug
測試 API:
去年秋天,我們開始在 VS Code 中添加對運行測試的原生支持,本月,第一組與測試相關的 API 已經交付。與之前的擴展插件相比,這些 API 提供了更大的靈活性、更好的性能和更豐富的用戶體驗。查看有關編寫測試擴展的指南以深入了解。
主題:
測試資源管理器 UI 插件的現有用戶可以通過將 testExplorer.useNativeTesting 設置為 true 來獲得原生體驗。但是,該轉換是基于測試資源管理器 UI 擴展現有 API,因此不包括諸如豐富差異之類的一些功能。
Java 擴展包中包含的 Microsoft Java 測試運行器是最早采用測試 API 的擴展之一 。
編寫測試擴展的指南:
https://code.visualstudio.com/api/extension-guides/testing
測試資源管理器 UI:
https://marketplace.visualstudio.com/items?itemName=hbenl.vscode-test-explorer
Java 擴展包:
https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack
Microsoft Java 測試運行器:
https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-test
新建文件菜單的貢獻點:
有助于創建新文件編輯器的擴展(例如筆記本或自定義編輯器)現在可以向新的 文件/新文件 菜單貢獻點貢獻命令。可以從歡迎頁面或文件菜單中的“新建文件...”項目訪問此菜單。
豐富狀態欄懸停:
狀態欄項目現在支持豐富的懸停,包括鏈接和圖標 StatusBarItem.tooltip: string | IMarkdownString
* If `MarkdownString.supportThemeIcons` is true, you can use icons with the `$(iconName)` syntax.
* If the `MarkdownString` is trusted, you can also add command links. Syntax: `([test](command:vscode.newWindow))`
如果 MarkdownString.supportThemeIcons 設置為 true,您可以使用帶有 $(iconName) 語法的圖標
如果 MarkdownString 受信任,還可以添加命令鏈接。語法:([test](command:vscode.newWindow))
狀態欄警告顏色:
表示警告的狀態欄項目可以使用新添加的顏色 statusBarItem.warningBackground 和 statusBarItem.warningForeground。
沒有 additionalProperties 的對象設置:
對象設置必須將 additionalProperties 設置為 false,以便在設置編輯器中支持對象。否則,設置編輯器會解讀為復雜設置(不規律的設置),并將用戶定向到設置 JSON 文件。
多行字符串設置:
要在設置編輯器中添加多行字符串設置的支持,請將 "editPresentation": "multilineText" 作為鍵值配對添加到字符串設置中。將字符串設置更改為多行設置將導致設置編輯器在多行文本區域(而非單行輸入框中)呈現設置值。
更新的 Codicons:
我們已經添加了下列新圖標到 codicon 庫中:
azure
compass-active
compass-active
compass-dot
compass
debug-all
debug-coverage
git-pull-request-closed
git-pull-request-draft
issue-draft
layers-active
layers-dot
layers
codicon:
https://code.visualstudio.com/api/references/icons-in-labels
文本文檔更改原因:
當事件 workspace.onDidChangeTextDocument 被觸發時,事件對象的新屬性 reason 會告知用戶文本更改的原因是撤消或重做操作。
語言服務器協議:
語言服務器協議的下一個新版本以及對應的 npm 模塊已經發布。3.17 版本包含了一個關于完成項標簽詳細信息的新提案,該提案符合 VS Code 本身的最新變化。
語言服務器協議:
https://microsoft.github.io/language-server-protocol/
3.17 版本:
https://microsoft.github.io/language-server-protocol/specifications/specification-3-17/
最終確定“writeMemory”請求和“memory”事件提案:
writeMemory 請求已經完成,現在可以在 Debug Adapter Protocol 的 1.48 版和與之相對應的 npm 模塊中使用。如果調試適配器具有 supportsWriteMemoryRequest 功能,客戶端可以使用 writeMemory 請求將字節寫入給定位置的內存。
memory 事件有一個新的提案,將在下一個里程碑中添加到 DAP。
Debug Adapter Protocol:
https://microsoft.github.io/debug-adapter-protocol/
新的提案:
https://github.com/microsoft/debug-adapter-protocol/issues/194#issuecomment-886687894
每個里程碑版本都附有新提議的 API,擴展插件的作者們可以試用它們。我們期待您的反饋。如果您想要嘗鮮提議的新 API,請完成以下步驟:
您必須使用 Insiders 版本,因為提議的 API 經常被修改
你必須在你的擴展的 package.json 文件中加入這一行:"enableProposedApi": true
將最新版本的 vscode.proposed.d.ts 文件復制到項目的源位置
您將不能使用建議 API 發布擴展插件。因為新的版本可能會有重大變化,我們需要保證現有的擴展插件可以被繼續使用。
vscode.proposed.d.ts:
https://github.com/microsoft/vscode/blob/main/src/vs/vscode.proposed.d.ts
isDefault 用于 TaskGroup:
group 屬性存在于 tasks.json 文件中定義的任務上,也通過任務 API 公開。group 屬性有一個 isDefault 屬性,該屬性直到現在在 API 中都不可用。該提案將 isDefault 屬性公開為 TaskGroup 上的只讀屬性,以便擴展可以讀取哪個任務是組的默認任務,但不能通過為組設置默認值來覆蓋用戶配置。
用于 AuthenticationGetSessionOptions 的 forceRecreate
到目前為止,用于獲取身份驗證會話對象的 getSession API 從來沒有能力要求用戶需要再次登錄。然而這對于使用 SAML/單點登錄 (SSO) 體驗的 GitHub 等身份驗證服務是必需的,其中訪問令牌最終會在 SSO 會話到期時失去對資源的訪問權限。該提案為 AuthenticationGetSessionOptions 添加了另一個名為 forceRecreate 的屬性,允許您要求用戶再次登錄。向用戶顯示類似于您指定 createIfNone 時顯示的模式體驗。
基于 iframe 的 webviews 現在在桌面上隨處可見:
本月我們完成了從 Electron 的 webview 標簽元素過渡到基于普通 <iframe> 元素的 webview 。這更好地協調了 VS Code 的 webviews 跨桌面和 web 的實現,也讓我們刪除了很多現在冗余的代碼。
Electron 的 webview 標簽:
https://www.electronjs.org/docs/api/webview-tag
Electron 13 更新:
在這個里程碑版本中,我們完成了將 Electron 13 捆綁到 VS Code 的實驗,這要感謝所有參與 Insiders 測試和自托管的參與者。這是 Chromium 91.0.4472.124 附帶的主要 Electron 版本。此版本的 Node.js 版本沒有變化,它仍然是 v14.16.0。
Electron 沙盒支持的進展:
隨著我們準備讓 VS Code 工作臺啟用 Electron 的沙盒功能,我們希望在 linux 上啟用混合沙盒模式,且不在分布式軟件包 deb、rpm、snap、tar 存檔中捆綁 cli 參數 --no-sandbox。Chromium 在 linux 上有一個多層沙盒模型。如果 Chromium 無法將命名空間沙盒用于第 1 層,它將嘗試通過幫助程序 chrome-sandbox 來使用 setuid 沙盒。要使 setuid 二進制文件工作,它需要滿足以下條件:
沙箱二進制文件必須可由 Chromium 進程執行
它必須是 SUID 并且可以被其他人執行
我們能夠為 deb 和 rpm 包保留這些條件。目前無法獲得 snap 的這些權限,我們有以下跟蹤問題 https://github.com/microsoft/vscode/issues/127140。
至于其他使用 tar 存檔的應用程序,如果應用程序無法使用命名空間沙盒(這在容器內運行時可能會發生)它將失敗并顯示以下錯誤
FATAL:setuid_sandbox_host.cc (158)] 找到了 SUID 沙盒助手二進制文件,但沒有正確配置。而不是在沒有沙盒的情況下運行,我現在正在中止程序。您需要確保 chrome-sandbox 由 root 用戶擁有并且模式為 4755。
如果發生這種情況,您可以使用以下兩個選項之一來使其正常工作:
修復 setuid helper 權限問題
使用 --no-sandbox 標志運行
沙盒:
https://www.electronjs.org/docs/tutorial/sandbox
linux 上有一個多層沙盒模型:
https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux/sandboxing.md
setuid 沙盒:
https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux/suid_sandbox.md
煙霧測試的一些改進:
我們一直為每個構建版本運行一套完整的煙霧測試。我們測試打開 VSCode(桌面和 Web)并執行一堆 UI 元素以確保正確的功能。這個里程碑版本中我們在這個基礎上投入了更多資源,從而使我們能夠從最終計劃中移除手動的煙霧測試。
煙霧測試現在可以在所有平臺(macOS、Linux 和 Windows)上運行。最重要的是,我們已經實現在每次代碼提交時自動運行煙霧測試,從而我們可以及時地發現 VS Code 新版本可能引入的軟件錯誤。
最后,感謝我們用于自動化 Web 冒煙測試的 Playwright 庫,我們采用了他們的跟蹤工具,這使得我們可以查看并且重復運行失敗的煙霧測試。
Playwright:
https://github.com/microsoft/playwright
跟蹤工具:
https://playwright.dev/docs/next/trace-viewer/
學習資料
http://aka.ms/vscodelearn
http://aka.ms/vscodelearn:
https://docs.microsoft.com/zh-cn/users/nathanxue/collections/3jxsyzg0epdj3?WT.mc_id=VSCode_457601
重大修復
[26425](https://github.com/microsoft/vscode/issues/26425):沒有更改時不應顯示“打開更改”按鈕
[100815](https://github.com/microsoft/vscode/issues/100815):外部終端在連接到遠程 WSL 時中斷
[106981](https://github.com/microsoft/vscode/issues/106981):當窗口縮放設置為 -1 時,終端光標重影
[127959](https://github.com/microsoft/vscode/issues/127959):調試程序暫停時將打開調試窗格
[129059](https://github.com/microsoft/vscode/issues/129059):設置編輯器中的對象小組件不呈現說明
[129070](https://github.com/microsoft/vscode/issues/129070):無法通過僅按“確定”按鈕更正下拉列表設置值
[129415](https://github.com/microsoft/vscode/issues/129415):無法在單一文件模式下運行用戶任務
前來說開源代碼編輯器&IDE方面,VSCode可以是一枝獨秀,是目前使用最廣泛的工具。VSCode中大量擴展可以讓我們的開發生活越來越方便高效。本文蟲蟲就可以大家介紹一下當前最流行的VSCode插件擴展。
ESLint是OpenJS基金會下的熱門JavaScript開源庫。該庫也提供了VSCode擴展,可以無縫的集成到VSC中。它可以用來檢測錯誤并自動修復它們或提供手動修復它們的選項。
這些錯誤是由語法錯誤或違反編程風格指南產生的。編程風格可以按照企業的實際情況設置。
ESLint易于使用,文檔豐富,而且可高度定制。
星級:5
下載次數:1817萬
源碼倉庫: github /Huachao/vscode-restclient
Coding過程中代碼格式時常會弄亂,比如:錯誤地縮進了JS代碼、每行寫了超過80個字符,等等。不光影響美觀和可讀性,對于處女座的碼農來說這也是個巨大的障礙。
有了Prettier,它可以幫我們搞定這一切。它負責將代碼格式化為優雅、人性可讀的格式。包括正確縮進代碼,如果代碼太長則將代碼分解,是否與添加分號保持一致等等。
ESLint和Prettier可以完美地協同工作,幫助團隊提供與JavaScript樣式指南保持一致的、對可維護性非常有用的。
星級:4
下載次數:1799萬
源碼倉庫: github /prettier/prettier-vscode
GitLens插件增強了VSC中內置的Git功能。提供git更改、作者和更改時間的詳細信息。
這意味著在編碼時,可以在代碼旁邊看到git更改的詳細信息。懸停時,它會為提供有關該代碼行的更多git信息和操作。
這些操作包括暫存更改、提交更改、推送提交等等。 你真的不需要帶有這個擴展的Git CLI。 此外,您可以輕松導航和修改任何文件的git歷史記錄(向后和向前)。
星級:5
下載次數:1263萬
源碼倉庫: github/eamodio/vscode-gitlens
使用Code Runner可以很輕松地在VSC中運行代碼并在VSCode 輸出(終端窗口)。該擴展支持超過41種流行語言的代碼,包括 C、C++、Java、JS、PHP、Python、Perl、Go 和Rust等。
Code Runner可以運行文件中的所有代碼,也支持按需運行選定的代碼。比如:可以選擇一個函數并僅運行該函數。
運行選定代碼時,應確保選定代碼不依賴于未選定代碼,否則可能導致錯誤。
星級:5
下載次數:1087萬
源碼倉庫: github /formulahendry/vscode-code-runner/
GitHub PR and ISSues可幫助直接在VSCode中查看和管理GitHub PR和問題。
有了它,可以輕松地從GitHub列出問題和拉取請求。可以評論問題、開始處理問題、查看和驗證拉取請求等等。
無需要打開GitHub Web頁面來管理拉取請求或解決問題,所有這些都可以在VSCode中完成。
星級:3
下載次數:470萬
源碼倉庫: github/Microsoft/vscode-pull-request-github
Indent Rainbow可實現代碼縮進著色。這對于JS和Python等語言非常有用。每個級別都有不同的顏色,可以輕松判斷的縮進級別。
該擴展是可定制的,可以輕松更改每個級別的顏色,可支持四種以上顏色。
星級:5
下載次數:281萬
源碼倉庫: github/oderwat/vscode-indent-rainbow
DotENV 擴展可以突出顯示的.env文件,使其更加易讀而且防止錯誤。這對于Node 開發人員設置環境變量時非常有用。
這個擴展為評論(它啟用評論)、字符串、數字、屬性、關鍵字等提供了不同的顏色。在VSCode中這些默認都是全白的,但這個擴展改變了這一點。它基本上使.env文件看起來像另一種具有語法突出顯示的語言文件。
星級:5
下載次數:234萬
源碼倉庫: github/mikestead/vscode-dotenv/
REST Client 可以用來操作和管理HTTP請求并直接在編輯器中查看響應。
使用該擴展,可以管理HTTP請求(GET、POST、DELETE、PUT 等),這是使用API 的一個很酷的功能,請求響應結果可以輕松保存到本地磁盤。
它還支持 GraphQL以及身份驗證。
星級:5
下載次數:210萬
源碼倉庫: github /Huachao/vscode-restclient
TailwindCSS是一個開源擴展,可以用來極大限度地提高工作效率。
我們知道Tailwind主要是關于類的,這個擴展提供了TailwindCSS中所有類名的快速自動完成。使用此擴展程序,可以通過將鼠標懸停在特定類名稱上來查看其樣式。
Tailwind CSS還為樣式表或標記中的錯誤提供linting。所以如果錯誤地使用了一個類名,它就會提醒你。
星級:5
下載次數:86萬
源碼倉庫: github /tailwindlabs/tailwindcss-intellisense
VSCode-Icons可根據文件夾/文件的名稱或基于文件的擴展名提供交互式和好看的文件/文件夾圖標。
使用具有不同圖標的不同類型的文件夾或文件,可以在項目中無縫導航,而無需一直閱讀文件夾或文件的名稱。這需要更輕松、更快速的導航,同時使編輯器的文件列表更加美觀且更易用。
本文我們介紹了一些優秀的VSCode擴展。當然這只是VSCode龐大生態系統中的冰山一角,更多更好的插件需要大家去挖掘和開發。
覺比特幣隔三差五就要來個分叉。但什么是分叉呢?我們能從中獲利嗎?分叉會有風險嗎?你通過分叉拿到免費的幣了嗎?我們一起來聊聊吧。
時間回到2017年8月,第一個由比特幣分叉產生的數字貨幣誕生了:比特幣現金。然而,從那以后,相繼出現了很多比特幣的分叉幣,比如比特幣黃金、比特幣鉆石。大部分人還不知道這些分叉究竟意味著什么,分叉是如何發生的,自己能不能從中獲利。
所以說,什么是分叉呢?
分叉基本上是對當前比特幣代碼(或協議)的更改,換句話說,有人對比特幣的規則進行了改變。想象一下,你正和來自世界各地成千上萬的人一起玩游戲,這個時候有人說,"要不我們把規則改了吧。"通常來講,為了讓游戲保持完整,需要每個人就規則的改變達成共識。規則改變之后,不影響游戲的正常運行。但是如果大家沒有就這個改變達成共識,那就會產生出兩種不同版本的游戲,一個運行原有的規則,另一個運行新的規則。換句話說,游戲產生了分叉,類似于道路的分叉,同樣也會發生在比特幣代碼中。
通常,當分叉發生時,你將會擁有一個"原始比特幣"和一個"新比特幣" 。舉個例子,比特幣現金把區塊大小從1 MB更改為8 MB,因此每個塊可以處理更多筆交易。
所以有一些人支持這次改變,他們從比特幣網絡轉移到了比特幣現金網絡。
也有人想維持原有的規則,繼續使用"原始比特幣"(所以就產生了分叉)。
當然,關于比特幣分叉我解釋的比較簡單,因為每一次分叉各不相同。
有軟分叉,新版本可以和舊版本很好地兼容;
也有硬分叉,產生出一個完全不同的新幣。
大家目前聽說的所有的比特幣分叉都是硬分叉。
為什么我們要關心分叉呢?有幾點原因:
首先,你可能會覺得新規則和新幣比原來的好;
其次,分叉可能對比特幣社區、比特幣的應用,甚至比特幣的價格產生影響,之后我們會討論這個影響。
最后,你希望通過出售分叉出的新幣從中獲利,因為每個比特幣的持有者都能獲得這些新分叉幣。
等一下。
我能白拿幣?
是的,你沒有聽錯。
回到剛剛說的游戲。想象一下,你的游戲已經運行了很長時間,你已經攢了很多積分。現在有人想改變規則,但不希望玩家們失去已有的積分,所以當新游戲開始運行時,每個人都會獲得相同數量的新積分。比如,你在原來的游戲里有150個積分,有了新游戲以后你會再獲得新游戲的150積分。如果你愿意的話,你可以同時玩兩個游戲。在這兩個游戲里,你都有150個積分。
我們來看一下這個情況如何應用于比特幣的。當分叉發生時,支持分叉的人們說,"我們不喜歡原有的規則,所以我們現在創造出一個新的來。"在分叉時持有比特幣的人就會擁有兩種"比特幣":"原始比特幣"和"新比特幣"。你自己決定去用哪個,或者兩個都用。意思是,當分叉發生的時候如果你持有一個比特幣,原來的一個比特幣還在你手里,并且你還可以領取一個運行在新規則上的"新比特幣",
是不是不太容易理解?記住一句話就行了:
當比特幣分叉發生時,任何比特幣持有者都能獲得相同數量的新幣。
新幣是不會自動到你地址上的,你需要自己去領取。所以,每個新分叉幣都有不同的領取機制,在這個視頻我們就不詳細講了。
你可以把成功領取到手的新幣囤著,或者賣掉。換句話說,通過分叉可以躺賺,因為你輕松拿到免費的幣后就可以在交易所出售了。這錢賺的是不是很容易呀?
隨著比特幣現金等一系列分叉幣的出現,分叉看起來似乎是一種改變比特幣原有路線的正當方式。不過在比特幣現金之后的分叉都比較類似,而且更多的是營銷噱頭而不是實際的意識形態變化。換句話說,如果有人覺得比特幣不夠好,他可以創造出一個全新的山寨幣,根本沒必要克隆比特幣。那他們之所以選擇分叉比特幣,主要有以下三點原因:
1. 營銷噱頭
比特幣分叉就是新的ICO,每個人都希望拿到免費的分叉幣,所以大家不遺余力地去分叉比特幣。當發行新幣時如何更好地吸引投資者們的關注呢?只要說,你在分叉比特幣,那就成了。
2. 開發者能大賺一筆。
一些分叉其實并沒有真的去復制比特幣之前的規則,規則改變的方式就是,開發者拿到大量新發行的新幣,等到新幣可以開始交易,他們就在市場上拋售。
3. 以分叉為名進行詐騙
詐騙者可以分叉比特幣來砸盤,甚至可以在用戶領取新分叉幣的過程中竊取用戶的比特幣。所以,領取分叉幣也是存在很大風險的。
那么,我們如何安全地領取新分叉幣呢?
首先,建議大家好好了解一下這個分叉幣,了解開發者團隊,了解他們的過往背景,了解他們規劃的進程如何,讀一下有關這個項目的文章。如果都沒問題的話,這個分叉幣就應該沒問題。不過呢,即使這次分叉是正當的,也并不意味著領取新幣就值。
領取新幣的過程通常很復雜,操作不熟練就有丟幣的風險。比如說,你有0.5個比特幣,那你就有資格擁有0.5個比特幣黃金,我不知道這0.5個比特幣黃金值不值得你冒風險。當然,這個由你自己來做決定。什么是比特幣分叉?通過分叉可以獲利嗎?
有一件很重要的事情:分叉幣必須要實現重放保護。基本上,網絡能將舊幣與新幣分開,在領取新分叉幣的時候不會將原始幣發送到新幣地址。
當你決定要領取分叉幣時,我建議你以一些正規錢包或資料的指南為準。記住一點,這是你自己的錢,只有你自己對此負責。一定要遵循一條規則:
在領取新幣前,你可以把比特幣轉到能生成新助記詞的新錢包,這樣,你就可以將比特幣丟失的幾率降低到幾乎為零。
希望大家現在對分叉的定義、運行方式、優勢以及潛在的問題有了一定的了解。
https://v.qq.com/x/page/t0925hnbvsc.html
原資料鏈接:
中文翻譯:Cobo錢包
*請認真填寫需求信息,我們會在24小時內與您取得聯系。