Package: emacs;
Reported by: Arthur Miller <arthur.miller <at> live.com>
Date: Sun, 26 Feb 2023 16:29:02 UTC
Severity: normal
Found in version 30.0.50
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61817 in the body.
You can then email your comments to 61817 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#61817; Package emacs.
(Sun, 26 Feb 2023 16:29:02 GMT) Full text and rfc822 format available.Arthur Miller <arthur.miller <at> live.com>:bug-gnu-emacs <at> gnu.org.
(Sun, 26 Feb 2023 16:29:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Arthur Miller <arthur.miller <at> live.com> To: bug-gnu-emacs <at> gnu.org Subject: 30.0.50; Project.el finds incorrect project roots in git worktrees Date: Sun, 26 Feb 2023 17:23:36 +0100
What actions trigger the bug:
Two different, unrelated repositories with emacs source code tree. My tree(s)
looks like this:
~/repos/emsrc/emacs/
~/repos/enacs-tests/emacs/
Where in both the last "emacs/" is the Emacs source tree from main git
repository.
~/repos/emsrc/emacs/ is the one I use for my "everyday" Emacs. I build Emacs now
and then once in a week or few weeks with a script, and I make each build in its
own our-of-source worktree. The other one is one where I used to do some tests.
It shouldn't matter since all worktrees are contained withing parent directory,
which in one case is "emsrc" and in the other case "emacs-tests", but for some
reason project.el sees the wrong one.
1. create two parent folders each one containing a copy of emacs sources
1. create out of source worktree for Emacs source under one of those
2. navigate to the worktree/lisp/progmodes
3. run M-: (project-known-project-roots)
In my Emacs, I am in my currently installed emacs worktree, where git root is
~/repos/emsrc/emacs but project.el returns ("~/repos/emacs-tests/emacs/") as a
result, which is totally unrelated to this source tree. I don't know what
happends, but I guess project.el goes "too far" out in search for roots; no
idea, I am not chasing the bug, but I don't see much code in project.el related
to worktrees. The only place I see them mentioned is about submodules.I
personally have used this one for quite some time, and it seems to correctly
handle worktrees for me:
#+begin_src emacs-lisp
(defun git-root (&optional directory)
"Find git root in a git project.
If DIRECTORY is not given, return git root of DEFAULT-DIRECTORY.
This should correctly find git root even for worktrees placed outside of a git
repository as well as in subdirectories in main git repository."
(let* ((directory (expand-file-name (or directory default-directory)))
(git-dir (locate-dominating-file directory ".git"))
(git-file (and git-dir (expand-file-name ".git" git-dir))))
(if (and git-file (file-directory-p git-file))
git-dir
(and git-file
(with-temp-buffer
(insert-file-contents-literally git-file)
(when (search-forward "gitdir: " nil t)
(let ((beg (point))
(end (search-forward ".git" nil t)))
(buffer-substring-no-properties beg (- end 4)))))))))
#+end_src
I don't use submodules, so I don't know if it works there, and there are
probably better ways to handle this, perhaps asking git for worktree list, but
that cost executing a git process, while parsing a file is relatively cheap and
much faster.
I don't know if this use-case is too bisarre; I will actually remove my
emacs-tests folder, it is an old remain, but still, I don't think project.el
should repport invalid project roots anyway.
In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.17.8) of
2023-02-26 built on pascal
Repository revision: 013655811aa1c89754372610c8c6ccccec166035
Repository branch: no-gtk-with-cairo-and-native-230226-061643
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Arch Linux
Configured using:
'configure --with-native-compilation --with-x --with-x-toolkit=no
--without-gconf --without-gsettings --without-toolkit-scroll-bars
--with-xinput2 --without-included-regex --without-compress-install 'CFLAGS=-O2
-march=native''
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG JSON LCMS2 LIBOTF
LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY OLDXMENU PDUMPER
PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TREE_SITTER WEBP X11 XDBE XIM
XINPUT2 XPM ZLIB
Important settings:
value of $LANG: sv_SE.UTF-8
locale-coding-system: utf-8-unix
Major mode: Dired by name
Minor modes in effect:
ace-window-display-mode: t
helm-flx-mode: t
windmove-mode: t
emms-mode-line-mode: t
emms-playing-time-display-mode: t
emms-playing-time-mode: t
beacon-mode: t
server-mode: t
which-key-mode: t
wrap-region-global-mode: t
electric-pair-mode: t
global-auto-revert-mode: t
global-hl-line-mode: t
global-subword-mode: t
subword-mode: t
auto-image-file-mode: t
display-time-mode: t
delete-selection-mode: t
save-place-mode: t
winner-mode: t
pixel-scroll-precision-mode: t
auto-insert-mode: t
helm-mode: t
helm-minibuffer-history-mode: t
helm-adaptive-mode: t
dired-auto-readme-mode: t
dired-omit-mode: t
dired-async-mode: t
dired-hide-details-mode: t
shell-dirtrack-mode: t
helm-autoresize-mode: t
helm--remap-mouse-mode: t
async-bytecomp-package-mode: t
speed-of-thought-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
buffer-read-only: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
auto-save-visited-mode: t
abbrev-mode: t
Load-path shadows:
/home/arthur/.config/emacs/lisp/emacs-lisp/package hides /home/arthur/.emacs.d/lisp/package
/home/arthur/.emacs.d/elpa/with-editor-20230212.2214/with-editor hides /home/arthur/.emacs.d/elpa/with-editor-20230210.1157/with-editor
/home/arthur/.emacs.d/elpa/with-editor-20230212.2214/with-editor-autoloads hides /home/arthur/.emacs.d/elpa/with-editor-20230210.1157/with-editor-autoloads
/home/arthur/.emacs.d/elpa/with-editor-20230212.2214/with-editor-pkg hides /home/arthur/.emacs.d/elpa/with-editor-20230210.1157/with-editor-pkg
/home/arthur/.emacs.d/elpa/with-editor-20230212.2214/with-editor hides /home/arthur/.emacs.d/elpa/with-editor-20230118.1656/with-editor
/home/arthur/.emacs.d/elpa/with-editor-20230212.2214/with-editor-autoloads hides /home/arthur/.emacs.d/elpa/with-editor-20230118.1656/with-editor-autoloads
/home/arthur/.emacs.d/elpa/with-editor-20230212.2214/with-editor-pkg hides /home/arthur/.emacs.d/elpa/with-editor-20230118.1656/with-editor-pkg
/home/arthur/.config/emacs/lisp/transient hides /home/arthur/.emacs.d/elpa/transient-20230220.1425/transient
/home/arthur/.config/emacs/lisp/transient hides /home/arthur/.emacs.d/elpa/transient-20230209.2250/transient
/home/arthur/.emacs.d/elpa/transient-20230220.1425/transient-autoloads hides /home/arthur/.emacs.d/elpa/transient-20230209.2250/transient-autoloads
/home/arthur/.emacs.d/elpa/transient-20230220.1425/transient-pkg hides /home/arthur/.emacs.d/elpa/transient-20230209.2250/transient-pkg
/home/arthur/.config/emacs/lisp/transient hides /home/arthur/.emacs.d/elpa/transient-20230201.1644/transient
/home/arthur/.emacs.d/elpa/transient-20230220.1425/transient-autoloads hides /home/arthur/.emacs.d/elpa/transient-20230201.1644/transient-autoloads
/home/arthur/.emacs.d/elpa/transient-20230220.1425/transient-pkg hides /home/arthur/.emacs.d/elpa/transient-20230201.1644/transient-pkg
/home/arthur/.config/emacs/lisp/transient hides /home/arthur/.emacs.d/elpa/transient-20230107.1528/transient
/home/arthur/.emacs.d/elpa/transient-20230220.1425/transient-autoloads hides /home/arthur/.emacs.d/elpa/transient-20230107.1528/transient-autoloads
/home/arthur/.emacs.d/elpa/transient-20230220.1425/transient-pkg hides /home/arthur/.emacs.d/elpa/transient-20230107.1528/transient-pkg
/home/arthur/.config/emacs/lisp/textmodes/string-edit hides /home/arthur/.emacs.d/elpa/string-edit-20220604.2128/string-edit
/home/arthur/.emacs.d/elpa/sotlisp-20220909.803/sotlisp hides /home/arthur/.emacs.d/elpa/sotlisp-1.6.2/sotlisp
/home/arthur/.emacs.d/elpa/peg-1.0.1/peg-autoloads hides /home/arthur/.emacs.d/elpa/peg-1.0/peg-autoloads
/home/arthur/.emacs.d/elpa/peg-1.0.1/peg-tests hides /home/arthur/.emacs.d/elpa/peg-1.0/peg-tests
/home/arthur/.emacs.d/elpa/peg-1.0.1/peg hides /home/arthur/.emacs.d/elpa/peg-1.0/peg
/home/arthur/.emacs.d/elpa/peg-1.0.1/peg-pkg hides /home/arthur/.emacs.d/elpa/peg-1.0/peg-pkg
/home/arthur/.emacs.d/elpa/peep-dired-20160321.2237/peep-dired hides /home/arthur/.emacs.d/elpa/peep-dired-1.1.0/peep-dired
/home/arthur/.emacs.d/elpa/peep-dired-20160321.2237/peep-dired-autoloads hides /home/arthur/.emacs.d/elpa/peep-dired-1.1.0/peep-dired-autoloads
/home/arthur/.emacs.d/elpa/peep-dired-20160321.2237/peep-dired-pkg hides /home/arthur/.emacs.d/elpa/peep-dired-1.1.0/peep-dired-pkg
/home/arthur/.emacs.d/elpa/magit-section-20230213.2018/magit-section hides /home/arthur/.emacs.d/elpa/magit-section-20230211.1642/magit-section
/home/arthur/.emacs.d/elpa/magit-section-20230213.2018/magit-section-pkg hides /home/arthur/.emacs.d/elpa/magit-section-20230211.1642/magit-section-pkg
/home/arthur/.emacs.d/elpa/magit-section-20230213.2018/magit-section-autoloads hides /home/arthur/.emacs.d/elpa/magit-section-20230211.1642/magit-section-autoloads
/home/arthur/.emacs.d/elpa/magit-section-20230213.2018/magit-section hides /home/arthur/.emacs.d/elpa/magit-section-20230204.1138/magit-section
/home/arthur/.emacs.d/elpa/magit-section-20230213.2018/magit-section-pkg hides /home/arthur/.emacs.d/elpa/magit-section-20230204.1138/magit-section-pkg
/home/arthur/.emacs.d/elpa/magit-section-20230213.2018/magit-section-autoloads hides /home/arthur/.emacs.d/elpa/magit-section-20230204.1138/magit-section-autoloads
/home/arthur/.emacs.d/elpa/magit-section-20230213.2018/magit-section hides /home/arthur/.emacs.d/elpa/magit-section-20230106.1659/magit-section
/home/arthur/.emacs.d/elpa/magit-section-20230213.2018/magit-section-pkg hides /home/arthur/.emacs.d/elpa/magit-section-20230106.1659/magit-section-pkg
/home/arthur/.emacs.d/elpa/magit-section-20230213.2018/magit-section-autoloads hides /home/arthur/.emacs.d/elpa/magit-section-20230106.1659/magit-section-autoloads
/home/arthur/.emacs.d/elpa/magit-section-20230213.2018/magit-section hides /home/arthur/.emacs.d/elpa/magit-section-20221127.2227/magit-section
/home/arthur/.emacs.d/elpa/magit-section-20230213.2018/magit-section-pkg hides /home/arthur/.emacs.d/elpa/magit-section-20221127.2227/magit-section-pkg
/home/arthur/.emacs.d/elpa/magit-section-20230213.2018/magit-section-autoloads hides /home/arthur/.emacs.d/elpa/magit-section-20221127.2227/magit-section-autoloads
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-xml hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-xml
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-prolog hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-prolog
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-steep hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-steep
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-sorbet hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-sorbet
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-vetur hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-vetur
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-beancount hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-beancount
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-dockerfile hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-dockerfile
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-tex hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-tex
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-hack hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-hack
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-r hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-r
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-haxe hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-haxe
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-yaml hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-yaml
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-pylsp hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-pylsp
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-elixir hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-elixir
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-groovy hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-groovy
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-rf hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-rf
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-elm hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-elm
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-nginx hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-nginx
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-json hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-json
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-angular hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-angular
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-svelte hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-svelte
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-toml hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-toml
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-zig hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-zig
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-pwsh hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-pwsh
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-protocol hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-protocol
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-icons hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-icons
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-cmake hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-cmake
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-rust hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-rust
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-php hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-php
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-diagnostics hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-diagnostics
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-erlang hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-erlang
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-mode-autoloads hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-mode-autoloads
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-actionscript hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-actionscript
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-purescript hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-purescript
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-racket hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-racket
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-html hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-html
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-solargraph hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-solargraph
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-lens hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-lens
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-nim hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-nim
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-ocaml hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-ocaml
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-ada hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-ada
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-csharp hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-csharp
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-semantic-tokens hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-semantic-tokens
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-lua hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-lua
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-css hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-css
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-markdown hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-markdown
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-v hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-v
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-vimscript hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-vimscript
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-dired hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-dired
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-graphql hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-graphql
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-go hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-go
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-vala hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-vala
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-mode hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-mode
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-javascript hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-javascript
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-completion hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-completion
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-fsharp hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-fsharp
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-sqls hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-sqls
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-perl hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-perl
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-clojure hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-clojure
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-gdscript hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-gdscript
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-dhall hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-dhall
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-pyls hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-pyls
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-nix hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-nix
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-verilog hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-verilog
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-fortran hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-fortran
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-kotlin hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-kotlin
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-modeline hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-modeline
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-iedit hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-iedit
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-ido hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-ido
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-crystal hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-crystal
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-terraform hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-terraform
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-vhdl hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-vhdl
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-clangd hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-clangd
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-headerline hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-headerline
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-d hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-d
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-bash hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-bash
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-mode-pkg hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-mode-pkg
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp
/home/arthur/.emacs.d/elpa/lsp-mode-20230221.1558/lsp-eslint hides /home/arthur/.emacs.d/elpa/lsp-mode-20211211.1834/lsp-eslint
/home/arthur/.emacs.d/elpa/lispy-20221225.1927/elpa hides /home/arthur/.emacs.d/elpa/ivy-20220926.1250/elpa
/home/arthur/.config/emacs/lisp/emacs-lisp/helper hides /home/arthur/.emacs.d/elpa/helper-0.5/helper
/home/arthur/.emacs.d/lisp/helm-git-branch hides /home/arthur/.emacs.d/elpa/helm-git-branch-0.1/helm-git-branch
/home/arthur/.emacs.d/elpa/git-commit-20230220.1901/git-commit hides /home/arthur/.emacs.d/elpa/git-commit-20221106.1128/git-commit
/home/arthur/.emacs.d/elpa/git-commit-20230220.1901/git-commit-autoloads hides /home/arthur/.emacs.d/elpa/git-commit-20221106.1128/git-commit-autoloads
/home/arthur/.emacs.d/elpa/git-commit-20230220.1901/git-commit-pkg hides /home/arthur/.emacs.d/elpa/git-commit-20221106.1128/git-commit-pkg
/home/arthur/.emacs.d/elpa/emacsql-sqlite-20230221.1532/emacsql-sqlite hides /home/arthur/.emacs.d/elpa/emacsql-20230221.1532/emacsql-sqlite
/home/arthur/.emacs.d/elpa/emacsql-20230221.1532/emacsql hides /home/arthur/.emacs.d/elpa/emacsql-20230118.2020/emacsql
/home/arthur/.emacs.d/elpa/emacsql-20230221.1532/emacsql-pkg hides /home/arthur/.emacs.d/elpa/emacsql-20230118.2020/emacsql-pkg
/home/arthur/.emacs.d/elpa/emacsql-20230221.1532/emacsql-compiler hides /home/arthur/.emacs.d/elpa/emacsql-20230118.2020/emacsql-compiler
/home/arthur/.emacs.d/elpa/emacsql-20230221.1532/emacsql-autoloads hides /home/arthur/.emacs.d/elpa/emacsql-20230118.2020/emacsql-autoloads
/home/arthur/.emacs.d/elpa/elisp-refs-20220704.2141/elisp-refs hides /home/arthur/.emacs.d/elpa/elisp-refs-1.4/elisp-refs
/home/arthur/.emacs.d/elpa/elisp-refs-20220704.2141/elisp-refs-autoloads hides /home/arthur/.emacs.d/elpa/elisp-refs-1.4/elisp-refs-autoloads
/home/arthur/.emacs.d/elpa/elisp-refs-20220704.2141/elisp-refs-pkg hides /home/arthur/.emacs.d/elpa/elisp-refs-1.4/elisp-refs-pkg
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-26 hides /home/arthur/.emacs.d/elpa/compat-29.1.3.2/compat-26
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-25 hides /home/arthur/.emacs.d/elpa/compat-29.1.3.2/compat-25
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-29 hides /home/arthur/.emacs.d/elpa/compat-29.1.3.2/compat-29
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-27 hides /home/arthur/.emacs.d/elpa/compat-29.1.3.2/compat-27
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-pkg hides /home/arthur/.emacs.d/elpa/compat-29.1.3.2/compat-pkg
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-28 hides /home/arthur/.emacs.d/elpa/compat-29.1.3.2/compat-28
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-autoloads hides /home/arthur/.emacs.d/elpa/compat-29.1.3.2/compat-autoloads
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-macs hides /home/arthur/.emacs.d/elpa/compat-29.1.3.2/compat-macs
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat hides /home/arthur/.emacs.d/elpa/compat-29.1.3.2/compat
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-26 hides /home/arthur/.emacs.d/elpa/compat-29.1.1.0/compat-26
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-25 hides /home/arthur/.emacs.d/elpa/compat-29.1.1.0/compat-25
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-29 hides /home/arthur/.emacs.d/elpa/compat-29.1.1.0/compat-29
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-27 hides /home/arthur/.emacs.d/elpa/compat-29.1.1.0/compat-27
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-pkg hides /home/arthur/.emacs.d/elpa/compat-29.1.1.0/compat-pkg
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-28 hides /home/arthur/.emacs.d/elpa/compat-29.1.1.0/compat-28
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-autoloads hides /home/arthur/.emacs.d/elpa/compat-29.1.1.0/compat-autoloads
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-macs hides /home/arthur/.emacs.d/elpa/compat-29.1.1.0/compat-macs
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat hides /home/arthur/.emacs.d/elpa/compat-29.1.1.0/compat
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-26 hides /home/arthur/.emacs.d/elpa/compat-28.1.2.2/compat-26
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-25 hides /home/arthur/.emacs.d/elpa/compat-28.1.2.2/compat-25
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-27 hides /home/arthur/.emacs.d/elpa/compat-28.1.2.2/compat-27
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-pkg hides /home/arthur/.emacs.d/elpa/compat-28.1.2.2/compat-pkg
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-28 hides /home/arthur/.emacs.d/elpa/compat-28.1.2.2/compat-28
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-autoloads hides /home/arthur/.emacs.d/elpa/compat-28.1.2.2/compat-autoloads
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-macs hides /home/arthur/.emacs.d/elpa/compat-28.1.2.2/compat-macs
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat hides /home/arthur/.emacs.d/elpa/compat-28.1.2.2/compat
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-26 hides /home/arthur/.emacs.d/elpa/compat-28.1.1.1/compat-26
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-25 hides /home/arthur/.emacs.d/elpa/compat-28.1.1.1/compat-25
/home/arthur/.emacs.d/elpa/compat-28.1.2.2/compat-help hides /home/arthur/.emacs.d/elpa/compat-28.1.1.1/compat-help
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-27 hides /home/arthur/.emacs.d/elpa/compat-28.1.1.1/compat-27
/home/arthur/.emacs.d/elpa/compat-28.1.2.2/compat-font-lock hides /home/arthur/.emacs.d/elpa/compat-28.1.1.1/compat-font-lock
/home/arthur/.emacs.d/elpa/compat-28.1.2.2/compat-24 hides /home/arthur/.emacs.d/elpa/compat-28.1.1.1/compat-24
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-pkg hides /home/arthur/.emacs.d/elpa/compat-28.1.1.1/compat-pkg
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-macs hides /home/arthur/.emacs.d/elpa/compat-28.1.1.1/compat-macs
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-28 hides /home/arthur/.emacs.d/elpa/compat-28.1.1.1/compat-28
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat-autoloads hides /home/arthur/.emacs.d/elpa/compat-28.1.1.1/compat-autoloads
/home/arthur/.emacs.d/elpa/compat-29.1.3.4/compat hides /home/arthur/.emacs.d/elpa/compat-28.1.1.1/compat
/home/arthur/.emacs.d/lisp/company-cmake hides /home/arthur/.emacs.d/elpa/company-20230209.134/company-cmake
/home/arthur/.emacs.d/elpa/closql-20230220.1944/closql-autoloads hides /home/arthur/.emacs.d/elpa/closql-20230212.2019/closql-autoloads
/home/arthur/.emacs.d/elpa/closql-20230220.1944/closql-pkg hides /home/arthur/.emacs.d/elpa/closql-20230212.2019/closql-pkg
/home/arthur/.emacs.d/elpa/closql-20230220.1944/closql hides /home/arthur/.emacs.d/elpa/closql-20230212.2019/closql
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-clojuredocs hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-clojuredocs
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-completion hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-completion
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-profile hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-profile
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-cheatsheet hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-cheatsheet
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-format hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-format
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-eldoc hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-eldoc
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-find hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-find
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-client hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-client
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-classpath hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-classpath
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-common hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-common
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-jar hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-jar
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-util hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-util
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-repl-history hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-repl-history
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-debug hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-debug
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-eval hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-eval
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-browse-ns hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-browse-ns
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-stacktrace hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-stacktrace
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-overlays hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-overlays
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-repl hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-repl
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-tracing hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-tracing
/home/arthur/.emacs.d/elpa/cider-20230218.915/nrepl-dict hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/nrepl-dict
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-selector hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-selector
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-ns hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-ns
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-browse-spec hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-browse-spec
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-test hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-test
/home/arthur/.emacs.d/elpa/cider-20230218.915/nrepl-client hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/nrepl-client
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-macroexpansion hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-macroexpansion
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-connection hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-connection
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-doc hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-doc
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-resolve hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-resolve
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-xref hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-xref
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-scratch hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-scratch
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-inspector hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-inspector
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-autoloads hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-autoloads
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-mode hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-mode
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-apropos hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-apropos
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-popup hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-popup
/home/arthur/.emacs.d/elpa/cider-20230218.915/cider-pkg hides /home/arthur/.emacs.d/elpa/cider-20230208.2108/cider-pkg
Features:
(shadow mail-extr emacsbug qp gnus-ml gnus-topic nndraft nnmh nnfolder utf-7
network-stream gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg
nntp gnus-cache cus-start help-fns radix-tree cl-print bug-reference bookmark
tabify org-capture timezone org-goto cursor-sensor org-mouse let-alist
ob-hide-markers ace-window avy org-eldoc org-element org-persist org-id
org-refile avl-tree oc-basic ol-eww eww url-queue mm-url ol-rmail ol-mhe ol-irc
ol-info ol-gnus nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls
dig gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group gnus-undo
gnus-start gnus-dbus gnus-cloud nnimap nnmail mail-source utf7 nnoo gnus-spec
gnus-int gnus-range message sendmail yank-media rfc822 mml mml-sec epa epg
rfc6068 epg-config mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader
gnus-win ol-docview doc-view jka-compr ol-bibtex bibtex ol-bbdb ol-w3m ol-doi
org-link-doi vc-git diff-mode vc-dispatcher helm-command dired-narrow
helm-external helm-net tramp-archive tramp-gvfs tramp-cache time-stamp zeroconf
ffap helm-flx flx emms-mpris dbus sv-kalender lunar solar cal-dst holidays
holiday-loaddefs extras windmove recentf tree-widget emms-librefm-stream xml
emms-librefm-scrobbler emms-i18n emms-history emms-score emms-stream-info
emms-metaplaylist-mode emms-bookmarks emms-cue emms-mode-line-icon emms-browser
sort emms-playlist-sort emms-last-played emms-player-xine emms-player-mpd tq
emms-lyrics emms-url emms-streams emms-show-all emms-tag-editor
emms-tag-tracktag emms-mark emms-cache emms-info-native bindat
emms-info-exiftool emms-info-tinytag emms-info-metaflac emms-info-opusinfo
emms-info-ogginfo emms-info-mp3info emms-player-vlc emms-player-mplayer
emms-player-mpv emms-mode-line-cycle emms-mode-line emms-playing-time
emms-player-simple emms-info emms-later-do emms-playlist-limit emms-volume
emms-volume-sndioctl emms-volume-mixerctl emms-volume-pulse emms-volume-amixer
emms-playlist-mode emms-source-playlist emms-source-file locate emms-setup emms
emms-compat beacon c++-setup server overseer pkg-info url-http url-auth
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums url-gw nsm puny epl f f-shortdoc s
disp-table page-break-lines company-yasnippet company-ispell ispell
company-clang company-elisp company-etags etags fileloop generator xref
company-semantic company-template company-keywords make-mode nnir gnus nnheader
gnus-util mail-utils range mm-util mail-prsvr which-key solarized-dark-theme
solarized solarized-faces wrap-region elec-pair autorevert hl-line cap-words
superword subword image-file image-converter time delsel saveplace winner
pixel-scroll cua-base cl-extras autoinsert elisp-extras popup helm-pages
helm-mode helm-misc helm-adaptive helm-projectile projectile project lisp-mnt
grep compile ibuf-ext ibuffer ibuffer-loaddefs helm-eshell helm-elisp helm-files
image-dired image-dired-tags image-dired-external image-dired-util xdg
image-mode dired-setup tmtxt-dired-async tmtxt-async-tasks dired-auto-readme
text-property-search dired-git-log dired-copy-paste dired-subtree
dired-hacks-utils dash org-view-mode org-view-font face-remap markdown-mode
color thingatpt openwith dired-x wdired dired-async dired-aux dired
dired-loaddefs exif filenotify tramp tramp-loaddefs trampver tramp-integration
cus-edit pp cus-load wid-edit files-x tramp-compat shell parse-time iso8601
ls-lisp helm-buffers helm-occur helm-tags helm-locate helm-grep helm-regexp
helm-eval edebug-x comp comp-cstr warnings advice which-func imenu edebug debug
backtrace helm-info helm-utils helm-types helm-help helm helm-global-bindings
helm-core helm-source helm-multi-match helm-lib async-bytecomp async
yasnippet-snippets yasnippet cl-extra derived easy-mmode help-mode outshine
outshine-org-cmds outorg org-pretty-table org-protocol org ob ob-tangle ob-ref
ob-lob ob-table ob-exp org-macro org-src ob-comint org-pcomplete pcomplete
comint ansi-osc ansi-color ring org-list org-footnote org-faces org-entities
time-date ob-emacs-lisp ob-core ob-eval org-cycle org-table ol rx org-fold
org-fold-core org-keys oc org-loaddefs find-func cal-menu calendar cal-loaddefs
org-version org-compat org-macs format-spec noutline outline icons company-files
company-capf company sotlisp skeleton paredit edmacro kmacro diminish cl
helm-easymenu pcase info package browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie generate-lisp-file url-domsuf url-util
mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars
cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse
jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese composite
emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev
obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face
macroexp files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote threads
dbusbind inotify lcms2 dynamic-setting font-render-setting cairo xinput2 x
multi-tty make-network-process native-compile emacs)
Memory information:
((conses 16 1097924 136505)
(symbols 48 48935 1)
(strings 32 202453 20654)
(string-bytes 1 7492488)
(vectors 16 116979)
(vector-slots 8 2994192 162034)
(floats 8 1542 7804)
(intervals 56 37098 2620)
(buffers 984 45))
bug-gnu-emacs <at> gnu.org:bug#61817; Package emacs.
(Sun, 26 Feb 2023 18:04:02 GMT) Full text and rfc822 format available.Message #8 received at 61817 <at> debbugs.gnu.org (full text, mbox):
From: Dmitry Gutov <dgutov <at> yandex.ru> To: Arthur Miller <arthur.miller <at> live.com>, 61817 <at> debbugs.gnu.org Subject: Re: bug#61817: 30.0.50; Project.el finds incorrect project roots in git worktrees Date: Sun, 26 Feb 2023 20:03:08 +0200
On 26/02/2023 18:23, Arthur Miller wrote:
> What actions trigger the bug:
>
> Two different, unrelated repositories with emacs source code tree. My tree(s)
> looks like this:
>
> ~/repos/emsrc/emacs/
> ~/repos/enacs-tests/emacs/
>
> Where in both the last "emacs/" is the Emacs source tree from main git
> repository.
>
> ~/repos/emsrc/emacs/ is the one I use for my "everyday" Emacs. I build Emacs now
> and then once in a week or few weeks with a script, and I make each build in its
> own our-of-source worktree. The other one is one where I used to do some tests.
> It shouldn't matter since all worktrees are contained withing parent directory,
> which in one case is "emsrc" and in the other case "emacs-tests", but for some
> reason project.el sees the wrong one.
>
> 1. create two parent folders each one containing a copy of emacs sources
> 1. create out of source worktree for Emacs source under one of those
> 2. navigate to the worktree/lisp/progmodes
> 3. run M-: (project-known-project-roots)
>
> In my Emacs, I am in my currently installed emacs worktree, where git root is
>
> ~/repos/emsrc/emacs but project.el returns ("~/repos/emacs-tests/emacs/") as a
> result
What does (project-root (project-current)) return? And which dirs you
are testing it in?
> I am not chasing the bug, but I don't see much code in project.el related
> to worktrees.
Normally, there shouldn't be any need to handle worktree specially: it
contains a file called .git at the top which can serve as a marker just
fine.
> The only place I see them mentioned is about submodules.I
> personally have used this one for quite some time, and it seems to correctly
> handle worktrees for me:
You code looks like it can return the "actual git root" that can be a
directory residing somewhere else than the current directory tree. Is
that what you wanted? Off the top of my head, that should break the
'project-files' method.
bug-gnu-emacs <at> gnu.org:bug#61817; Package emacs.
(Mon, 27 Feb 2023 07:34:02 GMT) Full text and rfc822 format available.Message #11 received at 61817 <at> debbugs.gnu.org (full text, mbox):
From: Arthur Miller <arthur.miller <at> live.com> To: Dmitry Gutov <dgutov <at> yandex.ru> Cc: 61817 <at> debbugs.gnu.org Subject: Re: bug#61817: 30.0.50; Project.el finds incorrect project roots in git worktrees Date: Mon, 27 Feb 2023 08:32:39 +0100
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 26/02/2023 18:23, Arthur Miller wrote:
>> What actions trigger the bug:
>> Two different, unrelated repositories with emacs source code tree. My tree(s)
>> looks like this:
>> ~/repos/emsrc/emacs/
>> ~/repos/enacs-tests/emacs/
>> Where in both the last "emacs/" is the Emacs source tree from main git
>> repository.
>> ~/repos/emsrc/emacs/ is the one I use for my "everyday" Emacs. I build Emacs
>> now
>> and then once in a week or few weeks with a script, and I make each build in its
>> own our-of-source worktree. The other one is one where I used to do some tests.
>> It shouldn't matter since all worktrees are contained withing parent directory,
>> which in one case is "emsrc" and in the other case "emacs-tests", but for some
>> reason project.el sees the wrong one.
>> 1. create two parent folders each one containing a copy of emacs sources
>> 1. create out of source worktree for Emacs source under one of those
>> 2. navigate to the worktree/lisp/progmodes
>> 3. run M-: (project-known-project-roots)
>> In my Emacs, I am in my currently installed emacs worktree, where git root is
>> ~/repos/emsrc/emacs but project.el returns ("~/repos/emacs-tests/emacs/") as a
>> result
>
> What does (project-root (project-current)) return? And which dirs you are
> testing it in?
It returns the current worktree folder:
"/home/arthur/repos/emsrc/no-gtk-with-cairo-and-native-230226-061643/"
which I guess is what project.el finds as root since it only uses .git as a
marker, if I understand correctly what you write little further.
>> I am not chasing the bug, but I don't see much code in project.el related
>> to worktrees.
>
> Normally, there shouldn't be any need to handle worktree specially: it contains
> a file called .git at the top which can serve as a marker just fine.
Well define "normally" and "just fine" :). Anyway, when I read your reply it seems
like I have wrong expectation from project.el, so the fault is on my side. I
thought it can deal with git projects in general, but as I understand it then,
it only works with files in current directory.
>> The only place I see them mentioned is about submodules.I
>> personally have used this one for quite some time, and it seems to correctly
>> handle worktrees for me:
>
> You code looks like it can return the "actual git root" that can be a directory
> residing somewhere else than the current directory tree.
Git worktrees can be placed outside the main repository tree:
git worktree add ../my-new-shiny-emacs-patch
as an example. The code will find correct git root both outside, or within the
repo. But I think it should be done by actually asking git to list worktrees
instead.
> Is that what you
> wanted?
Yes that is what I wanted? :-).
For automation purpose I need to find the project root, so I can pull sources to
main, create a clean worktree from main, and switch Emacs to the new worktree
interactively in one command, like M-x make-new-patch. Emacs asks me for a name
and create a clean worktree from the main trunk for current project. Actually
better variant is to ask which branch to patch, but the first one is slightly
faster and works just fine in many cases.
bug-gnu-emacs <at> gnu.org:bug#61817; Package emacs.
(Mon, 27 Feb 2023 11:52:01 GMT) Full text and rfc822 format available.Message #14 received at 61817 <at> debbugs.gnu.org (full text, mbox):
From: Dmitry Gutov <dgutov <at> yandex.ru> To: Arthur Miller <arthur.miller <at> live.com> Cc: 61817 <at> debbugs.gnu.org Subject: Re: bug#61817: 30.0.50; Project.el finds incorrect project roots in git worktrees Date: Mon, 27 Feb 2023 13:51:00 +0200
On 27/02/2023 09:32, Arthur Miller wrote:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
>> On 26/02/2023 18:23, Arthur Miller wrote:
>>> What actions trigger the bug:
>>> Two different, unrelated repositories with emacs source code tree. My tree(s)
>>> looks like this:
>>> ~/repos/emsrc/emacs/
>>> ~/repos/enacs-tests/emacs/
>>> Where in both the last "emacs/" is the Emacs source tree from main git
>>> repository.
>>> ~/repos/emsrc/emacs/ is the one I use for my "everyday" Emacs. I build Emacs
>>> now
>>> and then once in a week or few weeks with a script, and I make each build in its
>>> own our-of-source worktree. The other one is one where I used to do some tests.
>>> It shouldn't matter since all worktrees are contained withing parent directory,
>>> which in one case is "emsrc" and in the other case "emacs-tests", but for some
>>> reason project.el sees the wrong one.
>>> 1. create two parent folders each one containing a copy of emacs sources
>>> 1. create out of source worktree for Emacs source under one of those
>>> 2. navigate to the worktree/lisp/progmodes
>>> 3. run M-: (project-known-project-roots)
>>> In my Emacs, I am in my currently installed emacs worktree, where git root is
>>> ~/repos/emsrc/emacs but project.el returns ("~/repos/emacs-tests/emacs/") as a
>>> result
>>
>> What does (project-root (project-current)) return? And which dirs you are
>> testing it in?
>
> It returns the current worktree folder:
>
> "/home/arthur/repos/emsrc/no-gtk-with-cairo-and-native-230226-061643/"
>
> which I guess is what project.el finds as root since it only uses .git as a
> marker, if I understand correctly what you write little further.
>
>>> I am not chasing the bug, but I don't see much code in project.el related
>>> to worktrees.
>>
>> Normally, there shouldn't be any need to handle worktree specially: it contains
>> a file called .git at the top which can serve as a marker just fine.
>
> Well define "normally" and "just fine" :). Anyway, when I read your reply it seems
> like I have wrong expectation from project.el, so the fault is on my side. I
> thought it can deal with git projects in general, but as I understand it then,
> it only works with files in current directory.
We could change project-try-vc to follow the link to the parent repo,
but how is the rest of it going to work?
If the project root is the parent repo, which set of files would
(project-files pr) return? And how could that be implemented?
>>> The only place I see them mentioned is about submodules.I
>>> personally have used this one for quite some time, and it seems to correctly
>>> handle worktrees for me:
>>
>> You code looks like it can return the "actual git root" that can be a directory
>> residing somewhere else than the current directory tree.
>
> Git worktrees can be placed outside the main repository tree:
>
> git worktree add ../my-new-shiny-emacs-patch
>
> as an example. The code will find correct git root both outside, or within the
> repo.
Exactly.
> But I think it should be done by actually asking git to list worktrees
> instead.
>
>> Is that what you
>> wanted?
>
> Yes that is what I wanted? :-).
>
> For automation purpose I need to find the project root, so I can pull sources to
> main, create a clean worktree from main, and switch Emacs to the new worktree
> interactively in one command, like M-x make-new-patch. Emacs asks me for a name
> and create a clean worktree from the main trunk for current project. Actually
> better variant is to ask which branch to patch, but the first one is slightly
> faster and works just fine in many cases.
It sounds like your code is Git-specific, not project-neutral.
But you still could find the worktree root using project.el, and then
read the contents of .git, follow the link and do your automation stuff.
bug-gnu-emacs <at> gnu.org:bug#61817; Package emacs.
(Mon, 27 Feb 2023 14:16:01 GMT) Full text and rfc822 format available.Message #17 received at 61817 <at> debbugs.gnu.org (full text, mbox):
From: Arthur Miller <arthur.miller <at> live.com> To: Dmitry Gutov <dgutov <at> yandex.ru> Cc: 61817 <at> debbugs.gnu.org Subject: Re: bug#61817: 30.0.50; Project.el finds incorrect project roots in git worktrees Date: Mon, 27 Feb 2023 15:15:42 +0100
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 27/02/2023 09:32, Arthur Miller wrote:
>> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>>
>>> On 26/02/2023 18:23, Arthur Miller wrote:
>>>> What actions trigger the bug:
>>>> Two different, unrelated repositories with emacs source code tree. My tree(s)
>>>> looks like this:
>>>> ~/repos/emsrc/emacs/
>>>> ~/repos/enacs-tests/emacs/
>>>> Where in both the last "emacs/" is the Emacs source tree from main git
>>>> repository.
>>>> ~/repos/emsrc/emacs/ is the one I use for my "everyday" Emacs. I build Emacs
>>>> now
>>>> and then once in a week or few weeks with a script, and I make each build in its
>>>> own our-of-source worktree. The other one is one where I used to do some tests.
>>>> It shouldn't matter since all worktrees are contained withing parent directory,
>>>> which in one case is "emsrc" and in the other case "emacs-tests", but for some
>>>> reason project.el sees the wrong one.
>>>> 1. create two parent folders each one containing a copy of emacs sources
>>>> 1. create out of source worktree for Emacs source under one of those
>>>> 2. navigate to the worktree/lisp/progmodes
>>>> 3. run M-: (project-known-project-roots)
>>>> In my Emacs, I am in my currently installed emacs worktree, where git root is
>>>> ~/repos/emsrc/emacs but project.el returns ("~/repos/emacs-tests/emacs/") as a
>>>> result
>>>
>>> What does (project-root (project-current)) return? And which dirs you are
>>> testing it in?
>> It returns the current worktree folder:
>> "/home/arthur/repos/emsrc/no-gtk-with-cairo-and-native-230226-061643/"
>> which I guess is what project.el finds as root since it only uses .git as a
>> marker, if I understand correctly what you write little further.
>>
>>>> I am not chasing the bug, but I don't see much code in project.el related
>>>> to worktrees.
>>>
>>> Normally, there shouldn't be any need to handle worktree specially: it contains
>>> a file called .git at the top which can serve as a marker just fine.
>> Well define "normally" and "just fine" :). Anyway, when I read your reply it
>> seems
>> like I have wrong expectation from project.el, so the fault is on my side. I
>> thought it can deal with git projects in general, but as I understand it then,
>> it only works with files in current directory.
>
> We could change project-try-vc to follow the link to the parent repo, but how is
> the rest of it going to work?
>
> If the project root is the parent repo, which set of files would (project-files
> pr) return? And how could that be implemented?
I don't know how it works now, so I can't really tell you, but you have called
git root "actual git root", so perhaps something that differentiate between
directory hierarchy root (worktree), and real git root (project). Perhaps
project-vc-root, if you don't already use that name, or something similar?
>>>> The only place I see them mentioned is about submodules.I
>>>> personally have used this one for quite some time, and it seems to correctly
>>>> handle worktrees for me:
>>>
>>> You code looks like it can return the "actual git root" that can be a directory
>>> residing somewhere else than the current directory tree.
>> Git worktrees can be placed outside the main repository tree:
>> git worktree add ../my-new-shiny-emacs-patch
>> as an example. The code will find correct git root both outside, or within the
>> repo.
>
> Exactly.
>
>> But I think it should be done by actually asking git to list worktrees
>> instead.
>>
>>> Is that what you
>>> wanted?
>> Yes that is what I wanted? :-).
>> For automation purpose I need to find the project root, so I can pull sources
>> to
>> main, create a clean worktree from main, and switch Emacs to the new worktree
>> interactively in one command, like M-x make-new-patch. Emacs asks me for a name
>> and create a clean worktree from the main trunk for current project. Actually
>> better variant is to ask which branch to patch, but the first one is slightly
>> faster and works just fine in many cases.
>
> It sounds like your code is Git-specific, not project-neutral.
Yepp. Question is what project.el then really is, if it can't handle vc specific
"projects", if it is only synomim for operations on directory trees? Perhpas it
should be called dirtree.el, because that is what it does: it works on
directory trees and uses "project markers" to know where to start/stop? I am not
trying to by sarcastic or negative. I don't mean it is not useful, we need both,
operations that work as projectile/project, on directory trees, but also those
that actually understand a possible project structure. To me projectile and now
project.el seems more like they are an extension to Dired, not in some negative
connotation, but at least conceptually, then really project handling. I am not
trying to be negative, I am a bit oversimplistic and exaggerating, becuase I am
trying to illustrate the difference how I think about "projects".
Version control has become an integral part of all projects, at least in
software industry, just as building projects, boilerplate generating projects
etc. What I am saying is that project-neutral is OK, we don't want just a
different name for Git commands, but any project library nowadays should be able
to work with vc systems, build systems etc. At least for software management
projects.
> But you still could find the worktree root using project.el, and then read the
> contents of .git, follow the link and do your automation stuff.
Yeah, but it what does it saves me? In Git case it is really synonym to:
(git-dir (locate-dominating-file directory ".git"))
I can just as well call built-in function instead of requiring project.el.
As said I thought project.el was more general to work with projects on a deeper
level, sort-of EDE replacement or complement, and I wanted to use it as library,
but I understand now it is not.
bug-gnu-emacs <at> gnu.org:bug#61817; Package emacs.
(Mon, 27 Feb 2023 22:40:02 GMT) Full text and rfc822 format available.Message #20 received at 61817 <at> debbugs.gnu.org (full text, mbox):
From: Dmitry Gutov <dgutov <at> yandex.ru> To: Arthur Miller <arthur.miller <at> live.com> Cc: 61817 <at> debbugs.gnu.org Subject: Re: bug#61817: 30.0.50; Project.el finds incorrect project roots in git worktrees Date: Tue, 28 Feb 2023 00:39:48 +0200
On 27/02/2023 16:15, Arthur Miller wrote: >> We could change project-try-vc to follow the link to the parent repo, but how is >> the rest of it going to work? >> >> If the project root is the parent repo, which set of files would (project-files >> pr) return? And how could that be implemented? > > I don't know how it works now, so I can't really tell you, but you have called > git root "actual git root", so perhaps something that differentiate between > directory hierarchy root (worktree), and real git root (project). Perhaps > project-vc-root, if you don't already use that name, or something similar? Do you mean you want a separate helper to get to the "worktree parent" repository? We could add something like that to VC, I guess. But your own code seems to be working well too. I haven't had a use for "worktree parent" myself, though. And until we get a good idea for how people will use a feature, it's a little difficult to choose a place for it. >>> Yes that is what I wanted? :-). >>> For automation purpose I need to find the project root, so I can pull sources >>> to >>> main, create a clean worktree from main, and switch Emacs to the new worktree >>> interactively in one command, like M-x make-new-patch. Emacs asks me for a name >>> and create a clean worktree from the main trunk for current project. Actually >>> better variant is to ask which branch to patch, but the first one is slightly >>> faster and works just fine in many cases. >> >> It sounds like your code is Git-specific, not project-neutral. > > Yepp. Question is what project.el then really is, if it can't handle vc specific > "projects", if it is only synomim for operations on directory trees? Perhpas it > should be called dirtree.el, because that is what it does: it works on > directory trees and uses "project markers" to know where to start/stop? I am not > trying to by sarcastic or negative. It uses VCS-specific information and converts it to a shape that should be usable without the caller being aware of which underlying data that information is determined by. In particular, it reads .gitmodules, .git and .gitignore. And, well, different backends can make different decisions on the backends's behavior. But, ideally, it should be good for the majority of uses. Such as our built-in commands, for example: project-vc-dir, project-eshell, etc. > I don't mean it is not useful, we need both, > operations that work as projectile/project, on directory trees, but also those > that actually understand a possible project structure. To me projectile and now > project.el seems more like they are an extension to Dired, not in some negative > connotation, but at least conceptually, then really project handling. I am not > trying to be negative, I am a bit oversimplistic and exaggerating, becuase I am > trying to illustrate the difference how I think about "projects". It a way -- yes, because we describe a project as a set of files. With a well-defined root. But it doesn't absolutely have to be in the shape of a single directory tree, though it usually is. Whenever one chooses a different shape, though, they should consider how that will affect the common uses. > Version control has become an integral part of all projects, at least in > software industry, just as building projects, boilerplate generating projects > etc. What I am saying is that project-neutral is OK, we don't want just a > different name for Git commands, but any project library nowadays should be able > to work with vc systems, build systems etc. At least for software management > projects. You seem to be assigning a lot of meaning to the fact that the root doesn't point to "worktree root", but to the current repository root (modulo the search in the parent directory when the current repo is detemined to be a submodule). But would it be a better choice? When I use worktrees, it's to carry on development in a certain branch. Meaning, I need to be able to pull/push/commit in that branch, all within the same worktree. To do a pull, or to run some commands in that worktree, I can call project-eshell. To do a commit, I can call up project-vc-dir. In both cases, the useful thing to do for 'project-root' is to return the current repository root, not the worktree parent. Because you don't make new commits in the parent repo when working on a worktree, you make them in the current one. I'm all for adding new Version Control related features, but they should be based off realistic, specific user scenarios. >> But you still could find the worktree root using project.el, and then read the >> contents of .git, follow the link and do your automation stuff. > > Yeah, but it what does it saves me? In Git case it is really synonym to: > > (git-dir (locate-dominating-file directory ".git")) > > I can just as well call built-in function instead of requiring project.el. Sure. locate-dominating-file is an underrated function. If you just want to find the current repository root (no matter if it's a submodule or etc), the above will easily work. project-try-vc adds some caching on top of that, but you might not need it. > As said I thought project.el was more general to work with projects on a deeper > level, sort-of EDE replacement or complement, and I wanted to use it as library, > but I understand now it is not. The idea was for a more simple/transparent and extensible EDE alternative. Or an extension point to plug Projectile in. It can still grow some additions (such as build tool support), but for now we have what we have.
bug-gnu-emacs <at> gnu.org:bug#61817; Package emacs.
(Tue, 28 Feb 2023 00:35:01 GMT) Full text and rfc822 format available.Message #23 received at 61817 <at> debbugs.gnu.org (full text, mbox):
From: Arthur Miller <arthur.miller <at> live.com> To: Dmitry Gutov <dgutov <at> yandex.ru> Cc: 61817 <at> debbugs.gnu.org Subject: Re: bug#61817: 30.0.50; Project.el finds incorrect project roots in git worktrees Date: Tue, 28 Feb 2023 01:34:23 +0100
Dmitry Gutov <dgutov <at> yandex.ru> writes: > On 27/02/2023 16:15, Arthur Miller wrote: > >>> We could change project-try-vc to follow the link to the parent repo, but how is >>> the rest of it going to work? >>> >>> If the project root is the parent repo, which set of files would (project-files >>> pr) return? And how could that be implemented? >> I don't know how it works now, so I can't really tell you, but you have called >> git root "actual git root", so perhaps something that differentiate between >> directory hierarchy root (worktree), and real git root (project). Perhaps >> project-vc-root, if you don't already use that name, or something similar? > > Do you mean you want a separate helper to get to the "worktree parent" > repository? I wouldn't call it "worktree parent", because it relatively git specific; if you prefer to be project neutral; but something like that yes. > repository? We could add something like that to VC, I guess. But your own code > seems to be working well too. I didn't meant to ask for someone to write it for me :), I can use my own code, but as said I had somewhat different expectation from project.el when I did this request. You can just close it, it is ok; I am sorry for the trouble. > I haven't had a use for "worktree parent" myself, though. And until we get a > good idea for how people will use a feature, it's a little difficult to choose a > place for it. If you have a branch "main", work in a branch X, and would like to test/fix something unrelated to X, wouldn't you create a new workree Y from clean "main"? It is a bit special case, which I personally use, so to automate this, "worktree" as root is not enough, I need the actual root. For other purposes I need the worktree. So as said, both are needed. Of course, worktree will be used more frequently for natural reasons. More general case is to create patch for some unrelated branch Z, in which case I am not sure, but I believe I need to exec git branch and/or git worktree list and parse the output to see where to jump, and from which branch and directory to create a new worktree. >>>> Yes that is what I wanted? :-). >>>> For automation purpose I need to find the project root, so I can pull sources >>>> to >>>> main, create a clean worktree from main, and switch Emacs to the new worktree >>>> interactively in one command, like M-x make-new-patch. Emacs asks me for a name >>>> and create a clean worktree from the main trunk for current project. Actually >>>> better variant is to ask which branch to patch, but the first one is slightly >>>> faster and works just fine in many cases. >>> >>> It sounds like your code is Git-specific, not project-neutral. >> Yepp. Question is what project.el then really is, if it can't handle vc >> specific >> "projects", if it is only synomim for operations on directory trees? Perhpas it >> should be called dirtree.el, because that is what it does: it works on >> directory trees and uses "project markers" to know where to start/stop? I am not >> trying to by sarcastic or negative. > > It uses VCS-specific information and converts it to a shape that should be > usable without the caller being aware of which underlying data that information > is determined by. > > In particular, it reads .gitmodules, .git and .gitignore. > > And, well, different backends can make different decisions on the backends's > behavior. But, ideally, it should be good for the majority of uses. Such as our > built-in commands, for example: project-vc-dir, project-eshell, etc. Yes, they are nice, and they illustrate that for some purpose, worktree is needed. >> I don't mean it is not useful, we need both, >> operations that work as projectile/project, on directory trees, but also those >> that actually understand a possible project structure. To me projectile and now >> project.el seems more like they are an extension to Dired, not in some negative >> connotation, but at least conceptually, then really project handling. I am not >> trying to be negative, I am a bit oversimplistic and exaggerating, becuase I am >> trying to illustrate the difference how I think about "projects". > > It a way -- yes, because we describe a project as a set of files. With a > well-defined root. But it doesn't absolutely have to be in the shape of a single > directory tree, though it usually is. > > Whenever one chooses a different shape, though, they should consider how that > will affect the common uses. It is not about the shape; you can put a worktree as a subdirectory in a main repository, it does not need to be out of source tree; project.el will still not find the real git root. You can test it yourself in Emacs source: In Emacs repo create new worktree: git worktree add new-test; change to newly created folder and test your tools, they will work only on new-test. >> Version control has become an integral part of all projects, at least in >> software industry, just as building projects, boilerplate generating projects >> etc. What I am saying is that project-neutral is OK, we don't want just a >> different name for Git commands, but any project library nowadays should be able >> to work with vc systems, build systems etc. At least for software management >> projects. > > You seem to be assigning a lot of meaning to the fact that the root doesn't > point to "worktree root", but to the current repository root (modulo the search > in the parent directory when the current repo is detemined to be a submodule). > > But would it be a better choice? I don't think it is either one; definitely not an exclusive choice. I tried to say that we need both. But the root :) of this discussion, is that I missunderstood project.el as an attempt to create a useful middleware for general working with projects, but I guess you and other authors are more seeing it as an end-user application. I appologize, I should have probably looked more into the code and asked. I just tried to use some functions :). > When I use worktrees, it's to carry on development in a certain branch. Meaning, > I need to be able to pull/push/commit in that branch, all within the same > worktree. Yes, in some cases that is a workflow. But there are cases when its prefered to checkout other branch, while work on something else; and as said above, in that case is prefered to make a new worktree from either "clean" main or some other branch. > To do a pull, or to run some commands in that worktree, I can call > project-eshell. To do a commit, I can call up project-vc-dir. In both cases, the > useful thing to do for 'project-root' is to return the current repository root, > not the worktree parent. Because you don't make new commits in the parent repo > when working on a worktree, you make them in the current one. In this cases yes; but in some other cases no. Uses you mention are definitely more frequent, then checking out unrelated branch, but I don't think it is so uncommon either. > I'm all for adding new Version Control related features, but they should be > based off realistic, specific user scenarios. Automation. I don't want to open terminal (or magit, does not matter), switch branches and do that stuff manually (if I don't have to). >>> But you still could find the worktree root using project.el, and then read the >>> contents of .git, follow the link and do your automation stuff. >> Yeah, but it what does it saves me? In Git case it is really synonym to: >> (git-dir (locate-dominating-file directory ".git")) >> I can just as well call built-in function instead of requiring project.el. > > Sure. locate-dominating-file is an underrated function. If you just want to find > the current repository root (no matter if it's a submodule or etc), the above > will easily work. project-try-vc adds some caching on top of that, but you might > not need it. I didn't know you have caching in project.el; that is a good feature to have. I personally don't need it, but definitely good to know it is there. >> As said I thought project.el was more general to work with projects on a deeper >> level, sort-of EDE replacement or complement, and I wanted to use it as library, >> but I understand now it is not. > > The idea was for a more simple/transparent and extensible EDE alternative. Or an > extension point to plug Projectile in. Ede is extensible; it is just a bit arcane and there is not too much documentation, unfortunately. I would prefer if Ede was re-used instead of the duplicated effort, but I do understand if you want to replace it. > It can still grow some additions (such as build tool support), but for now we > have what we have. In my opinion, Emacs lacks 1) a good and easy to use boiler-plate generator framework. Ede is meant for that, but it is arcane to use and is meant to be used with existing projects. Also, Emacs will automatically create a new folder if asked to find-file, when folder does not exists. But, if a foder exists, it creates new file in that folder, which is not preferred behavior. In the end, as an end-user I have to manually create folders or run scripts before I can ask Ede to fill-in with some code generator. There is no reason to not automate project generation. We do have all the tools in Emacs already but I haven't seen any good generator. Maybe there is some, but I am not aware of one. I am playing with a little framework based on org-capture; but it is nothing polished I wish to share with anyone. With boilerplate I mean init git, generate readme, lsp database, makefiles and that sort of stuff. I think a combo between Ede and project.el would be nice. 2) better integration with tools for common workflow(s). Adding features, fixes, tests etc, is mostly about creating a new patch, which with addition of worktrees in Git can be super nicely automated. For example: add new library, or add new executable, or add new fix, it all boiles down to add new branch which leads to add new worktree, add a possible target in Makefile, create possibly a test file, probably some other thing. It would be nice to be able to say: M-x add-new-shared-library or M-x add-new-executable, or M-x add-new-fix and Emacs will do at least initial boilerplate. If you plan to add build tool support to project.el, it would be welcome :).
Dmitry Gutov <dgutov <at> yandex.ru>:Arthur Miller <arthur.miller <at> live.com>:Message #28 received at 61817-done <at> debbugs.gnu.org (full text, mbox):
From: Dmitry Gutov <dgutov <at> yandex.ru> To: Arthur Miller <arthur.miller <at> live.com> Cc: 61817-done <at> debbugs.gnu.org Subject: Re: bug#61817: 30.0.50; Project.el finds incorrect project roots in git worktrees Date: Wed, 1 Mar 2023 01:51:09 +0200
On 28/02/2023 02:34, Arthur Miller wrote: > Dmitry Gutov <dgutov <at> yandex.ru> writes: > >> On 27/02/2023 16:15, Arthur Miller wrote: >> >>>> We could change project-try-vc to follow the link to the parent repo, but how is >>>> the rest of it going to work? >>>> >>>> If the project root is the parent repo, which set of files would (project-files >>>> pr) return? And how could that be implemented? >>> I don't know how it works now, so I can't really tell you, but you have called >>> git root "actual git root", so perhaps something that differentiate between >>> directory hierarchy root (worktree), and real git root (project). Perhaps >>> project-vc-root, if you don't already use that name, or something similar? >> >> Do you mean you want a separate helper to get to the "worktree parent" >> repository? > > I wouldn't call it "worktree parent", because it relatively git specific; if you > prefer to be project neutral; but something like that yes. It's a Git-based relation. Depending on how we might define a "project parent" in the future (probably as "project of root's parent directory", though), and how the worktrees reside on disk relative to the parent, these notions won't necessarily match. >> repository? We could add something like that to VC, I guess. But your own code >> seems to be working well too. > > I didn't meant to ask for someone to write it for me :), I can use my own > code, but as said I had somewhat different expectation from project.el when I > did this request. You can just close it, it is ok; I am sorry for the trouble. Sure, closing. I just didn't want to shut the thread down before all questions are answered. >> I haven't had a use for "worktree parent" myself, though. And until we get a >> good idea for how people will use a feature, it's a little difficult to choose a >> place for it. > > If you have a branch "main", work in a branch X, and would like to test/fix > something unrelated to X, wouldn't you create a new workree Y from clean "main"? > It is a bit special case, which I personally use, so to automate this, "worktree" > as root is not enough, I need the actual root. For other purposes I need the > worktree. So as said, both are needed. Of course, worktree will be used more > frequently for natural reasons. That sounds like a fine approach, though not the only possible one. I usually have a limited number of worktrees: some constant, and some for temporary branches. I suppose it depends whether you need to create some configuration files specific to the local system when deploying and testing a new repository checkout. >>> I don't mean it is not useful, we need both, >>> operations that work as projectile/project, on directory trees, but also those >>> that actually understand a possible project structure. To me projectile and now >>> project.el seems more like they are an extension to Dired, not in some negative >>> connotation, but at least conceptually, then really project handling. I am not >>> trying to be negative, I am a bit oversimplistic and exaggerating, becuase I am >>> trying to illustrate the difference how I think about "projects". >> >> It a way -- yes, because we describe a project as a set of files. With a >> well-defined root. But it doesn't absolutely have to be in the shape of a single >> directory tree, though it usually is. >> >> Whenever one chooses a different shape, though, they should consider how that >> will affect the common uses. > > It is not about the shape; you can put a worktree as a subdirectory in a main > repository, it does not need to be out of source tree; project.el will still not > find the real git root. You can test it yourself in Emacs source: Indeed, it won't, because nobody told it it should traverse up to "worktree parent", always or under certain condition. That structure would also be quite weird, though: root in dir A, but all project files residing in some sub-sub-directory D of A. Doesn't that sound weird? > In Emacs repo create new worktree: git worktree add new-test; change to newly > created folder and test your tools, they will work only on new-test. Sure. Just keep in mind that worktrees are not always a subdirectory of the "worktree parent". I keep them side-by-side, for example. >>> Version control has become an integral part of all projects, at least in >>> software industry, just as building projects, boilerplate generating projects >>> etc. What I am saying is that project-neutral is OK, we don't want just a >>> different name for Git commands, but any project library nowadays should be able >>> to work with vc systems, build systems etc. At least for software management >>> projects. >> >> You seem to be assigning a lot of meaning to the fact that the root doesn't >> point to "worktree root", but to the current repository root (modulo the search >> in the parent directory when the current repo is detemined to be a submodule). >> >> But would it be a better choice? > > I don't think it is either one; definitely not an exclusive choice. I tried to > say that we need both. Then the question would be how to provide both of those pieces of information to callers. If we add the constraint that it has to be in some abstract way (independent from Git), then the answer is probably "no way". But the feature with "parent" projects will likely satisfy some uses and scenarios. > But the root :) of this discussion, is that I missunderstood project.el as an > attempt to create a useful middleware for general working with projects, but I > guess you and other authors are more seeing it as an end-user application. I > appologize, I should have probably looked more into the code and asked. I just > tried to use some functions :). I do believe that it's a "useful middleware". And a trait of such middlewares is they usually try to present some abstraction over the implementation. >> When I use worktrees, it's to carry on development in a certain branch. Meaning, >> I need to be able to pull/push/commit in that branch, all within the same >> worktree. > > Yes, in some cases that is a workflow. But there are cases when its prefered to > checkout other branch, while work on something else; and as said above, in that > case is prefered to make a new worktree from either "clean" main or some other branch. Sure. >> I'm all for adding new Version Control related features, but they should be >> based off realistic, specific user scenarios. > > Automation. I don't want to open terminal (or magit, does not matter), switch > branches and do that stuff manually (if I don't have to). If, perhaps, we would add a command doing something like the above to project.el, or we envision somebody doing it in some popular extension, *and* it would be possible to do with several project backends (maybe real and potential ones), then that would sound like a feature for project.el. If a caller, OTOH, needs to know that they're working with Git, and with a particular project backend, to do what they wanted, then that would be a poor fit for the API. But we could try to fit in features in some other way. Adding them to the VC package, perhaps. >>> As said I thought project.el was more general to work with projects on a deeper >>> level, sort-of EDE replacement or complement, and I wanted to use it as library, >>> but I understand now it is not. >> >> The idea was for a more simple/transparent and extensible EDE alternative. Or an >> extension point to plug Projectile in. > > Ede is extensible; it is just a bit arcane and there is not too much > documentation, unfortunately. I would prefer if Ede was re-used instead of the > duplicated effort, but I do understand if you want to replace it. I honestly don't understand EDE enough to have a solid opinion. But it did seem to have some pronounced pieces that didn't make sense for projects I regularly interact with. >> It can still grow some additions (such as build tool support), but for now we >> have what we have. > > In my opinion, Emacs lacks > > 1) a good and easy to use boiler-plate generator framework. Ede is meant for that, > but it is arcane to use and is meant to be used with existing projects. Also, Emacs > will automatically create a new folder if asked to find-file, when folder does > not exists. But, if a foder exists, it creates new file in that folder, which is not > preferred behavior. > > In the end, as an end-user I have to manually create folders or run scripts > before I can ask Ede to fill-in with some code generator. > > There is no reason to not automate project generation. We do have all the tools > in Emacs already but I haven't seen any good generator. Maybe there is some, but > I am not aware of one. > > I am playing with a little framework based on org-capture; but it is nothing > polished I wish to share with anyone. With boilerplate I mean init git, generate > readme, lsp database, makefiles and that sort of stuff. I think a combo between > Ede and project.el would be nice. That sounds like a decent feature, though one that is often taken up by command line tools. It not quite clear what Emacs integration would add to that. Besides, perhaps being able to write templates in Org, or something. But the beauty of it, it doesn't have to be strongly bound to project.el. It can *use* project-current/project-root, but be a package of its own, with separate naming/features/hooks and language/framework detection. > 2) better integration with tools for common workflow(s). Adding > features, fixes, tests etc, is mostly about creating a new patch, which with > addition of worktrees in Git can be super nicely automated. For example: add new > library, or add new executable, or add new fix, it all boiles down to add new > branch which leads to add new worktree, add a possible target in Makefile, > create possibly a test file, probably some other thing. It would be nice to be > able to say: M-x add-new-shared-library or M-x add-new-executable, or M-x > add-new-fix and Emacs will do at least initial boilerplate. > > If you plan to add build tool support to project.el, it would be welcome :). Hmm, as I see it, this is split into two different parts: - Do a Git-specific thing (create a worktree), once per body of work. - Do a build tool specific thing, probably several. The thing about the latter, you have described pretty well the general direction of what features a hypothetical buildtool.el might contain. Alas, I have little experience with languages where you regularly do things like that (adding new shared libraries, new executables, other build artefacts), and it seems to be an open question whether there is point in adding a language agnostic API on top of that, or if people should just create c++-buildtool.el, java-buildtool.el, etc, separately without trying to unify the UI. If somebody else wanted to work on this, though, probably a fair amount of people on this list would welcome that, and help with advice/review/some later contributions.
bug-gnu-emacs <at> gnu.org:bug#61817; Package emacs.
(Wed, 01 Mar 2023 03:04:02 GMT) Full text and rfc822 format available.Message #31 received at 61817-done <at> debbugs.gnu.org (full text, mbox):
From: Arthur Miller <arthur.miller <at> live.com> To: Dmitry Gutov <dgutov <at> yandex.ru> Cc: 61817-done <at> debbugs.gnu.org Subject: Re: bug#61817: 30.0.50; Project.el finds incorrect project roots in git worktrees Date: Wed, 01 Mar 2023 04:03:19 +0100
[Message part 1 (text/plain, inline)]
Dmitry Gutov <dgutov <at> yandex.ru> writes: > Depending on how we might define a "project parent" in the future (probably as > "project of root's parent directory", though), and how the worktrees reside on > disk relative to the parent, these notions won't necessarily match. Sure, but I don't think they have to. I am just telling that we need both; my suggestion is to use project-vc-root, as the king of all roots; regardless of the shape of folder structures; and current-project-root for worktrees and what not. Just as a suggestion, more about this one little further below. >> If you have a branch "main", work in a branch X, and would like to test/fix >> something unrelated to X, wouldn't you create a new workree Y from clean "main"? >> It is a bit special case, which I personally use, so to automate this, "worktree" >> as root is not enough, I need the actual root. For other purposes I need the >> worktree. So as said, both are needed. Of course, worktree will be used more >> frequently for natural reasons. > > That sounds like a fine approach, though not the only possible one. Yeas; of course; there is never one approach only. > have a limited number of worktrees: some constant, and some for temporary > branches. I suppose it depends whether you need to create some configuration > files specific to the local system when deploying and testing a new repository > checkout. Exactly. The more general approach is to list branches with completing read and let user choose one to create a patch to. But the one I described is just a little quick-fix. M-x add-new-patch, and it does what I described above. >>> Whenever one chooses a different shape, though, they should consider how that >>> will affect the common uses. >> It is not about the shape; you can put a worktree as a subdirectory in a main >> repository, it does not need to be out of source tree; project.el will still not >> find the real git root. You can test it yourself in Emacs source: > > Indeed, it won't, because nobody told it it should traverse up to "worktree > parent", always or under certain condition. Exactly, so once in a worktree, current project.el can't find the "actual git root" as you called it. I would like it to be able too, so that I can use project.el as a "generic" library independent of VC system. > That structure would also be quite weird, though: root in dir A, but all project > files residing in some sub-sub-directory D of A. Doesn't that sound weird? Yes, it is very weird, and that why I too also make worktrees out of the main repo, parallel to it. I took it up because you wrote about choosing different shapes for directory structures and consequences, but I do same as you. > Then the question would be how to provide both of those pieces of information to > callers. If we add the constraint that it has to be in some abstract way > (independent from Git), then the answer is probably "no way". I am not sure myself; but obviously for the VC that does not support the feature, project-vc-root could return just what it returns now, and just act as a synonym for project-root, while for systems that do (git) it will return whatever actual root is? > I do believe that it's a "useful middleware". And a trait of such middlewares is > they usually try to present some abstraction over the implementation. Ok, can we then have some useful stuff like: project-add-new-patch and project-add-new-target or similar (I welcome better ideas); where at least some common actions are automated? project-vc-dir already does some VC stuff (push, pull etc), it can well provide some other useful abstractions? I can help to donate those, at least for Git, but the Git part is easy to write anyway. > If, perhaps, we would add a command doing something like the above to > project.el, or we envision somebody doing it in some popular extension, *and* it > would be possible to do with several project backends (maybe real and potential > ones), then that would sound like a feature for project.el. > > If a caller, OTOH, needs to know that they're working with Git, and with a > particular project backend, to do what they wanted, then that would be a poor > fit for the API. But we could try to fit in features in some other way. Adding > them to the VC package, perhaps. Exactly; I totally agree; that is why I have started discussion. I can do git-based everything easily myself, but instead of doing it git-based per definition I wanted to use project.el as an abstraction so my little project stuff can work in possibly other scenarios then just with Git. > I honestly don't understand EDE enough to have a solid opinion. But it did seem > to have some pronounced pieces that didn't make sense for projects I regularly > interact with. EDE seems interesting to me, because of the integration with rest of Emacs, speedbar etc, but I can't say I have much understanding of Ede myself. > That sounds like a decent feature, though one that is often taken up by command > line tools. It not quite clear what Emacs integration would add to > that. Besides, perhaps being able to write templates in Org, or something. As said: automation. I have nothing against command line, and I can certainly just write a little shell or elisp script to create a folder, copy some files, init git, generate some pieces etc. But everytime I do, manually, or writing a new script, I am repeating a set of dull steps, which are totally unnecessary and just take focus from what I really want to do. > Besides, perhaps being able to write templates in Org, or something. Well, I wouldn't say it is just "or something" and you don't need to use it in Org at all :). Org-capture does setup a small gui (read-key) and is easy to re-use. More important it provides a relatively familiar interface to writing Lisp property lists (capture templates) even to non-lispers :). org-capture is quite well accepted in Org community, I believe; and there are a lots of non-programmers which use it for wrting notes, mailes etc. I don't know; it is really small, already included, and usually already loaded into Emacs; and lots easier to use than some other alternatives to provide some basic gui and entry point for customization. I have attached a toy example for an illustration. I am sure I could resue transient, hydra, or just write my own too, but I want something that comes with Emacs which Hydra does not, and am not so familiar with transient myself, and I believe holds for lots of other people too. > But the beauty of it, it doesn't have to be strongly bound to project.el. It can > *use* project-current/project-root, but be a package of its own, with separate > naming/features/hooks and language/framework detection. Yes, of course, I know it can; that is what I already do. It does not even need to use Emacs, I can write it in Bash or as a script for cmd.exe; but that is not the quesiton. Currently I don't even use project.el, but as said, if it will provide more backends and abstractions, I would prefer to use it than to make my own git-specific everything. >> 2) better integration with tools for common workflow(s). Adding >> features, fixes, tests etc, is mostly about creating a new patch, which with >> addition of worktrees in Git can be super nicely automated. For example: add new >> library, or add new executable, or add new fix, it all boiles down to add new >> branch which leads to add new worktree, add a possible target in Makefile, >> create possibly a test file, probably some other thing. It would be nice to be >> able to say: M-x add-new-shared-library or M-x add-new-executable, or M-x >> add-new-fix and Emacs will do at least initial boilerplate. >> If you plan to add build tool support to project.el, it would be welcome :). > > Hmm, as I see it, this is split into two different parts: > > - Do a Git-specific thing (create a worktree), once per body of work. Yes, and to me this feels like a good target for an abstraction. Shouldn't something like that be in project-vc-dir app? > - Do a build tool specific thing, probably several. Again yes. That is the harder part, but there is a lot of freedom to implement just parts of it, and successively per tool, and so on, and the entry point could be the abstraction above. > The thing about the latter, you have described pretty well the general direction > of what features a hypothetical buildtool.el might contain. Alas, I have little > experience with languages where you regularly do things like that (adding new > shared libraries, new executables, other build artefacts), and it seems to be an > open question whether there is point in adding a language agnostic API on top of > that, or if people should just create c++-buildtool.el, java-buildtool.el, etc, > separately without trying to unify the UI. That does not have to be a build artefact, like .dll or .jar or .exe. It is just a "target". That is the beauty of Makefile which works just with targets and dependencies, and does not care what a target is. "clean" target as we know it from C or C++, or start or stop some web or system services are just as normal as building artefacts. > If somebody else wanted to work on this, though, probably a fair amount of > people on this list would welcome that, and help with advice/review/some later > contributions. Sure, I am happy to hear suggestions and opinions; especially if someone can help me to understand and re-use Ede for the tool integration. However; I am even more happy if you add something like project-vc-root (or choose any name you want), and some hooks or other abstraction for project-add/remove-* where * is any of patch, feature, target, ... something similar, I guess you get the idea :). Anyway, thank you for the kind answers and interesting discussion, and hope you don't mind I have deleted older parts; it was a bit hard tp read. so I have left just your latest and my answers (mostly); hope it is ok.
[project-capture.el (text/plain, attachment)]
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Wed, 29 Mar 2023 11:24:04 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.