deadpixi / tine Goto Github PK

If i do an insert block with Esc IB Enter (which keeps the block and keeps it highlighted), and then undo it, the block is gone.

Seems wrong.

The following is a fragment of a program that has run through go fmt, so the lines begin with true TAB (U+0009) characters.

		if i < len(vmet) {
			fmt.Sprintf("%s, vmtx, height, %d, tsb, %d", vmet[i].Advance, vmet[i].Tsb)
		}

i have no idea if the TAB characters will survive this transmission in the year 2023.

attempting to put the cursor near the end of the Sprintf line in fact draws the cursor at the screen top-left. for example, move to the beginning of the Sprintf line and use Shift-right or Ctrl-] to move to end of line.

For me, on an 80-column terminal, the cursor is blinking at the top-left and the screen contents are not redrawn.

the block is highlighted in reverse video. If the block includes the last line of the file and the checkerboard zone beyond the end of the file is visible, then the checkboard is also shown in reverse video.

This may be hard to see on some displays because the checkerboard is usually 50% "on". But i guess that on my mac the subpixel rendering and/or the reverse video isn't gamma corrected properly, so i can see it as a change in brightness even if i can't see the individual pixels change.

To show:

• start tine on empty file: tine newfile
• type in "Hello" or somesuch
• Ctrl-K Ctrl-K to make a single line block

If this is true to AmigaDOS then that's fine, but it's still surprising enough that a note about screen update and scrolling would be welcome.

In a sufficiently large file, the output of man ls | sed 99q say, pressing Enter when the cursor is at the beginning of the file apparently has no effect. In fact the file changes correctly, but the fresh empty line has been scrolled out of the way above the cursor.

The first time i noticed the scrolling behaviour of Enter (which i think is: either scroll the lines after the cursor down, or scroll the lines after the cursor up, whichever is the fewer lines) i thought it was unsettling, but then i quite liked it.

But now i've discovered this "entering a blank line at the top of file" i'm unsettled again.

behaviour:

• Ctrl-N to join two lines
• a few Ctrl-F to change the case (as it happens this was a nano inspired mistake, but whatever)
• Esc u Enter to undo

i was wondering if the undo would undo a single Ctrl-F or the whole sequence of them. What it actually did was undo all of them and also the Ctrl-N. As if the Ctrl-F in and of themselves could not be undone, and the before was restore to the point before the last edit that counted, which was Ctrl-N.

I say half-ignored because this is a bit like Ctrl-F being ignored by undo, for the purposes of decided how far back to undo, but actually correctly undoing the action of them (in addition to some other edit).

Undoing a join puts the cursor just before the split point (the end of the first line that participated in the join). Regardless of where the cursor was.

Again, i can't tell if this is faithful to AmigaDOS or not, but it seems wrong even if it is faithful. I suppose undo in general should either put the cursor back to where it was or not move it at all.

To reproduce:

• put the cursor at the beginning of a sequence of two lines both of which have content;
• join the lines with Ctrl-N (note, cursor still at beginning of line)
• undo the join with Esc u Enter. BUG: cursor jumps to join point

I've no idea what should happen morally, but it seems that the most tine thing to do
would be to not move the cursor at all.

by the way, it did surprise me that Ctrl-N join did not put the cursor at the join point, but i suppose that's intentional.

Even if you can't currently see some of those lines because they are "off the top" of the terminal. This feels like it probably is true to the AmgiaDOS ed, but is hilarious.

As tine uses the terminal cursor by default, there is no visible cursor in the buffer when in extended mode, which can be confusing when using cursor movement commands.

Perhaps the text cursor could be displayed using inverted colors when in extended mode.

I see from https://wiki.amigaos.net/wiki/AmigaOS_Manual:_AmigaDOS_Using_the_Editors that on AmigaDOS: "To enter extended mode, press Esc. An asterisk appears as a prompt in the status line".

I don't have access to AmigaDOS so i don't know if that is true, but it seems plausible and i think would be convenient. I find the lack of prompt disturbing.

I note that in vi the prompt is the same key used to enter command line (:). Perhaps tine could use ␛ (this is U+241B SYMBOL FOR ESCAPE).