OSDN側に要望リクエストありましたのでIssue展開します。
https://osdn.net/projects/sakura-editor/forums/34071/39646/

デフォルトのインストーラーに含む強調キーワードファイル他をどうインストーラ他にどうやって含めていくかって話があるのかなとは思いますが。

HTML 要素リファレンス - HTML | MDN
https://developer.mozilla.org/ja/docs/Web/HTML/Element

CSS リファレンス - CSS: カスケーディングスタイルシート | MDN
https://developer.mozilla.org/ja/docs/Web/CSS/Reference

JavaScript リファレンス - JavaScript | MDN
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference

このあたり方向性見えればキーワードファイルの追加は私でもできそうですが、
第三者提供物をどう受け取ってどうパッケージングしていくかってフローのイメージができてません。

cmake の導入に関してどう思いますか?

cmake は、マルチプラットフォームのビルドツール(正確にはビルド用のプロジェクト生成ツール)です。
CMakeLists.txt というテキストファイルにビルド設定を記述します。

CMakeLists.txt が置かれているトップディレクトリを指定して実行することにより
各種ビルドツールで使用できるプロジェクトファイルを生成できます。
(Visual Studio, Ninja, Makefile など)

単体テストの GoogleTest も使用している他、XCode でのコンパイルに
使用されている clang/llvm でもビルドに使用されています。

cmake を使うことのメリットは、
複数のバージョンの Visual Studio に容易に対応できたり複数のコンパイラに対応できることです。GitHub 上で Sakura Editor のMinGW-W64 対応を行っている方がおられるようですが、
このようなニーズにも対応できると思います。

32bit バージョンと64bitバージョンのビルドをするときもメンテする労力も少ないです。

デメリットは
CMake の使い方を覚える学習コストがかかり、実運用できるまでに時間がかかることと
日本語の情報がすくないことです。

MakefileMake を #18 の変更に対応させる
(SubWCRev を使うのをやめて、git show の出力を使うように仕様変更したが
仕様変更に追従していない)

Appveyor で追加のコミットなしで強制的にリビルドする方法の紹介です。

↓　これは私が作った　python スクリプトです。(python 2 系が対象です)
https://github.com/m-tmatma/AppVeyorBuild/blob/master/python/appveyorBuild.py

実行する前に以下を実行しておきます。
pip install --user appveyor-client

以下を実行すると、 でアクセスできるすべてのリポジトリ、
すべてのブランチに対して、ビルドをかけます。

appveyorBuild.py　

は
https://ci.appveyor.com/api-token
で確認できます。

比較的軽い修正の詰め合わせ #48 のPRを送ったんですが、
appveyorのビルドが走っていないように見えます。
自リポジトリでのビルド確認はできているんですが、なんか微妙です。

Win32 Release に LargeAddressAware が入っている理由を調べる

• sakura/sakura/sakura.vcxproj

  Line 75 in 1633967

  <LargeAddressAware>true</LargeAddressAware>

• https://msdn.microsoft.com/ja-jp/library/wz223b1z.aspx
• #84 (comment)

