Re: [dev] Why not use the -exec feature of find?

2021-07-02 Thread Cág
Greg Minshall wrote: >> Slightly off-topic and moderately unpopular: find(1) doesn't quite well >> fit into the Unix userland. It starts with the syntax: multiletter >> options (POSIX calls them operands though), the $program $option(s) >> $file(s) order (compare the find's "do where what" vs

Re: [dev] Why not use the -exec feature of find?

2021-06-29 Thread Cág
Slightly off-topic and moderately unpopular: find(1) doesn't quite well fit into the Unix userland. It starts with the syntax: multiletter options (POSIX calls them operands though), the $program $option(s) $file(s) order (compare the find's "do where what" vs natural -- like sed's or grep's --

Re: [dev] [dmenu][docs] XLFD fonts are not supported

2021-06-04 Thread Cág
Hi, > If my report is correct, please update that webpage. Thanks! The wiki is open for everyone, go ahead and send the patch. https://suckless.org/wiki/ -- caóc

Re: [dev] I made Emacs use the same keys as st for changing font size

2021-05-31 Thread Cág
> Perhaps I am the only suckless fan who also uses Emacs. :> I highly recommend mg[0], a sane Emacs implementation. [0]: https://github.com/hboetes/mg/ -- caóc

Re: [dev] less lines of code suck less

2021-05-06 Thread Cág
Greg Reagle wrote: > Would sbase suck less if the program head, which is currently a C > program of 77 lines, were replaced with something like > #!/bin/sh > sed "$1"q Plan 9 doesn't have head(1), neither do I in my sbase, not even a wrapper. `sed 10q` emulates the default behavior of head,

Re: [dev] Completeness suckless

2021-04-26 Thread Cág
Laslo Hunhold wrote: > I used to be more open towards "more user-friendliness" a few years ago, > but realized that if you look at modern users, most of them are > unwilling to invest time and effort into getting something to work and > expect too much from others in terms of support and guidance.

Re: [dev] st: enlarge font

2021-03-26 Thread Cág
Markus Wichmann wrote: > Страхиња Радић wrote: >> Didn't know that, thanks. What is the reasoning behind having a >> separate .def.h in the first place then? Wouldn't editing a local copy >> of config.h from the cloned repository suffice? > The idea is that you keep your config.h around when you

Re: [dev] st: enlarge font

2021-03-24 Thread Cág
Страхиња Радић wrote: > It will work, but more correct would be to change config.def.h, per > Makefile: > config.h: config.def.h > cp config.def.h config.h > Also, in the future you can also try setting different values for > "size=" instead of "pixelsize=", as it works better for some

Re: [dev] [sbase][tar] GNU tar support

2020-11-25 Thread Cág
Hi all, Laslo Hunhold wrote: > Dear Cág, > Even if a suckless implementation of GNU tar was possible, would you > really want it to be included? I'd rather like to encourage people to > use standard non-proprietary file formats. Yeah, I think I would. tar(1) is one of those

[dev] [sbase][tar] GNU tar support

2020-11-25 Thread Cág
Hi, A quick question: for "POSIX tar archive (GNU)" files tar prints tar: unsupported tar-filetype L Is GNU tar support out of scope? Cheers -- caóc

Re: [dev] Re: [hackers] announcing tec: temporary email commands

2020-10-21 Thread Cág
Greg Reagle wrote: > May I see the single script please? Attached. My workflow is usually similar to this: 1. Download mails and list unread: `mblaze s -d` 2. Read them: `mblaze s -v 1:5` 3. Reply to a message: `mblaze s -r 4` There are separate arguments to list sent, unread, archived, etc.,

Re: [dev] [st] BadLength

2020-05-20 Thread Cág
Hi, Markus Wichmann wrote: > It appears to me that on Linux, only ca. three ways to render fonts > remain: One is to use xlib and its fonts, but this does not work very > well with Unicode. Then there is Xft and fontconfig, requiring XML > config files, and while it does work well in many cases,

