Выделить и скопировать из режима просмотра (F3)

Вам не хватает чего-то в Far? Вы считаете, что вашу идею стоит услышать? Пишите сюда.
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Выделить и скопировать из режима просмотра (F3)

Post by citRiks »

Latest post of the previous page:

DrKnS wrote: Wed 26 Feb, 2020 15:03
citRiks wrote: Wed 26 Feb, 2020 14:21именно так
Добавить, конечно, можно. Можно и диалог такой прямо в фар засунуть. А как этим пользоваться?
Вот есть экран текста. Как вы невооруженным глазом определите координаты нужной вам позиции? Возьмете карандаш и будете по экрану водить и строки в уме считать? Так проще мышь взять.
Не, сценарий нужности не такой совсем, для того и нужен такой АПИ который я спрашиваю,
чтобы не считать ни в уме ни в Луа.
А искомый сценарий такой:
1.) Эмуляция курсора на вьювере
2.) Чтобы его эмулировать, мы рисуем на экране что нибудь мигающее.
Пусть для начала в позиции экрана {Х= 20, У = 20}
Вот он там сидит себе мигает.
3.) А привязки к позиции в файле то нет..
как соотнести позицию {20, 20} с файлом?
А соотносить надо, например чтобы отметить "вот тут начало selection".
Вы скажете "есть же позиция начала экрана viewer.FilePos, чего же тебе еще надо, хороняка!?"
Да, позиция начала экрана есть, но с этой позиции у нас есть 20 строк произвольной длины,
что значит позиция начала экрана нам никак не помогает, а надо знатъ позицию экрана в файле,
т.е. функцию ScreenPosToFilePos(Х, У) {retruns} offset
Вьювер-то внутри себя ее имеет, использует для выделения мышью, но ее нету в АПИ
User avatar
zg
zero-gravity
Posts: 6015
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 185 times
Contact:

Выделить и скопировать из режима просмотра (F3)

Post by zg »

citRiks wrote: Wed 26 Feb, 2020 15:36Позиция (в байтах) начала экрана у нас есть, но нет позиции конца экрана (в байтах), или где она в существующем АПИ?
а где я говорю про существующее апи? вы предложили две функции, я не понимаю, зачем нужна вторая, поэтому спрашиваю у вас. вы за два сообщения не смогли добавить никакой дополнительной информации и даже начали съезжать куда-то в сторону, из чего я могу сделать вывод, что либо вы сами не очень понимаете — зачем это нужно, либо вам в принципе всё равно на ваше предложение.
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Выделить и скопировать из режима просмотра (F3)

Post by citRiks »

zg wrote: Wed 26 Feb, 2020 14:27 citRiks писал(а): ↑
viewer.FilePosToScreenPos(offset)
зачем?
Вот тут я вполне конкретно ответил:
citRiks wrote: Wed 26 Feb, 2020 14:57 Например, чтобы знать находится ли интересующая нас точка (=позиция, =символ) файла в экранном буфере или же за его пределами.
Если за пределами, то в принципе достаточно будет получить {X= -1, Y= -1}
И\или знать начало и конец в байтах экранного буфера, например получать так
viewer.ScreenStarCharOffset
viewer.ScreenEndCharOffset
Или, если это возможно, выдавать {Х=300, Y = -12345} - точка справа за пределом экрана и наверху за пределом экрана.
Другой подобный use case:
мы сделали выделение скриптом,
но не знаем видит ли юзер его начало, конец, середину, или вообще не видит.
И чтобы прокрутить экран туда куда нужно если нужно.
вот тут вы не согласились вот тут вы не согласились сказав что можно без этой второй фунцкии обойтись, поскольку ...
А, дошло. предложенное действительно помогает, но лишь частично, ок, сейчас дообьясню.
zg wrote: Wed 26 Feb, 2020 15:04 citRiks писал(а): ↑
Ср 26 фев, 2020 16:57
Например, чтобы знать находится ли интересующая нас точка (=позиция, =символ) файла в экранном буфере или же за его пределами.

