Forgot to add this counterpart for when you want to use a non-project
semaphore but also want to project-current to tell the truth about being a
non-project:

  (defun my/project-current-non-project-advice (orig-fun &rest args)
    (let ((p (apply orig-fun args)))
      (when (and p (string= (project-name p) my:project--non-project-dir))
        (setq p nil))
      p))
  (advice-add #'project-current :around
#'my/project-current-non-project-advice))

On Fri, Oct 11, 2024 at 10:35 AM Ship Mints <shipmints@gmail.com> wrote:

> In addition to guarding project-try-vc, I also have a customized cache for
> non-projects specifically to get around the incessant retesting for what
> are effectively invariant conditions.
>
> If of any utility to others:
>
> (use-package project
> ...
>   (defconst my:project--non-project-dir ".") ; nil disables the cache;
> NOTE: eglot relies on project-root so this has to be a real path
>   (defun my/project-try-non-project-cache (dir)
>     (unless (and my:project-vc-inhibit-remote (file-remote-p dir)) ; yet
> another optional remote guard
>       (let ((proj (cons 'transient (or my:project--non-project-dir
> (expand-file-name dir)))))
>         (vc-file-setprop dir 'project-vc proj) ; project caches via vc
> internal properties
>         proj)))
>   (add-to-list 'project-find-functions #'my/project-try-non-project-cache
> 'append))
>
>   ;; customized project current name function that respects
>   ;; non-project marker and returns nil if a non-project
>   (defun my/project-current-name (&optional buf)
>     "Return the current project name for BUF, or nil if a non-project.
> If BUF is nil, the current buffer is used."
>     (with-current-buffer (or buf (current-buffer))
>       (when-let* ((p (project-current))
>                   (pn (project-name p)))
>         (unless (string= pn my:project--non-project-dir)
>           pn))))
> ...
> )
>
> On Thu, Oct 10, 2024 at 8:38 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
>> On 09/10/2024 19:10, Juri Linkov wrote:
>> > Or maybe better to cache the value of project-name on remove projects.
>>
>> Just the project->project-name mapping? Why not. I suppose there'd still
>> be a pause when switching projects, but it's not as bad.
>>
>> For general caching, from past threads it seems the most problematic
>> case is "no project". Because OT1H it's still costly it terms of remote
>> I/O. But on the other, this is exactly when the cache might get invalid
>> soon (because the user will initialize a Git repo, or create another
>> root marker, etc).
>>
>> I guess we should come back to this after bug#72300.
>>
>>
>>
>>