>> -setenv("SHELL", sh, 1);
>> +setenv("SHELL", args[0], 1);
>
> I'm not sure whether this is a good idea? The user asked to execute
> args[0] instead of the shell, but this doesn't imply that args[0] is
> his shell.
Yes, you are right, it should be setenv("SHELL", sh, 1);
Can you send
>
> What exactly does "terminal configuration" mean here? TERM, LINES, and
> COLUMNS? Shouldn't st itself be responsible for setting these? They
> certainly don't belong in the profile.
Value of erase key for example, or in general the configuration
of line kernel driver (stty(1)). Backspace key
> On Sat, Oct 11, 2014, at 04:07, k...@shike2.com wrote:
>> Value of erase key for example, or in general the configuration
>> of line kernel driver
>
> These can't come from the profile either; since st opens a new tty that
> is not the same device the user logged in on.
And the profile runs in
> Why shouldn't a non-login shell have a utmp session? And if this option
> is to use a login shell, rather than merely using utmp, then I don't
> think it should be a compile-time option - just because someone
> sometimes wants a login shell (which could be done before, if desired,
> by running e
> On Sun, Oct 12, 2014, at 14:32, k...@shike2.com wrote:
> That doesn't mean that the question of what the default should be is not
> worth discussing.
Default configuration was discussed here some time ago, and suckless
developers agreed with current configuration. Both options, Backspace
genera
> Because that is the character sent by the key in this position with this
> expected function (i.e. the also, for better or worse, what modern linux systems have standardized
> on (I haven't done a survey of bsd, solaris, etc).
Linux has not standardized anything. POSIX is the standard. You c
>
> Patch letting st not embedding when given Window id is zero, without failing.
It makes sense to me, so I will apply it next week.
Regards,
From: "Roberto E. Vargas Caballero"
---
Makefile |6 +-
config.def.h |2 ++
last.c | 59 ++
3 files changed, 66 insertions(+), 1 deletion(-)
create mode 100644 last.c
diff --git a/Makefile b/Makefile
index 3989a77.
From: "Roberto E. Vargas Caballero"
$? is expanded to all the requisites that are newer than the current target,
so we can avoid update files that were not modified since last time
the library was built.
---
Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile
> On 26 October 2014 19:36, Dmitrij D. Czarkoff wrote:
>> Apparently no workaround is needed - just use sane libc or avoid using
>> new codepoints until glibc fixes that. Or, if you won't feel dirty
>> after that, send a patch to glibc instead.
>
> 'Just using musl' doesn't seem feasible given a
Hi,
> Apparently curses provides:
>
> int init_color(short color, short r, short g, short b);
>
> not quite sure what it does internally.
There is no support for true color in terminfo, so curses cannot
handle it. If your application need it the only way is to print
directly the sequences, and
> That's how POSIX-2001 defines it.
>
> So yeah, using abs() to "catch" the invalid case is fine, but could be
> refined even more.
>
Ok, it is true. We should catch this case, but I don't like the idea
of the abs. I think the correct solution should be print the invalid
character.
Regards,
> A simpler possibility is to let it enabled by default and let the user
> switch it off with a command line argument (like it's done for the mouse
> grabbing). I think it would make sense as all major terminal emulators
> support true color.
We have something similar for alternate screen to,
Hi,
>>
>> There is no support for true color in terminfo, so curses cannot
>> handle it.
>
> Is this a fundamental limitation or just a lack of standardization?
>
> https://lists.gnu.org/archive/html/bug-ncurses/2013-10/msg7.html
Mainly lack of standardization (this feature was added to
> Silvan Jegen said:
>> I do agree that this is the right approach. There is however another
>> instance of a wcwidth call on line st.c:3443 that should be handled as
>> well (maybe with abs in that particular case?).
>
> As I get it, by the time wcwidth() is called there, all codepoints libc
> is
> Hi,
>
>> printf "\x1b[38;2;255;100;0mTRUECOLOR\x1b[0m\n"
>
>
> I think this truecolor control sequence is not suckless.
>
> Although I had already mentioned about this feature (konsole-style
> true color support) on some places with my bad English, now I try to
> say my opinion repeatedly in
> Ok as far as I can tell there are two unrelated issues involved (feel
> free to correct me):
>
> 1) being able to use many colors (possibly all 2^24) at the same time
>
> 2) being able to set some of the used colors to RGB values
>
> The first is not easily possible with ncurses. As you p
Hi,
> - POSIX states the SHELL environment variable "... shall represent a
> pathname of the user's preferred command language interpreter." As
Well, this is a really complex topic. First because in this sentence
is not specified what is 'user's preferred command language
interpreter'. I read
> in config.h something along the lines of
>
> enum color_mode {
> REVERSE,
> COLOR,
> };
> struct selection_colors {
> enum color_mode;
> int colors[];
> }
> static const struct selection_colors same = { .color_mode = COLOR,
> .colors = { 7, 0 } };
> static const struct selection_colors d
> Hi folks,
>
> my delete-key behaves as backspace since commit
> 9d9e049eac3dacb2725f9d792f7cdd2230062313 on all my linux machines
> (debian, fedora, ubuntu) and openbsd.
> i had this problem in the past (and wrote to this list about it), and
> my .zshrc since then contains stty erase ^H:
Hi,
>>> Above my opinion might be not constructive, so now I propose alternate
>>> sequences:
>>>
>>> I recommend a recall of Konsole style truecolor control seqences, and
>>> propose to change them as follows:
>>>
>>> CSI 38 ; 2 ; Pr ; Pg ; Pb m -> CSI ? Pr ; Pg ; Pb $ m
>>> CSI 48 ; 2 ; P
>> HOME must hold the value of the user's home directory, if this
>> value is not the value of /etc/passwd then you have an error
>> in your configuration. The same can be said about SHELL. You
>> can change your shell selection using chsh.
>
> I don't agree with your interpretation of the POSIX
If you are interested,
> - Modify the keys generated by st. This option is not dificult, because
> you
> only have to modify the values in your config.h (I think I should put
> this
> option in the FAQ to).
If you are interested in this solution this is the patch:
diff --git
Hi,
> I applied this patch and now when I press DELETE in the shell I get a
> '~'.
Can you send the output of:
infocmp
and the output of
cat
^VDelete (press first control V and then Delete key)
Regards,
> sent is interesting, but as a teacher, I need some mathematical symbols,
> and a tool to write more than 3 words per slide...
>
> (by the way, on debian, sent can't find any font...)
>
> reveal.js is interesting too, but far from suckless...
>
> I'll stick to markdown+pandoc->beamer for now un
>> Output of infocmp attached: out.txt
>>
>> Output of ^VDelete:
>>
>> ^[[3~
>>
>
>
> You appear to have mistyped something. CSI requires only one bracket.
^[ is the ESC representation, so ^[[ is CSI. The terminal is generating
CSI 3 ~, that from your infocmp output is kdch1:
kdch1=\E[
>> So, it should be recognized as Delete key. What shell are you using?
>>
>> Regards,
>
> st - simple terminal
>
I asked you about your shell, not about your terminal emulator.
Regards,
> - Rename volatile bool q = false; to "isrunning".
is.* is a reserved name space, it have not to be used in external scope.
> - Use the safer strlcpy or snprintf instead of strcpy().
I disagree, check the size before of calling strcpy. If you want to
avoid security risk you also have to check
> * Use strtonum() or estrtol() from sbase instead of atoi().
I agree here if the string comes from the user. If the string
is an internal string then there is no problem with atoi.
>> I disagree, check the size before of calling strcpy. If you want to
>> avoid security risk you also have to check the output of strlcpy
>> to detect truncations, so you don't win anything. In both cases
>> you have to add a comparision, so it is better to use strcpy that
>> is standard.
>
> Goo
>> > * Use strtonum() or estrtol() from sbase instead of atoi().
>>
>> I agree here if the string comes from the user. If the string
>> is an internal string then there is no problem with atoi.
>
> It is generally unlikely that the string has been validated to
> be an integer before getting to a
> I am personally not opposed to using yacc. Yeah I like hand-rolled
> recursive descent parsers are cool but yacc is a standard tool that
> most people are familiar with.
>
> Roberto, what do you think?
I agree with you. I think yacc is a suckless tool, and I am sure we will
have to use it for
>> I did a quick survey of a number of other terminal emulators: tmux,
>> xterm, GNU screen, rxvt and dvtm all check the SHELL environment
>> variable. Checking SHELL is expected behaviour, and it's a useful one at
>> that.
>>
>> Eric
>
> Checking SHELL is common behaviour and any user setting S
> Sorry, it is zsh.
>
It should work. I don't know why it doesn't work for you.
Do you have something in .zshrc?
Regards,
Good point. I'll apply it.
Thanks.
I have tested with your .zshrc and I don't have the problem you describe.
Are you sure that your config.h has the modifications the patch adds
to config.def.h?
Regards,
Applied!!!
>
>> variables
>> =
>> declaration of pointer, * is adjacent to variable not type (as it's
>> part of the variable not the type, avoids int* i, j; etc.)
>
> This is a very smart point. I see this very often, even though not
> in sbase. a grouped declaration "int* a, b, c;" could falsl
>> > By default I read if (!functioncall()) as 'if the function call
>> > failed'. I like the (strcmp(p, q) == 0) idiom because I don't fall
>> > into the trap of reading the statement as 'if the string comparison
>> > failed'. It is the one case I can think of where I prefer an explicit
>> > co
> system headers should come first, then a newline, then libc headers
> then a newline then local headers.
I usually do just the inverse, first libc headers and later system
headers.
> the libc headers are guaranteed to work regardless of the order of
> inclusion but need to come after the syst
>> types
>> =
>> user defined types start with a capital letter
>> when possible typedef struct {} Name;
>
> Debatable. I'd like to hear more opinions on this.
For long time I followed the rule of kernel style of not using typedef
ever, but I changed it to the rule of using typedef only w
> On Tue, Nov 18, 2014 at 09:53:33AM -0500, Greg Reagle wrote:
>> Another way to provide style guidance is to refer to a particular source
>> file or project as an epitome or paragon, if such a paragon exists That
>> takes much less time than explicitly developing a style guide.
>
> Yes my initia
> The Makefile made libutil.a and libutf.a identical. Here is a patch to fix
> this.
>
> -$(LIB): $(LIBUTFOBJ) $(LIBUTILOBJ)
> +$(LIBUTF): $(LIBUTFOBJ)
> +$(AR) -r -c $@ $?
> +$(RANLIB) $@
> +
> +$(LIBUTIL): $(LIBUTILOBJ)
> $(AR) -r -c $@ $?
> $(RANLIB) $@
>
In fact
>>> types
>>> =
>>> user defined types start with a capital letter
>>> when possible typedef struct {} Name;
>>
>> Debatable. I'd like to hear more opinions on this.
>
> In most suckless code types always start with capital letters (pretty
> much acme/p9 influenced), as opposed to lower cas
> On 18 November 2014 19:25, Greg Reagle wrote:
>> Hello. Is there a particular reason that a combination of cp, mkdir,
>> and chmod are used rather than the install command, in several suckless
>> projects (in the install target of Makefile)?
>
> To me the answer is rather obvious. install viol
>> In fact, POSIX says that it could be only:
>>
>>
>> $(LIB): libutf($(LIBUTFOBJ)) libutil($(LIBUTILOBJ))
>>
>> but my experience is that it doesn't work in BSD systems :(
>
> We now depend on GNU make. I am tired of fighting make implementations.
Ok, but I think current Makefile works
> Was there as reason or did the user trolls attending the last one
> just have fun pissing off most of the suckless-contributors?
> There's no reason to have a conference in Budapest when most people
> come from a completely different part of the world.
> However, I think we could put together so
> C90, or any version of standard C, does not have a concept of "system
> headers", other than giving implementations permission to place their
> own implementation-defined files in places searched by #include
> .
At this point I was talking about POSIX of course. C90 doesn't give
implementations
Hi,
> Hi Evan,
>
> I'd prefer to stick to the existing makefile. It might be scary to
> say that it depends on GNU make but bear in mind that of all the make
> implementations I've tried only OpenBSD make had some trouble with it.
I think we should remove the GNU make dependence, because we don
> Er, by "permission" I meant it doesn't make the _implementation_
> non-compliant.
No, it doesn-t make cthe compiler non-complaint, but it makes your
code non complaint.
> And implementation-defined is not the same as undefined.
I perfectly know it, but in this case it is not exactly said
if
> st.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/st.c b/st.c
> index fc91334..db9a332 100644
> --- a/st.c
> +++ b/st.c
> @@ -3922,6 +3922,9 @@ run(void) {
> TIMEDIFF(now,
>
>> The style(9)-changes were absolutely necessary and it's better to do this
>> as early as possible instead of waiting and waiting until it's too late
>> and you have a really big number of patches for a given program.
>
> The thing I dislike most about the style changes is the alignment of
> va
> Who here doesn't use ctags or similar? Because using navigation
> techniques that only work if not technically enforced style guidelines
> are followed is not really helpful to people who read and write code in
> many different projects.
I don't use ctags. It's simple, if you use the correct co
> On Fri, Jan 30, 2015 at 12:41 AM, FRIGN wrote:
>> On Thu, 29 Jan 2015 15:08:39 -0800
>> Rian Hunter wrote:
>>
>>> When MODE_INSERT is set we'd shift characters on the same
>>> line forward before inserting our character in tputc().
>>> This did not account for wide characters where width != 1.
> Thanks k0ga. I have not taken the time to check whether this is on the
> wiki or on git, but last week I updated my suckless software packages
> and patches and to have this was definitely a good thing.
I have uploaded it to the wiki, but I have to add a README about it.
Regards,
>
> Thanks for the feedback everyone. Glad to contribute, st is literally the only
> sane freely available graphical terminal emulator in existence.
>
> The original code still looks a bit fishy to me. It looks like there could be
> a situation where two newlines are written when a single charac
Good evening,
>
> What is left to discuss is where to put these functions. I would propose
> to place chartorunearr into rune.c, where already chartorune() and
> others reside.
> I would place readrune() and writerune() into a new file called
> runeio.c.
> The name doesn't really matter, becaus
> On Tue, 10 Feb 2015 21:21:56 +0100
> k...@shike2.com wrote:
>
> Hey k0ga,
>
>> When you write a library one of the objects is to minimize
>> what code is included in the binary when the library is linked.
>> When you link with a library you extract object file
> On Tue, Feb 10, 2015 at 10:07:52PM +, Connor Lane Smith wrote:
>> int
>> utftorunestr(const char *s, Rune *p)
>> {
>> int i, n;
>>
>> for(i = 0; (n = chartorune(&p[i], s)), p[i] != 0; i++)
>> s += n;
>> return i;
>> }
>>
>> int
>> fgetrune(Rune *p, FILE *fp)
>> {
> diff --git a/st.c b/st.c
> index 1deb7bc..547ddc9 100644
> --- a/st.c
> +++ b/st.c
> @@ -2992,7 +2992,7 @@ xloadfonts(char *fontstr, double fontsize) {
> if(!pattern)
> die("st: can't open font %s\n", fontstr);
>
> - if(fontsize > 0) {
> + if(fontsize > 1)
> Firstly, I did not know C required backslashed newlines for
> continuation,
It doesn't need it. Backslash escapes newlines, but in this
case is not needed because two strings together are joined.
They are put only because it's part of the style used by
the original author of st.
> but a bit mo
> As per discussion on IRC with FRIGN, ioctl is no standard, but it is
> probably a defacto standard; how else can you determine the terminal
> width portably? However, this patch adds a fallback in case you can't
> read the terminal width - this is how cols currently does it.
You can trust the v
> Maybe still add an assert() against the divisor != 0 before the code in the
> other patch.
>
> Just so people in the future will know that if it does == 0 there is a logic
> error elsewhere in the program.
>
I don't like this idea, because it means we have to add an assert before
any divisio
> Use the terminfo delay syntax ($) in our flash capability to avoid
> hardcoding a fixed delay in redraw() when called from tsetmode() with
> DECSCNM.
> We need to turn on the npc capability so that delays are made with
> xon/xoff instead of padding characters.
I tried long time ago something sim
> By the way, I looked at other term definitions of this capability and I
> noticed this interesting difference:
>
> vt200|vt220, similar for xterm, konsole, etc.
> flash=\E[?5h$<200/>\E[?5l
> vt330|vt340, vt400, linux-basic…
> flash=\E[?5h\E[?5l$<200/>
>
Hi,
> This is very inconsistent, because the first linebreak uses the backslash and
> the second one directly following it does not use it. I think the first one
> should be removed.
It is true that it is inconsistent (and I think it's my fault). I personally
don't like these unneeded \, and I th
> The ioctl() can be assumed to be present on all systems, but in case
> TIOCGWINSZ doesn't exist, we fall back to the fixed value. This is the
> best of both worlds.
>
I like your solution, but I think COLUMNS should have a bigger
priority, because in this case user can define a different value
> On Sun, 15 Feb 2015 19:35:51 +0100
> k...@shike2.com wrote:
>
>> I like your solution, but I think COLUMNS should have a bigger
>> priority, because in this case user can define a different value of
>> the current width.
>
> Okay, then do 3 fallbacks
>
> ioctl -> getenv -> fixed width
>
Ups,
Hi,
> your line driver. I mean, st ignores xon/xoff characters, so the line
> driver (configured via stty with the flags ixon, ixoff, ixany) is
> making the job of stopping the comunication. If we add this patch to
> st we must add some information about it in the FAQ (similar to the
> informa
> I think the base assumptions programmers have about pointers is
> different from integers. Pointers with null values are universally
> known to be special and a case that should be checked for. With
> integers, it's not obvious what the valid range is supposed to be, in
> many cases 0 is okay.
> Hello list,
>
> I know this isn't a democracy, but I agree with Greg, it makes more
> sense to only set PRIMARY, not CLIPBOARD, in selcopy. Removing the
> clipboard-related lines from xsetsel seems to do the trick. I've
> attached a patch that does just that.
I agree here, it shouldn't modiy th
I will apply it. Thanks
Regards,
>> a new version of the patch? Also, I think such a patch should be
>> considered for inclusion at http://st.suckless.org/patches/. Thank you!
>
> There you go!
> Please let me know if it works. Apply with "git am".
>
I submitted a version of the patch to the wiki, and I supposed it already
w
>> I know this isn't a democracy, but I agree with Greg, it makes more
>> sense to only set PRIMARY, not CLIPBOARD, in selcopy. Removing the
>> clipboard-related lines from xsetsel seems to do the trick. I've
>> attached a patch that does just that.
>
> I agree here, it shouldn't modiy the CLIPBOA
Hi,
> char *name; /* string representation of op */
> - int type; /* from Tok.type */
> - int prec; /* precedence*/
> - int nargs; /* number of arguments (unary or binary) */
> - int lassoc; /* left
>
> For 32 Bit / 64 Bit machines (assuming int is 32 bit and char is 8 bit).
> Signed, unsigned makes no difference, assuming self-aligned (which is the
> case on x86, x86_64 and ARM):
>
If the char is signed you have to do bit sign extension, and for
example transform 0x81 into 0xff81. De
Applied, thanks.
>
> What if you're trying to test a program that requires network connectivity?
> It'd be good to be able to mock the networking stuff.
Write your program to deal with sdtdin and stdout, and comunicate
to the network using nc or inetd.
Regards,
>> Idea: modify `st` so it can change `cursorahape` dynamically, modify
>> `vis` to change the cursor on mode change.
> Maybe I'm crazy, but doesn't st already do this? Neovim is able to change the
> cursor when running in it.
There is a sequence to chnge the cursor shape, and I guess neovim
is us
> Yeah, I'd really like to get rid of boost, and possibly migrate to a
> lighter regex lib. The problem is that no currently available libs match
> the required feature set:
>
Write it. it is not so somplex to write a regex library.
Regards,
>> On Mar 3, 2016, at 11:00 AM, k...@shike2.com wrote:
>> Write it. it is not so somplex to write a regex library.
>>
>
> I'm guessing you started writing "simple", and corrected it to "complex". A
> Freudian Slip?
>
> ;)
I'm writing a compiler, so a regex library is extremely simple for me.
T
Hi,
> I'm thinking about removing support for all
> output formats except unified context from
> my diff(1) candidate. I want to hear your
> opinion.
I don't like the idea at all. I use some times
the ed output for some scripts. SCCS, RCS and
CVS use it to, so I think it is a very bad idea
to rem
Hi,
> Move focus to another window
> Expected: printed ^[[O in place of pending ^
> Actual result: nothing changed
I have tested it in dwm and git st and I receive a ^[[O.
Can you try it with dwm and send the results?
Regards,
Hi again,
> Test case for bug:
> Open empty terminal
> st -e tmux
> Activate focusing
> printf "\e[?1004h"
> Catch one focus event
>
> Move focus to another window
> Expected: printed ^[[O in place of pending ^
> Actual result: nothing changed
I mistook in my previos
Hi,
> I'm glad someone finally tried it.:)
I'm sorry. I am setting my network now, and I cannot read
the mail as fast as I used to do it. BTW, the another
maintainer shold have to answer, but he is a bit lazy ...
> However, I wonder how you could receive this focus-in event:
I mistook, I didn'
Hi again,
> We can try to test if we are receiving the event or not.
> The posibilities here are:
>
> - Mode is NotifyGrab
> - We do not receive the event
And the answer was: Any of them. We are not receiving the 1004
set mode sequence. I don't know why, but tmux think that is
better
> It's likely that tmux checks some specific terminfo properties
> before relaying 1004. If that's the case, we could temporarily
> override them inside .tmux.conf to confirm and then add to compiled
> st terminfo permanently.
Uhmmm, I dunno. As far as I know there is no terminfo
capability relate
Hi,
> I usually compile suckless software with tcc,
> but it fails at static linking, so I found myself
> cloning scc.
Scc is still a work in progress. It is far of being
completed and being able to compile programs.
> I changed PREFIX in config.mk to /usr/local and
> successfully installed it.
> I think compilers are way over my level, but it's a subject that interest me
> and
> clang is massive c++, gcc is nonstandard bloat, tcc doesnt seem sufficient,
> so I wanna help.
There are a lot of places were helping without having a big idea about
compilers. The scc driver is one of the pl
> I tried to ran cc2 from the directory, but it still hangs.
> Even if I simply try "./cc2". The same applies to
> cc2-amd64-sysv and cc2-i386-sysv.
yes, it is logical because cc2 reads the input data from stdin, so if
you execute it without piping into it the output of cc1 then it will
wait forev
> I forgot to ask, will scc be intended for
> building something big, say, GTK+ programmes,
> or maybe even the kernel? And what about
> inline assembly and compiling assembly code
> itself?
We don't want to follow all the extensions of GNU, this is for sure.
If you try to be compatible with GCC
> After I quit using shift-alt-q it's completely frozen, can't even switch
> between consoles.
Strange. As far as I know, it only can happen if the kernel itself
frozen, or the tty is in raw mode. I suppose the kernel is not
frozen, (we don't code so good code to be able to hang the kernel),
th
> There is no such thing as GNU syntax. gas supports both syntaxes;
> AT&T is the de facto standard.
I meant the GNU syntax for inline assembly, not the syntax of
the assembler itself. Something that I could accept is for example:
__asm("...");
or
__asm {
...
> inline assembly is irrelevant and not needed.
This is my way of thinking, because if you need asm, then your code is
not portable at all, and then it is better to move the asm to a
function and coded it directly in asm in a .as file. I am open to
discuss it, because I can understand a few cases
> .S or .asm actually, .as is ActionScript. If my two cents are counted,
I know several toolchains that use .as for assembler file.
Regards,
> but simplicity is more important. And yet if ye don't want to use GNU
> syntax for inline assembly, then people would have to
> write code to comply with scc rules.
I think this force them to write these parts in assembler directly,
and it opens the door to the few cases where it can be needed.
> Is it appropriate to use ANSI escape codes in the program rather than
> using something like tput or terminfo, or to just execute the "clear"
> command? Are the escape codes portable?
No, they are not. The problem here is that a lot of ppl in suckless
think that doesn't matter to keep the com
> clear(1) from ncurses also clears the scrollback buffer if the terminal
> supports it (see the manpage), that's not what you'd want here. As for
> portability, tput clear does `^[[2J^[[H` for basically everything:
Dimitris, if I send patches to remove these hard coded sequences by
calls to tput
> What would be the right way to do something like this?
Using the terminfo database.
Hi Markus,
> This change allows st to correctly render fonts given in point sizes,
> bringing its behavior in line with other software: dwm, dmenu, tabbed,
> etc:
>
> FC_DEBUG=1 st -f Terminus:size=10
I think __20h__ should take a look to this patch, he is the expert
in fonts (thankfully for me
1 - 100 of 113 matches
Mail list logo