вы получаете позицию в файле для начала экрана и для конца и сравниваете. поэтому я всё ещё жду практический пример использования FilePosToScreenPos.
тут я вас не до конца понял, но все же сказанное тиут мною имеет смысл:
citRiks wrote: Wed 26 Feb, 2020 15:36 zg писал(а): ↑
Ср 26 фев, 2020 17:04
Bы получаете позицию в файле для начала экрана и для конца и сравниваете

Позиция (в байтах) начала экрана у нас есть, но нет позиции конца экрана (в байтах), или где она в существующем АПИ?
Отмечу что в экране может помещаться любое количество байтов, поэтому вот так НЕ получится:
ПозицияКонцаЭкранаВБайтах = ПозицияНачалаЭкранаВБайтах + ДлинаЭкрана{УмножитьНа}ШиринаЭкрана
zg wrote: Wed 26 Feb, 2020 19:03 а где я говорю про существующее апи? вы предложили две функции, я не понимаю, зачем нужна вторая, поэтому спрашиваю у вас. вы за два сообщения не смогли добавить никакой дополнительной информации и даже начали съезжать куда-то в сторону, из чего я могу сделать вывод, что либо вы сами не очень понимаете — зачем это нужно, либо вам в принципе всё равно на ваше предложение.
(сейчас дообьясню в общем)
Last edited by citRiks on Wed 26 Feb, 2020 20:09, edited 3 times in total.
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Выделить и скопировать из режима просмотра (F3)

Post by citRiks »

Значит так, у нас ест экран 20выс. на 80шир. {H=80, W=80}
Хорошо, у нас есть локация первого и последнего символа экрана.
Но с последним символом влезшим в экран не все так просто.
Что если если последний символ "Хэ" последней строчки в экране расположен (~Х=50) менее ширины экрана (W=80)?
Нам что тогда скажет первая функция ScreenPosToFilePos(20, 80)?
два основных варианта:
1.) ScreenPosToFilePos честно скажет "да не знаю я, тут нет никакого символа", и тогда нам от этой функции пользы нет, увы.
2.) ScreenPosToFilePos попытается нам помочь скажет, да, тут у меня буква "Хэ" написана, это 12345-й о счету символ в файле.
И что же получается? Получается что мы ошибочно считаем что в координате экрана {20, 80} сидит буква "Хэ", и прокручиваем туда туда курсор и фокус.
На пустое местов в экране!
Обманывемся сами, подводим нашего юзера который пользуется нашим макросом.
есть правда еще третий замороченный вариант:
3.) Кроме оффсета в файле быквы "Хэ" (последнего символа последней строки) ScreenPosToFilePos возвращает нам еще и насколько последняя строка эта недотягивает до конца экрана,
т.е. ширинаЭкрана - длинаСтрочки = 80 - 50 = 30
По-моему тут пахнет усложнениями, нет?
Ну допустим, пусть так.
Напомню что нам надо точно спозиционировать курсор исходя из оффсета в файле, - ну юзер туда воткнул какую закладку, - или SelectionStart, или SelectionEnd, или whatever needed,
и хочет туда теперь прокрутится, мы его хотим туда прокрутить.
Потому что оффсет в файле это наша единственная ориентация на которыю можно положится, все остальное - плавающие произвоодные от оффсета.
И нам надо спозиционировать курсор на искомой букве в экране, имея ее координату в файле =оффсет)
Допустим мы мы получили так или иначе что "окно" экрана это байты с 12345 по 12500.
Как нам первая функция ScreenPosToFilePos поможет поставить курсор юзера на букву "Хэ" если она будет 12400-я?
По-моему никак, разве что только перебором всех позиций в диапазоне 80 умножить на 20 равно 1600 тыков. Кхм...
Last edited by citRiks on Wed 26 Feb, 2020 21:08, edited 4 times in total.
User avatar
zg
zero-gravity
Posts: 6015
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 185 times
Contact:

Выделить и скопировать из режима просмотра (F3)

Post by zg »

citRiks wrote: Wed 26 Feb, 2020 19:59Вот тут я вполне конкретно ответил:
нет. в последний раз. у вас есть функция viewer.ScreenPosToFilePos(X, Y). вы вызываете её для начала экрана, вызываете для конца экрана. получаете два числа. если позиция в файле расположена между ними, то она на экране, нет — нет. мне кажется — это очевидно. зачем viewer.FilePosToScreenPos(offset)?
ps: не надо простыней текста, возможно я даже что-то упускаю, но очень много воды и повторов.
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Выделить и скопировать из режима просмотра (F3)

Post by citRiks »

zg,
ну моя мысль если совсме вкратце:
недостаточно знать влазит буква в экран или нет,
мы хотим на нее вставать курсором, а для того нужен FilePosToScrеenPos, и недостаточно ScreenPosToFilePos.

так лучше обьяснил?
можно ли еще привести сценарии нужности?
их есть у меня!

И на всякий случай повторюсь:
FilePosТоScreenPos действительно менее важна чем ScreenPosToFilePos.
Но все же лучше ее иметь, если не очень дофига работы (?)
Вроде бы, если вьювер знает где в файле сидит каждая буква на экране 20х80 (ScreenPosToFilePos),
то наверное он должен знать и обратное, как символы буфера из диапазона 12345-12500 расположены на экране (FilePosToScreenPos),
по крайней мере в пределах этого current screen.
с тем что за пределами - ок, разобрались, да, достаточно понимать
что некий оффсет=10000 находится за выше по тексту за верхним пределом,
а оффсет=15000 находится ниже по тексту под нижним пределом
ы..?
Last edited by citRiks on Wed 26 Feb, 2020 21:06, edited 3 times in total.
User avatar
zg
zero-gravity
Posts: 6015
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 185 times
Contact:

Выделить и скопировать из режима просмотра (F3)

Post by zg »

citRiks wrote: Wed 26 Feb, 2020 20:52мы хотим на нее вставать курсором
в результате чего? курсор на экране, пользователь двигает его при помощи стрелок и тут нужен только ScreenPosToFilePos. единственное, что мне приходит в голову, это переход на начало/конец выделения по нажатию клавиши. но это однократное действие и вполне реализуемого перебором.
citRiks wrote: Wed 26 Feb, 2020 20:52так лучше обьяснил?
к сожалению, нет.
citRiks wrote: Wed 26 Feb, 2020 20:52можно ли еще привести сценарии нужности?
их есть у меня!
и почему вы их всех скрываете? почему единственный практический пример привёл я?
citRiks wrote: Wed 26 Feb, 2020 20:52Но все же лучше ее иметь, если не очень дофига работы (?)
зачем добавлять в апи что-то ненужное? добавить просто, но потом же это надо поддерживать. доки писать, а если не писать, то некоторые прямо требуют.
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Выделить и скопировать из режима просмотра (F3)

Post by citRiks »

zg wrote: Wed 26 Feb, 2020 21:53 и почему вы их всех скрываете? почему единственный практический пример привёл я?
Ну вот же я писал ранее:
citRiks wrote: Wed 26 Feb, 2020 20:00 Напомню что нам надо точно спозиционировать курсор исходя из оффсета в файле, - ну юзер туда воткнул какую закладку, - или SelectionStart, или SelectionEnd, или whatever needed,
и хочет туда теперь прокрутится, мы его хотим туда прокрутить.
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Выделить и скопировать из режима просмотра (F3)

Post by citRiks »