Re: [dev] [sbase] [ed] A couple of notes

2020-03-22 Thread Cág
Michael Forney wrote: > Sometimes people just don't have the time to investigate the issue and > come up with a fix. It could even be that the fix involves more > complex restructuring of the rest of the code. Hello Michael, Thanks for understanding. There's definitely a lack of time on my

[dev] [sbase] [ed] A couple of notes

2020-03-17 Thread Cág
I must admit I only use ed(1) (of sbase) these days. It has been like this for a year or so. There are a couple things I've come across the sbase's version of ed: 1. w doesn't print the byte count. Suppose a sample ed session (using P to distinguish my input from ed's output): % ed P *a milk

Re: [dev] Mice with 3+ buttons

2019-12-20 Thread Cág
Teodoro Santoni wrote: > If xev outputs something when you click in it with those buttons, you > can use them in dwm's config.h putting in their x.org keysym. > Never heard of those mivr, they are quite cheap on amazon, I'm > interested... If all those buttons are supported on linux (e.g. xev >

[dev] Mice with 3+ buttons

2019-12-19 Thread Cág
Hi, I've recently got two different A4Tech/X7 mice with nine buttons, one at work and one for home. I'd like to map buttons 8 and 9 to some keyboard events, let it be volume changing (like XF86XK_AudioRaiseVolume), or simple copy-pasting for st(1), e.g. let the button 8 be Ctrl-Shift-C and the

Re: [dev] Pandoc replacement that sucks less

2019-04-30 Thread Cág
Greg Reagle wrote: You could buy a bigger hard drive. Wasting resources is never a good idea. -- caóc

Re: [dev] JFS filesystem

2019-04-23 Thread Cág
Daniel Cegiełka wrote: If you have a power failure, it simply can lose data (whether JFS or XFS). Unfortunately I can confirm this. We've lost data twice on a CentOS server with XFS, and once it happened on my local machine because of a freeze. -- caóc

Re: [dev] Preprocessor

2019-04-23 Thread Cág
Evan Gates wrote: Not sure about the preprocessor stuff, but this right here is terrible practice. Use a for loop and glob. Assuming that "$1" is a directory: for p in "$1"/*; do ... http://mywiki.wooledge.org/ParsingLs http://porkmail.org/era/unix/award.html -- caóc

Re: [dev] [dwm] background wallpaper redraw

2019-04-23 Thread Cág
https://github.com/Gottox/bgs Also this: https://github.com/ttzhou/setroot -- caóc

[dev] [ubase] setuid bits for passwd and su

2019-02-15 Thread Cág
Hi, The ``install'' rule in the ubase's Makefile doesn't set the appropriate permissions for these two executables. Is it intentional? It's a trivial thing to add, so I'd send a diff. Thanks -- caóc

Re: [dev] [Announce] [dwm-6.2] [dmenu-4.9] new release

2019-02-03 Thread Cág
Anselm Garbe wrote: Hi there, I'm glad to announce new dwm and dmenu releases: * dwm-6.2: https://dl.suckless.org/dwm/dwm-6.2.tar.gz * dmenu-4.9: https://dl.suckless.org/tools/dmenu-4.9.tar.gz These releases are the last ones that contain Xft support, which will be removed in the releases to

Re: [dev] Let's talk about Go, baby

2019-01-29 Thread Cág
Anselm Garbe wrote: Implying C is such an obscure language that can never pay your bills. No implication here. But demand for plain C developers is considerably lower these days with the exception of the embedded/IoT and kernel space. And often plain C is subsumed with C++ unfortunately, as it

Re: [dev] Let's talk about Go, baby

2019-01-26 Thread Cág
Anselm Garbe wrote: However, when forced into typical day job developments to fund your well being, golang might actually be the sanest option on the table -- in order to avoid worse options such as Rust, Java, Kotlin, Scala, Ruby, C#, Swift etc. Implying C is such an obscure language that can

Re: [dev] Coding style: why /* */ and not //?

2018-12-27 Thread Cág
Silvan Jegen wrote: I also prefer // (mostly because to insert those I can just do a block insert in vim/vis). The only downside of //-style comments that I can see is that they are only allowed since C99[0]. Maybe I am missing something too though. I use vi[0] and have this in my .exrc: map

Re: [dev] Yet another "sane alternatives" thread

2018-12-26 Thread Cág
Martin Tournoij wrote: The chosen language is just one "suckless metric". I hold little love for C++, but I'll choose a well-designed and well-written C++ program over a badly designed and badly written C program any day of the week. A good example to illustrate this point might be procmail:

Re: [dev] Yet another "sane alternatives" thread

2018-12-26 Thread Cág
Martin Tournoij wrote: 1. Is there any network utility suite like net-tools or iproute2 but sane and active? Or maybe net-tools was forked by somebody? Usually the stuff you want to do with these tools are limited to just a few tasks ("connect to wired network", "connect to wireless network",

Re: [dev] Yet another "sane alternatives" thread

2018-12-25 Thread Cág
Sylvain Bertrand wrote: ??? clang/llvm is a c++ abomination: a massive pile of c++ cr*p. If you dislike the GNU make, wait to read the c++ code of cmake, the build system of clang/llvm, not to mention ninja (something in the horrible python3 or python2). I am into llvm code right now, and I feel

Re: [dev] Yet another "sane alternatives" thread

2018-12-25 Thread Cág
Sean MacLennan wrote: Wrong. Not even you can compile it with Clang, (HOSTCC=clang CC=clang), but link it with lld: http://lists.llvm.org/pipermail/llvm-dev/2017-January/109288.html Sorry, I should have said you can't compile a *working* kernel with clang. They are close though, and I believe

Re: [dev] Yet another "sane alternatives" thread

2018-12-25 Thread Cág
Sean MacLennan wrote: I'm thinking of something you can compile the Linux kernel[0] with. The Linux kernel only compiles with the GNU toolchain. There are efforts to get it compiling with clang but I believe they are not there yet. Wrong. Not even you can compile it with Clang, (HOSTCC=clang

Re: [dev] Yet another "sane alternatives" thread

2018-12-25 Thread Cág
Stephen Turner wrote: Toybox? I haven’t followed the project in a bit, I really should check in and see what they have finished but I know that project aimed to get most if not all of a build environment recreated in a portable form so if you haven’t seen it then I recommend it. If I may ask,

Re: [dev] Yet another "sane alternatives" thread

2018-12-25 Thread Cág
Jan Bessai wrote: Not sure if it has any advantages for you, but you might try bmake https://apps.fedoraproject.org/packages/bmake It is a port of the Netbsd make. bmake has its own conditionals like .if, .ifdef, .else, etc., i.e. it is itself incompatible with GNU make. I'm thinking of

[dev] Yet another "sane alternatives" thread

2018-12-24 Thread Cág
Hi, This is long and rather off-topic (and a bit of ranting is included, as always). I have to use EL7/Fedora almost daily and Ubuntu once every week or two. As you might know, they have this GNOME/systemd/etc. thing. I'm already kinda used to GNOME freezing, and systemd's "A job is running"

Re: [dev] Open Source DIY ethics

2018-12-24 Thread Cág
Alessandro Pistocchi wrote: Agree :-) Sent from my iPhone Nice signature :) -- Sent from my Nokia 105

