[devel] Fwd: [Bram@: Re: vim7 and xterm variants]

[devel] Fwd: [Bram@: Re: vim7 and xterm variants]

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

Предыстория - Bram слегка изменил встроенные termcap'ы в vim7 и в
консоли отвалилась поддержка кнопок Home и End, причём в xterm
работает только End, а в aterm только Home.

xterm генерит \e[1~/\e[4~, aterm - \e[7~/\e[8~

Не пора ли привести всё это к общему знаменателю?

P.S. 2 ldv: Дим, я заберу aterm? 1.0beta2 допилю на выходных,
utempter оно умеет.

----- Forwarded message from Bram Moolenaar <Bram@moolenaar.net> -----

Date: Fri, 25 Mar 2005 13:08:53 +0100
From: Bram Moolenaar <Bram@>
To: "Alexey I. Froloff" <raorn@>
Subject: Re: vim7 and xterm variants

[..skip..]

For me the xterm always produces \eOH and \eOF without a modifier key
and \e[1;*H  and \e[1;*F with a modifier key.  The xterm documentation
mentions the other codes \e[1~ and \e[4~ for the VT220 keypad.  Oh, it
seems I used 7 instead of 1 for the home key here.  I'll fix that.

I can't find anything about \e[7~ and \e[8~ in the xterm documentation.
Since I needed to define the new sequences to allow all kinds of
modifiers I dropped these.  If these would also need to be supported I
would have to introduce yet another HOME key alternative.

> So, I'd like to know why you've made these changes and who is
> really wrong - builtin termcaps or my terminal emulators?

I made these changes to be able to accept modifiers as xterm sends them
for function keys.

After fixing the mistake with <Home> it should be OK.  rxvt and aterm
appear to send different sequences for <Home> and <End>, thus you need
to use a different termcap entry for them.  I don't know if there is
some historical reason they use different codes than xterm.  You might
want to ask their mainainers.

----- End forwarded message -----

-- 
Regards, Sir Raorn.
-------------------
Я - за. Но я знаю людей, которые будут против. ;-(
		-- rider in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Fwd: [Bram@: Re: vim7 and xterm variants]

[Sergey Pinaev]

On Fri, 25 Mar 2005 17:54:07 +0300
"Alexey I. Froloff" <raorn@immo.ru> wrote:

> Предыстория - Bram слегка изменил встроенные termcap'ы в vim7 и в
> консоли отвалилась поддержка кнопок Home и End, причём в xterm
> работает только End, а в aterm только Home.
> 
> xterm генерит \e[1~/\e[4~, aterm - \e[7~/\e[8~

Это "у кого как" =/
xterm - ^[[H/^[[F
aterm - таки да, таки ^[[7~/^[[8~
aterm + screen - ^[[1~/[[4~
xterm + screen - ^[OH/^[OF

-- 
mail="Sergey Pinaev <dfo@antex.ru>"
url="http://`echo $mail | sed 's/.* <\(.*\)@\(.*\)>/\1.\2/'`"

Re: [devel] Fwd: [Bram@: Re: vim7 and xterm variants]

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

Hi,


On Fri, Mar 25, 2005 at 05:54:07PM +0300, Alexey I. Froloff wrote:
> Предыстория - Bram слегка изменил встроенные termcap'ы в vim7 и в
> консоли отвалилась поддержка кнопок Home и End, причём в xterm
> работает только End, а в aterm только Home.

Остаётся только радоваться, что End в xterm по-прежнему работает как End,
а не как Home.

> xterm генерит \e[1~/\e[4~, aterm - \e[7~/\e[8~
> 
> Не пора ли привести всё это к общему знаменателю?

Каким образом? xterm != rxvt.

> P.S. 2 ldv: Дим, я заберу aterm? 1.0beta2 допилю на выходных,
> utempter оно умеет.

Бери на здоровье.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Fwd: [Bram@: Re: vim7 and xterm variants]

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

* Dmitry V. Levin <ldv@> [050325 18:10]:
> > xterm генерит \e[1~/\e[4~, aterm - \e[7~/\e[8~
> > Не пора ли привести всё это к общему знаменателю?
> Каким образом? xterm != rxvt.
Таким:

#ifdef LINUX_KEYS
# define KS_HOME    "\033[1~"   /* Home == Find */
# define KS_END     "\033[4~"   /* End == Select */
#else
# define KS_HOME    "\033[7~"   /* Home */
# define KS_END     "\033[8~"   /* End */
#endif

И от $TERM это не зависит...

> > P.S. 2 ldv: Дим, я заберу aterm? 1.0beta2 допилю на выходных,
> > utempter оно умеет.
> Бери на здоровье.
Спасибо.

-- 
Regards, Sir Raorn.
-------------------
Потребитель не всегда знает, что ему нужно :-)
На самом деле, я противник голосований, когда их результаты не обязательны к
исполнению.
		-- aen in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Fwd: [Bram@: Re: vim7 and xterm variants]

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

On Fri, Mar 25, 2005 at 06:20:49PM +0300, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [050325 18:10]:
> > > xterm генерит \e[1~/\e[4~, aterm - \e[7~/\e[8~
> > > Не пора ли привести всё это к общему знаменателю?
> > Каким образом? xterm != rxvt.
> Таким:
> 
> #ifdef LINUX_KEYS
> # define KS_HOME    "\033[1~"   /* Home == Find */
> # define KS_END     "\033[4~"   /* End == Select */
> #else
> # define KS_HOME    "\033[7~"   /* Home */
> # define KS_END     "\033[8~"   /* End */
> #endif
> 
> И от $TERM это не зависит...

Если aterm будет в ответ на Home/End посылать не те последовательности,
которые описаны в terminfo-записи для того типа терминала, который aterm
эмулирует, то пользователей такого aterm ждут очевидные неприятности.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Fwd: [Bram@: Re: vim7 and xterm variants]

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

* Dmitry V. Levin <ldv@> [050325 18:29]:
> > И от $TERM это не зависит...
> Если aterm будет в ответ на Home/End посылать не те
> последовательности, которые описаны в terminfo-записи для того
> типа терминала, который aterm эмулирует, то пользователей
> такого aterm ждут очевидные неприятности.
Вопрос - тип терминала однозначно определяется переменной
окружения $TERM или есть ещё способы?

-- 
Regards, Sir Raorn.
-------------------
[...] нет необходимости поддерживать целостность того, чего нет.
		-- ldv in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Fwd: [Bram@: Re: vim7 and xterm variants]

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

* Dmitry V. Levin <ldv@> [050325 18:12]:
> > Не пора ли привести всё это к общему знаменателю?
> Каким образом? xterm != rxvt.
Дело было не в бобине.  vim думает, что "rxvt" - это такой
"xterm".  Отрепортил Куда Надо, либо vim отвыкнет так думать,
либо начнёт понимать ещё и rxvt'шные Home/End, посмотрим что
сделает Bram...

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Fwd: [Bram@: Re: vim7 and xterm variants]

[Stanislav Ievlev]

On Fri, Mar 25, 2005 at 09:12:59PM +0300, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [050325 18:12]:
> > > Не пора ли привести всё это к общему знаменателю?
> > Каким образом? xterm != rxvt.
> Дело было не в бобине.  vim думает, что "rxvt" - это такой
> "xterm".  Отрепортил Куда Надо, либо vim отвыкнет так думать,
> либо начнёт понимать ещё и rxvt'шные Home/End, посмотрим что
> сделает Bram...
Ещё может быть вариант, что Bram заточился под новый xterm - его имя xterm-new.
> 
> -- 
> Regards,
> Sir Raorn.



> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> https://lists.altlinux.ru/mailman/listinfo/devel

Re: [devel] Fwd: [Bram@: Re: vim7 and xterm variants]

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

* Stanislav Ievlev <inger@> [050328 17:32]:
> > Дело было не в бобине.  vim думает, что "rxvt" - это такой
> > "xterm".  Отрепортил Куда Надо, либо vim отвыкнет так думать,
> > либо начнёт понимать ещё и rxvt'шные Home/End, посмотрим что
> > сделает Bram...
> Ещё может быть вариант, что Bram заточился под новый xterm -
> его имя xterm-new.
Этот глюк он исправил.

-- 
Regards, Sir Raorn.
-------------------
Дефис AKA минус в именах пакетов использовать НЕЛЬЗЯ, это грех перед
Богом, за который вас заставят 1000 лет пересобирать пакеты в чистилище.
		-- mhz in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]