Add Simplenote package

[RedAtman]

• I'm the package's author and/or maintainer.
• I have have read the docs.
• I have tagged a release with a semver version number.
• My package repo has a description and a README describing what it's for and how to use it.
• My package doesn't add context menu entries. *
• My package doesn't add key bindings. **
• Any commands are available via the command palette.
• Preferences and keybindings (if any) are listed in the menu and the command palette, and open in split view.
• If my package is a syntax it doesn't also add a color scheme. ***
• If my package is a syntax it is named after the language it supports (without suffixes like "syntax" or "highlighting").
• I use .gitattributes to exclude files from the package: images, test files, sublime-project/workspace.

My package is Simplenote

My package is similar to Quick Simplenote, However it should still be added because Sometimes it doesn't work properly in Sublime Text 3/4.

• UPDATES:
  • Python 3.8 compatibility
  • Sublime Text 3/4 compatibility
  • Bug fixes

Run the ChannelRepositoryTools: Test Default Channel command:
...............................................................................................................

Ran 9727 tests in 0.182s

OK

[kaste]

I wonder why that isn't a proper fork with all the history preserved. Could you make it a proper fork? And then we may consider replacing the old plugin with your new update. You don't claim any breaking changes either, just bug fixes and the general shift to python38 and ST4.

Have you actually reached out to the old maintainer?

[RedAtman]

I have been using the original plugin for a while, but it seems that the author is no longer updating it. I checked the code and found that there were many bugs in the new version of Sublime Text, and the code structure was quite cumbersome. Therefore, I rewrote the plugin, only borrowing the ideas, settings, and hotkey bindings. In fact, the code refactoring is about 70% complete.

[RedAtman]

In the future, I plan to add some new features to the plugin:

1. Replace the existing RESTful API with WebSocket to reduce network I/O.
2. Add a new note list display mode.
3. Automatically detect whether a note is in Markdown format and apply system tags to inform other platform clients.
   ...

[kaste]

I like it. This should still be a takeover because we don't need both packages, do we? E.g. we could pin Sublime Text 3 users to an old tag. For this to work, we would have needed the original commits, even if they would point to a different root. But you did not import/fork the old tags either. I probably need to clone your repo because I don't know if the GitHub webpage is just too limited to show the whole repo story.

Let's also wait what @braver says. IMO it should be a takeover with the minor package rename, and with a pinned old version that refers the last commit/tag of the original author. I really would have liked if @RedAtman had preserved the history of the code/project.

[RedAtman]

I re-forked the repository, preserving the existing tags, and created new tags for my new version.

[kaste]

Ah okay, you're moving fast here. Something is wrong with settings management as you must use load_settings() for them.
It looks like you assume the package is installed unpacked but is actually not (only your dev environment is unpacked). Package Control normally puts your package in a zip file in installed_packages_path() https://www.sublimetext.com/docs/api_reference.html#sublime.installed_packages_path

Thus, the following will not work https://github.com/RedAtman/simplenote/blob/bfb861bb5d138019df832dcbadf0a9ed05e1ea1a/simplenote.py#L31-L41

SIMPLENOTE_PACKAGE_PATH = os.path.join(sublime.packages_path(), SIMPLENOTE_PROJECT_NAME)
SIMPLENOTE_TEMP_PATH = os.path.join(SIMPLENOTE_PACKAGE_PATH, "temp")
_SIMPLENOTE_NOTE_CACHE_FILE = os.environ.get("SIMPLENOTE_NOTE_CACHE_FILE", "note_cache.pkl")
SIMPLENOTE_NOTE_CACHE_FILE = os.path.join(SIMPLENOTE_PACKAGE_PATH, _SIMPLENOTE_NOTE_CACHE_FILE)
SIMPLENOTE_NOTE_FETCH_LENGTH = int(os.environ.get("SIMPLENOTE_NOTE_FETCH_LENGTH", 1000))
_SIMPLENOTE_SETTINGS_FILE = os.environ.get("SIMPLENOTE_SETTINGS_FILE", "simplenote.sublime-settings")
SIMPLENOTE_SETTINGS_FILE = os.path.join(SIMPLENOTE_PACKAGE_PATH, _SIMPLENOTE_SETTINGS_FILE)
# SETTINGS = sublime.load_settings(SIMPLENOTE_SETTINGS_FILE)
SETTINGS: Settings = Settings(SIMPLENOTE_SETTINGS_FILE)

[RedAtman]

I have refactored the logic for the settings. Please check if it meets our expectations.

[kaste]

The settings handling is looking good.

But keep in mind that SIMPLENOTE_PACKAGE_PATH = os.path.join(sublime.packages_path(), SIMPLENOTE_PROJECT_NAME) exactly this path does not exist for end-users. You need check that and maybe create it. I don't know what you want to store there. Maybe use os.path.join(sublime.cache_path(), SIMPLENOTE_PROJECT_NAME), but that directory would not exist by default too!

[packagecontrol-bot]

Automated testing result: WARNING

Repo link: Simplenote
Results help

Packages added:
  - Simplenote

Processing package "Simplenote"
  - WARNING: The package does not contain a top-level LICENSE file. A license helps users to contribute to the package.

[RedAtman]

The settings handling is looking good.

But keep in mind that SIMPLENOTE_PACKAGE_PATH = os.path.join(sublime.packages_path(), SIMPLENOTE_PROJECT_NAME) exactly this path does not exist for end-users. You need check that and maybe create it. I don't know what you want to store there. Maybe use os.path.join(sublime.cache_path(), SIMPLENOTE_PROJECT_NAME), but that directory would not exist by default too!

Okay, your suggestion was good. I have completed it and created a new tag.