Re: [dev] GPL free Linux

2018-11-12 Thread Cág
Alessandro Pistocchi wrote: Hi everyone, Hi, I am working on a project to remove gpl stuff from Linux userspace ( I am ok with GPL executables but not with GPL or LGPL libraries ) and I see that your projects tend towards more open licenses. You probably should be replacing GNU stuff with

Re: [dev] freetype2/fc pain

2018-09-24 Thread Cág
Anselm wrote: > Back in the days I also concluded that the introduction of Xinerama > and multihead support was a bad idea after all. > > What do you guys think about this idea? A couple of ideas: 1. Having Xft and Xinerama support in the patches section 2. Create ifdefs for Xft as they are now

Re: [dev] [st] solarized light patch colors incorrect

2018-09-08 Thread Cág
opal hart wrote: > Look at any other dev project and you'll see that this is a childish > display no matter the implications of the bug. suckless is not your average dev project. You are supposed to know something before using it. You and OP are being petty and lazy, because instead of writing a

Re: [dev] [st] solarized light patch colors incorrect

2018-09-07 Thread Cág
I am currently LOL'ing @ the thread. It ain't no CVE, it's a freakin color scheme crap. Found a bug -> fix the damn thing. Don't need no MS in CS. -- caóc

[dev] Re: noice and NetBSD curses

