On Fri, Feb 13, 2026 at 05:36:48PM -0500, Paul Fox wrote: > thomas wrote: > > > > I can bisect, etc., and see that this case (typing without spaces) never > > did work as you expect (inserted text ok, cursor position not ok). > > Oh, well that's a relief. I haven't been missing anything, then! H-)
apparently not. I didn't see any mention of linebreak past the initial work
(where I noted that it didn't work with color-highlighting).
But I added this to my ever-growing list :-)
Working notes:
8,051 items
38,987 lines
206,745 words
1,463,635 chars
709 pages (55 lpp)
780 pages (50 lpp)
Supporting files/notes:
6,501 files
362M chars
(that's a simple script using find and awk.
I could write a fancier script to give a breakdown,
but when I replied recently I came up with about 16% for vile).
> But speaking of linewrap...
>
> I've been realizing that with most of the world is reading email on
> their phones these days, I should have a way of composing email that's
I kind of glance at my phone, and mark things that I'll have to respond
to but do most actual reading (and replying) on bigger screens.
I run xterm in a 40x80 window, and triage (delete uninteresting mail) on
web browsers. I delete most of the mail, so I end up saving about a
thousand a month.
I rarely reply in the phone (I recall doing that a few years ago).
> one paragraph to a line, so that the text wrapping on a narrow screen
> gets a fighting chance. I'm sure that if you read this message on a
> phone it will look terrible.
agreed - a little choppy
> vile's linewrap does the right thing with long lines, but there's no
> easy way to move up and down vertically within a long wrapped line
> that spans multiple screen lines.
...someone was complaining about termux vs ncurses this week.
Are you using that?
Reading the source code (it has no documentation, and its developers don't know
much about terminfo or termcap) it seems that it might be capable of doing
something with shifted cursor-keys. But it's expressed as "termcap" and some
of that is bound to 3-characters (which will _never_ work because termcap uses
exactly 2 characters for the capability names).
See the "kDN" and "kUP" (which ncurses would match as "kD" and "kU"):
Apparently that was via copy/paste from xterm:
/* the terminfo codes here are ncurses extensions */
/* ignore the termcap names, which are empty */
DATA( "", "kUP", XK_Up, SHIFT ),
DATA( "", "kDN", XK_Down, SHIFT ),
termux has this:
TERMCAP_TO_KEYCODE.put("kB", KEYMOD_SHIFT | KEYCODE_TAB); //
termcap=kB, terminfo=kcbt: Back-tab
TERMCAP_TO_KEYCODE.put("kD", KEYCODE_FORWARD_DEL); // terminfo=kdch1,
delete-character key
TERMCAP_TO_KEYCODE.put("kDN", KEYMOD_SHIFT | KEYCODE_DPAD_DOWN); //
non-standard shifted arrow down
TERMCAP_TO_KEYCODE.put("kF", KEYMOD_SHIFT | KEYCODE_DPAD_DOWN); //
terminfo=kind, scroll-forward key
TERMCAP_TO_KEYCODE.put("kI", KEYCODE_INSERT);
TERMCAP_TO_KEYCODE.put("kN", KEYCODE_PAGE_UP);
TERMCAP_TO_KEYCODE.put("kP", KEYCODE_PAGE_DOWN);
TERMCAP_TO_KEYCODE.put("kR", KEYMOD_SHIFT | KEYCODE_DPAD_UP); //
terminfo=kri, scroll-backward key
TERMCAP_TO_KEYCODE.put("kUP", KEYMOD_SHIFT | KEYCODE_DPAD_UP); //
non-standard shifted up
(I use mutt in xterm - locally - and it's using a correct terminfo)
> Has anyone ever written a key binding that will go up and down by
> screen lines (as opposed to real lines) when in linewrap mode? (Or,
> have I been oblivious, and is there already a way to do this?)
>
> I.e., I want bindings that will move the cursor up and down throught
> the same column in every line of the screen, whether part of a wrapped
> line, or not. Extra points for maintaining a "desired goal" column
> when passing through a screen line that's too short.
"backward-row" Shift+#A ^X-^U
or "previous-row"
( motion: move up CNT rows on the screen )
"forward-row" Shift+#B ^X-^D
or "next-row"
( motion: move down CNT rows on the screen )
which I use with xterm's shifted cursor-keys.
It's been there a while...
(I added the Shift+#A, Shift+#B in the end of 2006, for winvile)
> I started trying to write stored procedures to do this, and have actually
> gotten it to work in the forward/down direction, but going the other
> way is kicking my butt.
>
> Here's what I've got, going forward, if anyone's interested.
>
> store-procedure forw-in-lw-line
> ~if > $lcols $curcol
> ; unless we're at a line that's shorter than where we
> ; started, add another page width to our current column
> set-variable %nextcol &add $curcol $pagewid
> ~endif
> ~if &leq %nextcol $lcols
> ; our "next" column is still on the line, so go there
> ~force %nextcol goto-column
> ~else
> ; if we're trying to go past the end of the line, go to
> ; the next line, instead.
> ~force down-line-at-bol
> ~force &modulo %nextcol $pagewid goto-column
> ~endif
> ~endm
> bind-key forw-in-lw-line +
> bind-key forw-in-lw-line =
>
>
> You'd think going backward would be a simple inversion of the code,
> it's harder than that. For me, anyway!
>
> paul
>
> =----------------------
> paul fox, [email protected] (arlington, ma, where it's 33.8 degrees)
>
>
>
--
Thomas E. Dickey <[email protected]>
https://invisible-island.net
signature.asc
Description: PGP signature
