[dev] Estadobar: a status bar for dwm
I made a simple status bar for myself. It's possible other people may like it. Description, instructions, and download at https://lee-phillips.org/estadobarpage/
Re: [dev] [st] When shrinking the width of a st window, overflowing text gets cut out and it is no longer retrievable, not even if the width is reset to the original one
By the way: some other terminal programs do not have this problem. For example, xfce4-terminal retains the information in its window under dwm resizing. However, it uses three times the memory of either st or xterm.
Re: [dev] [st] When shrinking the width of a st window, overflowing text gets cut out and it is no longer retrievable, not even if the width is reset to the original one
I compiled the current version of this scroll program and used it with both st and xterm. It had no effect. The programs behaved as before, with lines getting erased after window resizing. I also prefer to use dwm to manage my terminal windows rather than a multiplexer, so I am keenly interested in a solution to this problem. It is the only thing that makes the dwm experience less than perfectly delightful.
Re: [dev] [st] When shrinking the width of a st window, overflowing text gets cut out and it is no longer retrievable, not even if the width is reset to the original one
> No effect at all? It is at least supposed to allow you to scroll back. I > suspect something is wrong with the way you're trying to use scroll. Sorry, I think I already had a scrollback patch applied to st, so I could already scroll back (and I forgot that that patch was in there). So my message was misleading. However, it has no effect on what I'm after: restoring the parts of lines cut off horizontally when changing the sizes of windows. How to use: aren't I supposed to type `scroll st` to start the terminal?
Re: [dev] [st] When shrinking the width of a st window, overflowing text gets cut out and it is no longer retrievable, not even if the width is reset to the original one
> What I did to make it work is to run "./scroll" in an already-existing st > window, as you would with GNU screen or tmux. This works! Thank you very much. I was following the instructions in the man page, which say to do `scroll st`.
Re: [dev] [st] When shrinking the width of a st window, overflowing text gets cut out and it is no longer retrievable, not even if the width is reset to the original one
> Nope, the manpage includes this (and looking at git history, has > since its inception): > > EXAMPLES > st -e scroll /bin/sh > > You must have misread it. You're right, it does say that. But I didn't so much misread it as read the top of it, were it has: SYNOPSIS scroll [-Mh] [-m size] [program [arg ...]] and failed to read the EXAMPLES. Aren't the SYNOPSIS and EXAMPLES contradictory?
Re: [dev] Why not use the -exec feature of find?
> All over the place (tutorials, manuals, articles, questions and answers) I > see the advice to use the null feature of find (-print0) and xargs (-0) to be > able to handle any kind of wacky file name (e.g. filenames with newlines). > Granted, *if* you are going to pipe find into xargs, the advice makes sense. > But wouldn't it be better in every way to use the -exec (or -execdir) feature > of find instead of piping into xargs? Why isn't that the common advice? Is > the -exec feature of find fairly new, or fairly new to Posix? I usually use -exec (I don't think it's new), but the xargs method is required if you want to stop execution on a failed subcommand; the -exec version will just go on to the next file. If you have a huge number of files and multiple cores you may want to use the xargs method, as it can easily be parallelized.
Re: [dev] Why not use the -exec feature of find?
> Even when you use multiple arguments per command as with
> -exec '{}' +
> ? It is still spawning a new process for every file match?
No, then it will use the maximum number of file arguments allowed by your shell
for each process.
Re: [dev] [st] Crash when displaying these characters
I think there may be anchovies on that pizza. This is known to cause problems with several terminal emulators.
Re: [dev] Is there a text editor following the UNIX philosophy?
> The dependancy on tree-sitter is specficially what made me uninstall neovim > and switch over to vanilla vim. You can use the same syntax files you use with Vim on Neovim; you don't have to use tree-sitter. There is no dependancy.
Re: [dev] Simpler WiFi alternatives
Since the administrators of this list are unable or unwilling to block access to this loser, I'm unsubscribing. I don't need this kind of garbage in my inbox. I have plenty of other kinds of garbage already. Lee