2018-08-10 Thread Cág
Hi, The problem was solved here: http://mail-index.netbsd.org/netbsd-users/2018/08/10/msg021219.html I'm attaching Leonardo's patch, please review. -- caóc $NetBSD$ Directly use addstr() instead of printw() in order to output every bytes without any transformation (and hence also correctly

Re: [dev] noice and NetBSD curses

2018-08-07 Thread Cág
Silvan Jegen wrote: > I thought that maybe one of the programs is linked against the > non-"...w" variant of the curses library (i. e. "libncurses" instead > of "libncursesw") but it turns out that NetBSD's curses library does > not have this separation at all. Interesting stuff. Some programs,

Re: [dev] [dwm] [PATCH] Do not draw bar if it is hidden

2018-08-07 Thread Cág
Laslo Hunhold wrote: > Maybe we can layer this check out though and do a > > if (m->showbar) { > drawbar(...) > } > > What do you guys think? +1 -- caóc

Re: [dev] noice and NetBSD curses

2018-08-07 Thread Cág
Silvan Jegen wrote: > I thought that maybe one of the programs is linked against the > non-"...w" variant of the curses library (i. e. "libncurses" instead > of "libncursesw") but it turns out that NetBSD's curses library does > not have this separation at all. Interesting stuff. It can handle

Re: [dev] noice and NetBSD curses

2018-08-05 Thread Cág
Silvan Jegen wrote: > I have the same locale set up (LANG=en_US.UTF-8) and on my (Linux) > machine, both rover and noice (compiled from tip) show the "früh.mp3" > filename correctly without me having to set LC_ALL=C. Keep in mind, this is NetBSD with its own curses library. It was suggested that

Re: [dev] [st] Hardcoded colors. Can I change them runtime?

2018-08-01 Thread Cág
opal hart wrote: > Yes, it's a normal array of colours. To set colour 215 (starting from > 0), for example, just add a line `[215] = "#123456",` and it will set > that colour as appropriate. However, st already supports both > 256-colour and truecolour so you may not need to do this depending on

Re: [dev] noice and NetBSD curses

2018-08-01 Thread Cág
Silvan Jegen wrote: > What does running 'locale' print on both machines? Mine's are all en_US.UTF-8, except for LC_COLLATE. I don't set anything other than LANG in profile. -- caóc

Re: [dev] noice and NetBSD curses

2018-08-01 Thread Cág
Hiltjo Posthuma wrote: > Maybe setlocale(LC_CTYPE, ""), not sure if that is correct. You could > technically mix different locales in filenames or use (almost) any byte > sequence though. rover, which I mentioned in the OP, has it too: https://github.com/lecram/rover/blob/master/rover.c#L405

[dev] noice and NetBSD curses

2018-07-31 Thread Cág
Hey, The thread is here[0], and I guess this is more of curses problem, but since I first noticed it with noice, here it is. The question: what do rover and noice do differently, that the former displays Unicode filenames right, and the latter only under the LC_ALL=C local. P.S. 2f30 guise