zg wrote: Wed 26 Feb, 2020 21:53 в результате чего? курсор на экране, пользователь двигает его при помощи стрелок и тут нужен только ScreenPosToFilePos.
единственное, что мне приходит в голову, это переход на начало/конец выделения по нажатию клавиши. но это однократное действие и вполне реализуемого перебором.
ну да, я тоже писал про selection.. Простым перебором на тысячи позиций?
это мину закладывать, люди начнут пользоваться, макросить, и 100% многие если не большинство найдут сценарии где этот перебор будет ощутимо тормозить, и будут плеваться на это придумавших..
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Выделить и скопировать из режима просмотра (F3)

Post by citRiks »

Еще в копилку сценариев:
Реализация CtrlShift(Right|Left)

Нормальный эфективный вариант:
1.) мы читаем из файла куда случился прыжок на слово, где оно заканчивается.
а заканчиватся оно может например на следующей или предыдущей странице, или через пять страниц, но нас это не колышет,
потому что мы нашли в файле конец слова, спокойно делаем FilePosToScreenPos, видим конец слова что на следующей странице, прокручиваем страницу на одну строчку,
проверям присутствие слова на уже сдвинутом скрине, если нет, то сдвигаем построчно пока конец слова не будет попадать в буфер..
Вызовов фунцкии FilePosToScreenPos будет меньше чем пальцев на руке, и мы получим полный контроль позиционирования, ценой этих немногих вызовов.

Вариант "Из Пушкина-Луну!"
2.) Мы начинаем переводить экранные позиции в символы с файла, нам надо знать что это за символы, посимвольно вызывать ScreenPosToFilePos, и потом посимвольно читать с файла, составлять слово, или что это вообще там в файле. Тут становится непонятно как трактоватъ пустое место справа от строчек.. ну что-то можно придумать, но это надо придумывать и грузить и CPU и IO и RAM и GarbageCollector, и вот это все

Из той же оперы "выделить параграф\предложение", и спозиционировать как-то правильно, а не абы как получится.
Правильно - это например так чтобы конец выделения не сповпадал с концом экрана, иначе человеку непонятно где закончилось выделение.

проще говоря:
* с FilePosToScreenPos мы легкочитаем с файла все что нужно, а потом легко встаем курсором\скролом\фокусом туда куда нужно.
* с ScreenPosToFilePos мы через заднее место читаем что имеет пользователь на экране, а потом через заднее же место пытаемся спозиционироваться на экране.
"Заднее место" в моей терминологии, это когда в моей терминологии затратно для усилий как программера так и ресурсов компа, как-то CPU/IO/RAM

В других сценариях ScreenPosToFilePos будет необходима, a FilePosToScreenPos и не нужна.
А тут я описал как все же сделать так чтобы не мучить себя, юзеров и ресурсы компа.
Last edited by citRiks on Wed 26 Feb, 2020 22:45, edited 3 times in total.
User avatar
buniak_a_h
Posts: 4234
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 642 times
Contact:

Выделить и скопировать из режима просмотра (F3)

Post by buniak_a_h »

zg wrote: Wed 26 Feb, 2020 21:53 курсор на экране, пользователь двигает его при помощи стрелок
Стесняюсь спросить… то - про вьюер? Как-то у меня курсор стрелками во вьюере не двигается …
Впрочем, отметка мышкой тоже не получается: при клике на верхней части окна начинается скролл с бешенной скоростью назад; на нижней - вперёд.
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Выделить и скопировать из режима просмотра (F3)

Post by citRiks »

zg wrote: Wed 26 Feb, 2020 21:53 зачем добавлять в апи что-то ненужное? добавить просто, но потом же это надо поддерживать. доки писать, а если не писать, то некоторые прямо требуют.
Mне представляется нужным, выше у меня достаточно аргументов?
Давайте я напишу доки, или пошлю вам описание работы этих двух функций, а вы его скопипастите куда надо.
Можно приписать "строго экспериментально, не поддерживается, используйте на свой страх и риск".

User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Выделить и скопировать из режима просмотра (F3)

Post by citRiks »

