AkelPad

1. Любой скрипт - это плохое решение.

но это немалый труд и практически полное переписывание всех имеющихся скриптов, + потеря многих предоставляемых WSH-ом приятностей.

Не на много больший труд чем написать сам плагин. Никто же не заставляет и не рассчитывает на собственный язык, можно и нужно взять готовый. Думаю что среди таких найдется достаточно легкий, встраиваемый, фичастый и расширяемый язык. А приятности - не так уж и уникальны(я сходу уникальных не назову).

Паскаль всё-таки не скриптовой, не претендент

по сути отсутствие регулярок в большинстве претендентов и останавливает. Да, существуют различные биндинги библиотек, но от этого легче не становиться(проблема кодировок)

PascalScript, DWScript... правда, эти обычно сами пишутся на Паскале, т.ч. не вариант именно по этой причине.

Сама же регулярка должна кушать widechar и всё

Как язык написания плагина Паскаль подходит - AkelDll.pas лежит в исходниках лавно

Другая проблема в том, что плагин при этом развезет

Всего-то нужно заставить весь мир Юникс пересесть на widechar, который у них между-прочим 4-байтный. А именно оттуда портировались на WIN32 все претенденты. Об пришитые pcre.dll я думал и даже чего-то там пробовал - пока нечем похвалится.

In situations where performance is critical, you may want to use TPerlRegEx directly. The PCRE library is based on UTF-8 while the Delphi VCL uses UTF-16 (UnicodeString). TPerlRegEx is also based on UTF-8, giving you full control over the conversion between UTF-16 and UTF-8. You can avoid the conversions if your own code also uses UTF8String. The RegularExpressions unit uses UnicodeString just like the rest of the VCL, and handles the UTF-16 to UTF-8 conversion automatically.

Теоретически - да, но писать плагин кроме Инструктора некому, а он приверженец классического С

Широко распрострённое заблуждение. "Развезёт" точно так же, как программу на любом языке с высокоуровневым графическим фреймворком. А если юзать только WinApi, то файлы будут ничуть не больше сишных.

Хм. Хочешь сказать,

Вспомните, сколько мороки нужно было пережить, что-бы написать резидента на Паскале во времена ДОС. И там "высокоуровневые" фреймворки как ни странно не использовались.

Хочу сказать, что заставить их работать как этого нужно WIN32 приложению тяжелее чем написать собственную реализацию. Живой пример тому - ASpell. Все выходцы из Юникс по самые я... завязаны на libc. libc в свою очередь пинают много ног, и пинок одной ногой портит отношения с другой.

Если дело за "писать" то найдется кому. Дело в организации и мотивации. 90% опенсорса загнулось по причине плохой мотивации, столько же проектов просто не родилось.

Не доводилось, но к чему здесь этот пример, не понял.

program pog;
uses system;
begin
end.

Возможно. Однако - факты: в Дельфи сумели встроить и zlib, и pcre - причем в виде obj, а не dll, то есть непосредственно в бинарник. И ничего, работает. А жесткая завязанность, имхо, идет от кривого кода.

Самая весомая мотивация - это "мне позарез нужна вот эта фича, но её некому сделать, придется самому"

system вот этот гребаный юнит - паскалевский runtime ложится в каждую прогу(а сейчас и в каждый exe dll и в такое место что расчете размера резидента его вне резидентной области не вытеснишь. А сейчас он ложится в каждую DLL - каждой своя копия. И не использовать его не получается.

И как всегда между obj и программой лежыт двойная прослойка, конвертирующая deplhi-шные типы в родные для либы.

В сях даже на hello world нужно целых две либы подключать.

#if 0
#echo off
cl /O1 /Tc %~nx0 /link /nodefaultlib /entry:main kernel32.lib /release /subsystem:console
exit /b
#endif
#include <windows.h>
const char hw[] = "Hello, World";
void main(void)
{
	DWORD dw=0;
	HANDLE h = GetStdHandle(STD_OUTPUT_HANDLE);
	WriteFile(h, hw, sizeof(hw)-1, &dw, NULL);
	ExitProcess(0);
}

Аж одну

Покоцать System.pas просто не получится - это только брланду подсилу.

Хм. Хитро придумано. Я по старинке помнил stdio/conio

кого шибко колебут эти несчастные 30 кило

правда, неизвестно, какой при этом получается объём бинарник