Feature request: Configurable Favorites Storage

[ww7]

In some cases, would be useful to have separate Favorites for Workspace or a certain folder.

As I understand, currently we have only two choices, <default> or absolute path.

I propose the next options:

• name - subfolder from Workspace root or from an opened folder, e.g. .favorites (relatively to current opened folder or Workspace root). If no custom folder exist - use <default>.

• Boolean setting Separate Favorites for Workspace, where we can choose if certain Workspace uses separate Favorites (where lists stored in subfolder with Workspace name inside <default>, these also can respect "favorites.dataLocation" and use name)

[oleg-shilo]

Great idea. Txs

[oleg-shilo]

Provided a wrong commit message the change 3efa1ae was about #22 not #this one.

[lonix1]

Where does <default> save to?

[oleg-shilo]

And then:

[lonix1]

awesome thanks!

[ww7]

How does this work now?

Seems only absolute path and \ works.

Привет. В документации не описано как задания пути хранения работает. На данный момент только \ и полный кастомный путь?

Я предлагал две идеи для добавления портативности.

1) Возможности разделить фаворитесы для разных воркспейсов. Т.е. если задав: <workspace> - сохранит в подпапке с именем воркспейса в папке профиля VSCODE, т.е. по сути будет / Если открыт не workspace - использовать \ 2) Возможность использовать релятивные пути, т.е. если папку перенести, что бы могло подтягивать из текущей открытой корневой папки: например .favs - если в открытой папке/workspace есть подпапка .favs - сохранять туда, если нету - использовать \

[oleg-shilo]

Hi Serhii,

Sorry, I will stick to English. My Russian is rusty and the rest of the audience will also need to understand the discussion.

Indeed you proposed two options: "I propose the next options:". After considering both of them I have decided to chose the first one.

The reason - it is simpler and consistent with the existing persistence model. Splitting the storage into multiple locations is possible but can potentially lead to the confusing user experience (e.g. dealing with nested/grouped lists).

I hope it explains.

[ww7]

Hi Oleg, so how it can be configured additionally to \ and absolute path?

After considering both of them I have decided to choose the first one.

Path not available If I try e.g. .fav or .vscode/.fav

Is relative path not possible? Only some custom full path?

[oleg-shilo]

The description is here: https://github.com/oleg-shilo/Favorites.vscode#list-definition-rules

But to put it simple, you just create you normal fav list, open your workspace and then simply right-click the list (or any item) and select "associate..."

[oleg-shilo]

Saying that, if you feel you want to give it a crack with "relative path" feel free to experiment and if you have something working then push the PR and we can have a look at it.

Maybe sacrificing grouping is the way to go. May be not hiding the rest of the lists is the compromise to your original proposal that you are prepared to make...

[ww7]

Thanks. Basically, my requests are only around the possibility to use a relative path. I do not know JS, so maybe I create a new issue feature request.

[oleg-shilo]

Indeed create a feature request and I will give it a try. I am going to revisit all VSCode plugins anyway.

[oleg-shilo]

Done.

From v1.5.3 you can use workspace local list local.list.txt in the workspace folder <workspace>\.fav\

This list can contain both absolute and relative paths. All relative paths are to be resolved against the workspace folder. The simplest content of the .fav\local.list.txt:

.\.fav\local.list.txt 

[lonix1]

This new feature is really nice, thanks!