buniak_a_h, обсуждается "как реализовать курсор", которого сейчас нету :)
A в начале темы - интересный скрипт с примитивным посимвольным выделением.
примитивный по функциональности, но при этом довольно гениальный реазлизацией.
(сам бы я до такого ну оооочень долго бы додумывался)
User avatar
zg
zero-gravity
Posts: 6015
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 185 times
Contact:

Выделить и скопировать из режима просмотра (F3)

Post by zg »

citRiks wrote: Wed 26 Feb, 2020 22:01Ну вот же я писал ранее:
когда я читал это сообщение, оно состояло из одного слова.
citRiks wrote: Wed 26 Feb, 2020 22:08ну да, я тоже писал про selection.. Простым перебором на тысячи позиций?
вы шутите? если да — то мне не смешно. если нет, то мне грустно и обсуждение надо заканчивать. количество попыток=log2(ширина*длина). т.е. для 80x25 это 12, для 500x200 — 17. более того, внутри фара это скорее всего будет так же реализовываться.
citRiks wrote: Wed 26 Feb, 2020 22:261.) мы читаем из файла куда случился прыжок на слово, где оно заканчивается.
а заканчиватся оно может например на следующей или предыдущей странице, или через пять страниц, но нас это не колышет,
потому что мы нашли в файле конец слова, спокойно делаем FilePosToScreenPos, видим конец слова что на следующей странице, прокручиваем страницу на одну строчку,
проверям присутствие слова на уже сдвинутом скрине, если нет, то сдвигаем построчно пока конец слова не будет попадать в буфер..
Вызовов фунцкии FilePosToScreenPos будет меньше чем пальцев на руке, и мы получим полный контроль позиционирования, ценой этих немногих вызовов.
и это вы говорите об эффективности? а если конец слова через 5Gb? единственное, что можно сделать, если конец слова не на экране, это установить позицию просмотра на конец слова и курсор естественно вначале, либо чуть умнее немного отступив, и при этом курсор всё равно можно установить и без FilePosToScreenPos.
buniak_a_h wrote: Wed 26 Feb, 2020 22:48Стесняюсь спросить… то - про вьюер? Как-то у меня курсор стрелками во вьюере не двигается …
я стеснятся не буду и спрошу в лоб: это вежливо вырывать слова из контекста и прикидываться дурачком?
buniak_a_h wrote: Wed 26 Feb, 2020 22:48Впрочем, отметка мышкой тоже не получается: при клике на верхней части окна начинается скролл с бешенной скоростью назад; на нижней - вперёд.
опять же без стеснения, f1 нажимать пробовали? читать умеете?
citRiks wrote: Wed 26 Feb, 2020 22:54Mне представляется нужным, выше у меня достаточно аргументов?
за время обсуждения их стало меньше.
citRiks wrote: Wed 26 Feb, 2020 22:54Давайте я напишу доки, или пошлю вам описание работы этих двух функций, а вы его скопипастите куда надо.
вы для начала объясните, зачем нужна вторая функция.
citRiks wrote: Wed 26 Feb, 2020 22:54Можно приписать "строго экспериментально, не поддерживается, используйте на свой страх и риск".
никто ж не читает, чуть выше свежий пример.
Мы недостаточно используем сильные стороны ФАРа, зачастую даже там где с полпинка заработает.
citRiks wrote: Wed 26 Feb, 2020 22:54Может надо побольше выносить в АПИ, чтобы можно было макросить эффективно?
Вот был бы неплохо просмотрщик с неплохой функциональностью и интеграцией.
вот недавно кто-то попросил DN_LISTCHANGE в меню, я мягкость проявил, до сих пор аукается.
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Выделить и скопировать из режима просмотра (F3)

Post by citRiks »

zg wrote: Thu 27 Feb, 2020 00:13 citRiks писал(а): ↑
Чт 27 фев, 2020 00:01
Ну вот же я писал ранее:

