» SciTE Ru-Board Edition

всем спасибо, разобрался

cvaqlav

Цитата:

-add: в shell добавлена функция inputbox.

Отличная работа Давно ждали такой функции.
Есть небольшое пожелание:
четвертый параметр (функция проверки ввода) сейчас передается как строка содержащая имя функции, хорошо бы сделать его указателем на функцию. Это более типично для Луа и избавляет от необходимости заведения глобальной функции.

Добавлено:
И еще есть замечание - функция проверки ввода должна вызываться при попытке завершить ввод (нажатие Enter или кнопки OK). Сейчас нет возможности запретить ввод пустого значения.

vladvro
На самом деле inputbox - временная мера. Когда соответствующая часть gui кем-нибудь будет доведена до ума, эту функцию нужно будет прибить.

Цитата:

...хорошо бы сделать его указателем на функцию...

Совершенно согласен, мне тоже не нравится, что приходится мусорить в глоб. пространстве. Всё дело в том, что я совершенно не знаю Lua, поэтому фактически скопировал учебный пример. Но попробую сделать: это интересно. (Если кто-нибудь другой не опередит. )

Цитата:

...функция проверки ввода должна вызываться при попытке завершить ввод...

Уточни, пожалуйста. Совсем убрать контроль в процессе набора и проверять только окончательный результат или добавить возможность доп. проверки?

cvaqlav

Цитата:

Уточни, пожалуйста. Совсем убрать контроль в процессе набора и проверять только окончательный результат или добавить возможность доп. проверки?

только добавить.

cvaqlav vladvro
Мне кажется что и существующаяя система проверки ввода будет реально использоваться на 5-10%.
Пихать в код проверку окончательного результата, когда это элементарно делается дополнительной строчкой кода на lua, считаю излишеством.

mozers

Цитата:

Пихать в код проверку окончательного результата, когда это элементарно делается дополнительной строчкой кода на lua, считаю излишеством.

Вероятно я был неправильно понят. В коде нужно добавить проверку ТОЙ ЖЕ функцией, что проверяет ввод каждого символа, перед закрытием диалога по "ОК". Если она вернула false, то не закрывать диалог. Я полагаю это не будет большим "излишеством". Но если есть другие предложения, как реализовать запрет ввода пустого значения, то я готов их обсудить.

vladvro

Цитата:

Вероятно я был неправильно понят.

Вероятно. Тем лучше. Хоть что-то начинаю понимать в Lua.
mozers
Внести проверочную ф-цию дело пары минут. Сложность в др. части...
(И даже не говори, чтобы переводил хелп. У меня Лингвобубен - весь в дырах. :\ Пусть это дело сначала "устаканится", а?)
All
Предлагаю (чтобы не было путаницы с версиями, типа SideBar vs. gui и т.п.) при каких-либо существенных изменениях делать метки ревизий. Напр. это метка текущей ревизии. А после выхода релиза прибивать их.

Цитата:

New Revision: 807
Log:
-chg: Опция "Сохранять файл сессии" заменена на команду "Выход (без сохранения сессии)" Alt+X

Хотел немного прокомментировать коммит 807, поскольку сам вначале не въехал в это рационализаторское предложение VladVRO.
Как чаще всего ведется работа в SciTE?
Открыты несколько файлов (проект) с которыми мы чаще всего работаем. Но то и дело приходится открывать какие то вспомогательные файлы чтобы что то подглядеть в них или чуть-чуть попутно подправить. Постепенно количество вкладок увеличивается… и мы с усталостью закрываем SciTE.
В следующий раз, когда мы вернемся к работе над своим проектом, мы обнаружим вместе с нужными файлами еще и кучу мусора, которую мы открывали прошлый раз и которую SciTE услужливо сохранил благодаря опции save.session=1.
Можно, конечно, сохранить нужные нам файлы проекта в сессию и открывать SciTE не с ярлыка, а с клика по файлу сессии. Можно нужные нам файлы или файл сессии поместить в Favorites SideBar. Можно. По разному можно…
А сейчас можно закрыть SciTE с помощью Alt+X и спокойно запускать его с ярлыка
Попробуйте - привычка придет быстро и мне кажется что фича будет наиболее часто используемой.
Вот только думаю как бы добавить в закрытие по Alt+X еще и отмену запроса на сохранение? (are.you.sure=0 сохраняет без запроса, а надо чтоб не сохранял. То, что надо я руками сохраню, а сохранять разные пробы-тесты в несколько строк – это совсем без надобности).