Re: [dev] [sbase] find and xargs different results than busybox

2018-07-20 Thread Cág
Markus Wichmann wrote: > Because ls's job is to list files. Not to columnate output. There's > another tool for that. Makes sense; there's cols(1) for that. > Unfortunately, GNU ls is capable of outputting color codes, but BSD > column is not capable of understanding them. I tried to write

Re: [dev] [sbase] find and xargs different results than busybox

2018-07-19 Thread Cág
If you take a look at README (https://git.suckless.org/sbase/tree/README), you'll find out completeness of the programs and missing arguments; out of all I only wonder why multi-column output of ls(1) is intentionally left out. On Plan 9 it is one-column, too, though. caóc

Re: [dev] [st] NotoColorEmoji.ttf makes st crash

2018-06-15 Thread Cág
Silvan Jegen wrote: > I am not able to reproduce this (on dwm tip with NotoColorEmoji.ttf > installed): > https://sillymon.ch/data/gvimwithemojiintitle.png Not only you need NotoColorEmoji installed, a colored emoji has to be in the title to break dwm. The one on your screenshot is monochrome.

Re: [dev] [st] NotoColorEmoji.ttf makes st crash

2018-06-08 Thread Cág
sylvain.bertr...@gmail.com wrote: > I did install the google noto fonts, did browse to a www site with > heavy use of utf-8 emojis with lynx and did crash. > The culprit was NotoColorEmoji.ttf. I'm afraid I don't know about st, but dwm crashes if there's an emoji in the window title, in case

Re: [dev] [bc]

2018-03-13 Thread Cág
Laslo Hunhold wrote: > [...] and I hate busybox! Why? Actually, if a Linux kernel can be compiled without GNU bc, it's a step forward. Next would be getting rid of gcc-isms, and, finally, making a new build system. -- caóc

Re: [dev] [dwm] Crash with emojis on title bar

2018-02-12 Thread Cág
Laslo Hunhold wrote: >> Pango is a much heavier library than Xft, so I would be surprised if >> Hiltjo was suggesting that was use Pango. > I'll give Hiltjo the freedom to share as much as he desires about what > he's doing, but "maybe" he was talking about a solution that is > developed

Re: [dev] Can I build stali with another libc?

2018-01-16 Thread Cág
k.suzaki wrote: > I want to know why another libc is bad (or good?) to build stali. > I guess it resembles to Harden Gentoo which allows to build uclib and musl. >https://wiki.gentoo.org/wiki/Project:Hardened_uClibc >https://wiki.gentoo.org/wiki/Project:Hardened_musl Please see the

Re: [dev] Can I build stali with another libc?

2018-01-16 Thread Cág
Daniel Cegiełka wrote: > > musl is the only alternative, fairly feature complete, libc, that is still > > being developed. uClibc/dietlibc haven't been around for many years > https://cgit.openadk.org/cgi/cgit/uclibc-ng.git/log/ Forgot about it. Anyway it doesn't see that much activity comparing

Re: [dev] Can I build stali with another libc?

2018-01-11 Thread Cág
k.suzaki wrote: > Dear, > Can I build stali with another libc? The old stali seems to be built by > uClibc. You can but you shouldn't. musl is the only alternative, fairly feature complete, libc, that is still being developed. uClibc/dietlibc haven't been around for many years, newlib is

Re: [dev] Are all dlopen() functions in the stali suppressed?

2018-01-11 Thread Cág
k.suzaki wrote: > I see. > The two ELF binaries of "ip and "debugfs" which include symbol may > say "Dynamic loading not supported". Obviously, the programmes you mentioned are third-party. If I understand correctly, the goal was to make the base userland statically linked (shell + sbase +

Re: [dev] terminal flickering when doing scrolling in emacs

2017-11-18 Thread Cág
Amos Bird wrote: > Hi, > When doing C-v/M-v in emacs frequently, st terminal flickers. This doesn't > happen in urxvt. > How can I fix that? Thanks! Hi, It doesn't happen in mg. Which Emacs do you use? -- caóc

Re: [dev] [dvtm] alt screen

2017-11-10 Thread Cág
Greg Reagle wrote: > According to http://shallowsky.com/linux/noaltscreen.html, another way > to disable the alternate screen is to change the terminfo entry to > remove rmcup and smcup. Have you tried that? To do so, edit dvtm.info, > remove the smcup and rmcup lines, and re-run make install

[dev] [dvtm] alt screen

2017-11-08 Thread Cág
Hi, Is there a way to disable the alternate screen in dvtm? If there isn't, any plans? Thanks -- caóc

Re: [dev] [sxiv] doesn't want to be compiled

2017-10-17 Thread Cág
ber.t@ wrote: > Does the new one work for you on OpenBSD? It does, thanks again! -- caóc

Re: [dev] [sxiv] doesn't want to be compiled

2017-10-16 Thread Cág
Bert Münnich wrote: > And since switching to GNU make I really got the hang of automatic > dependency generation and out-of-source builds. Thanks for making the makefile portable anyway, I appreciate it. -- caóc

Re: Re: [dev] [sxiv] doesn't want to be compiled

2017-10-08 Thread Cág
Laslo Hunhold wrote: > We need to stop falling for the fallacy that "portable" means "works > with BSDmake and GNUmake". Truly portable means consistent with the > POSIX spec. How different is BSD make from POSIX make? The man page says it's "mostly compliant" (it also says that "most of the

Re: Re: [dev] [sxiv] doesn't want to be compiled

2017-10-07 Thread Cág
Bert wrote: > Line 30 of your Makefile still contains the GNU make specific automatic > variable '$^'. You have to substitute it with '$(OBJ)' to make the LINK > cmd work. I've tried it, the output complains about missing object files: --- cc: autoreload_inotify.o: No such file or directory cc:

[dev] [sxiv] doesn't want to be compiled

2017-10-07 Thread Cág
Hi, I feel a bit stupid right now. The output is: --- LINK sxiv /usr/local/lib/libImlib2.so.6.0: warning: warning: strcpy() is almost always misused, please use strlcpy() /usr/local/lib/libImlib2.so.6.0: warning: warning: sprintf() is often misused, please use snprintf()

Re: [dev] [Announcement] slstatus

2017-09-08 Thread Cág
Aaron Marcher wrote: > Calling all external programs plus formatting programs is huge resource > overhead and insecure. Reasonable. > Lemonbar? ssd wrote: > dzen2? For some reason I thought they both used GTK. Thanks! Ciao -- caóc

Re: [dev] [Announcement] slstatus

2017-09-08 Thread Cág
Hiltjo Posthuma wrote: > I personally really like spoon from 2f30 created by the legendary > stateless and lostd: Both are nice and something I was looking for. I am interested for advantages of them vs a xinitrc script besides those stated on the dwmstatus page. I suppose, not needing to call

Re: [dev] [st] Exit upon attempting to render glyph

2017-08-10 Thread Cág
I use emojis on my dwm bar, and it is convenient on a laptop. While main fonts are occasionally changed, Noto Emoji is always a fallback font for the symbols. I've never had dwm or st crashed, no matter the reason. As it was previously stated by Laslo and Hiltjo, 99.9899735856% of issues are

Re: [dev] Xorg implementations

2017-07-09 Thread Cág
Quentin Rameau wrote: >> Apart from patching programmes to work with musl, Alpine has around >> sixty patches for musl itself[0]. >> These are upstream patches until the next release is tagged. Oh, thanks, they are, just looked. -- caóc

Re: [dev] [question] gobo linux filesystem hierarchy

2017-07-04 Thread Cág
Kajetan Jasztal wrote: > What do you think can be the downsides of filesystem hierarchy of > Gobo Linux[0]? STALI[1] was attempting to modify default hierarchy > after all. I personaly think it's clear, evident (only problem I have > is hiding symlinks in /) and elegant. It's in a way compatible

Re: [dev] Interesting Web Browser Decoupling Concept

2017-06-13 Thread Cág
So, to summarise: Browsers suck because web sucks C++ sucks Android sucks Python sucks Java sucks Javascript sucks In other news the sky is blue, water is wet and snow is white. -- caóc

Re: [dev] [announce] mle: a small terminal-based text editor

2017-04-10 Thread Cág
Thanks, it works. -- caóc

Re: [dev] [announce] mle: a small terminal-based text editor

2017-04-10 Thread Cág
S. Gilles wrote: > I wrote a patch[0] for mg which sort of adds Unicode support a while > back via wchar_t. Upstream interest was low, as they were just about > to release 6.0 and I got the impression they'd rather write it > themselves, but as far as I can tell it works. At the very least, > it

Re: [dev] [announce] mle: a small terminal-based text editor

2017-04-10 Thread Cág
robin wrote: > I wrote a vi like editor in <1k lines. > Fairly shitty, but maybe it inspires to something. > https://github.com/byllgrim/svi It is a good base, thanks, even though it lacks a delete functionality (backspace doesn't work on already written to a file characters), undo and a ruler.

Re: [dev] farewell

2017-04-01 Thread Cág
Hiltjo Posthuma wrote: > RIP sweet prince. Your small patches (0 lines) will be missed. Legend says, hiro is Theo that condescended to us, mere mortals, to teach us wisdom, to pass on knowledge and wit. Thou shalt hail hiro. -- caóc

Re: [dev] [announce] mle: a small terminal-based text editor

2017-03-29 Thread Cág
Wolfgang Corcoran-Mathe wrote: > mle is too complex for my taste (scripting and syntax highlighting > seem unecessary, though I’m in the grumpy minority here) Personally I'd like to see more of something like mg or busybox' vi. Unfortunately they both don't support UTF-8. nvi is pretty good as

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

2017-03-27 Thread Cág
Laslo Hunhold wrote: > I don't want to start a tmux debate here of course. Neither do I. Thanks for the answer. -- caóc

Re: [dev] [st] [PATCH 2/2] Keep end of lines in memory when resizing terminal

2017-03-26 Thread Cág
Laslo Hunhold wrote: > I hate using tmux and the like I am genuinely interested why. -- caóc

Re: [dev] [announce] ff2sixel: view farbfeld images in terminal

2017-03-22 Thread Cág
hiro wrote: > always found linux terminal scrollback buffers unusable, > so I try not to rely on it at all. Makes sense when you can simply tee(1) a dynamic output or less(1) a static one. Especially convenient when searching for compiling errors/warnings. Matter of taste though. -- Cág

Re: [dev] [announce] ff2sixel: view farbfeld images in terminal

2017-03-20 Thread Cág
https://www.enlightenment.org/about-terminology -- Cág

Re: [dev] Some core tools

2017-02-09 Thread Cág
bad omens for the *BSD people. All because of the licence. -- Cág

Re: [dev] looking for a simple music player

2017-02-09 Thread Cág
Hadrien Lacour wrote: > If you want the Noice of music player, there's cplay. If you want something a > little bit more like ranger/vifm, there's cmus. I personally use mpd and mpc > with sh scripts. Looks like cplay is Python and doesn't support flac players. Looks good though, thanks. -- Cág

Re: [dev] looking for a simple music player

2017-02-09 Thread Cág
that one too, as well as for showing current song. One kind man sent me his "noice music player". It already works but needs some minor fixes apparently. If it will be done, I'm sure it will appear here on the list. -- Cág

Re: [dev] looking for a simple music player

2017-02-08 Thread Cág
ormats to simply %{filename}. Also, for some reason it didn't play some flac files while mplayer with ffmpeg and flac did. -- Cág

Re: [dev] looking for a simple music player

2017-02-08 Thread Cág
> what do you need, ffado? > mpd might be best. mpd is C++ and pulls boost because it "imroves code readability and maintainability". -- Cág

Re: [dev] looking for a simple music player

2017-02-08 Thread Cág
Josuah Demangeon wrote: > Simple Audio Daemon may be interesting: > http://git.2f30.org/sad/files.html Looks like it only works with ALSA. -- Cág

Re: [dev] looking for a simple music player

2017-02-08 Thread Cág
Joseph Graham wrote: > Hey, what's wrong with mpd and ncmpc? I think mpd is too complicated for me. I've never figured out how it works and, after all, I only need to play my local library. -- Cág

Re: [dev] looking for a simple music player

2017-02-08 Thread Cág
ong without jumping through the whole playlist. -- Cág

[dev] looking for a simple music player

2017-02-07 Thread Cág
. Is there something like that? Thanks -- Cág

Re: [dev] Some core tools

2017-02-03 Thread Cág
Mattias Andrée wrote: > I'm not convinced mk(1) is less sucky > than POSIX make(1), but it may be less > sucky than many make(1) implementations. There is also bmake(1)[0], a port of NetBSD's make(1)[1]. OpenBSD has their own make(1)[2] as well. Cág [0]: http://www.crufty.net

Re: [dev] Re: Linux distros that don't suck too too much

2017-02-01 Thread Cág
For particular cases you will have to do some digging but default build options are pretty sane most of the time. > But it could be a nice source / project to > collaborate with as well. If interested, the site is here[0], the PDF guide is here[1], there are also some FAQs on netbsd.o

Re: [dev] Re: Linux distros that don't suck too too much

2017-02-01 Thread Cág
Mark Weber wrote: > nixos.org sucks less AFAIK (its deterministic), > but sometimes it sucks that some packages > haven't been packaged yet - but many have.. Nix is C++, Perl and autotools. > All packages for distros could be derived from > such. pkgsrc? Cág

Re: [dev] Re: Linux distros that don't suck too too much

2017-02-01 Thread Cág
er is in Python and now there will be Python in the init system. That's too much for a suckless distribution, in my humble opinion. Cág

Re: [dev] surf crash

2017-01-16 Thread Cág
the ports, but packages are usually compiled the way they should be. And the documentation is pretty good. Cág [0]: http://git.alpinelinux.org/cgit/aports/commit/?id=9878b048b45f977e69527a88e7f4d205cabccc94 [1]: https://alpinelinux.org/

Re: [dev] surf crash

2017-01-15 Thread Cág
Greg, Try re-installing libjavascriptcoregtk-1.0-0. It is fairly common for dpkg to install broken packages. Those Gdk and dbus warnings you received when running surf shouldn't be vital. If that still doesn't work, bewray your config.mk to us. Cág

Re: [dev] Request for video player recommendation with a good playlist

2017-01-15 Thread Cág
mplayer stopped decoding both mp3 and mp4 correctly for some reason. By the way, has anyone tried OSS on Linux recently? Cág

Re: [dev] [sbase] [tar] some errors

2016-12-24 Thread Cág
archive". Here's the part with it: http://git.suckless.org/sbase/tree/tar.c#n404 Cág

[dev] [sbase] [tar] some errors

2016-12-23 Thread Cág
it says "malformed tar archive". I've tried creating an archive from a single file, tar does it but when trying to extract it I get the error above. Cág

Re: [dev] [st] Crash on middle finger character

2016-12-18 Thread Cág
st crashes when trying to display REVERSED HAND WITH MIDDLE FINGER EXTENDED. It doesn't here though.

Re: [dev] [surf] Webkit2 with proxy server

2016-12-18 Thread Cág
want a modern www renderer). The dependence on GCC is stupid, right, just like on any other GNU software. The Linux kernel can't be compiled with anything other than this or Clang, which is in C++, but at least licensed under BSD or something. Cág

  1   2   >