Re: [dev] [bugs] st clears up upon resize and other little things

From: Brad Luther <bradkluther_AT_gmail.com>
Date: Sun, 17 Jan 2016 12:20:11 -0200

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
<k0ga_AT_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,
>
Received on Sun Jan 17 2016 - 15:20:11 CET

This archive was generated by hypermail 2.3.0 : Sun Jan 17 2016 - 15:24:12 CET