fixes

.serena/project.yml

@@ -1,27 +1,30 @@
-# the name by which the project can be referenced within Serena
+# the name by which the project can be referenced within Serena/when chatting with the LLM.
 project_name: "dotfiles"
 
-
+# list of languages for which language servers are started (LSP backend only); choose from:
-# list of languages for which language servers are started; choose from:
+#   ada                 al                  angular             ansible             bash
-#   al                  angular             ansible             bash                clojure
+#   bsl                 clojure             cpp                 cpp_ccls            crystal
-#   cpp                 cpp_ccls            crystal             csharp              csharp_omnisharp
+#   csharp              csharp_omnisharp    cue                 dart                elixir
-#   dart                elixir              elm                 erlang              fortran
+#   elm                 erlang              fortran             fsharp              gdscript
-#   fsharp              go                  groovy              haskell             haxe
+#   go                  groovy              haskell             haxe                hlsl
-#   hlsl                html                java                json                julia
+#   html                java                json                julia               kotlin
-#   kotlin              lean4               lua                 luau                markdown
+#   latex               lean4               lua                 luau                markdown
 #   matlab              msl                 nix                 ocaml               pascal
-#   perl                php                 php_phpactor        powershell          python
+#   perl                php                 php_phpactor        php_phpantom        powershell
-#   python_jedi         python_ty           r                   rego                ruby
+#   python              python_jedi         python_pyrefly      python_ty           r
-#   ruby_solargraph     rust                scala               scss                solidity
+#   rego                ruby                ruby_solargraph     rust                scala
-#   swift               systemverilog       terraform           toml                typescript
+#   scss                solidity            svelte              swift               systemverilog
-#   typescript_vts      vue                 yaml                zig
+#   terraform           toml                typescript          typescript_vts      vue
-#   (This list may be outdated. For the current list, see values of Language enum here:
+#   yaml                zig
-#   https://github.com/oraios/serena/blob/main/src/solidlsp/ls_config.py
+#   (This list may be outdated; generated with scripts/print_language_list.py;
+#   For the current list, see values of Language enum here:
+#   https://github.com/oraios/serena/blob/main/src/solidlsp/ls_config.py)
 # For some languages, there are alternative language servers, e.g. csharp_omnisharp, ruby_solargraph.)
 # Note:
 #   - For C, use cpp
 #   - For JavaScript, use typescript
 #   - For Angular projects, use angular (subsumes typescript+html; requires `npm install` in the project root)
+#   - For Svelte projects, use svelte (subsumes typescript/javascript for .svelte projects; requires npm)
 #   - For SCSS / Sass / plain CSS, use scss (some-sass-language-server handles all three)
 #   - For Free Pascal/Lazarus, use pascal
 # Special requirements:
@@ -54,8 +57,8 @@ ignore_all_files_in_gitignore: true
 
 # advanced configuration option allowing to configure language server-specific options.
 # Maps the language key to the options.
-# Have a look at the docstring of the constructors of the LS implementations within solidlsp (e.g., for C# or PHP) to see which options are available.
+# The settings are considered only if the project is trusted (see global configuration to define trusted projects).
-# No documentation on options means no options are available.
+# See https://oraios.github.io/serena/02-usage/050_configuration.html#language-server-specific-settings
 ls_specific_settings: {}
 
 # list of additional paths to ignore in this project.
@@ -120,13 +123,38 @@ read_only_memory_patterns: []
 # Example: ["_archive/.*", "_episodes/.*"]
 ignored_memory_patterns: []
 