Usually vscode config goes into .vscode/. (It's cleaner to have all the config in one place, and more discoverable.)

Is it maybe possible to save it to .vscode/favorites.local.list (or similar) as well? Or to control by settings.

[oleg-shilo]

Usually vscode config goes into...

Not exactly, .vscode is not created for open folders (not workspaces).

Nevertheless, your proposal is still a possibility. Though this feature is rather experimental as it is very limited (e.g. there is no support for VSCode assisted creation/removal/editing of the local lists).

Thus we can do it in the future releases if the feature sticks.

[lonix1]

.vscode is not created for open folders (not workspaces).

I assume my strikeout edit is correct? In that case I don't use the workspace feature, I just open the directory with my code and .git/, and I use the .vscode/ feature.

So I guess I didn't understand this feature, sorry.

(That said, in the future it would be nice to specify .vscode/, but it's working well for now, thanks.)

[lonix1]

Actually I just read this which suggests I am indeed using workspaces, but it is a "single-folder workspace", whereas I assume you and the OP were discussing something more complicated than that.

[oleg-shilo]

.vscode is not created for open folders (not workspaces). I assume my strikeout edit is correct?

Yes, you are correct. It was my typo. And I also when I said " this feature is rather experimental as it is very limited" I meant storing the configuration in the local folders.

It is limited because it is not possible to provide a good user experience for adding an opened doc to global vs local list. The same goes for editing. You click "Edit list" button, but which list do you want to edit? The items from both lists are displayed.

It is possible to solve but it requires some strong UX considerations :)

Though since currently the workflow requires manual management of local lists, I sss no problems with extending the support for an alternative naming convention.

The release v1.5.5: https://github.com/oleg-shilo/Favorites.vscode/releases/tag/v1.5.5

Supports an additional local list location: <workspace/folder>\.vscode\fav.local.list.txt. As you suggested.

Though I don't want to annoy the users with too frequent updates so did not publish the release on marketplace but only on GitHub and as a pre-release.

[lonix1]

That is amazing I'm gonna check it out thanks!

Yes frequent releases annoys me too... there are some plugins that update every second day! :rage:

[oleg-shilo]

Yes, it was. To chavlji credit, in this very stressful situation, he remained constructive and assisted with the fix so it was released super quickly. Just under 2 hours.

...I can't help but feel it's my fault too...

I know the feeling, mate :) But no, the reason was not related. The initial implementation of the node->right-click->rename had a bug. It did not ensure that the note item is a "favorites list". in this case, it was a folder so it renamed that folder.

I wish module 'fs' had separate fs.rename methods like in C# File.Rename and Directory.Rename. Then it would just throw an exception. But Node does it transparently for files and folders....

What is even more annoying is that in this case it was fs.rename('c:\a\b\c\folder_name', 'c:\d\e\f\new_file_name') and mode did not throw the exception but moved!!!! thefolder and renamed it.

[lonix1]

What is annoying is node's documentation. I've been spoilt by MSDN and now the docs.microsoft site, so maybe I'm expecting too much? :man_shrugging: :smile:

BTW just realised you're the guy that made the c# runner extension as well, it's one heck of an extension... thank you!

[oleg-shilo]

Yes I am 😄 I have been in this game for quite some time. And CS-Script (C# script), my starer project, is quite a vehicle that triggered so many derivative products/projects

[lonix1]

Then please allow me to ask an off topic question. I have one or two ideas for vscode extensions, but haven't pursued them. I used to make firefox addons but found the "community" to be a bunch of entitled unappreciative whiney snobs. I assume it's the same for vscode, nerds are nerds (I guess I'm one too :stuck_out_tongue_winking_eye:).

Is there any benefit for authoring extensions - given you've made that mega extension, do you find, for example, it helps job prospects (I imagine not)? Or is it purely for fun / self satisfaction (that was what it was for me, until users complained about silly things, I lost interest).

[oleg-shilo]

It's a difficult question that lies in the "meaning of life" domain. :)

I know very well the feeling. I remember a few cases when my work was bashed without even explaining the reason by someone with the "I do it because I can" attitude. I had a case or two on VSCode too.

Though I cannot really say it was often. And still consider vscode community as an OK crowd :) I cannot particularly complain.

I found that the most pragmatic way of handling "whiney snobs" is to ask them to explain the problem, to help you to fix it. If you are dealing with a snob then there is no response and everyone can see the troll. If it is a genuinely upset but constructive user then collaboration starts. And the outcome is actually mutually beneficial. The user gets the problem solved and you ... well, you advertise your supporting skill. :)

As for hiring, when I am hiring a developer I am not interested in certifications. not at all. But show me your GitHub page and I will tell you if I am interested.

A person can lie, code cannot.

I believe with my last two jobs my public profile has played a strong role in the outcome.

[lonix1]

I'm not sure whether authoring vscode extensions will help me job-wise, but you've convinced me to try - if only to keep my typescript skills from rotting away. (Now with dotnet blazor, I've no need to use javascript anymore.)

Meaning of life questions: those are the best ones, especially for a slow Monday.

Take care and keep on making great extensions. :smiley: