Community
    • Login

    When is there going to be a release of NPP plugintemplate with a definition of NPPM_ADDSCNMODIFIEDFLAGS

    Scheduled Pinned Locked Moved Notepad++ & Plugin Development
    13 Posts 4 Posters 316 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • ThosRTannerT
      ThosRTanner
      last edited by ThosRTanner

      There hasn’t been a release of the template for about a year, and it doesn’t have a definition of NPPM_ADDSCNMODIFIEDFLAGS so I have to add one myself if I want to use it.

      Could we have an update pretty please?

      CoisesC PeterJonesP 2 Replies Last reply Reply Quote 0
      • CoisesC
        Coises @ThosRTanner
        last edited by

        @ThosRTanner said in When is there going to be a release of NPP plugintemplate with a definition of NPPM_ADDSCNMODIFIEDFLAGS:

        Could we have an update pretty please?

        Of course, the way to request that would be to raise an issue in the plugintempate repository.

        This made me think, though (regarding both plugintemplate and plugindemo)…

        1. Several files should always be up-to-date with the latest release of Notepad++. One would think there might be a way to do that automatically in GitHub.

        2. It might make sense to instruct people to download from master rather than the latest “release”; then making a new release wouldn’t be a requirement every time a file is updated to match Notepad++.

        3. It seems like these repositories should be a GitHub template repositories.

        I don’t know GitHub well enough to know how to automate point 1 above (or if it is possible), or if there are reasons not to do 2 or 3.


        In the meantime, it’s probably a good idea to update all the files that come from Notepad++ before starting a new project based on any template.

        PeterJonesP 1 Reply Last reply Reply Quote 1
        • PeterJonesP
          PeterJones @ThosRTanner
          last edited by

          @ThosRTanner ,

          All you have to do is download the most recent Notepad_plus_msgs.h overtop the one in the template – and for Scintilla messages, get the most recent Scintilla.h as well. But I understand that having it pre-packaged in the template would be nice.

          Could we have an update pretty please?

          Who do you think you’re talking to, here? You’ve been here long enough to know that Don doesn’t read the most of the posts in the forum, except for in reply to his Announcements or his other rare posts: if you want to request an update to the template, creating an issue in the plugintemplate repo is the way to get his attention to get a release: just poking us fellow Notpead++ users will not help with that.

          ThosRTannerT 1 Reply Last reply Reply Quote 1
          • PeterJonesP
            PeterJones @Coises
            last edited by

            1. Several files should always be up-to-date with the latest release of Notepad++. One would think there might be a way to do that automatically in GitHub.

            The way that immediately comes to mind would be to have a time-based GH Action in the template repo that once a month downloads the most-recent copy of Notepad_plus_msgs.h and Scintilla.h and (if there’s a change) then the action can commit it back into the plugintemplate repo. I could probably develop that GH Action, if someone else had made an Issue requesting that it get auto-updated (hint, hint, @Coises).

            There’s probably some more git-centric (rather than GitHub Action) way of doing that, too, but I’m not enough of a git expert for that.

            1. It seems like these repositories should be a GitHub template repositories.

            That’s something to suggest in a separate Issue, making sure to put a link to those instructions in the request, so that Don knows how easy it is to turn it into a template. (The README could also be updated to include a summary of the instructions here for how to use a template repo to create a new repo based on that template.

            I don’t know GitHub well enough to know how to automate point 1 above (or if it is possible), or if there are reasons not to do 2 or 3.

            The one thing I see is that if both 1 and 3 are implemented, then the GHAction from 1 would be included when someone used the template-repo to create a new repo. It would be, in a way, “nice”, because it would make sure your plugin kept up-to-date; but it would also make changes to your plugin without your control, so it could be considered “bad”.

            CoisesC 2 Replies Last reply Reply Quote 2
            • CoisesC
              Coises @PeterJones
              last edited by

              @PeterJones said in When is there going to be a release of NPP plugintemplate with a definition of NPPM_ADDSCNMODIFIEDFLAGS:

              The one thing I see is that if both 1 and 3 are implemented, then the GHAction from 1 would be included when someone used the template-repo to create a new repo. It would be, in a way, “nice”, because it would make sure your plugin kept up-to-date; but it would also make changes to your plugin without your control, so it could be considered “bad”.

              I think (but again, my understanding of both git and GitHub are very elementary) that when a template repository is used as the source of a new repository, there is no persistent connection between the two. The template just initializes the new repository with structure and files.

              No one would (or should, anyway) fork the plugintemplate or plugindemo repositories. Having it be a template would just — again, if I understand it correctly — make it possible to start by making a new repository for your plugin on GitHub and then sync your local MSVC/git to that, if you preferred that to downloading the project, opening it in MSVC and then pushing it to git later.

              PeterJonesP 1 Reply Last reply Reply Quote 0
              • PeterJonesP
                PeterJones @Coises
                last edited by

                I think (but again, my understanding of both git and GitHub are very elementary) that when a template repository is used as the source of a new repository, there is no persistent connection between the two. The template just initializes the new repository with structure and files.

                I had never heard of the “template repo” feature until you linked it. But from my reading, when you create a repo based on that, it copies the entire structure of that repo – not as a link, but the whole structure; the GitHub Action Workflow definitions would seem to me to be part of that structure, so I would assume they would be copied; and thus, the action would still be there and active. (Again, if I understand correctly)

                No one would (or should, anyway) fork the plugintemplate or plugindemo repositories.

                If I understood the second page (the one I linked), it’s not a fork. But the creation process copies everything, including workflows

                CoisesC 1 Reply Last reply Reply Quote 0
                • CoisesC
                  Coises @PeterJones
                  last edited by

                  @PeterJones said in When is there going to be a release of NPP plugintemplate with a definition of NPPM_ADDSCNMODIFIEDFLAGS:

                  I could probably develop that GH Action, if someone else had made an Issue requesting that it get auto-updated

                  Issue #13: “Feature” request: Update files from Notepad++ automatically created.

                  1 Reply Last reply Reply Quote 1
                  • CoisesC
                    Coises @PeterJones
                    last edited by

                    @PeterJones said in When is there going to be a release of NPP plugintemplate with a definition of NPPM_ADDSCNMODIFIEDFLAGS:

                    the creation process copies everything, including workflows

                    Ugh. I missed that. You’re probably right, and that would be bad.

                    I know nothing yet about creating actions. Would it be possible to create the action so that it only runs if it is running in “nppplugins/plugintemplate” and would otherwise do nothing (unless the creator of the new repository changed it)?

                    PeterJonesP 1 Reply Last reply Reply Quote 0
                    • PeterJonesP
                      PeterJones @Coises
                      last edited by

                      Would it be possible to create the action so that it only runs if it is running in “nppplugins/plugintemplate” and would otherwise do nothing (unless the creator of the new repository changed it)?

                      Actually, I think you can; I think I have an example in one of the other actions I deal with… I’ll look into that and confirm as I work on #13.

                      rdipardoR 1 Reply Last reply Reply Quote 0
                      • rdipardoR
                        rdipardo @PeterJones
                        last edited by

                        @PeterJones said in When is there going to be a release of NPP plugintemplate with a definition of NPPM_ADDSCNMODIFIEDFLAGS:

                        Would it be possible to create the action so that it only runs if it is running in “nppplugins/plugintemplate” and would otherwise do nothing (unless the creator of the new repository changed it)?

                        Actually, I think you can.

                        An outline of such a workflow would be:

                        • Run the build on the schedule trigger event, as already suggested in the issue thread, e.g.:
                        on:
                          schedule:
                            - cron: "0 0 1 * *" #< first day of every month at 00:00 UTC
                        
                        • Use the checkout Action to fetch the Notepad++ trunk

                        • Use a diffing tool or action to compare the file paths of interest. If something changed, copy the upstream files into the template’s file paths and feed the project to MSBuild

                        • If the build passes, push the changed files and create a release

                        ThosRTannerT 1 Reply Last reply Reply Quote 2
                        • ThosRTannerT
                          ThosRTanner @rdipardo
                          last edited by ThosRTanner

                          @rdipardo Wouldn’t a better place to put the action be in the notepad++ repo so when a new version was released it’d do the updates to the template repo automatically?

                          @PeterJones @Coises thanks for all the replies and though processes on this.

                          rdipardoR 1 Reply Last reply Reply Quote 1
                          • ThosRTannerT
                            ThosRTanner @PeterJones
                            last edited by

                            @PeterJones you’d be surprised how much I don’t know despite having hung around for a long time

                            1 Reply Last reply Reply Quote 0
                            • rdipardoR
                              rdipardo @ThosRTanner
                              last edited by

                              @ThosRTanner said in When is there going to be a release of NPP plugintemplate with a definition of NPPM_ADDSCNMODIFIEDFLAGS:

                              @rdipardo Wouldn’t a better place to put the action be in the notepad++ repo so when a new version was released it’d do the updates to the template repo automatically?

                              You make a good point.

                              The workflow steps would essentially be the same, but in the opposite direction (clone the template repo, update the file tree, validate the build and push if successful). The main difference would be the trigger; ideally you would want to watch for tagged Notepad++ releases, e.g.,

                              on:
                                push:
                                  tags:
                                    - 'v*'
                              

                              This way new template versions can be explicitly tied to a Notepad++ release, e.g.,

                              # 'refs/tags/vX.Y.Z' -> 'vX.Y.Z'
                              echo "NPP_RELEASE=${env:GITHUB_REF}.Split('/')[2]" >> $env:GITHUB_ENV
                              # ...
                              git tag -a "${{ env.NPP_RELEASE }}" '@' -m "plugintemplate-for-Npp-${{ env.NPP_RELEASE}}"
                              git push --tags --repo=https://github.com/npp-plugins/plugintemplate
                              

                              But it would be a problem if incompatible changes were made to the template. A failed build would cause a red X to appear beside the tagged Notepad++ commit, giving the false impression the release was a botch.

                              I think the separation of concerns principle is best observed if the template project looks after its own updates. A little extra churn won’t be a great inconvenience. The majority of plugin authors are still copy-pasting the template files into their source tree, as shown by how many have “C” as their detected primary language, since the template files contain no unique C++ syntax or standard headers, which GitHub relies on to classify header files, unless you manually override the heuristics.

                              1 Reply Last reply Reply Quote 1
                              • First post
                                Last post
                              The Community of users of the Notepad++ text editor.
                              Powered by NodeBB | Contributors