-# list of additional workspace folder paths for cross-package reference support (e.g. in monorepos).
+# optional shell command to run before the language backend (LSP or JetBrains) is initialised.
+# the command runs in the project root directory and is only executed if the project is trusted
+# (see trusted_project_path_patterns in the global configuration).
+# serena waits for the command to exit: a non-zero exit code is logged as an error but does not
+# abort activation. a per-project timeout (activation_command_timeout, default 180s) is the safety
+# backstop for non-terminating commands; on expiry the process is killed and activation continues.
+# example: activation_command: "npx nx run-many -t build"
+activation_command:
+
+# maximum time in seconds to wait for activation_command to complete before killing it (default 180s).
+# must be a positive number.
+activation_command_timeout: 180.0
+
+# list of additional workspace folder paths for cross-package reference support.
 # Paths can be absolute or relative to the project root.
 # Each folder is registered as an LSP workspace folder, enabling language servers to discover
-# symbols and references across package boundaries.
+# symbols and references across package boundaries, but these folders are not indexed by Serena,
-# Currently supported for: TypeScript.
+# i.e. the respective symbols will not be found using Serena's symbol search tools.
 # Example:
 #   additional_workspace_folders:
 #     - ../sibling-package
 #     - ../shared-lib
-additional_workspace_folders: []
+ls_additional_workspace_folders: []
+
+# list of workspace folder paths (LSP backend only).
+# These folders will be used to build up Serena's symbol index.
+# Paths must be within the project root and should thus be relative to the project root.
+# Furthermore, the paths should not be filtered by ignore settings.
+# Default setting: The entire project root folder (".") is considered.
+# In (large) monorepos, this can be used to index only subfolders of the project root, e.g.
+#   ls_workspace_folders:
+#     - "./subproject1"
+#     - "./subproject2"
+ls_workspace_folders:
+- .

fedora/README.md

@@ -15,6 +15,7 @@ Wayland-сессией становится Niri. Профиль получен
 | `waybar/scripts/weather.sh` | Модуль Waybar с погодой через `wttr.in`. |
 | `khal-calendar/` | Rust-версия календарного модуля Waybar. |
 | `mail-counter/` | Rust-модуль Waybar для счетчика непрочитанных писем Thunderbird. |
+| `calendar-mail-popup-notes.md` | Набросок UX и архитектуры для собственного calendar/mail popup из Waybar. |
 | `fuzzel/fuzzel.ini` | Тема лаунчера Fuzzel на цветах Catppuccin Latte. |
 | `btop/btop.conf` | Настройки системного монитора btop. |
 | `glow/glow.yml` | Настройки терминального Markdown-viewer Glow. |

fedora/calendar-mail-popup-notes.md

