zulip terminal
Zulip Terminal 0.7.0
最近的更改|配置|熱鍵|常見問題解答|發展|教程
Zulip Terminal是Zulip的官方終端客戶端，提供基於文本的用戶界面（TUI）。
具體目的包括：
了解如何在我們的教程中使用Zulip終端。
我們認為客戶已經提供了相當穩定的中等優勢的日常用戶體驗。
當前的開發重點是改善更常用的日常用法方面，以減少用戶暫時切換到另一個客戶的特定功能的需求。
我們期望在長期內僅解決的當前限制包括：
終端客戶端當前與Zulip Web客戶端有許多有意的差異：
有關缺少功能支持的查詢，請查看常見問題（常見問題解答），我們的開放問題或在Zulip社區服務器上與用戶和開發人員聊天！
我們建議在專用的Python虛擬環境中安裝（請參閱下文）或使用自動選項（例如PIPX）
穩定的版本- 這些可在PYPI上作為包裝Zulip -Term提供
要安裝，請運行一個命令，例如： pip3 install zulip-term
最新（git）版本- 最新的開發版本可以從GIT存儲庫main分支機構安裝
要安裝，請運行一個命令： pip3 install git+https://github.com/zulip/zulip-terminal.git@main
我們還提供了一些示例碼頭，以在Docker/中構建Docker圖像。
由於運行所需的python 3.6+，以下內容應在大多數係統上工作：
python3 -m venv zt_venv （在當前目錄中創建一個名為zt_venv的虛擬環境）source zt_venv/bin/activate （激活虛擬環境；這假設一個類似bash的外殼）如果您打開另一個終端窗口（或註銷/重新啟動計算機），則需要在運行zulip-term之前再次運行上述步驟2 ，因為這會激活該虛擬環境。您可以在Python 3庫VENV文檔中閱讀有關虛擬環境的更多信息。
請注意，沒有自動上的系統，因此請跟踪與您的安裝版本相關的更新位置：
穩定版本
在升級之前，我們建議您檢查最近發行版的更改，以便您知道發行版之間有任何重要的更改。
現在，這些在Zulip Community Server（https://chat.zulip.org）上的＃emoins >終端發布主題中宣布，該主題在沒有帳戶的情況下可見。
如果您希望在宣布更新時收到電子郵件，歡迎您在此服務器上註冊一個帳戶，這將使您能夠啟用#Announce流的電子郵件通知（幫助文章，chat.zulip.org上的通知設置）。
您還可以在項目頁面上自定義GITHUB手錶設置以包含發行版。
PYPI提供了RSS發布供稿，以及其他各種服務跟踪此信息。
最新（git）版本
從main GIT分支安裝的版本也不會自動更新 - “最新”是指安裝點的狀態。
這也適用於其他來源或開發安裝（例如https://aur.archlinux.org/packages/python-zulip-term-git/）。
因此，使用上面的命令或與軟件包系統相關的一個（例如Arch）升級軟件包。
雖然main分支旨在保持穩定，但如果在兩個任意的“最新”版本之間升級，請注意，儘管我們的提交日誌應該非常可讀，但請注意不會匯總更改。
首次運行zulip-term時，它將在主目錄中尋找一個zuliprc文件，其中包含以登錄Zulip Server的詳細信息。
如果找不到此文件，則有兩個選擇：
zulip-term將提示您獲取服務器，電子郵件和密碼，並在該位置為您創建zuliprc文件
注意：如果您使用Google，github或其他外部身份驗證來訪問Zulip組織，那麼您可能沒有密碼集，目前需要創建一個用於使用Zulip-ensinal的密碼。
<Zulip server URL>/accounts/password/reset/的等效內容，以創建一個新的密碼（例如：https：//chat.zulip.org/accounts/password/password/reset/）。每次運行zulip-term時，都可以使用-c或--config-file選項指定替代zuliprc文件的路徑。 $ zulip-term -c /path/to/zuliprc
可以通過連接到該服務器的Web或桌面應用程序下載與您在特定Zulip服務器上的帳戶相對應的.zuliprc文件。在最近的版本中，可以在您的個人設置中的“帳戶和隱私”部分中找到，在API密鑰中，為“顯示/更改API密鑰”。
如果這是您唯一的Zulip帳戶，則可能需要將此文件移動並將其重命名為上面的默認文件位置，或將其重命名為更令人難忘的東西，您可以將其傳遞給---config-file選項。此.zuliprc文件為您提供了該用戶的所有權限。
可以從機器人部分下載類似的.zuliprc files ，但您已設置的任何機器人都可以下載。
注意：如果您的服務器使用自簽名的證書或不安全的連接，則需要手動向zuliprc文件添加額外的選項 - 請參閱Zulip Python模塊的文檔。
我們建議在第一次嘗試Zulip終端時使用-e或--explore選項（在探索模式下）運行zulip-term ，我們故意不將消息標記為讀取。嘗試跟隨我們的教程，以掌握事物。
zuliprc文件包含兩個部分：
[api]部分，其中包含連接到Zulip服務器所需的信息zulip-term配置的[zterm]部分在某些情況下，只能通過zulip-term自動生成第一部分的文件，或者您可以從服務器上的帳戶下載一個文件（請參見上文）。當您希望自定義zulip-term的行為時，可以在第二部分的一部分添加和調整。
下面的示例，帶有虛擬[api]部分內容，代表一個工作配置文件，所有默認兼容[zterm]值都沒有註釋，並帶有隨附的註釋：
[api]
[email protected]
key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
site=https://example.zulipchat.com
[zterm]
## Theme: available themes can be found by running `zulip-term --list-themes`, or in docs/FAQ.md
theme=zt_dark
## Autohide: set to 'autohide' to hide the left & right panels except when they're focused
autohide=no_autohide
## Exit Confirmation: set to 'disabled' to exit directly with no warning popup first
exit_confirmation=enabled
## Footlinks: set to 'disabled' to hide footlinks; 'enabled' will show the first 3 per message
## For more flexibility, comment-out this value, and un-comment maximum-footlinks below
footlinks=enabled
## Maximum-footlinks: set to any value 0 or greater, to limit footlinks shown per message
# maximum-footlinks=3
## Notify: set to 'enabled' to display notifications (see elsewhere for configuration notes)
notify=disabled
## Color-depth: set to one of 1 (for monochrome), 16, 256, or 24bit
color-depth=256
## Transparency: set to 'enabled' to allow background transparency
## This is highly dependent on a suitable terminal emulator, and support in the selected theme
## Terminal emulators without this feature may show an arbitrary solid background color
transparency=disabled
## Editor: set external editor command, to edit message content
## If not set, this falls back to the $ZULIP_EDITOR_COMMAND then $EDITOR environment variables
# editor: nano
注意：當
zulip-term啟動時，可以在命令行上指定這些配置設置中的大多數；zulip-term -h或zulip-term --help將提供全部選項列表。
請注意，WSL當前不支持通知；參見＃767。
以下命令在基於Debian的系統上安裝了notify-send ，也可以針對其他Linux系統找到類似的命令。
sudo apt-get install libnotify-bin
不需要附加包來啟用OS X中的通知。但是，要具有通知聲音，請設置以下變量（基於您的Shell類型）。聲音值（此處ping）可以是在/System/Library/Sounds或~/Library/Sounds上找到的.aiff文件中的任何一個。
bash
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.bash_profile
source ~/.bash_profile
ZSH
echo 'export ZT_NOTIFICATION_SOUND=Ping' >> ~/.zshenv
source ~/.zshenv
Zulip終端允許用戶通過Pyperclip將某些文本複製到剪貼板。該模塊利用了可能與操作系統隨附的各種系統軟件包。目前，“複製到剪貼板”功能僅可用於復制流信息彈出的流電子郵件。
在Linux上，此模塊使用xclip或xsel命令，該命令應該隨著OS隨附。如果這些命令都沒有安裝在您的系統上，請使用以下方式安裝任何一個命令：
sudo apt-get install xclip [Recommended]
或者
sudo apt-get install xsel
不需要其他包裝即可複製到剪貼板。
儘管Zulip Terminal旨在與任何Zulip服務器一起使用，但主要貢獻者位於Zulip社區服務器上的https://chat.zulip.org上， ＃Zulip-terminal流中的大多數對話。
歡迎您使用上面的鏈接查看該流中的對話，或註冊帳戶並與我們聊天 - 無論您是用戶還是開發人員！
我們的目標是保持Zulip社區友好，熱情和生產力，因此，如果參與，請尊重我們的社區規範。
這些是上面鏈接的社區規範的一個子集，它們與Zulip終端的用戶更相關：這些終端的用戶更有可能在文本環境中，在字符行/列中有限，並且存在於這一較小的流中。
更喜歡代碼塊中的文本，而不是屏幕截圖
Zulip Terminal支持下載圖像，但不能保證用戶能夠查看它們。
嘗試META + M查看示例內容格式，包括代碼塊
更喜歡靜音而不是常規提及 - 或避免完全提及
有了Zulip的主題，預期的接收者通常已經很清楚。經驗豐富的成員將在他們的時間允許的情況下出席 - 返回消息時會響應消息 - 其他成員可能會在此之前提供幫助。
（為那些不希望定期出席的人保存定期提及）
在輸入@_指定無聲提及之後
更喜歡修剪報價和回复文本僅對較長消息的相關部分 - 或避免完全引用
Zulip的主題通常會清楚您要回复哪些消息。用有限的行和文本列更難閱讀長消息，但是如果引用額外內容的整個長消息，這會惡化。
嘗試>引用選定的消息，在撰寫消息時刪除正常文本
更喜歡快速的表情符號反應，而不是簡單的簡短消息
反應佔用較少的空間，包括在Zulip終端中，尤其是當多個用戶希望以相同的情感回應時。
嘗試+在消息上切換大拇指（+1），或使用：搜索其他反應
Zulip Terminal是由令人敬畏的Zulip社區建造的。
要成為其中的一部分並為該代碼做出貢獻，請隨時在任何問題上工作或在＃Zulip-ensinal上提出您的想法。
對於提交結構和样式，請查看下面的“提交樣式”部分。
如果您是git的新手（或者！），則可以從Zulip Git指南中受益。貢獻時，重要的是要注意，我們使用面向折疊的工作流程。
一個簡單的教程可用於實現typing指標。按照它了解如何為Zulip-ensinal實施新功能。
當然，您可以在GitHub上瀏覽源和您下載的源樹中的源，並檢查源文件概述，以獲取有關當前如何安排文件的想法。
Zulip Terminal使用URWID在端子中渲染UI組件。 Urwid是一個很棒的庫，您可以通過使用Python渲染一個體面的終端UI。 URWID的教程是新貢獻者開始的好地方。
首先，在github上分叉zulip/zulip-terminal存儲庫（請參見如何），然後在本地克隆您的分叉存儲庫，用您的github用戶名代替your_username ：
$ git clone --config pull.rebase [email protected]:YOUR_USERNAME/zulip-terminal.git
這應該為當前目錄中的存儲庫創建一個新目錄，因此，使用cd zulip-terminal輸入存儲庫目錄並配置並獲取Zulip終端克隆叉子的上游遙控存儲庫：
$ git remote add -f upstream https://github.com/zulip/zulip-terminal.git
有關用於克隆和設置上游的命令的詳細說明，請參閱Zulip Git Guide的“ Get Zulip代碼”部分的步驟1。
有各種選項可用；我們正在探索每個人的好處，並會喜歡您使用或感覺最好的反饋。
請注意，每種情況中使用的工具通常相同，但以不同的方式調用。
以下命令應在存儲庫目錄中運行，該目錄由與上一節中類似的過程創建。
$ pip3 install --user pipenv
--python 3.6更具體） $ pipenv --three
$ pipenv install --dev
$ pipenv run pip3 install -e '.[dev]'
$ pipenv run gitlint install-hook
手動創建並激活虛擬環境；任何方法都應起作用，例如上述簡單安裝中使用的方法
python3 -m venv zt_venv （在當前目錄中創建一個名為zt_venv的VENV）source zt_venv/bin/activate （激活VENV；這假設一個類似Bash的外殼）安裝Zulip-期限，並具有開發要求
$ pip3 install -e '.[dev]'
$ gitlint install-hook
如果您已經make了：這是最新，最簡單的方法：
make （在當前目錄中的zt_venv中設置一個已安裝的虛擬環境）source zt_venv/bin/activate （激活VENV；這假設一個類似Bash的外殼）gitlint install-hook （連接gitlint提交掛鉤）建立了開發環境後，您可能會發現以下情況，具體取決於您的類型環境：
| 任務 | 製作和pip | PIPENV |
|---|---|---|
| 正常運行 | zulip-term | pipenv run zulip-term |
| 在調試模式下運行 | zulip-term -d | pipenv run zulip-term -d |
| 進行分析 | zulip-term --profile | pipenv run zulip-term --profile |
| 運行所有襯裡 | ./tools/lint-all | pipenv run ./tools/lint-all |
| 運行所有測試 | pytest | pipenv run pytest |
| 建立測試覆蓋報告 | pytest --cov-report html:cov_html --cov=./ | pipenv run pytest --cov-report html:cov_html --cov=./ |
如果使用PIP進行製作，則運行make將確保開發環境與指定的依賴關係保持最新，從而在Git和重新審進後很有用。
選擇您喜歡的文本編輯器或開發環境！
來源包括一個.editorconfig文件，該文件使許多編輯能夠自動配置自己以生成滿足項目最低要求的文件。有關編輯器支持，請參見https://editorconfig.org;請注意，如果您想使用此功能，則可能需要插件。
提交拉動請求（pr）或將更改推向現有拉的請求時，襯里和自動化測試（PYTEST）將在CI（GitHub操作）中自動運行。
但是，在計算機上運行這些檢查可以通過避免反復將代碼推向GitHub來加快開發的速度。實現此目的的命令已在上面的開發任務表中列出（單個襯裡也可以通過tools/中的腳本運行）。
另外，如果使用基於make系統：
make lint並make test運行所有每組任務make check運行所有支票，在推動PR之前很有用（或更新）tools/check-branch將運行您分支中的每個make check注意：直到所有林語和測試都通過，包括每次投票，都不太可能合併拉動請求。
糾正某些絨毛錯誤需要手動干預，例如從mypy進行類型檢查。
有關測試的提示，請查看以下有關Pytest的部分。
但是，如下所述，可以自動修復其他絨布錯誤 -這可以節省大量時間手動調整代碼以通過林格！
如果您有麻煩理解為什麼襯里或Pytest失敗的原因，請將您的代碼推到分支/PR，我們可以在PR或Chat.zulip.org中討論問題。
如果您更新這些，請注意，您不需要在兩個地方更新文本以通過覆蓋。
真相的來源是在源代碼中，因此只需更新Python文件並運行相關工具即可。目前我們有：
tools/lint-hotkeys --fix for config/keys.py再生文檔/hotkeys.mdtools/lint-docstring --fix for for file docstrings for docs/develoter-file-overview.md（這些工具也用於覆蓋過程，以確保這些文件已同步）
該項目分別使用black和isort進行代碼風格和導入排序。
這些工具可以在本地運行，但也可以自動為您格式化代碼。
如果您使用的是基於make的設置，則運行make fix將同時運行（和其他一些工具）並重新格式化代碼的當前狀態 - 因此，如果您對更改感到滿意，則首先要--amend 。
您也可以在文件或目錄上單獨使用工具，例如。 black zulipterminal或isort tests/model/test_model.py
當您在本地工作時，調查了進行的更改，通常會做出一系列小型承諾來存儲您的進度。通常，這可能包括在上一個提交中解決覆蓋或測試問題的提交。這些是發展風格的投入- 幾乎每個人都可能在某種程度上以這種風格寫作。
開發風格的委託商店將更改現在對您來說是可以的。但是，在共享您的代碼時，提交消息是與他人交流的好地方，而您的原因和原因。整理結構還可以使讀者更容易，更快地了解更改，並且您尊重他們的時間。一個例子是，與分裂相比，很大的單一提交可能需要很多時間來審查。另一個是，如果您在提交中修復了測試/裁剪：哪個提交（或提交！）是否可以解決，如果它在同一分支/PR中，為什麼原始commit不只是修復？
因此，當創建拉動請求（PR）時，請考慮您的代碼更有可能更快地合併，如果更易於閱讀，理解和審查- 其中很大一部分就是您將更改構成提交的方式，並描述提交消息中的這些更改。
為了提高生產力，使您的PR更容易進行審查和更新，我們遵循Zulip和其他地方採用的方法，旨在使PRS由一系列最小的連貫提交組成：
請注意，遵守這些原則可以在審查PR之前，之中和之後帶來其他好處，包括：
main上的git bisect的效用現在，我們在工作中執行PR的連貫性質的一致性有限，作為我們連續集成（CI）的一部分，確保孤立的PR提交，這基本上是在您的分支機構中make check的每個提交。您可以在使用tools/check-branch推送到GitHub之前在本地複制此內容。
儘管最初的概念驗證或概念證明是可以按原樣推動的，但可能只會根據整體變化進行審查。通常，如果單獨的投入看起來像是發展風格，那麼審閱者可能會提供更少的特定反饋，並且在合併之前肯定會要求最少的連貫提交。
重組命令- 大多數重組都依賴於交互式重新構造（例如git rebase -i upstream/main ），但請考慮在線搜索特定的操作，以及在#git help或在cath.zulip.org上搜索或詢問#git help或#learning 。
自我審查- 另一種有用的方法是在當地審查自己的承諾（請參閱Zulip建議），然後再推到Github之後。這使您可以檢查和修復任何看起來不合適的東西，這些東西可能會在他們的審核中進行，幫助您的提交看起來更加精緻，並再次表明您尊重審稿人的時間。
我們的目標是遵循標準的提交樣式，以保持git log一致且易於閱讀。
就像使用代碼一樣，我們建議您參考GIT日誌中的最新提交，以獲取我們積極使用的樣式的示例。
我們的提交消息的整體風格廣泛遵循Zulip提交消息的一般準則，因此我們建議您首先閱讀。
我們的提交標題（摘要）與一般的Zulip風格有輕微的變化：每種風格：
/隔開Tests updated或提交文本中Tests added ）refactor: ， bugfix:和requirements:請參閱下文）一些示例提交標題：（理想情況下在實踐中更具描述性！）
file3/file1/file2: Improve behavior of something.file1.txt ， file2.py和file3.mdrefactor: file1/file2: Extract some common function.file1.py和file2.pybugfix: file1: Avoid some noticeable bug.file1.py中的錯誤tests: file1: Improve test for something.file1的測試，可能在test_file1.py中requirements: Upgrade some-dependency from ==9.2 to ==9.3.為了滿足其中一些規則，您可以使用GitLint ，如下部分所述。
但是，請手動檢查您的提交與這些樣式規則，因為Gitlint無法檢查所有內容 - 包括語言或語法！
gitlint工具默認是在開發環境中安裝的，並可以幫助確保您的提交符合預期的標準。
該工具可以手動檢查特定的提交，例如。 gitlint用於最新的提交或gitlint --commits main..用於從main領導的提交。但是，我們強烈建議運行gitlint install-hook以安裝gitlint commen-message鉤子（或帶有Pipenv設置的pipenv run gitlint install-hook ）。
如果掛鉤是如上所述安裝的，則完成提交文本後，Gitlint將對我們設置的樣式進行檢查，如果有任何問題，它將提供建議。如果Gitlint找到了任何東西，它將詢問您是否希望按照（ y是'yes'）進行消息，停止提交過程（ n for'no no'）或編輯提交消息（ e for'for'edit'）。
儘管內容仍然取決於您的寫作技巧，但這可以確保提交（包括不同作者）之間的格式化結構更加一致。
使用Pytest編寫Zulip末端的測試。您可以閱讀/tests文件夾中的測試，以了解有關新類 /功能的編寫測試。如果您是Pytest的新手，那麼絕對建議閱讀其文檔。
目前，我們進行了數千項測試，可以在運行pytest時進行檢查。雖然它取決於您的系統功能，但通常需要不到一分鐘的時間才能運行。但是，在調試期間，您可能仍然希望限制測試範圍，以改善周轉時間：
如果許多測試以非常詳細的方式失敗，則可以嘗試-x選項（例如pytest -x ）在第一次失敗後停止測試；由於測試和測試固定裝置的參數化，只需一個修復即可解決許多明顯的錯誤/失敗！ （例如， pytest --maxfail 3對於較少破壞的版本）
為了避免每次進行所有成功的測試以及失敗，您可以使用--lf （例如pytest --lf ）運行，縮短了--last-failed （類似有用的選項可能是--failed-first and --new-first ，它可能與-x一起運行得很好）
由於pytest 3.10有--sw （ --stepwise ），它以與--lf和-x相同的方式通過已知的失敗起作用，可以將其與--stepwise-skip結合在一起，以控制哪個測試是當前的焦點
如果您知道失敗和/或在特定位置的測試名稱，則可能會將測試限制為特定位置（例如pytest tests/model ）或使用選定的關鍵字（例如pytest -k __handle ）
當僅運行測試的子集時，使用-v選項（ --verbose ）將變得更加實用和有用。而不是顯示. （或F ， E ， x等）對於每個測試結果，它給出了每個測試的名稱（帶有參數）（例如pytest -v -k __handle ）。此選項在測試中還顯示了更多詳細信息，可以多次給出（例如pytest -vv ）。
有關Pytest選項的其他幫助，請參閱pytest -h ，或查看完整的Pytest文檔。
print輸出如果使用-d或--debug在運行時啟用調試，則將Zulip-ensinal的Stdout（標準輸出）重定向到./debug.log 。
這意味著，如果您想檢查變量的值，或者可能指示到達代碼中的某個點，則可以簡單地使用print() ，例如。
print ( f"Just about to do something with { variable } " )並且在使用調試選項運行時，字符串將打印到./debug.log 。
使用BASH狀終端，您可以在另一個終端中運行諸如tail -f debug.log之類的東西，以查看其發生的print輸出。
如果您想在運行時或在特定狀態下調試Zulip-ensinal，則可以插入
from pudb . remote import set_trace
set_trace ()在代碼的一部分中，您要調試。這將為您啟動Telnet連接。您可以在./debug.log中找到telnet連接的IP地址和端口。然後簡單地運行
$ telnet 127.0.0.1 6899
在另一個終端中，其中127.0.0.1是IP地址，而6899是您在./debug.log中找到的端口。
這可能意味著您已經安裝了Zulip-ensinal的正常版本和開發版本。
為了確保您運行開發版本：
如果使用Pipenv，請從克隆/下載的zulip-terminal目錄中調用pipenv run zulip-term ；
如果使用PIP（PIP3），請確保您激活了正確的虛擬環境（VENV）；根據殼的配置方式，VENV的名稱可能出現在命令提示符中。請注意，不包括pip3命令中的-e也會引起此問題。