[kaste]

• I still don't fully grasp the way you do the settings. Why do you have still a simplenote.sublime-settings.example file here. Why the false/fake extension ".example". That would mean a user MUST first create a settings file before anything will work. Is it so that you cannot assume good defaults so that the user is really required to do that before the plugin can work?

• By convention, the commands must be namespaced using the name of the package. Eg. you use note_list which should be simplenot_list etc.

• You ship a Markdown.tmLanguage. Why do you want that? Sublime already ships a Markdown syntax. Probably remove that file.

• Since all keymap files have the same content, don't ship platform specific files at all. E.g. delete all *.keymap files and add a single Default.sublime-keymap file with the same content.

[RedAtman]

I'm all done. You are very patient.

[RedAtman]

What else needs to do?

[braver]

Some final tweaks to be made:

• You still have the ancient 2 separate menu entries for User/Default settings (and keymaps). Use the edit_settings command instead like so: https://github.com/braver/SideBarTools/blob/master/Main.sublime-menu#L17.
• Your settings and command files should match the package name (so properly capitalized).
• It's also always a good idea to be able to open the settings and keymaps from the command palette.
• Don't store the value of load_settings(), that might cause you to get stale settings values. Sublime Text already optimizes access to settings values for you, you shouldn't try to optimize on top of that. For instance, you can basically do load_settings() on keystroke and it won't meaningfully affect performance.

Looks like this is an improved version of the original. Unless @sickmartian opposes, we should replace the existing package so that existing users also finally get an update. Or maybe he could transfer the repo or otherwise let you manage the existing package. Let's give @sickmartian a few weeks to respond, but otherwise a takeover seems like the best way forward.

[sickmartian]

Thanks @braver for the tag, I was not aware of this fork until your message.

I would actually oppose a take over, while yes the original is discontinued and won't be updated anymore, any user that installed it might've gone through the repo and seen the docs and getting updates from a different repo sounds disingenuous and a recipe for supply chain attacks. I think the package should stand on it's own.

If you don't want duplicate packages you can remove mine, it's shitty for any remaining users that they will actually need to find and find the new plugin and install it, but I think them actually opting-in into the new source of code that will be executed into their machines and a new maintainer is the proper thing to do.

I won't point users to a new code/repo I haven't seen and a maintainer I don't know, same reason I won't transfer my repo or make them maintainer, they never reached out and did it on their own, so I think it should properly stand on it's own.

[braver]

Well I guess that’s a no 😉 While we prefer packages to be kept “alive” through contribution, forking, or whatever means are practical for that particular case, it’s not a requirement. You own your package and decide what happens with it.

So @RedAtman please just report back on that latest feedback and we’ll continue working towards shipping your addition to package control.

[RedAtman]

Some final tweaks to be made:

• You still have the ancient 2 separate menu entries for User/Default settings (and keymaps). Use the edit_settings command instead like so: https://github.com/braver/SideBarTools/blob/master/Main.sublime-menu#L17.
• Your settings and command files should match the package name (so properly capitalized).
• It's also always a good idea to be able to open the settings and keymaps from the command palette.
• Don't store the value of load_settings(), that might cause you to get stale settings values. Sublime Text already optimizes access to settings values for you, you shouldn't try to optimize on top of that. For instance, you can basically do load_settings() on keystroke and it won't meaningfully affect performance.

Looks like this is an improved version of the original. Unless @sickmartian opposes, we should replace the existing package so that existing users also finally get an update. Or maybe he could transfer the repo or otherwise let you manage the existing package. Let's give @sickmartian a few weeks to respond, but otherwise a takeover seems like the best way forward.

Thank you for your suggestions, I have now completed everything. and created a new release.

[RedAtman]

Well I guess that’s a no 😉 While we prefer packages to be kept “alive” through contribution, forking, or whatever means are practical for that particular case, it’s not a requirement. You own your package and decide what happens with it.

So @RedAtman please just report back on that latest feedback and we’ll continue working towards shipping your addition to package control.

Thank you all for taking this matter seriously. I am new to the open-source community, and my previous actions might have been a bit hasty. If @sickmartian still have time to update the code together., I would be honored to contribute to the original code and merge my new code into the original repository.

If the answer is no, I am also happy to offer my new code as a separate package. In the future, I might add some new features, such as replacing the current ReSTful API with Websocket, using sqlite as the database, or adding APIs for other notebook providers.

I like the simplicity of Simplenote and its extensible advantages in text display. However, the official client does not support fonts and styles very well. Therefore, I want to create a new client using Sublime Text's beautiful styles and rich syntax support.

In any case, I am willing to fully respect @sickmartian 's opinion and am grateful for the foundation you provided, which allowed me to quickly complete the current code, adapted for the latest version of Sublime Text.

[sickmartian]

Well I guess that’s a no 😉 While we prefer packages to be kept “alive” through contribution, forking, or whatever means are practical for that particular case, it’s not a requirement. You own your package and decide what happens with it.

Perfect, thanks for understanding 👍

Thank you all for taking this matter seriously. I am new to the open-source community, and my previous actions might have been a bit hasty. If @sickmartian still have time to update the code together., I would be honored to contribute to the original code and merge my new code into the original repository.

You didn't do anything hasty on my view, you took over a dead project and made it alive again, it's great and what should happen.

I'm just not comfortable giving control over the repo to someone I don't know in case there are active users using the plugin, feels like a responsibility I don't want. I also don't want to continue development or to audit new code for this.

So, I think you going with your own repo and not merging into mine is the way to go. Bests of luck on the new project 👍

[braver]

Alright, let’s go. If you do end up collaborating or whatever we can always merge the packages. For now, we’ll ship this.