когда я читал это сообщение, оно состояло из одного слова.
Но оно было не матерное! Я не позволяю себе матерится или врать в благородном общесте.
zg wrote: Thu 27 Feb, 2020 00:13 количество попыток=log2(ширина*длина). т.е. для 80x25 это 12, для 500x200 — 17
это вы про бинарный поиск? Снимаю шляпу, я про бинарный поиск не подумал, а было бы да, довольно умно так и сделать
Но мне пока непонятно, как применять бинарный поиск, если строки длинные, а экран не стоит на начале строк, а вообще стоит по середине.
т.е., наши строки 200 символов, экран стоит с 100-го символа по 180-й скажем.
тогда диапазон будет разорван на количество строк, что усложняет бинарный поиск..
хотя да, можно применять его внутри поддиапазонов что ли..
мысль как это делать не до конца созрела, но наверное можно.
Вот я о предлагал сделать функцию, чтобы желающим писать на Луа для вьювера не нужна бы была такая задумчивость и гениальность,
тем более если это уже есть внутри ФАРа. Ну нет - так нет.
zg wrote: Thu 27 Feb, 2020 00:13 более того, внутри фара это скорее всего будет так же реализовываться.
Внутри ФАРа это внутри, а снаружи ФАРа из Луа в ФАР я думаю что менее эффективно,
сомневаюсь что вызовы снаружи из Луа будут так же эффективны как Си-код внутри самого кода ФАРа..?
zg wrote: Thu 27 Feb, 2020 00:13 и это вы говорите об эффективности? а если конец слова через 5Gb? единственное, что можно сделать, если конец слова не на экране, это установить позицию просмотра на конец слова и курсор естественно вначале, либо чуть умнее немного отступив, и при этом курсор всё равно можно установить и без FilePosToScreenPos.
ну типа того, для больших скачков можно и нужно так и делать,
но все равно, потом надо реазливывать бинарные поиски, алгоритмы, или что там, чего я хотел избежать..
zg wrote: Thu 27 Feb, 2020 00:13 вы для начала объясните, зачем нужна вторая функция.
Хорошо, давайте попробуем обойтись без оной (FilePosToScreenPos) с одной первой (ScreenPosToFilePos),
если функции FilePosToScreenPos нет в ФАРе или если есть трудность с ее выносом в АПИ, вам это виднее конечно
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

Выделить и скопировать из режима просмотра (F3)

Post by citRiks »

Выдам общее ИМХО-соображение, но влекущее все детали реализации.
При работе с файлом, нам лучше плясать от файла.
Курсор на экране, все что на экране, это лишь отображение представления файла как файла, или как куска файла в памяти.
НАпример, если мы хотим делать какой регексп (на содержание файла конечно),
то нам в десятки раз проще читать из файл применяя регескп, это тривиально.
Нашли что надо в файле, знаем эти позиции регекспа в файле, и привели представление на экране в соответсвие с результами.
Т.е., применяя FilePosToScreenPos.
Это проще чем делать обратное - переведить представление на экране в содержание файла, т.е. ScreenPosToFilePos.
иными словами переводить представление файла в содержание, и уже потом делать на нем операции.
Проще просто потому что, то что на экране уже прошло транформации, и надо это уметь предусматривать и переваривать.
Для других сценариев, и для большинства других сценариев нужнее ScreenPosToFilePos.
Да, для реалзиции курсора FilePosToScreenPos не является необходимостью, но значительбно облегчает жизнь.

Строго говоря, ведь и ScreenPosToFilePos тоже не явалятся необходимостью.
Можно парсить буквы на экране и искать им соответсвие в файле, опираясь на существующий viewer.GetFilPos.
Но это очень муторно программеру, достоверный результат наверное достижим, но с большим трудом.
И опять же, зачем, если в ФАРе это уже есть и можно вынести в АПИ?
Лично я такой сценарий реализовывать не буду, потому что зачем биться башкой об стену,
если тут допустим что не хотят эффективного АПИ и скриптинга?
Post Reply

Return to “Предложения и идеи”