Re: [dev] Is there a text editor following the UNIX philosophy?
El mar, 15 feb 2022 a la(s) 20:16, Greg Minshall (minsh...@umich.edu) escribió: > > Ismael, > > > These errors mean the named auxiliary build scripts (needed for > > portability) are not present and must be provided... > > thank you for your explanation. i have wondered. > > > Technically, it's wrong to ask users to run autoreconf, projects must > > provide release tarballs with the pregenerated build system at > > releases, this is not just a convenience, first because that step is > > not repeatable and there's no way to fix it except by using the exact > > same autoconf environment, and because other actions might be part of > > the release process which make a snapshot different from a release > > tarball (e.g. bundling submodules, automated editing of some files to > > match the release, etc.). > > but, when "users" (such as many of us, but now a growing number of > others) pick up a "release" via git, my sense is that the authors of the > package have no (convenient?) way of providing the auxiliary scripts. Because that's not a proper release from the point of view of autotools. > so, the "user" must run autoreconf. is that still true? or, is there a > (convenient) way package authors can allow a simple "./configure && make > && make install" to work? The files aren't meant to be part of the development history, but that doesn't mean they shouldn't be tracked. A simple way to deal with the problem is to make an extra commit (outside the main branch) per release to hold these files and tag it as the release, that makes it trivial for websites like github to make proper release tarballs.
Re: [dev] Is there a text editor following the UNIX philosophy?
El dom, 13 feb 2022 a la(s) 22:23, Kyryl Melekhin (k.melek...@gmail.com) escribió: > > Michael Hendricks wrote: > > > Agreed. > > > > > If anybody wants to go and fix the build let me know of your fork or > > > patch as I want to try it, out of curiosity. > > > > After cloning the repo[1], I ran `autoreconf -fi` to generate a > > configure script. Then `./configure && make`. Aside from the > > autotools bloat, the build proceeded without trouble for me on > > OpenBSD. > > > > 1: https://github.com/screen-editor/se.git > > Indeed, `autoreconf -fi` worked, thanks. There is an error if one tries to > run just autoconf or autoreconf without arguments. Looks like this: > https://0x0.st/o8-X.txt > > I have no idea what these errors mean, so when I got them I just gave up > initially, as it would of been stupid to waste time trying to figure it > out... Imagine having a bloated build tool, that does not just work, > pathetic. I also find especially frustrating how the INSTALL file tells > the user to run autoconf with no arguments. > These errors mean the named auxiliary build scripts (needed for portability) are not present and must be provided... Technically, it's wrong to ask users to run autoreconf, projects must provide release tarballs with the pregenerated build system at releases, this is not just a convenience, first because that step is not repeatable and there's no way to fix it except by using the exact same autoconf environment, and because other actions might be part of the release process which make a snapshot different from a release tarball (e.g. bundling submodules, automated editing of some files to match the release, etc.).
Re: [dev] Special target ".POSIX" in Makefiles
El vie, 31 dic 2021 a la(s) 09:30, Laslo Hunhold (d...@frign.de) escribió: > > On Fri, 31 Dec 2021 12:49:46 +0600 > NRK wrote: > > Dear NRK, > > > Hmm, I was under the impression that `?=` was accepted into POSIX. > > But I cannot find any mention of it in the posix manpage (man 1p > > make) so I guess I was wrong. > > > > What would be a posix replacement for `?=` ? I assume something like: > > > > VAR = $$(if test -n "$$VAR"; then printf "%s" "$$VAR"; else > > printf "fallback"; fi) > > > > - NRK > > that is exactly what I meant earlier on that the POSIX-intended good > practices get destroyed by the retarded GNU extensions. Actually, many of those extensions come from SunPro Make, so not really GNU extensions, and I guess they were implemented in GNU make mainly for compatibility reasons, as at the time SunOS was probably the most relevant platform for the development of GNU (remember, this was a long time before autoconf/automake). Also, "?=" is meant to provide a default value for something you want to take from the environment into the makefile for substitution, but where otherwise you really want the environment value, so it has its uses; and it's fairly widespread.
Re: [dev] [PATCH] [st] Fix issues with wcwidth() returning -1 for unsupported unicode chars
On Sat, Oct 25, 2014 at 11:15 PM, dequis wrote: <...> > My patch: > > Just wcwidth(...) -> abs(wcwidth(...)) > > In other words: if wcwidth returns -1, interpret that as a column > width of 1. It's a bit dirty and lazy, but it works wonderfully for > most characters. <...> It's better than nothing, but I guess Xft could offer much better advice with XftTextExtents*.
Re: [dev] Bringing together OS'es terminals and their codepages
On Tue, 03 Dec 2013 12:59:59 +0100 Troels Henriksen wrote: > patrick295767 patrick295767 writes: > > > Would you know a technique to have a way that your application looks > > the same on whatever system (Linux, Mac, OS/2, Windows,..)? > > Use UTF-8. Seriously, different character sets are such an incredibly > sucky thing that nobody should consider re-introducing them, unless > necessary to interact with legacy systems. (Of course, one should > consider Windows to be legacy...) Unicode also has all the weird > line-drawing characters you could ever want, if you find them > important. > > On which systems are the Latin-set of code pages still necessary? > Have you heard of UTF-8? Try using luit for legacy applications.
[dev] [dmenu PATCH v2] Fix segfault on systems with broken locale support
Signed-off-by: Ismael Luceno
---
dmenu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/dmenu.c b/dmenu.c
index 8d9bbb6..9625705 100644
--- a/dmenu.c
+++ b/dmenu.c
@@ -608,7 +608,10 @@ setup(void) {
CWOverrideRedirect | CWBackPixel | CWEventMask,
&swa);
/* open input methods */
- xim = XOpenIM(dc->dpy, NULL, NULL, NULL);
+ if (!(xim = XOpenIM(dc->dpy, NULL, NULL, NULL))) {
+ fputs("dmenu: Failed to open input method\n", stderr);
+ exit(EXIT_FAILURE);
+ }
xic = XCreateIC(xim, XNInputStyle, XIMPreeditNothing | XIMStatusNothing,
XNClientWindow, win, XNFocusWindow, win, NULL);
--
1.8.4.2
[dev] [PATCH] dmenu: Fix segfault on systems with broken locale support
Fix segfault on systems with broken locale support
--- dmenu.c.orig 2013-11-16 10:52:03.970786705 -0300
+++ dmenu.c 2013-11-18 16:07:45.422148846 -0300
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -590,7 +591,13 @@
CWOverrideRedirect | CWBackPixel | CWEventMask, &swa);
/* open input methods */
- xim = XOpenIM(dc->dpy, NULL, NULL, NULL);
+ if (!(xim = XOpenIM(dc->dpy, NULL, NULL, NULL))) {
+ fputs("dmenu: Failed to open input method\n", stderr);
+ /* Might be an issue with the locale */
+ setlocale(LC_ALL, "C");
+ if (!(xim = XOpenIM(dc->dpy, NULL, NULL, NULL)))
+ exit(1);
+ }
xic = XCreateIC(xim, XNInputStyle, XIMPreeditNothing | XIMStatusNothing,
XNClientWindow, win, XNFocusWindow, win, NULL);