@@ -0,0 +1,191 @@
+# Calendar + Mail Popup Notes
+
+Заметка по идее компактного календарно-почтового инструмента для Fedora + Niri +
+Waybar.
+
+## Цель
+
+Нужны две связанные поверхности:
+
+1. Понятное решение в `waybar`, откуда можно быстро открыть календарь и увидеть
+   нужную информацию.
+2. Отдельное компактное `tool-window` / popup-окно с календарем и мини-почтой.
+
+Это не должен быть полноценный тяжелый PIM-комбайн на первом этапе. Основной
+приоритет — быстрый обзор и быстрые действия.
+
+## Что нужно уметь
+
+### В Waybar
+
+- Кликнуть по модулю.
+- Увидеть календарную информацию без переключения в большой клиент.
+- Быстро понять:
+  - что сегодня;
+  - что дальше по неделе;
+  - есть ли ближайшие события;
+  - есть ли непрочитанная почта.
+
+### В popup/tool-window
+
+- Посмотреть календарь на неделю и месяц.
+- Увидеть список ближайших событий.
+- Создать событие.
+- Иметь мини-почту как обзор, а не как полноценный mail client.
+
+## Ограничения текущего Waybar
+
+Встроенный `clock` модуль Waybar умеет:
+
+- показывать месяц/год;
+- переключать режимы;
+- листать календарь;
+- запускать команды по клику.
+
+Но встроенный календарь Waybar — только display layer:
+
+- он не показывает реальные CalDAV / Nextcloud / Google события;
+- он не умеет создавать события;
+- он не является полноценным event-aware календарем.
+
+Следствие: Waybar должен быть entry point, а не местом, где живет вся
+календарная логика.
+
+## Вывод по архитектуре
+
+Нужна связка из двух частей:
+
+1. `waybar` как обзор и кнопка входа;
+2. отдельное маленькое приложение/окно как рабочая поверхность.
+
+Рекомендованный подход:
+
+- hover в `waybar` показывает компактный календарный overview;
+- click открывает собственный popup/tool-window;
+- popup уже работает с реальными данными календаря и почты.
+
+## Предлагаемый UX
+
+### 1. Waybar popover / overview
+
+Минимальный состав:
+
+- верх: дата, `Today`, кнопка `+ Event`;
+- слева: мини-месяц;
+- справа или снизу: блок `Today / Tomorrow / This Week`;
+- отдельный короткий блок `Unread mail`.
+
+Роль этого слоя:
+
+- быстрое чтение;
+- быстрый переход;
+- минимум действий;
+- без тяжелой навигации.
+
+### 2. Tool-window / popup
+
+Форма окна:
+
+- не полноценное большое desktop app окно;
+- не полноразмерный почтовый клиент;
+- компактное floating window, открываемое по клику из `waybar`.
+
+Предпочтительная компоновка:
+
+- левая колонка: мини-месяц + список календарей;
+- центральная зона: week view или month-agenda;
+- правая колонка: `Upcoming`, `Reminders`, `Unread mail`.
+
+Верхняя строка:
+
+- `Today`
+- `New event`
+- `Search`
+- переключение `Week / Month`
+
+## Мини-почта: что это значит
+
+Почта в этом окне должна быть не отдельным MUA, а summary layer:
+
+- unread messages;
+- flagged / important;
+- письма за сегодня;
+- клик по письму открывает внешний клиент.
+
+Нежелательно на первом этапе:
+
+- полноценный composing;
+- threading;
+- archive/reply прямо в popup;
+- попытка заменить Thunderbird или другой почтовик.
+
+Идея: calendar-first окно с mail summary, а не равноправный split mail/calendar
+комбайн.
+
+## Референсы по форме и UX
+
+### Основной референс по форме
+
+`Fantastical Mini Window`
+
+- маленькое окно поверх рабочего контекста;
+- быстрый обзор событий;
+- быстрый add/search;
+- ощущается как utility window, а не как полноразмерное приложение.
+
+Ссылка:
+
+- https://flexibits.com/blog/2022/04/mini-window-big-productivity-getting-the-most-from-fantastical-for-macs-mini-window/
+
+### Референс по базовым календарным экранам
+
+`GNOME Calendar`
+
+- чистый month/week view;
+- отдельный event editor;
+- понятная структура desktop calendar без перегруза.
+
+Ссылка:
+
+- https://apps.gnome.org/Calendar/
+
+### Референс по плотной рабочей компоновке
+
+`Notion Calendar`
+
+- маленький месяц + основной agenda/week layout;
+- показывает, как совместить overview и рабочую область.
+
+Ссылка:
+
+- https://habr.com/ru/news/787144/
+
+### Референс по идее mail+calendar продукта
+
+`Thunderbird`
+
+- полезен не как popup reference, а как пример того, что почтовый summary и
+  календарь могут жить рядом;
+- для нашего UX слишком тяжел как direct reference.
+
+Ссылка:
+
+- https://www.thunderbird.net/en-US/
+
+## Практический вывод
+
+Лучшее направление для реализации:
+
+- брать `Fantastical Mini Window` как референс формы;
+- брать `GNOME Calendar` как референс календарных экранов;
+- делать calendar-first popup;
+- оставлять почту в формате короткого summary.
+
+## Следующий логический шаг
+
+Перед реализацией нужно решить:
+
+1. popup должен быть очень маленьким overview-окном или уже почти полноценным
+   mini-organizer;
+2. mini-mail нужен только для чтения summary или уже с действиями вроде
+   `mark read`, `archive`, `open`.