Добавлено:
cvaqlav
Чем shell.inputbox отличается от всех остальных придуманных человечеством контролов?
А тем, что только в нем, единственном и уникальном, все параметры надо задавать через одно место
И не надо доказывать что это дико удобно и наглядно и что завтра весь мир будет работать только по такому стандарту.
Срочненько играйте взад эту беду.

mozers

Цитата:

И не надо доказывать что это дико удобно и наглядно и что завтра весь мир будет работать только по такому стандарту.

Ты считаешь, мы с контролом уже можем начинать захват мира? Наконец-то!
В действительности же, этот пресловутый inputbox оказался удобной тестовой площадкой для работы с Lua. Поскольку, в отличие от того же gui, здесь я хотя бы понимаю каким образом работает остальной код.
Лично мне непозиционный способ передачи аргументов действительно кажется более удобным. Я, к примеру, совершенно не помню порядок аргументов. (Ну нет у меня памяти.)
Возможно, это делается в Lua по-другому. Тогда как? Это вопрос ко всем.
P.S. А откатить ты и сам можешь. Я одного не пойму. Разве на такие элементарные вещи, как рабочие правки (откаты и т.п.) нужно спрашивать разрешения у автора (типа как бы ненароком не обидеть)? Здесь что, ярмарка тщеславий или занятие интересным делом???

Добавлено:
vladvro
Как обе вещи (именованные аргументы и неглобальные ф-ции) делаются в Lua? Если можно, кинь ссылки. Или, хотя бы, примерно в какой стороне искать.

cvaqlav
Давай откати сам, а? Сам сделал - сам и откати... Ок?
Вообще я считаю что столь крутые эксперименты лучше проводить не в trunk, поскольку все изменения фиксируются в history которую смотрят не программисты.

Цитата:

Лично мне непозиционный способ передачи аргументов действительно кажется более удобным.
Возможно, это делается в Lua по-другому

Лично мне такой способ ОЧЕНЬ не нравится. Я таких примеров не видел. А если бы увидел, то всячески остерегся бы их применять.
Почему? А потому что я не хочу чтобы у людей, изучающих мои скрипты, без нужды пухла голова.
Есть всем известный и привычный стандарт. И пусть даже он в чем то хуже предложенного варианта, но привычка дико облегчает освоение нового. Поэтому чем больше новый контрол будет похож на все остальное, уже изученное - тем он лучше.
Люди, не изобретайте велосипед! Мало что ли нерешенных задач?

Мне почему то кажется что задача с использованием в контроле локальной функции или дико сложна или вообще нерешаема (Посмотрите ф-ции gui.dll - они все работают только если их объявить глобально). ИМХО не стоит мозг на это тратить, когда не решены более востребованные вещи...

mozers
По поводу отката я был неправ. Забыл, что там багфиксы есть. Если что: лучше переделать, а не просто отмотать назад.
Как там, мнение присяжных не изменилось? Казнить нельзя помиловать?

Добавлено:
Не обновил кэш, не видел твоего ответа. Мой ответ был на твой предыдущий пост.

Цитата:

Я таких примеров не видел.

То есть в Lua так не принято? Жаль. Ладно, оставлю этот способ для себя. А вы продолжайте мучиться.

Цитата:

Мне почему то кажется что задача с использованием в контроле локальной функции или дико сложна или вообще нерешаема

Да решаема. И даже легче, чем с таблицами в качестве параметра. Там вообще никаких заморочек. Вот только не уверен в верности выбранного способа передачи функции в качестве параметра. Подожду ответа VladVRO.
Короче понятно. Переделать и ну-ка её на фиг.

Цитата:

Люди, не изобретайте велосипед! Мало что ли нерешенных задач?

Это я, что ли, изобретатель велосипеда? Не... Он уже был там.

cvaqlav
Цитата:

Забыл, что там багфиксы есть. Если что: лучше переделать, а не просто отмотать назад.

Ок. Еще измени в 490 строке twl_toolbar.cpp NM_CLICK на LVN_ITEMCHANGED.
С помощью этой маленькой коррективы, предложенной Frank Wunderlich, мы убиваем сразу 2, уже изрядно поднадоевших, бага - повторный клик на выбранной ранее строке не будет вызывать события on_select и эвент будет работать сообразно своему названию (раньше он работал как on_click и лишние события приходилось отсеивать скриптом).
И выбор с помощью курсорных клавиш будет работать нормально, а не с запозданием на 1 шаг (см. показ тултипов в Abbreviations SideBar).

