Hello. Roberto Caballero - so I understand that the behavior that makes content be lost is because it is less hungry on memory? If that's the case, I think this is acceptable. It's a good reason. On the geometry being a multiple of the font, you say that "In the past there was some work to avoid this situation adding pagging pixel lines, and it generated a lot of problems". But ACE said there's still a way touse it like that, by setting resizehints = False in config.h. Would this bring problems?
Matthew of Boswell - thanks for the explanation and zsh patch. Too bad I use ash. It's a pain in the ass not to be able to use Delete on st. I'll see if I can adapt your zsh patch. Also, by what I understand, this will never be provided by default because it's a fundamental problem outside st? Thanks. On Sun, Jan 17, 2016 at 10:09 AM, Roberto E. Vargas Caballero <k...@shike2.com> wrote: > Hi, > > On Fri, Jan 15, 2016 at 10:53:30AM -0200, Brad Luther wrote: >> 1 - when you open st and some strings printed (try 'ls' for example), >> upon resizing it down and resizing it back up, the content is lost. >> Shouldn't the printed stuff remain there? This is an annoyance for >> when I, for example, 'ls' a folder, open an image that I found inside >> so dwm automatically tile st and the image, and then I close the >> image. Now the st window will not show all the content of the folder >> from when I did 'ls'. The files/folders previously printed that upon >> resize were covered are now gone and I have to 'ls' again. > > St resizes the line buffers each time that the geometry of the terminal > change, then the content of the space out of the new size is lost. > It is done by a design decision. In fact it is easier the another > behaviour and not resize anything and hungry memory that you are not > using. If you really want this behaviour you can get with any terminal > session manager (dvtm, tmux, screen ...). > > >> 2- st is the only program on dwm that doesn't cover the entire screen >> when opening it in fullscreen tile mode. There's always a line on the >> bottom of the screen to which st refuses to expand. > > This kind of situations can happen because the geometry of st must be > a multiply of the size of your font. In the past there was some work > to avoid this situation adding pagging pixel lines, and it generated > a lot of problems. Keep it simple. > >> 3- the delkey patch[0] isn't working for me. As I understand it should >> make 'Delete' erase the current the highlighted character, but it does >> nothing. All I did was clone the repo and apply the patch (which is >> simple enough). Are there any users successfully using this patch? >> What could I have done wrong? > > No, the objective of that patch is to change the ascii value generated > when you press backspace and delete, because at this moment, for some > very stupid historic problems, the majority of terminals generate > a DEL when you press backspace, instead of generating a BACKSPACE. > All this stuff is really well explained in the FAQ. The problem you > are haaving is that you are using bad programs that don't follow the > POSIX standard. You should send a patch to them. > > Terminal keyboard have two modes, keypad mode and ascii mode. When you > are in ascii mode the terminal generates the correct ASCII code which > will generate the function labelled in the key. In the case of St it > generates ^[P, which is the sequence that st understands to delete the > current character. When the keyboard is in keypad mode it generates > a sequence thought to be an unique identifier of the key. In the > terminfo definition of the terminals you can find which is the > sequence for every special key when they are in keypad mode, and it > means that a program that wants to check against these code must to > change the mode of the terminal to keypad before reading. There is a > terminfo definition to do this. Again everything is explain in the > FAQ. > > You can try to fix the problems of the other programs, or write > a patch of st that make it to send the same key in both modes and > upload it to the wiki. I will not do it because is giving the reason > to the bad written programs, instead of fixing them. But if you want > to do it and upload it to the wiki we can put the link to the patch > in the FAQ. > > Regards, >