sourceforge.netに上がっているパッチを適用する方法について提案します。(関連: #45)

パッチというのはここにあるパッチのことです。
https://sourceforge.net/p/sakura-editor/patchunicode/

現状で100個くらいの未適用パッチが積まれています。
内容にもよりますが、大半はそのまま使えるパッチだと思っています。
使えるものは活用しないともったいないです。

今回、一般掲示板に「エアロスナップ対応」をなんとかしてほしいという書込みがあり、
ここのパッチを適用するとしたら具体的にどうしたらいいんだ？という疑問がわきました。

なんとなく、こうしたらいいんじゃね？と思ったことを書いてみますので、
疑問点・改善案などありましたらコメントいただけると幸いです。

作業の流れ

1. 懸案のパッチファイルをticketsページからダウンロードする
2. ダウンロードしたファイルからパッチのベースrevを確認する
3. SVNで該当revを落としてくる
4. SVNリポジトリにパッチを適用する
5. GITリポジトリのログで該当revのコミットを探し、そのコミットで作業ブランチを作成する
6. SVN→GITのフォルダ間でdiffをとって差分をGIT側に適用する
7. GITリポジトリで変更をコミットする（掲示板のポスト日時、投稿者名で代理コミット）
8. GITリポジトリのログで該当revの次～最新コミットを選択し、作業ブランチにマージする
9. ローカルでビルドしてみて、問題があれば最小限の修正をする（修正は代理でなく自身のコミット）
10. 作業ブランチをGitHub上の適当なリポジトリにPushする
11. プルリクエストを送る
12. ReviewとReview結果への対応は通常通り行う（修正は代理でなく自身のコミット）
13. 問題が解決したらマージする

書き出してみると作業項目多いなぁ～～～。

プルリクエストの設定変更しませんか?
https://dev.classmethod.jp/tool/github/protect-branch/

以下のオプションを有効にするのがいいと思います。

• "Require pull request reviews before merging"
• "Dismiss stale pull request approvals when new commits are pushed"
• "Require status checks to pass before merging"

コードレビューに関してこんな機能があるようです。
https://blog.github.com/2016-12-07-introducing-review-requests/

Visual Studio Community 2017 インストール時に Windows SDK を入れておかないとビルド通らない（当然といえば当然だけど README に明記はしたほうが良い情報）。

他、諸々ビルド要件について精査して README に書いておく。

参考事例

https://twitter.com/arigayas/status/998445467418574848
この例では Windows SDK 8.1 で通っているけど、このあたりのバージョン挙動についても調べておきたい。

grep/grep 置換で除外ファイル、除外フォルダを指定できるようにする

https://sakura-editor.github.io/help/HLP000067.html
(旧: http://sakura-editor.sourceforge.net/htmlhelp2/HLP000067.html)

には以下のように書いてある。

• ファイルパターンの先頭に!を付ける(例: !*.obj)と，そのパターンに当たるファイルをGrep対象から外します。
• ファイルパターンの先頭に#を付ける(例: #*.svn)と、そのパターンに当たるサブフォルダをGrep対象から外します。(sakura:2.1.0.0以降)
• 指定位置にかかわらず除外指定は検索指定より優先されます．
• 何も指定しない場合は、「.」を指定したことになります。

しかし、ほとんどの人はこの機能の存在を知らない。(私も含めて)

簡単に、除外指定できるようにする。

以下サンプル (位置はずれている部分がありますが、サンプルなのでご容赦ください)

以下 grep ダイアログのリソースのみ変えた差分

diff.txt

コミュニティでansi版サポートが要るか意見集めてる認識です。

標準はただのdebug/releaseにしませんか？

当面は32bitがメインで行くと思いますが、いつまでも64bitを非公式有志版のみにしとくのも変な気がしますので。

メモリ確保失敗時の挙動について調査する

Funccode_define.h および Funccode_enum.h の生成処理が動作していない

sakura_core\Funccode_x.hsrc には以下のコメントが記載されている。

//このファイルから、Funccode_define.h と Funccode_enum.h が生成されます。

sakura_core\Funccode_x.hsrc から Funccode_define.h と Funccode_enum.h を
生成する処理は、sakura\preBuild.bat にあるが、HeaderMake と MakefileMake のパス名が
間違っているため (本来は HeaderMake_vc2017 と MakefileMake_vc2017) 機能していない。

Funccode_define.h も Funccode_enum.h もバージョン管理化にあるのでビルドエラーには
ならないが、初期実装者の意図とは異なっていると思われる。

最近はDevよりOps側の作業が多いのですが、サクラエディタはexe単品でCDに焼いて作業PCで動かして使うこともあり、毎度Iniファイルがない状態でスタートするので、すべてがデフォルトで動かしてます。

１点タイトルの通り常駐しちゃうので、毎度タスクトレイから落とすという些細なことなのですが、意外と常駐を嫌う担当者も多くて地味に手間なので「常駐しない」をデフォルトにしてはどうかと。

iniファイルごと持って行けばいい話といえばそれまでなのですが。。。

管理者を2人に増やします

• Organization の Owner (sakura-editor の管理者)
• Team の Maintainer (sakura-developers の管理者)

について、これまでは kobake が1人で受け持つ体制でやっていましたが、これらの管理者は常に2人程度いるのが好ましいかと思っています。管理者が1人だとその1人の連絡がとれなくなった場合にいろいろ困るので。

で、これは自分の独断で恐縮なのですが、 @KENCHjp さんを上記2か所の管理者として設定しました。サクラエディタとの付き合いが最も長く信頼できるというのが理由です。

Organization の Owner について

sakura-editor Organization の様々な設定ができます。実はあんまりいじりません。他の人を Owner に指名する権利も持ちます（Owner は複数人設定可能です）。

Team の Maintainer について

sakura-developers Team のチーム自体の設定（あまりいじらない）や、メンバー追加ができたりします。他の人を Maintainer に指名する権利も持ちます（Maintainer は複数人設定可能です）。

管理者としての心構え（？）

• 常に2人以上の管理者がいる状態を維持するのが好ましいです。
• 安全のため、2FA（二段階認証）を設定しておくのが好ましいです。

※というか 2FA は本当は管理者に限らず皆が設定しておくのが本当は好ましいですが今のところはスルーしてます。

@KENCHjp さん、責任を負担させるようですみませんが、支障なければよろしくお願い致します。
対応難しそうであれば今でも後でも辞退いただいて構いません。

今後の話

自分自身が割と飽きっぽいというか現実での環境をころころ変える性質なもので、たぶんどこかのタイミングで本業に忙殺されるなどの理由で疎遠になる可能性高いです。

あ、kobake 消えたな、って思ったら管理者もう1人増やしてください（すみません）。

旧 web site へのリンクを新 Web site に切り替える

sakura_lang.vcxproj を sakura_lang_en_US.vcxproj に名前変更する

ファイル名とプロジェクト名が異なりややこしい。

バージョン情報で git の commit hash を表示すると便利だと思います。

SubWCRev と同様のプログラムで
GitWCRev というプログラムも存在するが、
TortoiseGit がインストールされていないと使えない。

Appveyor の Build environment には
TortoiseGit がリストにはない。

ただ通常の git コマンドだけでも以下のようなバッチファイルで、git の commit hash を
取り出せるので、svnrev.h のようなファイルを作ることも可能だと思う。

@echo off
for /f "usebackq" %%s in (`git show -s --format^=%%H`) do (
    set COMMITID=%%s
)

echo %COMMITID%

外部モジュール(bregonig.dll とか)の管理方法を検討する

ラベルを使いませんか?
http://azunobu.hatenablog.com/entry/2015/09/22/143811

x64 のビルドに対応する

参考

64 ビット Windows プログラミング ガイド
https://msdn.microsoft.com/ja-jp/library/bb427430(v=vs.85).aspx

ユーザーがバグ報告するときに、OS 等の情報を簡単に取得できるようにする

ヘルプ → バージョン情報 → 情報をコピー で
サクラエディタ のバージョン情報をクリップボードに取得できるが、
OS の情報も取得できるようにする。

従来 OS の情報を取得するには GetVersionEx が使われてきたが、
Windows 8.1 以降では manifest を正しく設定しないと偽装された値を返す。

manifest に指定する GUID のメンテが面倒なので WMI を使ってみる

• WMI C++ Application Examples
• Example: Getting WMI Data from the Local Computer
• Windows Management (WMI): c++ Example

https://help.appveyor.com/discussions/questions/1154-appveyor-account-for-github-organizations

Posted by Feodor Fitsner on Jul 19, 2015 @ 04:12 AM のコメント参照

AppVeyor account is not bound to GitHub organization. Just sign up on https://ci.appveyor.com/signup page. If you mean the URL part https://ci.appveyor.com/project/<organization>/project then this could be updated on https://ci.appveyor.com/account page.

内容

次回リリースのバージョン番号を決めたいです。

参考

今のところリリースされている最新バージョンは 2.3.2.0 です。

https://sourceforge.net/projects/sakura-editor/files/sakura2/

• 2.3.2.0 ... 2017-05-02
• 2.3.1.0 ... 2016-08-14
• 2.3.0.0 ... 2015-10-12

次バージョンのリリース時期・内容

パッケージングの仕組みがうまく動くようになった段階でリリースするくらいの感覚で考えています。時期としては6月末くらい……かな、と（個人的な感覚です）。

次バージョン番号の検討材料

• 機能的に大きな変更は入らないと考えています。そういう意味では 2.3.3.0 くらいでも良いかも。
• GitHub 移行を大きな変更と捉え、2.4.0.0 にするという選択もあります。

これまでのリリース時期とバージョン番号の決定ポリシーについて

これまでにバージョン番号やリリース時期はどのように決められていたのか、ポリシー等分かる方いらっしゃいましたら情報いただきたいです。

Appveyor を導入しませんか?

(ご存知かもしれませんが)
Appveyor は Windows 上で動作するクラウドの CI ツールです。

オープンソース・ソフトウェアに対してはタダです。

.NET のアプリ以外にも C++ ベースの Windows アプリのビルドに使えます。
ビルドした成果物を Appveyor 経由で公開することもできます。

Appveyor を Github や bitbucket などと連携することによって

• 新しいブランチが作成されたタイミング、
• push されたタイミング、
• プルリクエストが作成されたタイミング、
• 手動
• REST API 経由 経由

などで自動的にビルドを行うことができます。

プルリクエストが送られたタイミングで自動的にビルドチェックをしてくれるので
プルリクエストをレビューする前にビルドが通るか確認できます。

また googletest などで単体テストを実装して Appveyor で実行することにより
回帰テストを実行することも可能です。

Python のアウトライン解析は実装されていて、拡張子 py　に対して
アウトラインの解析方法で、Python を設定すると使えるが
デフォルトでは使えないようになっているので、
初期状態でも使えるようにする。

OSDNフォーラム側トピック

• 開発・管理:コアメンバー募集 - サクラエディタ - OSDN

※OSDNフォーラム側で開発の話をするのは今後はやめようと思います。話が分散してしまうので。GitHub Issues 側に話を引き継いでいきます。

開発コアメンバー募集

現在、PR (Pull requests) のレビュー待ちが多く発生してしまっている感じです。

レビュー＆マージ権限を運用いただける方が追加でもう少しいると助かるな、と思っているのですが、ご協力いただける方がいらっしゃいましたら手を挙げていただけると嬉しいです。（現時点でのコアメンバーは @kobake, @ds14050, @KENCHjp の3名です）

特にこれまでの SourceForge 運営や外部活動に関わっていた方の再参入を歓迎致します。

名指ししちゃいます

• novice123 さん、直近までの積極的な Subversion コミットありがとうございました。よろしければ OSDN, GitHub についてもご参加いただけると嬉しいです。お待ちしております。
• kageshiron さん、Chocolateyパッケージ登録ありがとうございます。もしよろしければ OSDN, GitHub の管理にも関わっていただけると嬉しいです。
• @m-tmatma さん、積極的な Pull requests やご提案ありがとうございます。開発コアメンバーとしての参入いかがでしょうか。

お手間でなければ、という前提ですが！

上記以外の方のご参入もお待ちしております

上記以外の方のご参入もお待ちしております。

ただ、まったくの名無しさんに管理権限を付与するのはちょっと怖いので、何かしらの活動記録を確認できるものをご提示いただけると助かります。

プロジェクト・ソリューションのファイル名ですが、2017採用で文句が出ないようなら外しませんか？

ログ全体をチェックしていて気付きました。
HeaderMakeのメッセージ出力も化けています。
https://ci.appveyor.com/project/sakuraeditor/sakura/build/1.0.84#L458

自動生成ファイルをリポジトリから外す対応により上書きが発生しなくなったため、
初回メッセージは消えていました。

• #31 HeaderMake が生成するファイル (Funccode_define.h, Funccode_enum.h) をリポジトリから除外 86d411f

MakefileMakeについてはCMakeによる代替の可能性が出てきている認識です。
HeaderMakeについても代替案があるかも知れません。

• enumとdefineの定義を共用できるようにdefineマクロで工夫する、みたいなのをWebで見かけたことがあります。

MakefileMake同様に対応する( #44 )か、
あえてこのままとするか判断が必要と思います。

Installer を作成してみる

Inno Setup は以下から入手できる。
http://www.jrsoftware.org/isdl.php

最終的には appveyor でビルドしたいが、その準備作業です。

2018/6/8 追記

appveyor には innosetup-5.5.9-unicode.exe がインストールされている。

• https://www.appveyor.com/docs/build-environment/#tools
• appveyor/ci#2421

→　なので innosetup-5.5.9-unicode.exe を使う

2018/6/16 追記

Inno Setup 5 のコマンドラインでのコンパイル方法
http://www.jrsoftware.org/ishelp/index.php?topic=compilercmdline

http://www.jrsoftware.org/isdl.php で innosetup-5.6.1-unicode.exe が公開されているが、
https://www.appveyor.com/docs/build-environment/#tools では更新されていない。

こちらのOSDN投稿

旧掲示板の[開発A]5629
https://osdn.net/projects/sakura-editor/forums/34071/39620/

元
[5629] Windows 7 でタブバーを表示状態でリサイズしてタブを移動すると元のサイズに戻る
http://sakura-editor.sourceforge.net/cgi-bin/cyclamen/cyclamen.cgi?log=dev&tree=r5629

にあるパッチの取り込み。
PatchUnicode#1009
https://sourceforge.net/p/sakura-editor/patchunicode/1009/

https://github.com/orgs/sakura-editor/teams/sakura-developers
が何故かチーム外のユーザから見えない（404 not found になる）。
ここは見えるようにしたい（できるだけオープンにしたい）。

Sakura配下に集めませんか？

Postbuildに細工すれば可能だと思います。

sakura.exe と sakura_lang_en_US.dll の生成フォルダはプロジェクトのフォルダをもとに決められるが、
ソリューションフォルダをもとに決める。

プロジェクトのフォルダをもとに成果物が生成されるので、sakura_lang_en_US.dll が別のフォルダに
作成されるので英語リソースのテストをするのに手間がかかる。

OSDNフォーラムから移行。この話は今後は GitHub Issues 側でやっていきましょう。

概要

ライセンスをどうするか。今のところ候補に挙がっているのは「zlib」「MIT」くらい。

関連スレッド

• http://sakura-editor.sourceforge.net/cgi-bin/cyclamen/cyclamen.cgi?log=data&tree=s8407
• https://osdn.net/projects/sakura-editor/forums/34093/39615/

Issue・Pull Requestのテンプレート機能を使いませんか?
https://qiita.com/nyamogera/items/3fe6985b45fbd5377184

現在ChocolateyというWindows向けのパッケージマネージャで、サクラエディタのパッケージを公開しています。今後の管理方針をご相談したいです。

https://chocolatey.org/packages/SakuraEditor/2.3.2.0

自動更新

現在CI(AppVeyor)を利用してパッケージを自動更新しています。SourceForgeのリリースページをスクレイピングしているところを、今後はGitHub Releaseを見るように変更予定です。

本体のリリース手順にChocolateyパッケージの更新を追加する方法もありますが、他のメンテナの方の負担を増やすばかりでメリットはあまりないと考えています。

パッケージソースの管理

現状私のリポジトリで管理しています。

https://github.com/KageShiron/chocolatey-packages/tree/master/sakuraeditor

1. sakura-editorのorgに完全移行
2. sakura-editorのorgにソースだけ移し、submoduleで私のリポジトリに取り込んで自動更新のCIを回す
3. 現状維持

の3つが考えられます。ChocolateyのアカウントやCIの設定が面倒なことを考えると2.か3.が妥当かなとは思います。

#34 で直したはずだが、直っていない。

https://ci.appveyor.com/project/sakuraeditor/sakura/build/1.0.49

Build started
Set-WinSystemLocale ja-JP
Start-Sleep -s 5
git clone -q --branch=master https://github.com/sakura-editor/sakura.git C:\projects\sakuraeditor\sakura_1.0.49
fatal: destination path 'C:\projects\sakuraeditor\sakura_1.0.49' already exists and is not an empty directory.
Command exited with code 128

チケットやプルリクエストで Milestone を設定できますが、
Milestone は運用されていないようですが、運用しませんか?

Appveyor の バッジを README.md に追加してほしい
#15 の対応後にお願いします。

参考サイト:
http://kuttsun.blogspot.com/2017/11/github-appveyor-net.html

実際の例:
build: passing のところです。
https://github.com/google/googletest

失敗しているとすぐにわかるようになります。

.bat だと処理が冗長になりがちなので Power Shell スクリプトで pre-build, post-build を書けるように対応できないか検討中です。

検証中

• https://github.com/kobake/appveyor-test/commits/master … 検証のためコミット積み
• https://ci.appveyor.com/project/kobake/appveyor-test … AppVeyor 挙動の検証

https://ci.appveyor.com/project/kobake/appveyor-test/build/1.0.9

....
....
aaaaa
(ここにGitハッシュが出て欲しかったけど AppVeyor ビルドだと出ない。手元の VS2017 だと出る)
bbbbb
....
....

ファイル内で文字コードを指定できるのに標準と変えてあるように思っています。

Sjisでないとマズい理由があるんでしたっけ？

あとでもう少し詳しく書きますm(._.)m

sakura editor の自動更新の仕組みについて検討する

いろんな仕組みが考えられるがどの方式がいいか検討する。

着手します (kobake)

[x64対応] C4477 の警告を修正する

• x64 のビルドに対応する #40
• https://github.com/sakura-editor/sakura/wiki/x64
• [WIP] x64 作業集約場所 #86

https://msdn.microsoft.com/ja-jp/library/tcxf1dw6.aspx

size_t (つまり、32 ビット プラットフォーム上では unsigned __int32、64 ビット プラットフォーム上では unsigned __int64) → I

ptrdiff_t (つまり、32 ビット プラットフォーム上では __int32、64 ビット プラットフォーム上では __int64) → I

manifest ファイルの processorArchitecture が x86 になっている

参考
http://yasu1973fc2.blog99.fc2.com/blog-entry-76.html

sakura_lang のプロジェクトを Visual Studio 2017 に更新する

また、sakura_vc2017.sln のソリューションに sakura_lang のプロジェクトを追加して
Appveyor のビルド対象にする。

環境：Visual Studio Community 2017 [Version 15.7.1]
OS：Windows10 Pro [Version 1803]

検証記録用です。

bregonig.dll のライセンスに関して以下を見ると
https://github.com/sakura-editor/sakura/wiki/PackageStructure

bsd_license.txt があったので BSD ライセンスなのかなと思ったのですが、

正規表現ライブラリ bregonig.dll の 9. ライセンス を見ると
bregonig.dll は、正規表現ライブラリとして Oniguruma (Onigmo) を使用しており、Oniguruma (Onigmo) は BSD ライセンスとなっています。 とあります。

これは、bregonig.dll が依存している Oniguruma (Onigmo) というモジュールが
BSD ライセンスなのであって、bregonig.dll 自体は Perl と同じライセンス、すなわち GPL と Artistic License のどちらか のように見えます。

なので perl_license.txt や perl_license_jp.txt を同梱する必要があるのではないですか?

→ @k-takata さんから回答いただいたので同梱します。