Цитата:

Как там, мнение присяжных не изменилось? Казнить нельзя помиловать?

Жаль, что ты сам не осознаешь что "лучшее - враг хорошего". Меняй, не тяни.

Добавлено:
Корректива убивает не 2 а 3 бага!
Раньше перемещение по списку с помощью курсорных клавиш не порождало события on_select. Сейчас все работает отлично!
Браво, Frank Wunderlich
Вот что значит заниматься решением актуальных задач!

Добавлено:
Наверное стоит принять и еще одну заплату этого же автора:
Цитата:

another patch for the cursor-glitch when try to move the side-panel (on mousedown, false cursor is shown (vertical double-arrow))

twl_splitter.cpp:30:

void TSplitterB::mouse_down(Point& pt)

Alignment a = align();
m_start = pt;
cursor(m_cursor);

mozers
Проверяй, деспот.

Цитата:

Ок. Еще измени в 490 строке twl_toolbar.cpp NM_CLICK на LVN_ITEMCHANGED.

Сейчас изменю.

Цитата:

Жаль, что ты сам не осознаешь что "лучшее - враг хорошего".

Не осознаю и не собираюсь этого делать.

Цитата:

Вот что значит заниматься решением актуальных задач!

Я сам не пользуюсь gui. Наверное, отсюда и взаимонепонимание.
У меня, как и у многих здесь, своя сборка.

cvaqlav
Цитата:

Проверяй, деспот.

Я очень рад, что теперь можно записать так:
Код: local function CheckFilename(name)
return not name:match('[\\/:|*?"<>]')
end
filename_new = shell.inputbox(title, msg1, filename_new, CheckFilename)

Последний снимок с багфиксами от Frank Wunderlich.
mozers
И так можно по-прежнему:

Код: filename_new = shell.inputbox(title, msg1, filename_new, function(name) return not name:match('[\\/:|*?"<>]') end)

mozers, cvaqlav
Ох, елки, ну вы шустрые, я за вами не поспеваю

Цитата:

Если бы я лично сам писал скрипты Lua, то в предыдущий вариант вцепился бы намертво.

По поводу функции, все же для Луа типичным способом предачи параметров в функцию является а-ля Си, примером тому наборы встроенных библиотек string, math, table и т.д., посему в этом mozers прав, правильным является последний вариант. Хотя временами он бывает черезчур категоричен
В любом случае работа была проделана интересная, спасибо cvaqlav, например, я не знал как этот способ реализуется на Си, а теперь есть пример. И как продолжение этого, я бы предложил реализовать смешаный вариант, когда возможна передача параметров и класическим способом и именнованным, но это понятно только эксперимента ради, нужды в этом нет.
Классический способ, на мой взгляд, удобнее, т.к. написание компактнее, а список параметров всегда можно посмотреть во всплывающей подсказке.

Цитата:

Вот что значит заниматься решением актуальных задач!

Тут я солидарен с cvaqlav, актуальность понятие относительное
На мой взгляд создание функции inputbox, причем полностью доведеной до ума, не менее актуально чем gui.dll. И чем человек пользуется, то ему и понятно и интересно доделывать.

vladvro

Цитата:

...примером тому наборы встроенных библиотек string, math, table и т.д.

Ну точно! Исходники-то под боком, а я ищу невесть где.

Цитата:

И как продолжение этого, я бы предложил реализовать смешаный вариант

Да, это действительно интересно. Только вот в чём проблема. Сейчас мне известны 2 способа передачи именованных параметров.
1) Заносим параметры в таблицу, а её уже -- в функцию

Код: func(par_1, par_2, {par_31="...",... par_3n="..."}, par_4)

cvaqlav

Цитата:

Я же утверждал (и продолжаю так считать), что интерес в этом деле не самое главное.

Лан как скажешь

У меня еще пара замечаний по shell.inputbox:
1. желательно что бы пока запущен диалог нельзя было переключаться на редактор, хотя можно сделать это и опциональным.
2. когда переключаешься на другие приложения не должно быть видно окна диалога.

vladvro

Цитата:

У меня еще пара замечаний по shell.inputbox

