[elisp]: перемещение по экранной строке

goto-char, beginning-of-line, end-of-line, end-of-visible-line

К сожалению, сейчас не могу проверить, но есть подозрение, что это переход на начало\конец не экранной строк. То есть, эти функции, при обнаружении признака конца строки останавливаются. If this function reaches the end of the buffer (or of the accessible portion, if narrowing is in effect), it positions point there.
А может быть, пресловутый narrowing включен по умолчанию? Хотя я вроде выполнял widen...

А что надо сделать? Из первоначального поста непонятно.

Пример: сделать функцию, переводящую точку в середину строки. Например, в константную 40-ую колонку (при 80 символьной строке терминала), вне зависимости от длину текущей строки в буфере - 1, 15, 170, etc.

Можно подсмотреть идею в реализации функции end-of-visible-line.

> в 40-ую колонку

> длина текущей строки в буфере - 1, 15

Нет, этому положению просто не соответствует никакое значение точки. Можешь, конечно, запробелить до `(window-width)`.

А что ты делаешь, что тебе такое понадобилось?

Собственно, идея очень проста, но мне показалась интересной. Со всякими msf-abbrev скорость повышается, но все равно очень много времени тратится на перемещение по буферу. А идея такая - экран делится на x секторов по горизонтали и y по вертикали. ________ | 11| 12| 2x2 |___|___| | 21| 22| |___|___|

Ну и собсно переход в конкретный регион экрана - что-нибудь вроде (абстрактно) M-11 etc. А если в числе встречается 0, то по этой оси не двигаемся. Ну и дальнейшие модификации :)

//flagist0

Млиао, скажите, много ли народа пользуется ТеХом по умолчанию :(((

Собственно, идея очень проста, но мне показалась интересной. Со всякими msf-abbrev скорость повышается, но все равно очень много времени тратится на перемещение по буферу. А идея такая - экран делится на x секторов по горизонтали и y по вертикали. ________ | 11| 12| 2x2 |___|___| | 21| 22| |___|___|

Ну и собсно переход в конкретный регион экрана - что-нибудь вроде (абстрактно) M-11 etc. А если в числе встречается 0, то по этой оси не двигаемся. Ну и дальнейшие модификации :)

//flagist0

FFFF!
Млиао, скажите, много ли народа пользуется ТеХом по умолчанию :(((

Собственно, идея очень проста, но мне показалась интересной. Со всякими msf-abbrev скорость повышается, но все равно очень много времени тратится на перемещение по буферу.
А идея такая - экран делится на x секторов по горизонтали и y по вертикали.
________
| 11| 12| 2x2
|___|___|
| 21| 22|
|___|___|

Ну и собсно переход в конкретный регион экрана - что-нибудь вроде (абстрактно) M-11 etc. А если в числе встречается 0, то по этой оси не двигаемся. Ну и дальнейшие модификации :)

//flagist0

Я чего-то совсем не въехал в потребность. Сам посммтри, может быть, тебе интересно про vertical-motion посмотреть? И главу Motion by Screen Lines. Эта функция именно по строчкам экрана движется, а не по строчкам текста.

А, вот вчитался. Я правильно понимаю, что рафинированная задача такая: есть строчка в 15 символов при ширине экрана 80 символов. Надо попасть в координату 40 внутри этой строки. Так?

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

>Все так. Но желательно не менять саму строку, типа предложенного выше забивания до нужной координаты пробелами или табуляциями.

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

Вообще зависит от задачи. Пример (не привязанный к уже существующим решениям :) ): Обычно в исходниках правая часть экрана пуста. Допустим, я хочу ставить коменты только в третьем горизонтальном секторе, в конкретной колонке. Если ориентироваться на обычную длину строки, то все коменты будут с разным отступом. Хотя пример притянут за уши - но не люблю я притянутые к конкретным случаям решения :) Тем более, что в такой среде как емакс 100% должно быть решение.

>Допустим, я хочу ставить коменты только в третьем горизонтальном секторе, в конкретной колонке.

Да, но когда ты наберешь самый первый символ этого комментария, у тебя автоматически должны перед ним образоваться пробелы от конца строки до этого комментария. А то как хранить эти оторванные куски? Ясное дело, что просто добивается это хозяйство нужным числом пробелов в файле. Тогда ты ничего ничего и не теряешь. Посто если ты не введешь ничего в этой зоне, то после ухода оттуда, пробелы сотрутся. А если решишь что-то вбить, то пробелы вставленные не пропадут.

>Если ориентироваться на обычную длину строки, то все коменты будут с разным отступом.

Ну да, а разве проблемы посчитать? Отнимаем от нужного положения конец строки, заполняем пробелами. Ушел с позиции вниз/вверх -- новый расчет и заполнение, ушел вправо/влево дозаполнение/удаление пробела. Будет чутка подтормаживать, конечно, при перемещениях в этом секторе.

Хотя, конечно, отказываться от поиска штатного метода, который умеет чисто по экрану, а не по тексту бежать, не стоит. Но вот что-то мне ничего не вспоминается. Кстати, разумно написать вопрос в gnu.emacs.help

Мда, вобщем я осознал несознательность примера. Проблема-то общая - перемещение по секторам экрана, вне зависимости от мода и задачи. Например, гнус или w3m тоже требует перемещения по экрану, даже если ничего не надо редактировать (или если буфер рид-онли). Просто далеко не всегда удобно перемещаться по символам\словам\строкам\экранам. Даже переход в середину (а может вторую треть? или третью четверть?) строки требует кучи нажатий. А мне нужен метод, который как ^e\^a войдет в пальцы и подкорку и позволит перемещаться в любые сектора экрана. Вне зависимости от того, есть там символы или нет. А написать - напишу конечно :)

>Например, гнус или w3m тоже требует перемещения по экрану, даже если ничего не надо редактировать

Ну, кстати, в w3m практически весь буффер запробелен. попробуй походить C-f, C-b, C-p, C-n по буферу. Так что тут у тебя будет работать обычное перемещение по буферу: вычисляешь строку, в которую надо переместить курсор и позицию в строке.

> в w3m практически весь буфер запробелен

Как и в гнусе.

Тебе нужно написать функцию, которая по заданной колонке и строке ищет позицию в окне, наиболее близкую к соответствующей «экранной позиции».

> символам\словам\строкам\экранам

параграфам, страницам (^L), sexp'ам (включая кавычки), isearch'ам?

Мне вообще кажется, что проблема высосана из пальца, так как требуемые задачки решаются и так. Если буфер read-only, то просто его смещать нужным образом (зачем курсор перемещать по такому буферу?). Если в буфере нужно попасть на какую-то активную надпись, то в эту надпись можно попасть штатными методами (оторванного текста, не отбитого пробелами просто нет). Если надо в нужную позицию попадать в буфере, который редактируется, то добивка пробелами (padding какой-нибудь может быть даже штатный есть -- надо посмотреть). Было бы хорошо, если бы автор топика привел какую-нибудь задачу. Я вот, например, не помню ни одного текстового редактора, который так умеет -- notepad, nedit, (прости, господи) winword и т. д. -- никто не дает возможности гулять там, где ничего нет.