i'm working on a new tool which rewrites multiple lines on the terminal BUT not using ncurses. so far it seemed to work great - until i discovered the problem i'm asking about here!
i don't find a way to remove the last 30 rows, if my terminal can only display 20 rows at a time, so the not seen last 10 rows can't be modified. as a result it will produce 10 more output lines on every redraw of my statusbar. if i then use the scrollback of konsole it looks like a mess.
the problem in detail
when i run ./demo2 on a terminal (konsole, xterm like) and everything fits into the viewable area (i got a pretty big screen and resolution on my xserver) everything works as expected, see the screenshots from below.
however, if i shrink konsole, parts of the dynamically rewritten area (it starts with --------------------) are not deleted anymore since the terminal seems unable to reach it for some unknown reason.
https://en.wikipedia.org/wiki/ANSI_terminal says:
CSI n A CUU – Cursor Up Moves the cursor n (default 1) cells
CSI n B CUD – Cursor Down
CSI n C CUF – Cursor Forward
CSI n D CUB – Cursor Back
If the cursor is already at the edge of the screen, this has no effect.
this is exactly what i noticed, it can't be done using these functions. do you have an idea what i could do to fix that?
i tried various other terminal escape sequences and none worked. all i want to do is to rewrite the buffer of what is currently displayed on the terminal.
please note: i know ncurses but i would like to have this functionality without using it.
ideally: the DOM terminal
it would be cool to edit the terminal output like it was a DOM tree. so that i could update single elements like a status-widget. i could then have IDs for single elements and update only these, without touching other elements before or after - ideally not loosing the user's selection (made with the mouse). maybe TMUX is what i want but after looking at that i didn't see how to make it work.
that would pretty much reimplement X-widget style rendering on a terminal!
ideas welcome! ;-)
see my project [demo2.cpp] at:
https://github.com/qknight/nix-build-hack
see the screenshots:
https://raw.github.com/qknight/nix-build-hack/master/screenshot1.jpeg
https://raw.github.com/qknight/nix-build-hack/master/screenshot2.jpeg
Related
there is this annoying behavior in emacs which I don't know how to get rid of it.
lets say the current cursor position is on line 10 column 15.
now I need to quickly look up something far down the same buffer, I scroll down to that location and as I scroll down (or up) the cursor keeps moving and it loses its original location.
many people suggest to set a marker before scrolling but that is not a good solution, because you have to be always mindful of this fact before scrolling (which is impossible)
I know there should be a simple solution but I have not found it yet.
I'll appreciate your suggestions
As far as I know, Emacs doesn't allow you to scroll in such a way that your point disappears. I just took a quick look at xdisp.c and it looks like this is a fundamental assumption in the C code. This is different from some more recent editors (Sublime Text, VSCode etc).
However, the "many people" you mention actually have a reasonable point. If you're moving through the file by searching (C-s the-thing-im-looking-for) then Emacs will set a marker for you automatically.
I guess you could try adding a hook that set a marker at point whenever you scrolled? It wouldn't be trivial because you'd have to cope with things like not setting a load of markers through the file as your scroll dragged the cursor down. But my recommendation is probably to alter your workflow to match how Emacs wants to do things. In this case, it's probably a better approach than the modern editors it sounds like you're used to.
An option that might or might not be useful is scroll-preserve-screen-position. The description is somewhat hard to understand, but a net result is that if you mainly scroll using C-v/M-v, the point will visually stay at the same place on the screen (so if you do e.g. C-v C-v M-v M-v, the point will come back to its original position.
However, note that many commands do push a mark before they jump: isearch, end-of-buffer, imenu, xref-find-definition ... In all those cases, you can then press C-u C-SPC (the same command that you use to set the mark but called with a prefix argument) to pop the mark (concretely, jump to the last mark). If you need to jump back more than once, you can set the variable set-mark-command-repeat-pop to t, so that you only need to do C-u once and then repeatedly press C-SPC to pop more and more marks from the mark ring.
In general, there are better ways to navigate a buffer than scrolling in the wild; the cases where you do need to scroll, starting from "your current" point are (or should/could be ...) sufficiently rare that you know beforehand that you will be spending a possibly long time "looking around" in the buffer. It is then quite fast to set a mark, do your stuff somewhere else, and C-u <mash C-SPC as often as needed> until you get back to your initial point.
I've got emacs in front of me.
I've run a find-grep, and it's got many hits, which are displayed in a window. The file names are displayed in green as hyperlinks.
I make that the only window, with C-x 1.
If I click on a file name, the window splits vertically, and the file with the found text is displayed in the other window.
If I click on further filenames, then the new file replaces the old file, which is what I want to happen.
So far, so good...
However if I resize the windows, then emacs will periodically (when I click) split one of the two windows again, rendering the display difficult to read. It will then cycle opening new files between the two new windows. Occasionally it will open more windows and make the situation worse. If I close any of these new windows they just get reopened again.
In fact sometimes this perverse behaviour happens even if I don't resize anything. It just seems to happen more often if I do.
I would like emacs to stop buggering around and just have one find-grep window and one 'display' window, and always replace the display window with the new file. I would also like to be able to set these windows to the sizes that seem most convenient.
Is there any way to achieve this?
Or can anyone point me to an essay on how the whole (replace the contents of this window/replace the contents of a different window/create another window by splitting) thing works, so I can go and hack it sane.
Short fix:
Try doing this
(setq split-height-threshold nil
split-width-threshold nil)
This will prevent Emacs from splitting windows automatically (horizontally or vertically). This might be undesirable in other situations, but this should do the job. Try it for a week or so and see if it disrupts your flow.
Also, I found that if the point was in one of the windows, and I clicked on a link, the file opened up in the next window (if any).
So, if you want to make the file open in the right window (when you have more than one window), you can ensure that the point is in the window before the window you want.
Longer answer:
OK. I was able to reproduce the problem. The thing is the window showing the files is pretty big (wide or tall) because you resized it and Emacs sees that the width or height is greater than the respective threshold and splits it likewise. So, we have to either make the threshold higher or disallow the behaviour completely.
And, just to answer the last few questions:
To get current window - (selected-window)
To get next window - (next-window)
To select a window - (select-window foo-window)
To get the buffer of the current window - (current-buffer)
To get the buffer of some window - (window-buffer foo-window)
To set a buffer for a window - (set-window-buffer foo-window bar-buffer)
I'm sure you can hack together decent window/buffer management functions using these functions.
You can use C-h f to get more details on each of these functions.
Also check out the Elisp manual - http://www.chemie.fu-berlin.de/chemnet/use/info/elisp/elisp_26.html
There are several libraries like ncurses that assist in making command-line GUIs.
Simply put, how do they work?
My first thought was that ncurses intercepts all keyboard input, and draws each "frame" by outputting it line-by-line normally. Closer inspection, however, reveals that each new frame overwrites the previous one. How does it modify lines that have already been outputted? Furthermore, how does it handle color?
EDIT: The same question applies to anything with a "fancy" interface, like vim and emacs.
Text terminals have command sequences that do things like move the cursor to a particular position on the screen, insert characters, delete lines etc.
Each terminal type is different and has its own set of command sequences. ncurses has a databse (see terminfo for details)
Internally ncurses maintains 2 views of the screen: the current contents and what the screen should look like after the current pending changes are applied. Once the program requests a screen redraw, ncurses calculates an efficient way to update the screen to look like the desired view. The exact characters/command sequences output depend on what terminal type is in use.
curses (and ncurses, too, I think) works by moving the cursor around on the screen. There are control sequences to do such things. Take a look at the code again and you'll see them. These sequences are not ASCII control characters, they are strings starting with (umm...) ESC, maybe. Have a look here for a higher-level explanation.
When i run a command in cygwin when scrolled up it starts writing the output to that screen, so everything gets written over.
How can I change settings so that output will always be appended to the end not to where I have currently scrolled my window.
I found that rxvt doesn't do that but it also doesn't show me äöõü characters:(
Are you sure it's overwriting where you've currently scrolled to? I find the console just jumps back to the cursor position when there's new output. Still annoying though, and I don't know of a way to switch off that behaviour.
Anyway, have a look at 'mintty'. Like rxvt, it doesn't need an X server, but it does support Unicode, so the umlauts should be fine.
I need to turn automatic margins off according the following statement from Screen's manual in my Mac
If your terminal is a "true"
auto-margin terminal (it doesn't allow
the last position on the screen
to be updated without scrolling the screen) consider using a version
of your terminal's termcap that
has automatic margins turned off.
How can you turn automatic margins off by your terminal's termcap?
Most terminal emulators, including the mac default terminal, are not "true auto-margin terminals" in the sense being discussed here - they emulate a vt100-series terminal, which had "smart" wraparound. You can check by running cat and typing to the end of the last line - after you type the last character, the cursor remains at the end of the line (highlighting the character you just typed) until you type another character.
The only consequence of a 'true auto-margin terminal' is that a character cannot be displayed in the lower right hand corner (though some programs are able to work around that by shifting a character into place with ich/ich1)
According to XTerm Control Sequences, this sequence should do what was asked:
CSI ? 7 l
That is,
printf '\033[?7l'
The 7 is documented as
Ps = 7 -> Wraparound Mode (DECAWM).
and the final character l (lowercase L) denotes this as a reset rather than a set control.
For whatever reason, the terminfo name for this is more obscure: "automatic margins". These terminfo capabilities deal with the feature (see terminfo(5)):
auto_right_margin am am terminal has auto‐
matic margins
enter_am_mode smam SA turn on automatic
margins
exit_am_mode rmam RA turn off automatic
margins
Interestingly, the vt100-nam terminal description in ncurses (which apparently no one uses) initializes the terminal to use automargins margins using this string:
rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h,
(the \E[?7h sets it), and asserts that the terminal does not use automatic margins by cancelling am. It also has the terminfo capabilities rmam and smam. So you could do this to prove that it works:
tput rmam
stty columns 999
ps -efwwwwwl
and (for the ordinary user) see the ps listing nicely truncated against the right margin of the terminal window.
The other variants vt220-nam and vt320-nam appear correct...
By the way, for Mac, you would use the terminfo names such as rmcup rather than the termcap RA, because OSX uses ncurses' tput (terminfo) rather than the BSD variant.
Further reading:
tput, reset - initialize a terminal or query terminfo
database
history section for tput
history section for tset
Occasionally someone asks about suppressing automargins because they suppose that terminals can pan/scroll left/right to show the information which was not wrapped to a new line. Terminals which do this are rare, and OSX Terminal is not one of those. It behaves like a subset of xterm, which itself emulates the series of DEC terminals vt52/vt100/vt220/etc. In this question, OP is concerned/confused about this paragraph from the screen manual:
If your terminal is a "true" auto-margin terminal (it doesn't allow the
last position on the screen to be updated without scrolling the screen)
consider using a version of your terminal's termcap that has automatic
margins turned off. This will ensure an accurate and optimal update of
the screen in all circumstances. Most terminals nowadays have "magic"
margins (automatic margins plus usable last column). This is the VT100
style type and perfectly suited for screen. If all you've got is a
"true" auto-margin terminal screen will be content to use it, but
updating a character put into the last position on the screen may not
be possible until the screen scrolls or the character is moved into a
safe position in some other way. This delay can be shortened by using a
terminal with insert-character capability.
That last position on the screen refers to the lower-right corner of the terminal. In the normal case, if your cursor is on the lower-right corner and you print a character, you would expect the display to scroll up by one line and show the character on the next line. Also (because terminals can be implemented in different ways), some could scroll up when you print a character in the last position. The VT100 does not do this. Not only does it not scroll up in that case, but it ignores non-printing characters while on the margin (see xterm FAQ That description of wrapping is odd, say more?). There is a terminfo flag xenl which is set to show when the terminal does this special behavior. About a third of the terminal descriptions in the terminal database have this flag. While most of those are for terminals which you likely will never encounter, keep in mind that the advice in the manual page was written back in an era when those other terminals were as likely to be found as a VT100-lookalike. The early change-history for screen is poor, but the text was in screen's second posting to Usenet in 1992. The initial posting in 1987 said something similar:
Screen
never writes in the last position of the screen, unless the boolean
capability LP is found in the termcap entry of the terminal.
Usually,
screen
cannot predict whether or not a particular terminal scrolls when
a character is written in the last column of the last line;
LP indicates that it is safe to write in this position.
Note that the LP capability is independent of am (automatic
margins); for certain terminals, such as the VT100, it is reasonable
to set am as well as LP in the corresponding termcap entry
(the VT100 does not move the cursor when a character is written in
the last column of each line).
The later wording reflects the fact that the terminfo system was prevalent, and the name LP was not termcap name chosen for corresponding with xenl (it is xn).
The point of all of this is that screen attempts to convert between programs writing to different terminal types and make them all appear like one type of terminal — which means that it tries to put text on the terminal's display in all of the locations. The lower-right corner is a problem because some terminals would scroll up, spoiling the attempt to write there. As a workaround, some terminals provided an alternative:
using a different mode (insert),
put the cursor on the next to last position of the display,
write characters to fill in, pushing a character into the last position, and
turn insert-mode off once it is done (otherwise a nuisance).
About two thirds of the descriptions in the terminal database have the capability to do this insert-mode (smir). That still was not perfect, but it certainly was worth mentioning in 1992. About a quarter implement a similar similar feature ich1. Some implement both (and vi could get confused by those, by trying to do both methods).
VT100-lookalikes provide a third way to write that last position; screen checks for and uses whatever is there.
If I understand you correctly you're looking to set the autowrap feature to NO using terminfo database. If so I believe you can use the -nam flag to turn it off - something like vt100-nam should do it. You can also check by looking at the man pages for terminfo.
If this solves your question, mark this up. (^_^) If not... well comment back and I'll check again for you. Cheers!
Update: There's also a shortcut that may apply to you to toggle the wrap off and on. Check out the shortcut sheet here. And additional information for Screen can be found here (search for wrap). You can also check here on how to use setterm (section 17.14 Changing the Terminal Settings). Also check here for examples of changing settings.
Good luck again. (^_^)