Ок. Наверное, опциональность не помешает. Или 2-й вариант добавить, чтоб не перегружать параметрами.
Наверное, стоит добавить возможность позиционирования по центру SciTE/Desktop или мышиного указателя?

cvaqlav

Цитата:

Наверное, стоит добавить возможность позиционирования по центру SciTE/Desktop или мышиного указателя?

На мой взгляд, это уже лишнее, вполне нормально что диалог возникает по центру экрана.

Цитата:

Author: qVaclav
Date: Sun Oct 19 05:51:30 2008
New Revision: 817

Modified:
trunk/src/make_with_VC.bat
trunk/src/scite/src/SciTEBase.h
trunk/src/scite/win32/SciTEWin.cxx

Log:
-chg: В сборке для Windows теперь выставляется локаль, аналогичная ACP. Это сделано для корректной работы строковых функций Lua.
Примеры.
print(string.lower("КрОкОдИл")) -- печатает "крокодил"
print(string.upper("КрОкОдИл")) -- печатает "КРОКОДИЛ"
Класс %w и др. locale-зависимые теперь включают в свои наборы национальные символы (как и должно быть).

Пожалуйста, потестируйте, поскольку не уверен, что это не сломает сборку.

Все работает отлично
Я и не думал что от этой беды в принципе можно избавится без правки исходников Lua...
Только одно "но". Очень прошу оформить все исправления в соответсвии с нашими правилами.
(на библиотеки эти правила не распостраняются, т.к. из них доработанные блоки никто не тырит

Сегодня неожиданно наткнулся на такую функцию в арсенале Lua: os.setlocale.
Видимо, rev. 817 была ненужной?
Ведь тот же самый эффект достигается таким образом

Код: os.setlocale("Russian_Russia.1251", "all")

cvaqlav
Цитата:

os.setlocale("Russian_Russia.1251", "all")

Да... Мануалы, оказывается, надо читать... (это я - про себя)

Цитата:

Между прочим, я собираюсь отменить ревизию.

При таком раскладе, очевидно что это - правильный шаг.

Еще одну проблемку обнаружил Frank Wunderlich:
Команда editor.Focus = true, используемая во многих местах SideBar.lua, вызывает лишь появление курсора в окне редактирования, при этом фокус ввода остается по прежнему на SideBar-е

Уж и не знаю на чей счет ее отнести - SciTE или ext_gui... Пожалуй, все таки это - проблема SciTE, поскольку editor.Focus - команда SciTE, а не ext_gui

Мужики, поглядите в чем дело!

Помнится у меня точно такая же ерунда была с командой Helper Focus. Перебрал все фунции API начиная с SetFocus - все возвращали только курсор. Багу удалось победить с помощью API-шной SetForegroundWindow.

mozers
глянь, плиз ПМ

Цитата:

Author: qVaclav
Date: Tue Oct 21 09:46:45 2008
New Revision: 825
-add: Added gui.pass_focus() function, which allows to pass keyboard focus to editor

Класс
Сразу захотелось потянуть с выпуском сборки... (может еще че прикольненькое до релиза сделаете...

mozers
Угу, я тоже думал: сейчас буду бамбук курить, а пришлось вкуривать мануалы и выкуривать баги. :/
А Frank Wunderlich не хочет напрямую участвовать в SciTE-Ru? ИМХО толку от него поболее будет.

vladvro
Я по поводу лексера Forth'а. Есть код:
Код: ' :
: :
[ CALL, ] [C]HERE LAST !
;

DJ makrus

Цитата:

Тэг "'" дожен экранировать следующий за ним тег ":"

Вообще никакого правила для тега "'" в лексере не обнаружил.
Давай точное описание правила для этого тега, будем добавлять.

vladvro
Цитата:

Давай точное описание правила для этого тега...

С точки зрения лексера он как и, например, "CHAR" - работает со следующим за ним тегом, т.е. следующий тег не должен иметь свою расцветку, а фактически это слово оставляет на стеке адрес следующего за ним слова (но это описание, как я понимаю не нужно).
Если в лексере на тег "'" нет никакого ограничения, то это странно, т.к. нет необходимости вводить его в сам лексер, надо просто что бы лексер обрабатывал его так же как и остальные теги из группы "prewords1", т.е. фактически его надо добавить только в файл настроек forth.properties , а не в лексер, но сейчас это не работает