Projectile known projects file randomly being wiped #185
Comments
|
+1 |
|
Hmm, that's likely caused by Did this issue start recently or it has been around for a while? |
|
I'm a new Emacs user so I can't say it has been around for a while, but I will say that when I was configuring projectile and helm-projectile for the first time, it worked fine. I continued configuring other stuff and it suddenly broke. |
|
@bbatsov the projectile standalone works as expected as far as I can judge, so, yes, I think your guess about helm-projectile is correct. The issue is new, I'd say it wasn't there a week or two ago Update: I've tried using an older version of helm-projectile (e2e3882), but the issue is still reproducible |
|
I don't think the change is related to issue 2.
I also don't see how it should be related to issue 1.
The only error I got now that I didn't got before that
helm-highlight-files wasn't bound before I added `(require
'helm-for-files)` I'm not sure if that is something that should be
required.
For me everything works fine.
my config can be found here in the repository thaodan/emacs.d if that
helps.
|
|
Interesting that |
|
I don't know if anyone was able to reproduce it, but not all subsequent calls work for me. However, the behavior is slightly different for subsequent calls. For the first call after restarting Emacs, the contents of the projectile-known-projects-file is still there but the list is empty. For subsequent calls, there is a chance that the file gets wiped, which returns an empty list in turn. As long as the contents of the file are still there, it works as expected. |
|
At this point I'm not sure why |
|
This solution works for the most part as in it fixes my initial problems, but the projectile commands don't have the same fuzzy matching as helm-projectile. |
|
Right, so I guess a proper fix needed. I have the same config on my other laptop, which doesn't have this issue. I can check which projectile/helm/helm-projectile versions are installed there. I think it can be an integration issue Update: projectile-2.8.0, helm-projectile-1.0.0, helm-4.0 work fine |
|
I found the source of the issue in |
|
@bbatsov unfortunately the fix didn't help in my case |
|
Same here, just updated (snapshot 7a9497c) and I am observing the same behavior. |
|
I'm not sure if that makes a difference but should the options be set
and then projectile-mode on?
In my config[1] I enable projectile-mode after setting options such as
e.g. projectile-project-search-path.
[1] https://github.com/Thaodan/emacs.d/blob/master/init.org#projectile
|
|
It used to matter in the past, but now it doesn't as Projectile initializes the known projects only when you trigger some project switching action, and that's what caused the problem for I assume for most people the way to use |
|
Please test my second attempt to fix this. I hope I got it right this time around. |
|
Fixed it for me. Thanks! |
|
@bbatsov The fix still doesn't help. I can reproduce the issue, but now it manifests somehow differently. Also, I noticed that projectile-bookmarks.eld gets corrupted. Here is what it looks like (I opened two projects: emacs and awesome) I also created manually the projectile-bookmarks.eld, launched emacs and invoked |
|
Hmm, I'm out of ideas then. I'm still fairly certain there's some issue with I can't imagine how those |
|
Since testing e2e3882 didn't work. How
should it be related to the definition of helm-projectile-projects-source?
|
|
I did some bisecting by installing old packages one by one: Firstly, I installed helm-projectile 1.0.0 from melpa-stable + applied this patch 5813f72, as helm-projectile is broken in the stable repository. After this step I see no corruption anymore, but the list of projects is always empty Secondly, I installed projectile 2.8.0. After this step, I see no issues at all (just like on my other laptop where those packages are also installed). So, the combination of projectile 2.8.0, helm-projectile 1.0.0 and the latest version of helm (20250204.1208) works as expected |
|
A bit of extra context - I'm pretty sure this change bbatsov/projectile@7d5e816 caused the breakage here, but I think my recent changes to I'm guessing one bullet-proof fix would be to be to have See this for how to use the debugger https://emacsredux.com/blog/2025/02/03/debugging-emacs-commands/ |
|
It seems the problems is that Helm inserts some project paths fontified (no idea how exactly), which is very weird and I'm not sure how exactly is this happening and what triggered it. I have an idea about the fix. Normally Emacs treats fontified strings as strings, though, so this should work in theory regardless that in looks weird in its serialized form. |
|
@ohamov Can you test with the commit before this one 9db7976 ? (probably you'll need to add I'm like 99% this weird fontification happens in helm-projectile, and this seems like the only recent changes that might have caused it. |
|
I'm linking here #186, as it seems another person has the issue with font-locked entries corrupting their project bookmarks. |
|
Bozhidar Batsov ***@***.***> writes:
@ohamov Great news! @Thaodan, so it seems that something in the source
definition change messed up how known projects are saved for some
people, but I'm struggling to understand how project names get saved
straight from the helm buffer with some fontification in place.
Hm the only difference I can see how `projectile-known-projects` is used
in `(helm-projectile-remove-known-project)`.
I see no other instances where projectile-known-projects is modified.
|
|
Same here, but it's definitely happening somewhere, otherwise people won't be getting those weird fontified |
I am not sure if this is the correct way to fix, yet this workaround seems to work in my case. I had very similar observations as others claimed in bbatsov#185 when trying to debug this issue. Namely, right after executing `helm-projectile-swithc-project` I observed that `projectile-known-projects` had names changed with fontification. Fixes bbatsov#185
|
I have observed very similar issues. Namely, that the list of know projects started to disappear and noticed in I proposed #187 as a fix: create a separate list of candidates. I am not sure if this is the best way to fix it. Perhaps @thierryvolpiatto could weight in on why the list uses as a source is updated (likely, but not necessarily) by |
|
Przemysław Kryger ***@***.***> writes:
1. ( ) text/plain (*) text/html
I have observed very similar issues. Namely, that the list of know projects started to disappear and noticed
Error during file deserialization: (invalid-read-syntax "#")
in *Messages* buffer. Also the ~/.emacs.d/projectile-bookmarks.eld had
strings with properties stored. I managed to narrow it to
helm-type-file added to helm-projectile-projects-source: when I took
it out, and evaluated the buffer the issue disappeared - I could
change the project with helm-projectile-switch-project).
I proposed #187 as a fix: create a separate list of candidates. I am
not sure if this is the best way to fix it. Perhaps @thierryvolpiatto
could weight in on why the list uses as a source is updated (likely,
but not necessarily) by helm.
I don't know what you are speaking about, I would have to install
helm-projectile (and I guess projectile as well) and look at the code.
But from what I understand helm-projectile is listing projects right?
If it adds text properties to these candidates (face, display, anything
else..) with e.g. add-text-properties, it modifies the candidates of
this list directly by side effect. If it then tries to save this list
of projects (by printing the list presumably) it tries to save
candidates like #("foo" 0 3 (face font-lock-warning-face)) and fails
with "invalid read syntax #" as expected.
Note:
This is just a thought, I know nothing about helm-projectile and
projectile, I use helm-browse-project to manage my projects.
…--
Thierry
|
Yeah, the problematic part of the code is just a Helm source linked to a list of Projectile projects that get modified when we didn't expect them to. But from what you wrote it seems these modification of the underlying source from Helm is expected. Do I get this right? What are we supposed to do if we want to avoid it. |
|
Bozhidar Batsov ***@***.***> writes:
1. ( ) text/plain (*) text/html
But from what I understand helm-projectile is listing projects right?
If it adds text properties to these candidates (face, display, anything
else..) with e.g. add-text-properties, it modifies the candidates of
this list directly by side effect. If it then tries to save this list
of projects (by printing the list presumably) it tries to save
candidates like #("foo" 0 3 (face font-lock-warning-face)) and fails
with "invalid read syntax #" as expected.
Yeah, the problematic part of the code is just a Helm source linked to a list of Projectile projects that get modified when we didn't expect them to. But from what you wrote it seems these
modification of the underlying source from Helm is expected. Do I get
this right? What are we supposed to do if we want to avoid it.
Strip out text properties before saving or using a copy of list (like in
#187) ?
…
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.*Message ID: ***@***.***>
--
Thierry
|
|
From how I understood it Helm has the ability to differentiate between
the transformed and the untouched state of candidates.
Since for example for the helm action the selected candidate works fine
without any modified applied it must be possible to apply the same to
saving them.
Or maybe the candidates mechanism always touches candidates variables
leaving the helm functions to ignore any properties applied to the text
in them.
|
@thierryvolpiatto I was thinking of stripping them, but I'm just not sure what exactly gets triggered by Helm here, as there are no direct references to |
|
Bozhidar Batsov ***@***.***> writes:
1. ( ) text/plain (*) text/html
Strip out text properties before saving or using a copy of list (like in
#187) ?
@thierryvolpiatto I was thinking of stripping them, but I'm just not
sure what exactly gets triggered by Helm here, as there are no direct
references to projectile-add-known-project (the function that updates
the project bookmarks) in helm-projectile.el. I might add it there to
be on safe side, but I've been trying to understand how the change of
the Helm source in #181 resulted in this.
In #181 the new class is inheriting from helm-type-files which use
helm-highlight-files which is in turn modifying by side effect the local
var used by the :candidates fn. This can be fixed by using a copy of
the local var or use your own filtered-candidate-transformer function
that should make a copy of the string before modifying it.
If it is a problem I could modify helm-highlight-files to ensure it
doesn't modify elements of the local var, let me know.
PS: When creating a new class inheriting from another one like in #181,
and modifying the initial slots you may not endup with what you expect
(verify your source with C-h d), in this case initialize your new slot
values with a helm--setup-source defmethod.
…--
Thierry
|
|
Hello Bozhidar,
Thierry Volpiatto ***@***.***> writes:
Bozhidar Batsov ***@***.***> writes:
> 1. ( ) text/plain (*) text/html
>
> Strip out text properties before saving or using a copy of list (like in
> #187) ?
>
> @thierryvolpiatto I was thinking of stripping them, but I'm just not
> sure what exactly gets triggered by Helm here, as there are no direct
> references to projectile-add-known-project (the function that updates
> the project bookmarks) in helm-projectile.el. I might add it there to
> be on safe side, but I've been trying to understand how the change of
> the Helm source in #181 resulted in this.
In #181 the new class is inheriting from helm-type-files which use
helm-highlight-files which is in turn modifying by side effect the local
var used by the :candidates fn. This can be fixed by using a copy of
the local var or use your own filtered-candidate-transformer function
that should make a copy of the string before modifying it.
Unfortunately, this may not be enough, see
emacs-helm/helm#2709 and
https://github.com/emacs-helm/helm/wiki/Developing#transformers-may-modify-by-side-effect-the-initial-list-of-candidates
where the real candidate may be corrupted as well by side effect.
…--
Thierry
|
There are 2 problems that I am running into:
In both cases, whenever I open a fresh Emacs client, I can't instantly switch to a project which is very annoying. Here is the relevant part of my config:
I am using projectile MELPA 2.9.0 and helm-projectile 1.1.0
The text was updated successfully, but these errors were encountered: