Hi,
On Sun, Dec 15, 2024 at 03:27:34PM +0100, Elie Le Vaillant wrote:
> Maybe I'll try re-sending those patches. Last time, we had a discussion
> on the scope of sbase. But I think some patches are still relevant nonetheless
> (the cron one in particular).
I was reading old mails and I found that
On Fri, Aug 09, 2024 at 05:58:09PM +0200, Страхиња Радић wrote:
> Дана 24/08/09 03:16PM, Roberto E. Vargas Caballero написа:
> > [...] Seting TERM directly is always 99.99% wrong and you can
> > get wrong results.
>
> So, setting TERM to st or st-256colors while using st is
On Fri, Aug 09, 2024 at 12:33:57AM +0200, Страхиња Радић wrote:
> st sets the default, but setting TERM overrides that and allows for
> some flexibility. But the testing has shown that TERM is irrelevant for
> this issue. Even with the OP's settings, Backspace in st+yash is
> working without issues
Hi,
On Fri, Aug 02, 2024 at 12:28:14PM -0600, Randy Palamar wrote:
> luons...@autistici.org wrote:
> > export TERM=3D'linux-s'
>
> Try leaving TERM="st-256color" and report the results. Terminal
> programs (such as a shell) behave very differently depending on
> what the value of TERM is. As a us
Hi,
On Wed, Mar 13, 2024 at 11:51:46PM +0100, Elie Le Vaillant wrote:
> I think this layout has a few problems:
>
> - we lose the meaningful separation that the sbase/ubase layout allowed,
> i.e the distinction
> between what is portable and what isn't. This _could_ be included as
> part of
Hi,
I have pushed a new branch called ubase-merge that has all
the files from ubase in the directory ubase of the root directory
in the repository. You can still see the full history of a file
in that directory using something like git log --follow.
I am thinking about the new layout, and for now
Hi,
After reading the opinion of the people in this thread,
I think the best option is to merge the sbase and ubase
repositories and having a mechanism in the build system
to select the set of tools to be included in the build.
The main drawback of this is that the build system will
be more comple
Hi,
While reviewing several patches for sbase adding new tools
some discussion happened and I thought it was better to move the
discussion here.
The patches raised a concern about what should be the scope of
sbase. The idea of sbase was to provide a minimal portable POSIX
base, while having ubase
Hi,
On Mon, Jan 22, 2024 at 08:11:42PM +, ruivlea wrote:
> After sbase commits:
> - 270ca025ce236885e3177cd7acfd2cfbdf6e36a5
> expr: don't evaluate matched substr as a number
> - e50d533d598dbe284e225e2ee52ed5f76a6e6f6a
> expr: treat expressions as strs until evaluation
>
> I fail to buil
Hi,
On Mon, Oct 23, 2023 at 10:52:11AM -0400, Sean MacLennan wrote:
> Basically, I agree that undo is hard.
Indeed. Ed gets undo by design keeping a history keeping a list of lines
and every modification implies a new list, so you can always undo (at least
once).
Regards,
Hi,
On Fri, Sep 22, 2023 at 05:08:15PM +0200, Mattias Andrée wrote:
>
> You can used make to run ./configure automatically, all you need to do is
> simply
> rename Makefile to makefile.in, let ./configure run `ln -s makefile.in
> makefile`
> and create a new file named Makefile containing:
>
>
Hi,
On Fri, Sep 22, 2023 at 07:27:25PM +0600, NRK wrote:
> $ make
> # ... builds st
> $ make CFLAGS="-g3 -fsanitize=address,undefined"
> # ... builds nothing because make doesn't take CFLAGS changes into
> account.
>
> I've seen some (hacky) ways to dump the flags into a
Hi,
On Fri, Sep 22, 2023 at 04:06:25PM +0600, NRK wrote:
> On Fri, Sep 22, 2023 at 11:18:47AM +0200, Страхиња Радић wrote:
> > ./build.sh
>
> But in short: you simply include any `.c` file into one. There's zero
and then you get name collisions because all the static symbols are
compiled in a si
Hi,
On Sun, Jul 30, 2023 at 05:18:35PM -0300, Spenser Truex wrote:
> A friend of mine was impressed with how quickly I was spamming the most
> based and redpilled links from this script and wanted me to publish it.
I have a simple script also based in dmenu for this task, but yours is much
more c
Hi,
On Tue, Feb 07, 2023 at 10:30:24AM +0200, Κρακ Άουτ wrote:
> As I mentioned, in practice I don't see any differences. I'm wondering if
> theoretically there could be some positive effect. People who know how
> exactly the code works are better suited to supply a definitive answer than
> me,
Hi,
On Sat, Aug 06, 2022 at 04:55:47AM +0600, NRK wrote:
> The font2 patch[0] on the wiki kinda enables fallback fonts. But I
> didn't like the fact that it adds a separate array `font2`. IMO you
> should be able to do this, similar to dmenu/dwm:
>
> static const char *fonts[] = {
>
Hi,
On Sat, Aug 06, 2022 at 01:31:16AM +0300, Plato Kiorpelidis wrote:
> Here is my branch: https://github.com/kioplato/st/tree/user-specified-fonts
Please, can you send a patch to show the changes instead of a link
a some random page?
Regards,
Hi,
On Sun, Jul 31, 2022 at 01:00:23AM +0200, Laslo Hunhold wrote:
> I must admit that I only copied the ar-ranlib-invocation likewise from
> what I found on the internet for my libraries, so even though I don't
> think it makes any difference (i.e. increases portability apart from
> standards-leg
Hi,
On Sun, Jul 31, 2022 at 12:59:23AM +0200, Laslo Hunhold wrote:
> Granted, it's one thing what a standard defines and another what is
> actually used in everyday life, but calling a standard-defined option
> as _less_ portable than an undefined historical artifact is a stretch.
-std=c99 is not
Hi,
On Wed, Jul 20, 2022 at 12:23:01PM +, Tom Schwindl wrote:
> ranlib(1) is, in fact, legacy. It was used to create symbol tables for
> archives
> before ar(1) was able to do that by itself.
> POSIX now specifies that ar(1) should create a symbol table by default, when
> there is at least on
Hi,
On Sat, Jul 09, 2022 at 11:39:37AM -0300, Renato Andrade Galvão wrote:
> So I have used surf, which I compile from your suckless repositories,
> along with the webkit lib package from debian. Currently I can't do
> anything better than this.
I use surf in this way too. It works but it has pro
Hi,
On Sat, Jul 02, 2022 at 11:08:44PM +0200, Robin Ekman wrote:
> Possibly this is at least partially an issue with urwid, cf.
> https://lists.suckless.org/dev/1410/23724.html
Uh, yeah I think it can be a problem related to urwid. Maybe a
good idea is trying to reproduce the problem in a dif
Hi,
On Tue, Jun 07, 2022 at 03:21:49PM +0200, David Demelier wrote:
> -include ${DEPS}
...
> And you're done. On a fresh directory the -include ${DEPS} will
> silently fail and rebuild everything. Then .d files will be generated
> and touching any file will rebuild exactly what should be.
>
> The
Hi,
On Fri, Mar 04, 2022 at 07:59:09AM +, Sime Ramov wrote:
> I didn't manage to get this going via `config.h`:
>
> /*
> * What program is execed by st depends of these precedence rules:
> * 1: program passed with -e
> * 2: scroll and/or utmp
> * 3: SHELL environment v
Hi,
I attach several patches for st (sorry, for different
reasons i cannot use git-send-email).
Regards,
>From d18c3a8c9eb82b2d135f4feb44060e6adb29428e Mon Sep 17 00:00:00 2001
From: "Roberto E. Vargas Caballero"
Date: Fri, 10 Apr 2020 22:26:12 +0200
Subject: [PATCH 3/4] Fi
On Mon, Sep 24, 2018 at 10:26:52PM +0600, Eon S. Jeon wrote:
> I think fontconfig is to blame here. It?s what st is using to find fallbacks.
> It?s just that we don?t want such highly sophisticated fallback mechanism. We
> all love simple infallible code, so that we can always blame users. ;)
>
On Sun, Sep 23, 2018 at 10:07:45PM +0200, Silvan Jegen wrote:
> The author of the fork also maintains a simple Wayland drawing library[2]
> (which is also used in the Wayland st fork) and a Wayland compositor[3]
> library.
The author is the current maintainer of sbase.
On Sun, Sep 23, 2018 at 05:20:27PM +, sylvain.bertr...@gmail.com wrote:
> On Sun, Sep 23, 2018 at 09:22:00AM -0700, AR Garbe wrote:
> > On Sun, 23 Sep 2018 at 06:37, wrote:
>
> And has st a wayland backend or fork?
Yes, Michael Forney wrote it.
On Mon, Sep 24, 2018 at 09:35:11AM +0200, Hiltjo Posthuma wrote:
> > I don't think we should throw out support for a feature that more than a
> > billion
> > people on the planet rely on. That doesn't mean that we can't rethink how we
> > go about supporting that feature though.
Of course no, I a
On Sun, Sep 23, 2018 at 01:49:01PM +0200, Hiltjo Posthuma wrote:
> For st there was a X11/terminal code split to support Wayland, automated
> testing of terminal emulator code. Now there are abstractions but it is not
> useful. Maybe it should be reverted also?
The abstractions in st are really sm
Hi,
On Sat, Sep 22, 2018 at 09:10:37PM -0700, AR Garbe wrote:
> I'm really at a point to consider forking dwm and dmenu to simply rely
> on X11 as it used to be, perhaps with going the extra mile to remove
> Xinerama support as well and to rely on single headed setups.
I feel the same about st.
I am sorry, but st hasn't super powers, and it cannot do impossible things.
Control mask the upper bits of the key (key & 0x1F) while shift clears the
6th bit, so ctrl+shift+p = (p & ~0x20) & 0x1f. As you can see, it is
impossible to differentiate between ^p and ^P.
Regards,
,p
> I wrote a patch[0] for mg which sort of adds Unicode support a while
I wrote a 1 line editor for st [1]. It allows you to edit a page of text
and then print it to stdout or to some other file using -o.
Regards,
[1] http://lists.suckless.org/dev/1401/19894.html
> If someone can confirm that the man page should be updated to reflect
> the new keybindings, I will submit a patch of st.1. The man page still
> has "Alt".
Yeah, the man page should be updated.
Regards,
> purposes. Both approaches are better than writing your own configuration
> parser.
You can write your parser configurator using:
scanf(" %40s = %40s", key, value);
Regards,
> scrollback buffer built into st itself. Instead of mandating the use
> of tmux et al, I would rather put a helper tool into the st repo, that
> works as a basic shell wrapper process (no detaching). It would
It can be a separated tool integrated with st, in the same way
than utmp. I am going to
> scrollback buffer built into st itself. Instead of mandating the use
> of tmux et al, I would rather put a helper tool into the st repo, that
> works as a basic shell wrapper process (no detaching). It would
It can be a separated tool integrated with st, in the same way
than utmp. I am going to
> scrollback buffer built into st itself. Instead of mandating the use
> of tmux et al, I would rather put a helper tool into the st repo, that
> works as a basic shell wrapper process (no detaching). It would
It can be a separated tool integrated with st, in the same way
than utmp. I am going to
> I'd love to see scrollback also. I've played around a tiny bit with dumping
If you want to work in the backscroll tool I can help you [1].
Regards,
[1] http://ix.io/1vQQ
> this is a very good point! Even if this was approached with an external
> tool you probably just start implementing st again with all the bells
> and whistles, let alone the fact that you need a separate program to
> make st work as desired in a normal setup within a window manager.
No, you don'
> I don't think that's a typo, just a short form for "hey, watch out,
> remember we still have `i == minrow` from the last loop here!". ;)
Uh, you are right. Sadly I read your comment after pushing it.
Best regards,
> Totally inconsistent crap. Basically you have to stop using stupid
> programs that care about terminal width. It's the only real solution.
>
> I'm not even gonna talk about this curses bullshit. I don't care about
> integrating such useless programs into scrollback.
Indeed. Programs that look t
> I can live without scrollback, but what I dislike about st now is
> that it loses lines when I just shuffle my terminals around with
> dwm. When I have 3 windows (1 master, 2 stack) and move terminal
As I have said in the previous mail, I can help you to write the tool
to solve this problem.
B
Hi,
Thank you for your contribution, but after thinking about it
I think I am going to reject this patch. There are important
reasons why st hasn't a scrollback buffer, and the same reasons
apply to this patch. There are so many cases and so many
interactions that is better to keep this logic out
> Use Ctrl-Sfhit-C, not Alt-Shift-C, like the other terminal emulators use.
If all the people agree I am going to change the defaul keybinding to
CTRL+SHIFT+C, because it is an impossible sequence in the terminal
world, and it is not hiding any valid combination that can be used
by the programs ru
Hi,
On Tue, Jan 19, 2016 at 01:56:56PM -0200, Brad Luther wrote:
> Roberto Vargas - it works in a perfect way! I have one question. Why
> didn't it work by default on ash? Is ash a sucky shell? Should I file
> a bug? Because by what I understand this is a hack, right? Not the
> ideal way. But so f
On Tue, Jan 19, 2016 at 10:02:01AM -0200, Brad Luther wrote:
> I'm using ash and it's not working out of the box.
> I'll see if I can find a patch or then I'll try using mksh, but I
> really like ash.
> Thanks for the tips.
The patch is not so complex ...
Can someone put it in the wiki?
diff --g
Hello,
On Sun, Jan 17, 2016 at 12:20:11PM -0200, Brad Luther wrote:
> Roberto Caballero
The short form of my name is Roberto Vargas. Read [1].
> so I understand that the behavior that makes
> content be lost is because it is less hungry on memory? If that's the
> case, I think this is acceptable
Hi,
On Fri, Jan 15, 2016 at 10:53:30AM -0200, Brad Luther wrote:
> 1 - when you open st and some strings printed (try 'ls' for example),
> upon resizing it down and resizing it back up, the content is lost.
> Shouldn't the printed stuff remain there? This is an annoyance for
> when I, for example,
On Thu, Jan 07, 2016 at 01:56:13PM -0500, Greg Reagle wrote:
> I find it a real pain to work with things like man page source and markdown
> source and so forth because of the extra steps of making the output/object
> format.
>
You can use something like [0], or use gv, which automatically reload
On Fri, Jan 01, 2016 at 12:15:18PM +, Dimitris Papastamos wrote:
> At the end of the day, a bug is a bug irrespective of how it was introduced.
>
> I will have a look at the patch tomorrow.
My opinion is that all the code imported should be removed and
written in house.
For the same reason we don't care about the state of
the buffer in clearundo() we can reset modflag in
clearbuf(), because after calling it we don't want
to know anything about the previous state.
---
ed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ed.c b/ed.c
index 751e97
-s flag disables such warnings.
---
ed.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ed.c b/ed.c
index 1cf0d60..7e7fbb6 100644
--- a/ed.c
+++ b/ed.c
@@ -623,7 +623,8 @@ doread(char *fname)
}
inject(s);
}
- printf("%zu\n", cnt)
When we discard the content of an undo buffer
is because we don't need it anymore, and it means
that we don't care about the modify state of the buffer
so we can reset the modflag in clearundo(), and
remove this assignation each time clearundo() is called.
---
ed.c | 3 +--
1 file changed, 1 inser
These funcction initializes the scratch buffer, and in case of
having a file name parameter it loads the file in the scratch.
It also fixes a problem before this version, where the saved
filename was not set when the file didn't exist.
---
ed.c | 32 ++--
1 file changed
On Fri, Nov 20, 2015 at 10:52:28AM -0200, Marc Collin wrote:
> Hello, I want to report a segfault when using st.
>
> Steps to reproduce:
> 1) open st
> 2) "vim file"
> 3) Press "Enter"
>
> Around 30% of times this results in a crash.
> Here's the message st gives:
>
> erresc: unknown sequence ES
> hmm, it was originally added with
> b2db58c2a05168257ee4e4b941f0533c6dde2a10 to make the window title the
> status line.
> The window title does become the status line, but sandy keeps spitting
> stuff out while I'm editing, so I'll take a printed terminal status
> line over spittle.
> Is there a
On Sun, Oct 04, 2015 at 01:45:58PM -0400, shua lloret wrote:
> When I try to run sandy with TERM set as any of st,st-16color,st-256color,
> the title line is not shown, and is instead printed out randomly to stdout
> as I try to insert text. This happens when running "TERM=st sandy" in rxvt,
>
>
> > - am I correct in thinking that we install manual pages, but currently no
> > 'man' program to read them?
>
> I'd propose using the OpenBSD man tools.
>
I propose to use neatroff, that is a new implementation from scratch of
the full troff toolchain. I know that the main use of troff tod
Hi,
> > Wrong again:
> >
>
> Nope, fish works, though it turns out we bound the other escape
> manually.
> > xterm (debian testing):
> >
> > $ tput rmkx
> > ^[[F (End key)
> > ^[[H (Home key)
> > $ tput smkx
> > ^[OF (End key)
> > ^[OH (Home key)
It means you are wrong. Fish doesn't work b
Hi,
> That's not what I'm talking about. Of course a tone of terminals have
> smkx defined, but fish currently doesn't send it and works on (as far as
> I know) anything but st.
>
> In other words:
>
> If you launch fish in { konsole, xterm, gnome-terminal, linux in-kernel
> VTs, iTerm2, ... }
Hi,
> Our question is probably better stated as the following:
>
> st seems to e.g. send "[P" for delete instead of the '\E[3;2~' in
> terminfo (which fish does use), unless we explicitly do the equivalent
> of "tput smkx". This not only applies to delete, but a few other key
> combinations as we
> How do you know that smkx should be '\E[?1h\E='? Is there any
> documentation about it?
http://www.vt100.net/docs/vt100-ug/chapter3.html#SM
http://www.vt100.net/docs/vt100-ug/chapter3.html#DECKPAM
There are two issues related to keyboard configuration in the terminal
world:
- configura
On Tue, Sep 01, 2015 at 10:22:52PM +0800, Pickfire wrote:
> Hi, it seems that st does some terminal codes abnormally[1].
>
> What is the reason for st's key codes to be different from the other
> terminals? Is st following some standards?
>
> [1]:
> https://github.com/fish-shell/fish-shell/issue
> >mosh mentions some "UTF8 terminal mode", which is different
> >from "ISO 2022" and doesn't even have G0-3. It's all mentioned
> >in the link[1].
> >
> >[1]: https://www.cl.cam.ac.uk/~mgk25/unicode.html#term
This is the personal opinion of the author of the article. Can
you send me a link to th
On Sun, Jul 26, 2015 at 11:58:20PM +0200, Teodoro Santoni wrote:
> >
> > so why scc?
> >
>
> Once upon a time 8cc was a linux x86 64bit C compiler and scc a unix Z80 C
> compiler. Why what?
Yes, it is true. When I began scc (at that moment kcc), the problem I had
was that compilers for z80 was
Hi,
We are doing deep changes of style in st, and it means the style will
not be ready until 2 or three weeks, so if you have to update some of your
patches in the wiki, then it is better wait a bit (mainly because in other
case you will have to update your patch several times).
Thank yo
On Thu, Jul 09, 2015 at 10:23:45PM +0200, S. R. Gal wrote:
> > st -e sh -c 'tmux a -d || tmux'
>
> Both, above and st -e ''tmux a -d || tmux'', seem to work but they
> result with the following error messages:
>
Theoretically you can also omit -e in both cases.
Regards,
On Wed, Jul 08, 2015 at 09:30:47PM +0200, Markus Wichmann wrote:
> On Wed, Jul 08, 2015 at 12:00:35PM +0200, Roberto E. Vargas Caballero wrote:
> >
> > > We are ignoring return value of dup(), so just remove it.
> >
> >
> > From dup(3):
> >
> >
> In fact, the only thing that can be done here is:
>
> close(STDIN_FILENO);
> dup(cmdfd);
> + close(cmdfd);
> stty();
>
> because we are not going to use this file descriptor anymore,
> but I think we will not have a significant improvement.
> We are ignoring return value of dup(), so just remove it.
>From dup(3):
The dup() system call creates a copy of the file descriptor oldfd,
using the lowest-numbered unused descriptor for the new descriptor.
> if((cmdfd = open(opt_line, O_RDWR)) < 0)
>
Hi,
On Wed, Jul 01, 2015 at 09:40:41AM -0700, Weng Xuetian wrote:
> Some fcitx user reaches me about input method issue, and I surprisingly found
> that input method is broken again in st because I have fixed it once.
Yes. Maybe it is my fault because I didn't tested this part of st.
>
> The ne
On Fri, Jun 12, 2015 at 09:43:41PM +0200, Quentin Rameau wrote:
> > The font size is actually a double and can have non-integer values when
> > fonts are specified in point size instead of pixel size. Update zoom
> > functions to preserve the fractional component in a float. Some small
> > precisio
Hi,
On Sun, May 31, 2015 at 12:01:20PM -0400, s j wrote:
> printf "\e[38;2;255;255;255mTRUECOLOR"
Thanks for the bug report. I think this bug is not related
to the other problem reported (the incorrect data size for
fg and bg), but if you can try after reverting the commit
7ab6c92 it will be usef
Hi,
> But fg is defined as a ushort. [4]
>
> typedef struct {
> Rune u; /* character code */
> ushort mode; /* attribute flags */
> ushort fg;/* foreground */
> ushort bg;/* background */
>
Hi,
On Thu, May 28, 2015 at 01:55:20AM -0400, Michael Reed wrote:
> > This was mostly a 1-1 conversion, although mandoc(1) -Tlint and igor(1)
> > prompted moving AUTHORS down (among other small things).
> > Punctuation was also made more consistent to match sbase.
This is a topic we have discusse
Hi,
On Sat, May 23, 2015 at 03:43:08PM +0800, Ivan Tham wrote:
> >>I typed ``Ctrl + Space`` in st but it seems like it doesn't work. Fcitx
> >>is a Chinese IME for XIM.
> >
> >As far as I know no IME works with st (please correct me if I am
St has code to deal with input methods. I cannot test it
Applied, thanks.
Hi,
I have applied the patches 'Small bugfix for makeglyphfontspecs
cass in drawregion' by suigin, and 'set selection to IDLE on clear' by
v4hn. Thanks!!!
Regards,
Applied, thanks!
Applied, thanks!
On Mon, May 04, 2015 at 07:38:40PM +, non...@inventati.org wrote:
> It handles the case when Button1 is released. In this case either
> selcopy is called and there is no need to set dirty flag as selection is
> already rendered, or selclear is called, and it sets dirty flag by
> itself.
Ok, ca
Hi,
>
> In Plan 9, when one executes a graphical program from a terminal
> window it will take over that window, so that running a graphical text
> editor like Sam from a terminal is not so different from running a
> line editor. This was one of my favourite things from the Plan 9 GUI.
Indeed.
>
> Sorry, there aren't actually two extra padding bytes, even though the
> struct is two bytes longer in length. Don't know what I was thinking.
> Time for a coffee.
>
The problem with this kind of things is they depend too much
of the implementations, because you can have the padding or
not, s
>
> For what it's worth, I agree with this approach. uint32_t is
> guaranteed (since C99) to be just the right size to hold all Unicode
> points (as well as their UTF-8 representation) without wasting (too
> much) space.
But uint32_t is not guaranteed to be present in all the implementations,
alt
> > It is no casuality they added this rule to the standard. They added
> > it because is the idiomatic way of running over an array in C. Of
> > course CS teachers that liked pascal don't teach it anymore when
> > they were forced to move to C, but it is the best way for experienced
> The code in
Applied, thanks.
> - tsetdirt(sel.nb.y, sel.ne.y);
Can you explain why is not needed?
Regards,
Applied, thanks.
Applied, thanks.
Applied, thanks.
I prefer the current code, because the responsability of each function
is better designed. In the current code selsnap does all the work related
to SNAP_LINE and SNAP_WORD, but in your commit, a part is done in
selnormalize and other part in selsnap.
Regards,
Applied, thanks.
On Thu, Apr 30, 2015 at 09:23:15PM +, noname wrote:
> It is equal to term.col-1 in any case.
Can you explain why xt is equal to term.col-1 in any case? I cannot see
it from your comments. Please, could you extend explanations in your
commits?
Regards,
> @@ -753,14 +752,13 @@ selsnap(int *x, int *y, int direction) {
>
> gp = &term.line[newy][newx];
> delim = ISDELIM(gp->u);
> - if(!(gp->mode & ATTR_WDUMMY) && (delim != prevdelim
> + if(!(gp->mode & ATTR_WDUMMY)
> - if (sel.type == SEL_RECTANGULAR)
> - return;
...
> + if(sel.type == SEL_REGULAR) {
> + int len = tlinelen(sel.nb.y);
This patch inverts the logic. In the current code the function returns
when sel.type == SEL_RECTANGULAR, but in your code it test len only
when
Applied, thanks.
Hi,
I am going to apply the original patch. I think there is
space for improvements, so new patches are welcome.
Regards,
> Non-maintainers like us can't push to the repository. Mailing list only.
The idea is to use the mailing list as a peer review mechanism. I am
one of the maintainer of st and I also send the patches first to the
mailing list to see the opinion of another hackers.
Regards,
1 - 100 of 762 matches
Mail list logo
