Re: [hackers] [st] Remove ^E and ^Y
Sorry, this patch is for scroll, no for st.
On Sat, May 16, 2020 at 09:57:28AM +, Roberto E. Vargas wrote:
> ^E and ^Y are characters reserved by POSIX shell in emacs
> editing mode for "control of line" and "yank". St is generating
> ^E and ^Y as a hack because vi and less uses them for scroll
> backward/forward. being the only terminal emulator where
> mouse wheel can be used with them. A new patch was sent to
> st to do the same trick for terminal scroll, and making st
> returns shift+prev/next for shift+wheel.
> ---
> config.def.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/config.def.h b/config.def.h
> index 36b1a45..51c493b 100644
> --- a/config.def.h
> +++ b/config.def.h
> @@ -10,6 +10,4 @@ struct rule rules[] = {
> /* sequence eventlines */
> {"\033[5;2~", SCROLL_UP, -1}, /* [Shift] + [PageUP] */
> {"\033[6;2~", SCROLL_DOWN, -1}, /* [Shift] + [PageDown] */
> - {"\031",SCROLL_UP,1}, /* mouse wheel up */
> - {"\005",SCROLL_DOWN, 1}, /* mouse wheel Down */
> };
> --
> 2.26.2
>
>
[hackers] [st] Make shift+wheel behaves as shift+Prev/Next
St uses a very good hack where mouse wheel genereates ^Y and ^E,
that are the same keys that less and vi uses for backward and
fordward scrolling. Scroll, as many terminal emulators, use
shift+Prev/Next for scrolling, but it is also using ^E and ^Y
for scroling, characters that are reserved in the POSIX shell
in emacs mode for end of line and yanking, making scroll unsable
in st.
This patch adds a new hack, making shift+wheel returning the
same sequences than shift+Prev/Next, meaning that scroll or
any other similar program will not be able to differentiate
between them.
---
config.def.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/config.def.h b/config.def.h
index fdbacfd..293e00c 100644
--- a/config.def.h
+++ b/config.def.h
@@ -171,7 +171,9 @@ static uint forcemousemod = ShiftMask;
static MouseShortcut mshortcuts[] = {
/* mask button functionargument release
*/
{ XK_ANY_MOD, Button2, selpaste, {.i = 0}, 1 },
+ { ShiftMask,Button4, ttysend,{.s = "\033[5;2~"} },
{ XK_ANY_MOD, Button4, ttysend,{.s = "\031"} },
+ { ShiftMask,Button5, ttysend,{.s = "\033[6;2~"} },
{ XK_ANY_MOD, Button5, ttysend,{.s = "\005"} },
};
--
2.26.2
Re: [hackers] ubase musl
On Sat, Mar 21, 2020 at 12:23:51PM -0700, Michael Forney wrote: > On 2020-01-5, spaceman wrote: > > ubase won't compile with musl later than 1.1.23 because it lacks the > > major, minor and makedev function. Added the necessary include to make > > it compile. > > Yes, this is a known issue. I sent a patch last August: > https://lists.suckless.org/hackers/1908/16960.html > > Unfortunately, ubase does not have an active maintainer. As you are the maintainer of sbase, maybe it is a good idea if you become the maintainer of ubase. Regards,
Re: [hackers] [sbase] ed: Use reallocarray || Michael Forney
Hi,
On Tue, Dec 31, 2019 at 10:47:28PM +0100, g...@suckless.org wrote:
> diff --git a/ed.c b/ed.c
> index b844e86..e998e81 100644
> --- a/ed.c
> +++ b/ed.c
> @@ -204,7 +204,7 @@ makeline(char *s, int *off)
> if (lastidx >= idxsize) {
> lp = NULL;
> if (idxsize <= SIZE_MAX - NUMLINES)
> - lp = realloc(zero, (idxsize + NUMLINES) * sizeof(*lp));
> + lp = reallocarray(zero, idxsize + NUMLINES, sizeof(*lp));
reallocarray is not a posix function, so it shouldn't be used here. If you
don't fell confortable using realloc due to the possibility of overflow then
you should add an explicit check against it.
Regards,
Re: [hackers] [st][patch] Refresh keyboard mapping
> The diff looks good to me, but maybe there are objections by somebody > more familiar with X11-signals. I think it is ok and we should merge it. Evil_Bob, what do you think?
Re: [hackers] [st][PATCH 00/24] odg patches - fix warnings/errors, plug leaks, tidying up
Hi, > What's the point of all this if you are treating others who try to > participate this way ? > I have never seen such lack of tact. Yes, I am pretty sure that you didn't read any of the rants of Linus or Theo. > This sucks. This is suckless, no suckmore.
Re: [hackers] [st][PATCH 00/24] odg patches - fix warnings/errors, plug leaks, tidying up
Hi, > These patches fix all errors and warnings I found when building with lots of > compiler warning flags enabled, and running tools like cppcheck and valgrind. > There's lots of type and const correctness fixes, conflicting variable names, > a couple of memory leaks, and stylistic stuff like reducing variable scope. > Also avoid linking with libm and make building on OpenBSD a bit more > straightforward. First point, why do you think we care about what your linter says? If it gives false positives send patches to the developers of your linter. > Oliver Galvin (24): > add gitignore Why do you think we want a gitignore?. Suckless projects don't use .gitignore files. If you want to ignore files you can do it locally using .git/info/exclude > avoid unnecessarily checking if an unsigned variable is < 0, fixes > cppcheck warnings I don't care about cppcheck. And you modified the macro ISCONTROL() in a way that hides the difference beteween C0 control codes and C1 control codes. It is true that the code doesn't use this difference, but it is additional documentation in the code. > Reduce variable scope where possible, fix cppcheck style warnings I don't care about cppcheck. Suckless projects always declare the variable at the beginning of the function. > use const where possible, avoid discarding const, fixes errors from > -Wdiscarded-qualifiers I don't care about cppcheck. > avoid warnings from -Wunused-parameter I don't care about cppcheck. > fix warnings from -Wimplicit-fallthrough I don't care about cppcheck. And you are modifying the behaviour of st. How do you think that you can put random breaks and you are not going to break the code?!?!?!?!?!?!? > fix warning from -Wmaybe-uninitialized I don't care about cppcheck. > fix warnings from -Wsign-compare and -Wtype-limits. also make sure we > use size_t for len variables I don't care about cppcheck. > avoid redundant declaration and old-style function definition -extern char *argv0; +static char *argv0; Do you understand what you are doing there?!?!??!!?. You are creating a different variable in every file including arg.h!!!. > fix -Wshadow warnings, due to variable names conflicting with global > variables. also we don't need to pass global variables to xinit() I don't care about cppcheck. > rename variable to fix cppcheck shadow warning, due to variable name > conflicting with function I don't care about cppcheck. > fix remaining cppcheck warnings: reduce scope of some variables, and > avoid compiling selcheck_ when it's not used, by adding a new > setting in config.h I don't care about cppcheck. Why do you think this ifdef is a good thing??? Because we move from 45KB to 44.9KB? > clean up two warnings from clang about initialisation and sign > comparison I don't care about cppcheck. And now, I don't care about clang. Send patches to clang to remove false positives. > now st can build without errors/warnings with -Wall -Wextra -Wpedantic > enabled, enable them by default I don't care about cppcheck and I don't care about your warnings. > update config.def.h with necessary changes after my previous commits. > uses const everywhere and adds the SELCLEAR option Ok, at this point I can confirm that you don't have too much experience in programming, it is obvious. A free advise, don't hurt yourself and don't use const. > avoid leaking memory when xrealloc/xstrdup fail, by freeing memory > before die() I don't care about cppcheck and at this moment I don't care about valgrind. There isn't any memory leak, all the memory of the process is freed at the end of the process. > use EXIT_SUCCESS/FAILURE Please, don't submit style patches. St is a portable posix program, and in the posix enviroment the exit status is properly defined and the use of 0 and 1 is correct. > use compiler attribute to check die() parameters, and fix relevant > warning from clang Over my dead body. Learn to use C, please don't use GNU extensions. At this moment st can be compiled with any c99 compliant compiler: gcc, clang, pcc, lcc, tcc ... > improve type and const correctness by using more correct types. fixes > a bunch of -Wcast-qual warnings Your patch is not correct, rejected. > use EXIT_FAILURE/SUCCESS on exit At least you should learn to squash commits before sending them to any open source project. That's a pity that the mail history cannot be rewritten. Any recruiter that will search for your name in the future will discover this shame of patchset. Second free advise, before doing things try to learn from more experienced guys. > avoid unnecessarily linking to the math library, and detect openbsd > automatically in makefile Over my dead body!!!, what the fuck are you thinking???. Only the part of removing -m is good. You should learn to use POSIX Makefiles. At this moment st can be compiled using any POSIX Make: GNU make, BSD
Re: [hackers] [st][PATCH] Fixed 'missing glyph doesn't use
> I reverted 4242027, applied this patch, and it does indeed fix the > problem for me. Applied.
Re: [hackers] [st][PATCH] Fixed 'missing glyph doesn't use fontconfig config substitutions' bug
> I basically just copied the guts out of XftFontMatch[1] and saved > the intermediate configured FcPattern. Could be related to the bug that > inspired commit 4242027. > Ok, your patch seems correct, but I would like to know if your patch solves the issue of the commit 4242027, because in this case we can remove the changes of that commit, which are a bit ugly. Can you verify it? Regards,
Re: [hackers] [dwm] [PATCH] Replace str[n]cpy with strlcpy
> The only reason why strlcpy is "non-portable" is because the > Posix-committee has sticks up their asses (same with the > glibc guys). Why is so difficult to accept that your idea is so bad?. Why people like so much think in obscure conspiracions instead of accepting the true? Regards,
Re: [hackers] [dwm] [PATCH] Replace str[n]cpy with strlcpy
> there is also another point here: strlcpy is safer than strcpy
> and strncpy because _if_ there is an overflow the string will
What happens if you pass an incorrect size to strlcpy?. Please,
stop of saying stupid things.
if (strlcpy(dst, src, nsrc) >= nsrc)
error();
is equal to:
if (nsrc >= ndst)
error();
memcpy(dst, src, nsrc);
but the code with strlcpy is slower and not portable.
There is a reason why after 16 years strlcpy is not in any
standard, no C11, no POSIX, and it is because it sucks a lot.
>From my point of view the worst thing is that people believe
that using strlcpy the code magically becomes secure, and this
is a totally false security sensation. You have to check the
return code, and it means that the code is totally equivalent
to an explicit if. Look for example this case:
deluser(strlcpy(dst, "user15", 4));
Since you are not checking any return code there you are not
deleting the correct user, and this kind of attacks can be very
easy of attack, more easier than stack overflow.
In a previous mail you said that one of the reasons of using
strlcpy was to avoid problems in the future due to modifications
in the code. Did you think about it before writing it?. You
can say that of _ANY_ operation in C, mainly with pointers and
indexes, but strlcpy can not help at all in a situation like this:
#define LENA 5
#define LENB 6
char sa[LENB];
f(sa);
f(char s[LENB])
{
strlcpy(s, "This is a very long string", LENB);
}
and now you have this patch:
- char sa[LENB];
+ char sa[LENA];
Do you see? strlcpy didn't help at all, and due to the
false security sensation the programmer didn't dig to
see all the side effects of changing the size of sa.
C is a very low level language, and it is a language
without support for strings, and the only way of writting
correct code is to be very carefull and before doing any
change check everything, and look for all the possible
errors due to your change.
And of course, strlcpy is also totally useless because
you can do the same work with snprintf.
Regards,
PD: I don't want to begin a flame war, but please, stop
of being a fan boy and think for yourself, try to find
the strong points and what is propaganda.
Re: [hackers] [dwm] [PATCH] Replace str[n]cpy with strlcpy
>> I'll drop this little patch here so we finally make the switch to the safe safe?. You are not checking any of the return codes. You are only moving the problem from some place to another place. Please add checks and stop using non portable functions. I don't want your shit, thanks. Regards,
Re: [hackers] [scc] [PATCH] [cc2] Fix memset argument
Thanks!!!. My last commits are generating a lot of errors. Cc2 is in an unstavke stage now. I hope it will finish soon, and I will be able to put test cases. Sorry for the inconvenience. Regards,
Re: [hackers] [PATCH] [scc] [cc2-qbe] Print function parameter types and names
Thanks, I will apply it tomorrow with small changes:
> I had to disable the calls to apply(sethi) and apply(cgen) in cc2/main.c
> while testing because they were causing segfaults.
Yes, I am doing big modifications to scc-qbe now, and I hope I will
push tomorrow some changes I am doing and that will be the base for
the code generation. After that, I will be able to test, and I it
will be stable again. Sorry for the inconvenience.
>
> +extern Symbol *locals;
I will add it to cc2.h. I added a section of globals in cc2.h, and I think
locals is an important part of the interface that the arch codes can use.
> @@ -103,34 +105,29 @@ emittree(Node *np)
> }
> }
>
> -static void
> +static char *
> size2asm(Type *tp)
> {
> - char *s;
> -
> /* In qbe we can ignore the aligment because it handles it */
>
> if (tp->flags & STRF) {
> - s = "b\t";
> + return "b";
> } else {
> switch (tp->size) {
> case 1:
> - s = "b\t";
> - break;
> + return "b";
> case 2:
> - s = "h\t";
> - break;
> + return "h";
> case 4:
> - s = "w\t";
> - break;
> + return "w";
> case 8:
> - s = "l\t";
> - break;
> + return "l";
> default:
> abort();
> }
> }
> - fputs(s, stdout);
> +
> + return NULL;
> }
>
Perfect. I only think that the return NULL can be removed, because
abort will not return ever (well, technically talking, abort can return,
but it will not happen ever in cc2).
> @@ -160,7 +158,8 @@ void
> data(Node *np)
> {
> putchar('\t');
> - size2asm(>type);
> + fputs(size2asm(>type), stdout);
> + putchar('\t');
> emittree(np);
> putchar(',');
> putchar('\n');
What about: "printf("\t%s\t", size2asm(>type))" ?
> @@ -169,9 +168,19 @@ data(Node *np)
> void
> writeout(void)
> {
> + Symbol *sym = locals;
> +
> if (curfun->kind == GLOB)
> fputs("export ", stdout);
> - printf("function %s(", symname(curfun));
> + printf("function $%s(", symname(curfun));
> +
> + if (sym && (sym->type.flags & PARF)) {
> + printf("%s %s", size2asm(>type), symname(sym));
> + sym = sym->next;
> + for (; sym && sym->type.flags & PARF; sym = sym->next)
> + printf(", %s %s", size2asm(>type), symname(sym));
> + }
> +
> puts("){");
> puts("}");
> }
I imagine you wtite this code in this form because you don't want to
write a trailing ',' in the last parameter, but this is not a problem
because qbe accepts it. We can write in this form:
for (sym = locals; sym; sym = sym->next) {
if ((sym->flags & PARF) == 0)
break;
printf("%s %s,", size2asm(>type), symname(sym));
}
Or, why not, something like:
for (sym = locals; sym; sym = sym->next) {
if ((sym->flags & PARF) == 0)
break;
printf("%s %s%c\n",
size2asm(>type), symname(sym),
(sym->next) ? ',' : ')');
}
Regards,
Re: [hackers] [scc][PATCH] Fix NULL pointer dereference
> if ((sym = install(NS_IDEN, sym)) == NULL) {
> errorp("redefinition of parameter '%s'",
> -sym->name);
> +yylval.sym->name);
Upsss, good catch. I will apply it tomorrow. Thanks!
Regards,
Re: [hackers] [farbfeld] Remove dimension checks || FRIGN
> One problem I see with this approach is that an error will potentially go > unnoticed and require more time to diagnose than necessary. Indeed.
Re: [hackers] [ubase][PATCH] shred: call fsync at the end of each
> Or we could just refuse to support terminals > that do not support standard escape sequences. > Hardcoding the escape sequences is the only > way to remain sane. Here when you say standard you want to say "common". There are several standards about sequences, and maybe you don't have any of these terminals that doesn't follow xterm sequences, but there are. In fact, at this moment I have to write some code using a VT52 terminal. Sane code looks in the terminfo definition, and if you code doesn't look it, please avoid to send it here. I don't want to see it. Maybe in GNU they are going to be pleased of accepting such crappy software. In this case, I don't see the necessity of using sequences, or directly printing this disturbing sequences. Follow the rule "Silence is gold". Regards, PS: If you have complaints about terminfo, I don't want to listen them. You can send them to the POSIX committee, and I'm pretty sure they will take some time considering your opinion.
Re: [hackers] [ubase] Add nologin(8) || Mattias Andrée
> +.Os ubase Why it is in ubase? It is totally portable.
Re: [hackers] [sbase][PATCH] Improvements to sleep(1):
> I find these features overkill for sleep(1). Indeed.
Re: [hackers] [sbase][PATCH] stty belongs in ubase
> -stty Why stty belongs to ubase?. As far as I know termios is POSIX. Regards.
Re: [hackers] [ubase][PATCH] shred: call fsync at the end of each content shred pass
> + fprintf(logfp, "\033[A\033[K"); Please guys, stop writing code like this. You cannot print sequences directly to the terminal. You have to look in the terminfo entry first. I think I am going to modify in st every sequence that ppl is hardcoding in sbase and ubase. Regards,
Re: [hackers] [sbase][PATCH v4] Add diff(1) and bdiff(1)
Hi, > +.It Fl D > +Produce colored output if stdout, is a terminal. > +Always produce colored output if used twice or more. I'm totally against this feature. Programs that check against /dev/tty are not orthogonal and your implementation is not portable because you hardcoded the escape sequences in the code. I think is better don't colorize and let this work to colordiff(1). > +.Xr ed 1 . > +.It Fl f > +Produce output similar to the format of > +.Fl e , .Fl e? what is e? Both comments apply to diff and bdiff. Regards,
Re: [hackers] [sent] Fix cmdline argument check
> Noted, I sent a modified version of the patch, what do you think about > it? I think this version is clearly better than the first. Sometimes is difficult don't abuse of the ternary operator ;). Regards,
Re: [hackers] [farbfeld] Fix 2 little things in jpg2ff(1) || FRIGN
> I was wondering, don't you mean "argc != 0"? :) uhmmm, yeah. Regards,
Re: [hackers] [sent] Fix cmdline argument check
Hi,
> + if ((fp = ((argv[0] && strcmp(argv[0], "-")) ? fopen(argv[0], "r") :
> stdin))) {
>From my point of view this expresion is too complex and it should be
splitted in several subexpressions.
Regards,
Re: [hackers] [surf] Some cleanup in style. || Christoph Lohmann
On Tue, Feb 03, 2015 at 07:52:10PM +0100, FRIGN wrote: On Tue, 3 Feb 2015 17:17:15 +0100 (CET) g...@suckless.org wrote: commit b3a4392923b26e81c4faa35907a4a2d071e2275f Author: Christoph Lohmann 2...@r-36.net Date: Tue Feb 3 17:17:04 2015 +0100 Some cleanup in style. wrong: http://suckless.org/style His style fix is correct in respect to the existing code style of surf. The style guide is simply a guide. Yeah, this is the first rule of any code style guide, if a project has a style, don't change it. Regards,
Re: [hackers][st] Patch argbbg for git version 2014/11/22
Hi, Usually proposed patches are sent to the dev list because this list is where the git hooks send the commited patches. About your patch, you can add this patch directly to the wiki. Thanks,
Re: [hackers] [sbase] config.mk: make cc the default $CC || Hiltjo Posthuma
On Tue, Nov 11, 2014 at 11:05 AM, Dimitris Papastamos s...@2f30.org wrote: I agree on this, I think Hiltjo had some trouble because it was defaulting to c99 as opposed to cc and that did not exist on his system. Hiltjo, can you clarify again? Yeah that was my problem. .POSIX: in the Makefile specifies c99 is the default $CC[0]. That said I'll just fix my system. Feel free to revert this commit. [0]: http://pubs.opengroup.org/onlinepubs/007904975/utilities/make.html But POSIX also specifies that c99 is a component of the system that must be present, so this patch doesn't make sbase more POSIX compatible.
Re: [hackers] [sbase] config.mk: make cc the default $CC || Hiltjo Posthuma
Worth noting that POSIX doesn't specify a value for LD. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html#tag_20_76_13_09 Uhmm, you are rigth. It's funny they define LDFLAGS, but it is only used in the single file compilation.
Re: [hackers] [sbase] config.mk: make cc the default $CC || Hiltjo Posthuma
config.mk: make cc the default $CC -#CC = gcc -#CC = musl-gcc -LD = $(CC) CPPFLAGS = -D_BSD_SOURCE -D_GNU_SOURCE CFLAGS = -g -std=c99 -Wall -pedantic $(CPPFLAGS) LDFLAGS = -g +#CC = gcc #CC = tcc -#LD = $(CC) +#CC = musl-gcc +CC = cc +LD = $(CC) If you want to do that, then the only thing you have to do is don't assign any value to CC, because cc is the default value. If you do in this way then the user can set his prefered compiler exporting CC. The same apply to LD, there is a default value that is the correct for the system. Regards,
