PowerShellFar — PowerShell host и автоматизация Far Manager
- NightRoman
- Posts: 6172
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 32 times
- Been thanked: 62 times
- Contact:
PowerShellFar — PowerShell host и автоматизация Far Manager
Тут обсуждаем плагин PowerShellFar.
Связанная тема: обсуждение FarNet.
PowerShellFar scripts created by other authors: http://forum.farmanager.com/search.php? ... &sr=topics
Связанная тема: обсуждение FarNet.
PowerShellFar scripts created by other authors: http://forum.farmanager.com/search.php? ... &sr=topics
Last edited by NightRoman on Thu 20 Jan, 2011 15:24, edited 4 times in total.
- NightRoman
- Posts: 6172
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 32 times
- Been thanked: 62 times
- Contact:
В последнем анонсе версии 1.0.8 я упомянул, что эта версия уже похожа на первоначальную задумку. Пока знаю одну проблему (у себя) - если редактор запущен модально из PowerShell кода, то из него уже PowerShell код (пока) не вызовешь. Это я в ближайшие дни поправлю (не для всех случаев, но будет вполне практично).
Таким образом, следующая версия 1.0.9 будет типа кандидата на релиз, хотя это формальность, конечно. Тем не менее, может, у кого накопились замечания или проблемы? Тогда лучше сообщить сейчас, не исключено, что далее некоторое время я не смогу этим заниматься (активно).
Таким образом, следующая версия 1.0.9 будет типа кандидата на релиз, хотя это формальность, конечно. Тем не менее, может, у кого накопились замечания или проблемы? Тогда лучше сообщить сейчас, не исключено, что далее некоторое время я не смогу этим заниматься (активно).
Мне кажется несколько избыточным использовать PowerShell для скриптов для редактора.
Мила PowerShell синтаксиса, как мне кажется, в том, что оно похоже на стандартные шеллы: вызов всяких экзешников выглядит как родной, но сравнения и проч - явно сделаны в качестве инородного элемента.
например зачем использовать PSh чтобы просто сделать отступ в редакторе:
Вместо:
Мила PowerShell синтаксиса, как мне кажется, в том, что оно похоже на стандартные шеллы: вызов всяких экзешников выглядит как родной, но сравнения и проч - явно сделаны в качестве инородного элемента.
например зачем использовать PSh чтобы просто сделать отступ в редакторе:
Code: Select all
for($i = 0; $i -lt $tabSize; ++$i) {
if ($text[$i] -ne ' ') { break }
}
if ($i -lt $text.Length) {
$line.Text = $text.Substring($i)
}
Code: Select all
for(i=0; i<tabSize; ++i)
if (text[i]!=' ')
break;
if(i<text.Length)
line.Text = text.Substring[i];
- NightRoman
- Posts: 6172
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 32 times
- Been thanked: 62 times
- Contact:
Отчасти согласен. Но если они (эти скрипты для редактора) работают, почему же избыточно? Скриптов можно наделать тонны и никуда их не грузить, использовать только по необходимости - в случае с .NET кодом так не выйдет (напрямую).
PowerShell вообще избыточен, сколько лет без него прекрасно обходились. Но: и применение .NET как такового избыточно - все на С\С++ можно делать и лишние метры фреймворка не грузить и вспомогательные планины, обеспечивающие доступ к Far.
Это дело вкуса. И удобства. И скорости разработки. Особенно задач-однодневок, а то и одно-разок. PowerShell cкрипты для некоторых задач удобнее и реально экономят общее время разработки и оперативного внесения изменений (говорю за себя).
Меня не коробит синтаксис операторов сравнения абсолютно, хотя и необычен, и предпочел бы я тоже "нормальный". Но это ж просто синтаксис. Ну вот в WSH .js скриптах нормальные операторы, но не прижился у меня этот инструмент и все тут - его возможностей явно не хватает, тут никакой синтаксический сахар не поможет. Кстати, в команде разработчиков PowerShell этот спор об операторах шел пару лет, и на таком синтаксе все же остановились не случайно (почему - не в курсе).
Вопрос производительности PowerShell - это да, может быть критично для некоторых операций. В этом случае перекинуть скрипт на .NET язык - пустяковое дело (но уже убедившись, что он делает то, что нужно и нужен как таковой). Кстати, хотелось бы жалобы про производительность услышать, если есть, что именно тормозит, кроме "все" :) и первой загрузки сессии PowerShellFar.
PowerShell вообще избыточен, сколько лет без него прекрасно обходились. Но: и применение .NET как такового избыточно - все на С\С++ можно делать и лишние метры фреймворка не грузить и вспомогательные планины, обеспечивающие доступ к Far.
Это дело вкуса. И удобства. И скорости разработки. Особенно задач-однодневок, а то и одно-разок. PowerShell cкрипты для некоторых задач удобнее и реально экономят общее время разработки и оперативного внесения изменений (говорю за себя).
Меня не коробит синтаксис операторов сравнения абсолютно, хотя и необычен, и предпочел бы я тоже "нормальный". Но это ж просто синтаксис. Ну вот в WSH .js скриптах нормальные операторы, но не прижился у меня этот инструмент и все тут - его возможностей явно не хватает, тут никакой синтаксический сахар не поможет. Кстати, в команде разработчиков PowerShell этот спор об операторах шел пару лет, и на таком синтаксе все же остановились не случайно (почему - не в курсе).
Вопрос производительности PowerShell - это да, может быть критично для некоторых операций. В этом случае перекинуть скрипт на .NET язык - пустяковое дело (но уже убедившись, что он делает то, что нужно и нужен как таковой). Кстати, хотелось бы жалобы про производительность услышать, если есть, что именно тормозит, кроме "все" :) и первой загрузки сессии PowerShellFar.
Возможно, стоит подумать на тему - как сделать так, чтоб вышло?NightRoman wrote:Скриптов можно наделать тонны и никуда их не грузить, использовать только по необходимости - в случае с .NET кодом так не выйдет (напрямую).
Какое конкретно ты преимущество получаешь от PSh по сравнению, скажем, с JS.NET? За чято ты платишь таким синтаксисом?NightRoman wrote: Это дело вкуса. И удобства. И скорости разработки. Особенно задач-однодневок, а то и одно-разок. PowerShell cкрипты для некоторых задач удобнее и реально экономят общее время разработки и оперативного внесения изменений (говорю за себя).
Меня не коробит синтаксис операторов сравнения абсолютно, хотя и необычен, и предпочел бы я тоже "нормальный".
Мне кажется, что это для того, чтобы всё органично укладывалось в существующую комстроку. То есть чтобы c:\windows\cmd.exe было вызовом cmd.exe а c:\windows\cmd.exe > test.txt было вызовом с перенаправлением.Но это ж просто синтаксис. Ну вот в WSH .js скриптах нормальные операторы, но не прижился у меня этот инструмент и все тут - его возможностей явно не хватает, тут никакой синтаксический сахар не поможет. Кстати, в команде разработчиков PowerShell этот спор об операторах шел пару лет, и на таком синтаксе все же остановились не случайно (почему - не в курсе).
Но зачем это в редакторе?
Дополнение: в свое время у меня была идея сделать некую надстройку над Far.Net, которая бы позволяла динамисески классифицировать объекты внутри фара и писать к ним методы.
Что-то типа:
Что-то типа:
Code: Select all
<class name="CSharp" extends="SourceCode" where="extension == '*.cs'">
<method name="block comment" language="JScript">
function doIt(s)
{
return s.replace(/^/g, '//');
}
</method>
</class>
- NightRoman
- Posts: 6172
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 32 times
- Been thanked: 62 times
- Contact:
Как это сделать (в принципе) - я знаю, было бы время и руки бы дошли.Возможно, стоит подумать на тему - как сделать так, чтоб вышло?
Про удобство вызова приложений (как из cmd) ты уже упомянул. Но это не главное для меня, главное .NET - вот это действительно революционно в PowerShell. Ну и то, что конвейер из объектов - это тоже класс.Какое конкретно ты преимущество получаешь от PSh по сравнению, скажем, с JS.NET? За чято ты платишь таким синтаксисом?
До этого обходился Perl. Под виндой он просто не может конкурировать с PowerShell из-за нехватки .NET возможностей, разве что по скорости, но это для скриптов вторично.
- NightRoman
- Posts: 6172
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 32 times
- Been thanked: 62 times
- Contact:
- NightRoman
- Posts: 6172
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 32 times
- Been thanked: 62 times
- Contact:
Дошло, ясно. Но опять - надо надстройку делать и пользователю эти конфиги описывать и следовать некоторым новым правилам и т.д. Фреймворк начинает обрастать условностями.тут не имеются ввиду методы с точки зрения .NET а методы с точки зрения пользхователя - они могут показываться как пукты контествоно меню.
В PowerShellFar уже все это можно и так - и надстройки не нужны, инструмент уже есть сам по себе - на PowerShell в профайле делай любое меню, прицепляй любой код. Один инструмент на все случаи, далее дело за фантазией самого пользователя (разработчика, точнее, в нашем случае).
В конечном счете это все равно дело вкуса.
- NightRoman
- Posts: 6172
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 32 times
- Been thanked: 62 times
- Contact:
Обдумал я еще разок нашу дискуссию. Думаю, нет, ничуть не избыточно применять PowerShell для автоматизации редактора. Скрипты в редакторах - это очень даже обычная практика. А PowerShell - это один из мощнейших и удобнейших скриптовых языков на данный момент. Ответ вроде сам напрашивается.
Кстати, упомянутый пример кода с отступами в редакторе изначально у меня и был на C++ (вместе с авто-форматированием отступов). Перенес я их в PowerShell сначала просто в целях демонстрации и тестирования, а кончилось тем, что первоначальный C++ плагин я выбросил - мне смысла держать его просто нет - PowerShellFar я все равно использую, зачем мне лишнюю dll держать и грузить всякий раз? Разницы в производительности я не ощущаю (конечно, если прогнать в цикле и померять время, окажется, что теперь это делается в, скажем (не мерял), 100 раз медленнее, ну и что, я ж по команде эту операцию всегда делаю, а не в циклах).
Опять же со скриптами элементарно выделить и использовать в других скриптах общую функциональность (уже сделано: New-Editor-.ps1 New-Regex.ps1 Select-Menu-.ps1) - не надо думать ни о каких дополнительных библиотеках и прочих приседаниях. Нет-нет, скриптовый подход определенно имеет много плюсов. Наличие минусов - это нормально, никакой подход не может быть идеален. Но для не слишком объемных задач на PowerShell я пока реально серьезных минусов не вижу. Кроме того, насколько я знаю от разработчиков PowerShell на их форуме, MS эту технологию будут развивать и далее, производительность в том числе.
Кстати, упомянутый пример кода с отступами в редакторе изначально у меня и был на C++ (вместе с авто-форматированием отступов). Перенес я их в PowerShell сначала просто в целях демонстрации и тестирования, а кончилось тем, что первоначальный C++ плагин я выбросил - мне смысла держать его просто нет - PowerShellFar я все равно использую, зачем мне лишнюю dll держать и грузить всякий раз? Разницы в производительности я не ощущаю (конечно, если прогнать в цикле и померять время, окажется, что теперь это делается в, скажем (не мерял), 100 раз медленнее, ну и что, я ж по команде эту операцию всегда делаю, а не в циклах).
Опять же со скриптами элементарно выделить и использовать в других скриптах общую функциональность (уже сделано: New-Editor-.ps1 New-Regex.ps1 Select-Menu-.ps1) - не надо думать ни о каких дополнительных библиотеках и прочих приседаниях. Нет-нет, скриптовый подход определенно имеет много плюсов. Наличие минусов - это нормально, никакой подход не может быть идеален. Но для не слишком объемных задач на PowerShell я пока реально серьезных минусов не вижу. Кроме того, насколько я знаю от разработчиков PowerShell на их форуме, MS эту технологию будут развивать и далее, производительность в том числе.
- NightRoman
- Posts: 6172
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 32 times
- Been thanked: 62 times
- Contact:
- NightRoman
- Posts: 6172
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 32 times
- Been thanked: 62 times
- Contact: