Re: [dev] [st] [PATCH] Replace close and dup with dup2.

[Roberto E. Vargas]

  Second I don't have any warning with any of the compilers I use.
 
 Good for you. How is that in any way relevant? There is no prescribed
 compiler, is there? Also, the idea with this sort of distribution model
 is that the users also catch things that the maintainer won't.

I wanted to say that I test with all the mainstream compilers and
any of them generated the warning, so maybe is a distribution modified
version of gcc which generates the warning. Ey, guys can you send
who see this warning and what OS and compiler you are using?

Regards,

Re: [dev] Odds and ends (2/2): $XEMBED

[Roberto E. Vargas Caballero]

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.

 My suggestion is that we use an environment variable, say $XEMBED, to
 store the XID to which a spawned graphical process should make an
 embedding request. The program would check the environment, and
 whether it is a foreground process in its terminal (getpgrp() ==
 tcgetpgrp(STDOUT_FILENO)). If $XEMBED is set and it is a foreground
 process then it would make an X embed request.

The idea is good, but it means that you have to modify all the programs
to accept this new feature. If you want to experiment with this idea
you can try to add this variable in st and read it in surf.

Regards,

Re: [dev] [ST] [PATCH] Changed type for UTF-32 codepoints from long to uint_least32_t

[Roberto E. Vargas Caballero]

Applied, thanks!

Re: [dev] [ST] [PATCH] Clean up xdraws and optimize glyph drawing with non-unit kerning values

[Roberto E. Vargas Caballero]

Applied, thanks!

Re: [dev] [st] [PATCH 2/3] Move tresize comments around.

[Roberto E. Vargas Caballero]

Applied, thanks.

Re: [dev] [st] [PATCH 3/3] Remove 'slide' variable in tresize.

[Roberto E. Vargas Caballero]

Applied, thanks.
---BeginMessage---
---
 st.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/st.c b/st.c
index 51bd40c..ce2646e 100644
--- a/st.c
+++ b/st.c
@@ -2770,7 +2770,6 @@ tresize(int col, int row) {
int i;
int minrow = MIN(row, term.row);
int mincol = MIN(col, term.col);
-   int slide = term.c.y - row + 1;
bool *bp;
TCursor c;
 
@@ -2785,13 +2784,13 @@ tresize(int col, int row) {
 * tscrollup would work here, but we can optimize to
 * memmove because we're freeing the earlier lines
 */
-   for(i = 0; i  slide; i++) {
+   for(i = 0; i = term.c.y - row; i++) {
free(term.line[i]);
free(term.alt[i]);
}
-   if(slide  0) {
-   memmove(term.line, term.line + slide, row * sizeof(Line));
-   memmove(term.alt, term.alt + slide, row * sizeof(Line));
+   if(i  0) {
+   memmove(term.line, term.line + i, row * sizeof(Line));
+   memmove(term.alt, term.alt + i, row * sizeof(Line));
}
for(i += row; i  term.row; i++) {
free(term.line[i]);
-- 
1.8.4

---End Message---

Re: [dev] [st] [PATCH 1/2] Do not use switch for fork() call.

[Roberto E. Vargas Caballero]

I don't understand this patch. The switch-fork is a common idiom
and I don't know why you think it should be changed.

Regards,

Re: [dev] [st] [PATCH 1/2] Use do..while in window mapping loop.

[Roberto E. Vargas Caballero]

Applied, thanks.

Re: [dev] [st] [PATCH 2/2] Remove unnecessary XFilterEvent call.

[Roberto E. Vargas Caballero]

Applied, thanks.

Re: [dev] [st] [PATCH 2/2] Simplify loop condition.

[Roberto E. Vargas Caballero]

Applied, thanks.

Re: [dev] [st] [PATCH 1/3] tresize: move for loop outside if

[Roberto E. Vargas Caballero]

Applied, thanks.

Re: [dev] [st] [PATCH 4/3] tresize: remove unnecessary if

[Roberto E. Vargas Caballero]

 The assembly is rather irrelevant in this case. Let's write the code
 the way it is most understandable and clear.

Yeah, I totally agree with you here.

 I'd remove the if, memmove is equivalent to a non-op when the offset
 is 0.

But the problem now is to decide what is more understable. I prefer
an explicit if, because it alerts to the programmer about this case, but
the no-if version is shorter and without indentation, that usually
means that it is more understable.

The fact you can pass a size=0 to memcpy and memmove is one
of the most stupid things you can find in the C standard, because
it is illogical and remove a lot of optimizations in some processors,
so I don't know if honour this rule is something we should do.

Regards,

Re: [dev] [st] [PATCH 2/3] Move tresize comments around.

[Roberto E. Vargas Caballero]

Applied, thanks.

Re: [dev] [st] [PATCH 1/3] Fix typo.

[Roberto E. Vargas Caballero]

Applied, thanks,

Re: [dev] [st] [PATCH 3/3] Simplify tmoveto.

[Roberto E. Vargas Caballero]

Applied, thanks.

Re: [dev] [st] [PATCH] Remove useless if in tstrsequence.

[Roberto E. Vargas Caballero]

Applied, thanks.

Re: [dev] [st] [PATCH] Remove useless if in tstrsequence.

[Roberto E. Vargas Caballero]

Applied, thanks.

Re: [dev] [st] [PATCH 1/2] Do not use switch for fork() call.

[Roberto E. Vargas Caballero]

After asking in the IRC channel, all the people thought like me.
Both are correct, and the fork-switch is a very common idiom,
which makes easier to see what is the objective of the code, so
I will not apply this patch.


Regards,

Re: [dev] [st] [PATCH 1/3] Remove 'titles' variable.

[Roberto E. Vargas Caballero]

Applied, thanks.

Re: [dev] [st] [PATCH 2/3] Remove -e option. Use -- instead.

[Roberto E. Vargas Caballero]

I think we should keep the -e option, because xterm has this option and
it is used in a lot of places. I like the idea of executing all the remaining
parameters, but I think we should admit both forms.

Regards,

Re: [dev] [st] [PATCH 4/3] tresize: remove unnecessary if

[Roberto E. Vargas Caballero]

Applied, thanks.

Re: [dev] [st] [PATCH 3/3] Remove old TODO entry.

[Roberto E. Vargas Caballero]

Applied, thanks.

Re: [dev] [st] [PATCH 4/3] tresize: remove unnecessary if

[Roberto E. Vargas Caballero]

 This should be reverted.


Yeah, I agree. I also think we should put some comment saying that
if i ==  0 then it is possible to have some of the undefined cases
where src == NULL || dst == NULL || src == dst.

Some volunter to write the patch?

Re: [dev] [st] [PATCH] Fixed STR sequence termination condition

[Roberto E. Vargas Caballero]

 ascii code may only be checked for characters that have length equal to
 1, not width equal to 1

I think they are equivalent, but I like more the 'len' versin, so
I will apply it.

Thanks,

Re: [dev] [st] [PATCH] Fixed STR sequence termination condition

[Roberto E. Vargas Caballero]

 'width' is how much columns the character takes. It is one for 'ß' as

Uhmmm, you are right (it is a shame for me because I wrote this part ^^!!!).

Re: [dev] [sbase][PATCH] wc: Print number of bytes by default

[Roberto E. Vargas Caballero]

Hi,

   size_t nc = 0, nl = 0, nw = 0;
  
   while ((rlen = efgetrune(c, fp, str))) {
 - nc += (cmode == 'c') ? rlen :
 + nc += (cmode == 'c' || cmode == 0) ? rlen :
 (c != Runeerror) ? 1 : 0;
   if (c == '\n')
   nl++;

a '?' inside of other '?' is not a good idea. I think the expression
is complex enough to require an if-else.

Regards,

Re: [dev] [st] question about 24-bit color support

[Roberto E. Vargas Caballero]

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  */
 } Glyph;
 
 Since a ushort can only hold 16 bits, I don't see how this can possibly work.

You are right, it is a bug introcuded in 7ab6c92. This patch tried to
reduce the memory consumption, because it uses only values between 0-15,
and sometimes 0-255, but in the case of real color we need 32 bits.
So we have to revert that commit.

Regards,

Re: [dev] [st] segfault with true color output

[Roberto E. Vargas Caballero]

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 useful for me.

Thanks,

Re: [dev] [st][PATCH] Preserve pixelsize fractions in font defaultsize.

[Roberto E. Vargas Caballero]

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
  precision is lost, but the zoom reset function gets very close to the
  original size and the Arg union remains 32 bits wide.
 
 I actually made a similar patch a few days ago and gave it on IRC.
 I'm taking this occasion to post it here!

I'm going to apply this patch. Thanks!!!

Regards,

Re: [dev] [st] [PATCH] Convert manual to mdoc

[Roberto E. Vargas Caballero]

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 discussed in the past, and our conclusion
was that every suckless project will decide what format is going
to use for man pages. For example, sbase and ubase use mdoc, but
in the case of st, we decided to keep man format.

Regards,

Re: [dev] Input method under break (again) under st

[Roberto E. Vargas Caballero]

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 new issue is caused by commit 2937b05aed9cee8d6651cd806d31682a853c773 
 which removes a XFilterEvent call.

Are you sure this is the commit?

$ git fetch
$ git log -n1
commit bdd649a10289ade364f3deab3bbf6ee3169d67ca
Author: Quentin Rameau qu...@quinq.eu.org
Date:   Sun May 31 12:26:11 2015 +0200
do not truncate font size when zooming
$ git log -n1 2937b05aed9cee8d6651cd806d31682a853c773
fatal: ambiguous argument '2937b05aed9cee8d6651cd806d31682a853c773': unknown 
revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git command [revision...] -- [file...]'

 XFilterEvent is required to be called after you using XOpenIM, this is not 
 unnecessary. It does not only filter the key event, but some clientmessage 
 for 
 input method as well.

I can see it. We must add a comment to avoid this kind of problems in the 
future.

Regards,

Re: [dev] scc vs 8cc

[Roberto E. Vargas Caballero]

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 not confortable to me. I used hitech C
for msdos using dosemu, or the other possibility was sdcc, which at that
moment generated very bad code for z80. Another objective I had was
to be able of executing the compiler in a z80 host environment, so any of
the options I had at this moment were not good for me.

scc becomes a suckless project now, and we converted it
into a multi targered compiler, which will be able (some day ...)
of generating code for z80/386 and amd64.

There is another difference to, that is the source code style.  I
can say that 8cc, although well written, doesn't match the style
and quality of suckless projects.

Regards,

Re: [dev] [sandy] [st] Title incorrectly shown if TERM=st

[Roberto E. Vargas Caballero]

> 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 another app that uses the status line terminal capability
> ("hs" in terminfo) so I can test it?
> I don't know enough ncurses to whip up a test.

Today is common to set the title of your terminal with
the shell prompt, althought in this case ppl usually hardcode
the sequence in PS1.


Regards,

Re: [dev] [sandy] [st] Title incorrectly shown if TERM=st

[Roberto E. Vargas Caballero]

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,
>  and does not happen when running "TERM=xterm sandy" in st.

Stop doing that. TERM variable is the way user can say to terminfo
which is the terminal he is using, and terminfo will use this
information to print the correct escape sequence for the user
terminal. If you lie to terminfo then you will have problems, like
the problem you are commenting here. If you are using st, then set
TERM to st, st-16color or st-256color, but if you are using rxvt
then you must not use them.

Re: [dev] [PATCH 1/1] remove useless dup()

[Roberto E. Vargas Caballero]

 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)
   die(open line failed: %s\n, strerror(errno));
   close(STDIN_FILENO);
 - dup(cmdfd);
   stty();

So, it means we are assigning cmdfd to stdin. If you see the code in stty()
you will see:

void
stty(void)
{
char cmd[_POSIX_ARG_MAX], **p, *q, *s;
size_t n, siz;

if((n = strlen(stty_args))  sizeof(cmd)-1)
die(incorrect stty parameters\n);
memcpy(cmd, stty_args, n);
q = cmd + n;
siz = sizeof(cmd) - n;
for(p = opt_cmd; p  (s = *p); ++p) {
if((n = strlen(s))  siz-1)
die(stty parameter length too long\n);
*q++ = ' ';
q = memcpy(q, s, n);
q += n;
siz-= n + 1;
}
*q = '\0';
if (system(cmd) != 0)
perror(Couldn't call stty);
}

and then 'system(cmd)' takes cmdfd as stdin. If you remove
tha call to dup(), then stty command will not have the serial line
as stdin, and then it will not have the serial line as controlling
terminal, and the stty execution will affect the terminal where
the user launched st.

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.


Regards,

Re: [dev] [PATCH 1/1] remove useless dup()

[Roberto E. Vargas Caballero]

 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.
 

Sorry, this is wrong, cmdfd is used in several other places.

Re: [dev] [PATCH 1/1] remove useless dup()

[Roberto E. Vargas Caballero]

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):
  
 The  dup()  system  call  creates  a copy of the file descriptor 
  oldfd,
 using the lowest-numbered unused descriptor for the new descriptor.
  
  
 
 Yes, but can't dup() fail? Shouldn't we at least check or that?

No, it cannot. From dup(2):
ERRORS
 EBADF
  oldfd isn't an open file descriptor, or newfd is out of
  the allowed range for file descriptors.

 EBUSY
  (Linux only) This may be returned by dup2()  or  dup3()
  during a race condition with open(2) and dup().

 EINTR
  The dup2() or dup3() call was interrupted by a  signal;
  see signal(7).

 EINVAL
  (dup3()) flags contain an invalid value.  Or, oldfd was
  equal to newfd.

 EMFILE
  The process already has  the  maximum  number  of  file
  descriptors open and tried to open a new one.

Any of them apply here.

I'm beginning to think that maybe it is a good idea to change the
call to dup to dup2, not due to the lateral effect or to the error
handling, due to we have calls to dup2 in the same function and we
will also remove a line of code, so I will accept such patch.

Regards,

Re: [dev] st -e

[Roberto E. Vargas Caballero]

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,

[dev] St style changes

[Roberto E. Vargas Caballero]

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 you,

Re: [dev] [st] Stuck in ISO 2022 locking escapes and Evil escape sequences

[Roberto E. Vargas Caballero]

> >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 the standard where it is said?. The problem
with terminals is they stop their evolution at the beginning
of the 90, so there is no standard way of doing utf8 stuff.

> I thought suckless uses UTF-8? Most applications[1] are already using UTF8
> now, so does suckless need to use 'ISO 2022' or 'utf8'?

The utf-8 sequence that the page talks about is only a common
sequence that some terminals accepts, but it is not standard at
all, and there is no concept of utf-8 or ISO 2022 modes. St
implements a vt200 compatible terminal with only ASCII support
(without the upper part of the code table), and it has an
extension that is utf8. You don't have to send any sequence
to activate any 'mode'.

Regards,

Regards,

Re: [dev] [st] Terminal abnormal key codes

[Roberto E. Vargas Caballero]

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, ... } your keys work, without smkx.

Wrong again:

xterm (debian testing):

$ tput rmkx
^[[F  (End key)
^[[H  (Home key)
$ tput smkx
^[OF  (End key)
^[OH  (Home key)

> > The question here is, why do you want to write a shell knowing
> > it has bugs and it will not be able of running in all the possible
> > (current or future) terminals?
> 
> The only term I currently know of that has a problem with fish is st.

Did you test all the terminals in the terminfo definition?

There are near of 400 terminals. Maybe you don't care and you think
terminals is an obsolete part of the unix world, and maybe you are
right, but then you should think why you are writing a shell. You
can try with something like Unity shell which has no historical
baggage. But if you write an Unix terminal application you have to
follow the terminfo definition, and it clearly says what you have
to do.

You  can say all the times that works in the 5 or 7 terminals
you have tested, that I can find dozen of terminals where it will not
work. I can say you that your shell will not work in a real vt220 
terminal, for example.

Regards,

Re: [dev] [st] Terminal abnormal key codes

[Roberto E. Vargas Caballero]

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 because you have to
manyally hardcoded some values, that will work only in some terminals.
And you say that fish works? ...

> This means we might be able to simplify the key bindings if we do the
> smkx dance.

No, it means your program is wrong. We have here two programs, one
which follows the standard (st), and another that doesn't follow
the standard (fish), and you are trying the compliant program
changes its behaviour only because your code is so ugly you are
afraid of broken something if you modify the key match procedure.
I don't want to imagine how is written your code.

I will change the behaviour of st when POSIX changes its definition
and removes smkx/rmkx. Meanwhile fish has a bug. All the other
suckless developers I have asked about this question agree with me
in this point.

Please don't waste our time and fix your bugs.

Regards,

Re: [dev] [st] Terminal abnormal key codes

[Roberto E. Vargas Caballero]

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/issues/2309#issuecomment-136678774

Yes, st follows terminfo(5). Every terminal has different keys,
so, I don't know what you mean with st using different keys.
You can see the differences between xterm an linux vt:

$ infocmp xterm linux

comparing xterm to linux.
comparing booleans.
ccc: F:T.
eo: F:T.
km: T:F.
mc5i: T:F.
npc: T:F.
xon: F:T.
comparing numbers.
cols: 80, NULL.
lines: 24, NULL.
ncv: NULL, 18.
comparing strings.
acsc: '``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~', 
'+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260i\316j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376'.
cbt: '\E[Z', NULL.
civis: '\E[?25l', '\E[?25l\E[?1c'.
clear: '\E[H\E[2J', '\E[H\E[J'.
cnorm: '\E[?12l\E[?25h', '\E[?25h\E[?0c'.
cvvis: '\E[?12;25h', '\E[?25h\E[?8c'.
dim: NULL, '\E[2m'.
flash: '\E[?5h$<100/>\E[?5l', '\E[?5h\E[?5l$<200/>'.
ich1: NULL, '\E[@'.
indn: '\E[%p1%dS', NULL.
initc: NULL, 
'\E]P%p1%x%p2%{255}%*%{1000}%/%02x%p3%{255}%*%{1000}%/%02x%p4%{255}%*%{1000}%/%02x'.
invis: '\E[8m', NULL.
is2: '\E[!p\E[?3;4l\E[4l\E>', NULL.
kDC: '\E[3;2~', NULL.
kEND: '\E[1;2F', NULL.
kHOM: '\E[1;2H', NULL.
kIC: '\E[2;2~', NULL.
kLFT: '\E[1;2D', NULL.
kNXT: '\E[6;2~', NULL.
kPRV: '\E[5;2~', NULL.
kRIT: '\E[1;2C', NULL.
kb2: '\EOE', '\E[G'.
kbs: '^H', '^?'.
kcub1: '\EOD', '\E[D'.
kcud1: '\EOB', '\E[B'.
kcuf1: '\EOC', '\E[C'.
kcuu1: '\EOA', '\E[A'.
kend: '\EOF', '\E[4~'.
kent: '\EOM', NULL.
kf1: '\EOP', '\E[[A'.
kf13: '\E[1;2P', '\E[25~'.
kf14: '\E[1;2Q', '\E[26~'.
kf15: '\E[1;2R', '\E[28~'.
kf16: '\E[1;2S', '\E[29~'.
kf17: '\E[15;2~', '\E[31~'.
kf18: '\E[17;2~', '\E[32~'.
kf19: '\E[18;2~', '\E[33~'.
kf2: '\EOQ', '\E[[B'.
kf20: '\E[19;2~', '\E[34~'.
kf21: '\E[20;2~', NULL.
kf22: '\E[21;2~', NULL.
kf23: '\E[23;2~', NULL.
kf24: '\E[24;2~', NULL.
kf25: '\E[1;5P', NULL.
kf26: '\E[1;5Q', NULL.
kf27: '\E[1;5R', NULL.
kf28: '\E[1;5S', NULL.
kf29: '\E[15;5~', NULL.
kf3: '\EOR', '\E[[C'.
kf30: '\E[17;5~', NULL.
kf31: '\E[18;5~', NULL.
kf32: '\E[19;5~', NULL.
kf33: '\E[20;5~', NULL.
kf34: '\E[21;5~', NULL.
kf35: '\E[23;5~', NULL.
kf36: '\E[24;5~', NULL.
kf37: '\E[1;6P', NULL.
kf38: '\E[1;6Q', NULL.
kf39: '\E[1;6R', NULL.
kf4: '\EOS', '\E[[D'.
kf40: '\E[1;6S', NULL.
kf41: '\E[15;6~', NULL.
kf42: '\E[17;6~', NULL.
kf43: '\E[18;6~', NULL.
kf44: '\E[19;6~', NULL.
kf45: '\E[20;6~', NULL.
kf46: '\E[21;6~', NULL.
kf47: '\E[23;6~', NULL.
kf48: '\E[24;6~', NULL.
kf49: '\E[1;3P', NULL.
kf5: '\E[15~', '\E[[E'.
kf50: '\E[1;3Q', NULL.
kf51: '\E[1;3R', NULL.
kf52: '\E[1;3S', NULL.
kf53: '\E[15;3~', NULL.
kf54: '\E[17;3~', NULL.
kf55: '\E[18;3~', NULL.
kf56: '\E[19;3~', NULL.
kf57: '\E[20;3~', NULL.
kf58: '\E[21;3~', NULL.
kf59: '\E[23;3~', NULL.
kf60: '\E[24;3~', NULL.
kf61: '\E[1;4P', NULL.
kf62: '\E[1;4Q', NULL.
kf63: '\E[1;4R', NULL.
khome: '\EOH', '\E[1~'.
kind: '\E[1;2B', NULL.
kri: '\E[1;2A', NULL.
kspd: NULL, '^Z'.
mc0: '\E[i', NULL.
mc4: '\E[4i', NULL.
mc5: '\E[5i', NULL.
nel: NULL, '^M^J'.
oc: NULL, '\E]R'.
rin: '\E[%p1%dT', NULL.
rmacs: '\E(B', '\E[10m'.
rmcup: '\E[?1049l', NULL.
rmkx: '\E[?1l\E>', NULL.
rmm: '\E[?1034l', NULL.
rmpch: NULL, '\E[10m'.
rs1: '\Ec', '\Ec\E]R'.
rs2: '\E[!p\E[?3;4l\E[4l\E>', NULL.
setb: 
'\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m', NULL.
setf: 
'\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m', NULL.
sgr: 
'%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m',
 
'\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;%?%p7%t;8%;%?%p9%t;11%;m'.
sgr0: '\E(B\E[m', '\E[0;10m'.
smacs: '\E(0', '\E[11m'.
smcup: '\E[?1049h', NULL.
smkx: '\E[?1h\E=', NULL.
smm: '\E[?1034h', NULL.
smpch: NULL, '\E[11m'.
u8: '\E[?1;2c', 

Re: [dev] [st] Terminal abnormal key codes

[Roberto E. Vargas Caballero]

> 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:

- configuration of cursor keys
- configuration of keypad

These keys have two ways of working, in ascii mode or in application mode.
In ascii mode they generate the ascii value expected by the terminal to
perform the desired functiona (for example in the case of DELETE it sends
ESC [ P which is the sequence to delete current character), and in application
mode they generate some sequence which allows one program to identify the key.
If a program needs to know if a key was pressed it has to activate the 
application
mode before of testing anything, or the terminal can generate the ASCII sequence
if the terminal was in ASCII mode.

> >If your program does not use terminfo(3)
> >(http://linux.die.net/man/3/setupterm), then is broken.
> >About the problems with DELETE, please take a look to
> >the FAQ (section Why doesn't the Del key work in some programs?)
> 
> I had read the FAQ again and again, but I just doesn't understand why some 
> applications
> doesn't work in st but works in other terminal, the FAQ just says that
> the applications are buggy.

Yes, because it means your program is not setting the correct mode,
and assume that DELETE is going to generate the same sequence in both
modes. Again, taken from terminfo(5):


If the terminal has a keypad that transmits codes when the keys
are pressed, this information can be given. Note that it is not
possible to handle terminals where the keypad only works in
local (this applies, for example, to the unshifted HP 2621 keys).
If the keypad can be set to transmit or not transmit, give these
codes as smkx and rmkx. Otherwise the keypad is assumed to
always transmit.

Maybe is difficult to understand it, but I will say again: IF THE KEYPAD
CAN BE SET TO TRANSMIT OR NOT TRANSMIT, GIVE THESE CODES AS SMKX AND RMKX.
OTHERWISE THE KEYPAD IS ASSUMED TO ALWAYS TRANSMIT.

St gives values for smkx and rmkx, so if an application wants to read
the keypad it must print these sequences before. You can take the values
of these sequences usging the terminfo database, 'tput smkx' in the shell,
or the variable smkx after calling setupterm() if you link your C program
with terminfo.

Regards,

Re: [dev] [st] Terminal abnormal key codes

[Roberto E. Vargas Caballero]

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 well, like insert or ctrl-up.
> 
> Of course this is stated in the FAQ, but the question is _why_ is it
> this way and is it possible to change that?

Because there are two ways of using the terminal, in ASCII mode and in
application mode. Maybe you only use the terminal in application mode,
but some of us (mainly me) use the terminal for other kind of things,
connecting to non POSIX machines, over serial lines, and in these cases
we use this mode. St is not only a Unix place where ppl can write unix
commands (take a look to -l switch of st).

> From our perspective st is the only terminal (we've found at least) that
> behaves this way - every other term (like xterm, konsole or linux VTs)
> seems to not need this and just always sends the sequences specified in
> terminfo.

You are wrong:

$ curl http://www.catb.org/esr/terminfo/termtypes.ti.gz 2>/dev/null |
 gunzip |
 sed 's/#.*//g' |
 grep -c smkx
111

There are 111 definitions in the official terminfo definition which
use smkx.  Maybe you don't use any of them, but some of use use
some of them.  For example I have a physical vt500 that I use as
console in several of my servers, and it has smkx sequence. Are
you saying me that I am going to be able to use fish in this
terminal? and only because you are too lazy to follow the terminfo
standard?

> There's two things we can do on our side - do "tput smkx" and "tput
> rmkx" either only in st or always (which I don't know if it'll break
> stuff elsewhere) or bind both kinds of sequences st sends, neither
> solution being _great_.

It should not break anything. If the terminal does not define smkx
you will not print anything, and if the terminal define it is because
it needs the sequence. All the application which use curses work
without problems in st when they try to match any key. mainly because
curses follows the terminfo specification perfectly.

> So: Is there a rationale for that decision and would you consider
> changing it?

Changing the key assignation is st is very simple, all the table
is in config.h file. In the past we have changed the key assignation
(we transformed backspace key in a delete key), and it is something
we can do again, although it is going to be a pain in the ass
because we already updated the definition of st in the official
terminfo definition.  I will admit a patch like this if all the
another suckless developer agree, which I don't think will happen
(I will continue with my custom key assignation), but even in this
case you must fix your shell, because if you don't follow the
terminfo rules it will not be able to run in a lot of different
terminals.

The question here is, why do you want to write a shell knowing
it has bugs and it will not be able of running in all the possible
(current or future) terminals?

Regards,

Re: [dev] Stali RC

[Roberto E. Vargas Caballero]

> 
> > - 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 today is
man pages, and it can be solved using OpenBSD mandoc, but I feel that
a unix alike system without full support for troff is not unix alike.


https://github.com/litcave/neatroff
https://lists.gnu.org/archive/html/groff/2013-07/msg1.html
http://litcave.rudi.ir/neatroff.pdf

I think it is sane enough to be included in stali.


Regards,

Re: [dev] [st] Reporting a Segmentation fault

[Roberto E. Vargas Caballero]

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 ESC 0xFD '.'
> Segmentation fault
> 

I pushed a change to fix the problem with cat /dev/urandom,
but I think it was a different problem that you problem you
discovered. Can you confirm me if you still have the problem?

Regards,

[dev] [sbase][PATCH 2/4] ed: Reset modflag in clearbuf()

[Roberto E. Vargas Caballero]

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 751e973..7dc80c6 100644
--- a/ed.c
+++ b/ed.c
@@ -322,7 +322,7 @@ clearbuf()
free(zero);
zero = NULL;
scratch = csize = idxsize = lastidx = curln = lastln = 0;
-   lastln = curln = 0;
+   modflag = lastln = curln = 0;
 }
 
 static void
-- 
2.1.4

[dev] [sbase][PATCH 3/4] ed: add init()

[Roberto E. Vargas Caballero]

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, 18 insertions(+), 14 deletions(-)

diff --git a/ed.c b/ed.c
index 7dc80c6..1cf0d60 100644
--- a/ed.c
+++ b/ed.c
@@ -629,12 +629,6 @@ doread(char *fname)
fp = NULL;
if (fclose(aux))
error("input/output error");
-
-   if (savfname[0] == '\0') {
-   modflag = 0;
-   clearundo();
-   strcpy(savfname, fname);
-   }
 }
 
 static void
@@ -1359,6 +1353,23 @@ edit(void)
}
 }
 
+static void
+init(char *fname)
+{
+   size_t len;
+
+   if (setjmp(savesp))
+   return;
+   setscratch();
+   if (!fname)
+   return;
+   if ((len = strlen(fname)) >= FILENAME_MAX || len == 0)
+   error("incorrect filename");
+   memcpy(savfname, fname, len);
+   doread(fname);
+   clearundo();
+}
+
 int
 main(int argc, char *argv[])
 {
@@ -1380,15 +1391,8 @@ main(int argc, char *argv[])
signal(SIGINT, sigintr);
signal(SIGHUP, sighup);
signal(SIGQUIT, SIG_IGN);
-   if (!setjmp(savesp)) {
-   setscratch();
-   if (*argv) {
-   if (strlen(*argv) >= FILENAME_MAX)
-   error("file name too long");
-   doread(*argv);
-   }
-   }
 
+   init(*argv);
edit();
 
/* not reached */
-- 
2.1.4

[dev] [sbase][PATCH 1/4] ed: Move modflag=0 to clearundo()

[Roberto E. Vargas Caballero]

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 insertion(+), 2 deletions(-)

diff --git a/ed.c b/ed.c
index 623c6b4..751e973 100644
--- a/ed.c
+++ b/ed.c
@@ -247,6 +247,7 @@ clearundo(void)
free(udata.vec);
udata.vec = NULL;
newcmd = udata.nr = udata.cap = 0;
+   modflag = 0;
 }
 
 static void
@@ -342,7 +343,6 @@ setscratch()
error("input/output error in scratch file");
relink(k, k, k, k);
clearundo();
-   modflag = 0;
 }
 
 static void
@@ -1211,7 +1211,6 @@ repeat:
deflines(curln, curln);
doread(savfname);
clearundo();
-   modflag = 0;
break;
default:
error("unknown command");
-- 
2.1.4

[dev] [sbase][PATCH 4/4] ed: Don't show size of files in no diagnosistic mode

[Roberto E. Vargas Caballero]

-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);
+   if (optdiag)
+   printf("%zu\n", cnt);
 
aux = fp;
fp = NULL;
-- 
2.1.4

Re: [dev][ubase][PATCH] fix several problems in dd

[Roberto E. Vargas Caballero]

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.

Re: [dev] Auto-preview man pages

[Roberto E. Vargas Caballero]

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 the file
when it is modified (watch option).

[0] http://ninetimes.cat-v.org/tips/2009/07/17/0-realtime-troff/

Re: [dev] [bugs] st clears up upon resize and other little things

[Roberto E. Vargas Caballero]

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. It's a good reason.

If you want to change it you can modify tresize() and call to realloc
only if the new size is bigger than some variable where you store
the maximum until now. It is very simple patch and it can be a place
in the wiki.

> On the geometry being a multiple of the font, you say that "In the
> past there was some work to avoid this situation adding pagging pixel
> lines, and it generated a lot of problems". But ACE said there's still
> a way touse it like that, by setting resizehints = False in config.h.
> Would this bring problems?

Uhmmm. I didn't know this part. You should ask to Christoph Lohmann
because he is who maintains this part.

> Matthew of Boswell - thanks for the explanation and zsh patch. Too bad
> I use ash. It's a pain in the ass not to be able to use Delete on st.
> I'll see if I can adapt your zsh patch. Also, by what I understand,
> this will never be provided by default because it's a fundamental
> problem outside st?

You can read the thread in [2], and you will understand why I am not
going to change this behaviour in the git version. Again the patch is
very simple, you only have to modify the values in the array Key located
in config.def.h. You can see that there are two rows for XK_KP_Delete and
XK_Delete for XK_ANY_MOD. If you join them in only one row them you will
be able to run suck programs inside of a suckless terminal. If you do
it you can add the patch to the wiki and we can add a link in the FAQ,
but again, my suggestion is send a patch to the programs that are
wrong.

Regards,

[1] http://perez.cs.vt.edu/twolastnames
[2] http://comments.gmane.org/gmane.comp.misc.suckless/20370 

Re: [dev] [bugs] st clears up upon resize and other little things

[Roberto E. Vargas Caballero]

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, 'ls' a folder, open an image that I found inside
> so dwm automatically tile st and the image, and then I close the
> image. Now the st window will not show all the content of the folder
> from when I did 'ls'. The files/folders previously printed that upon
> resize were covered are now gone and I have to 'ls' again.

St resizes the line buffers each time that the geometry of the terminal
change, then the content of the space out of the new size is lost.
It is done by a design decision. In fact it is easier the another
behaviour and not resize anything and hungry memory that you are not
using. If you really want this behaviour you can get with any terminal
session manager (dvtm, tmux, screen ...).


> 2- st is the only program on dwm that doesn't cover the entire screen
> when opening it in fullscreen tile mode. There's always a line on the
> bottom of the screen to which st refuses to expand.

This kind of situations can happen because the geometry of st must be
a multiply of the size of your font. In the past there was some work
to avoid this situation adding pagging pixel lines, and it generated
a lot of problems. Keep it simple.

> 3- the delkey patch[0] isn't working for me. As I understand it should
> make 'Delete' erase the current the highlighted character, but it does
> nothing. All I did was clone the repo and apply the patch (which is
> simple enough). Are there any users successfully using this patch?
> What could I have done wrong?

No, the objective of that patch is to change the ascii value generated
when you press backspace and delete, because at this moment, for some
very stupid historic problems, the majority of terminals generate
a DEL when you press backspace, instead of generating a BACKSPACE.
All this stuff is really well explained in the FAQ. The problem you
are haaving is that you are using bad programs that don't follow the
POSIX standard. You should send a patch to them.

Terminal keyboard have two modes, keypad mode and ascii mode. When you
are in ascii mode the terminal generates the correct ASCII code which
will generate the function labelled in the key. In the case of St it
generates ^[P, which is the sequence that st understands to delete the
current character. When the keyboard is in keypad mode it generates
a sequence thought to be an unique identifier of the key. In the
terminfo definition of the terminals you can find which is the
sequence for every special key when they are in keypad mode, and it
means that a program that wants to check against these code must to
change the mode of the terminal to keypad before reading. There is a
terminfo definition to do this. Again everything is explain in the
FAQ.

You can try to fix the problems of the other programs, or write
a patch of st that make it to send the same key in both modes and
upload it to the wiki. I will not do it because is giving the reason
to the bad written programs, instead of fixing them. But if you want
to do it and upload it to the wiki we can put the link to the patch
in the FAQ.

Regards,

Re: [dev] [bugs] st clears up upon resize and other little things

[Roberto E. Vargas Caballero]

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 far it works really well!

I already answered this question a few mails ago. I am going to
quote my own mail:

- You can read the thread in [1], and you will understand why I am not
- going to change this behaviour in the git version. Again the patch is
- very simple, you only have to modify the values in the array Key located
- in config.def.h. You can see that there are two rows for XK_KP_Delete and
- XK_Delete for XK_ANY_MOD. If you join them in only one row them you will
- be able to run suck programs inside of a suckless terminal. If you do
- it you can add the patch to the wiki and we can add a link in the FAQ,
- but again, my suggestion is send a patch to the programs that are
- wrong.

I can see you didn't read the FAQ, so I'm going to quote the FAQ to:

- ## Why doesn't the Del key work in some programs?
- 
- Taken from the terminfo manpage:
- 
- If the terminal has a keypad that transmits codes when the keys
- are pressed, this information can be given. Note that it is not
- possible to handle terminals where the keypad only works in
- local (this applies, for example, to the unshifted HP 2621 keys).
- If the keypad can be set to transmit or not transmit, give these
- codes as smkx and rmkx. Otherwise the keypad is assumed to
- always transmit.
- 
- In the st case smkx=E[?1hE= and rmkx=E[?1lE>, so it is mandatory that
- applications which want to test against keypad keys send these
- sequences.
- 
- But buggy applications (like bash and irssi, for example) don't do this. A 
fast
- solution for them is to use the following command:
- 
- $ printf '\033[?1h\033=' >/dev/tty
- 
- or
- $ tput smkx
- 
- In the case of bash, readline is used. Readline has a different note in its
- manpage about this issue:
- 
- enable-keypad (Off)
- When set to On, readline will try to enable the
- application keypad when it is called. Some systems
- need this to enable arrow keys.
- 
- Adding this option to your .inputrc will fix the keypad problem for all
- applications using readline.
- 
- If you are using zsh, then read the zsh FAQ
- :
- 
- It should be noted that the O / [ confusion can occur with other keys
- such as Home and End. Some systems let you query the key sequences
- sent by these keys from the system's terminal database, terminfo.
- Unfortunately, the key sequences given there typically apply to the
- mode that is not the one zsh uses by default (it's the "application"
- mode rather than the "raw" mode). Explaining the use of terminfo is
- outside of the scope of this FAQ, but if you wish to use the key
- sequences given there you can tell the line editor to turn on
- "application" mode when it starts and turn it off when it stops:
- 
- function zle-line-init () { echoti smkx }
- function zle-line-finish () { echoti rmkx }
- zle -N zle-line-init
- zle -N zle-line-finish
- 
- Putting these lines into your .zshrc will fix the problems.

The problem with ash is they don't use the smkx sequence as they should.
You can send a mail to them and see if they want to fix their bug.

Regards,

[1] http://comments.gmane.org/gmane.comp.misc.suckless/20370

Re: [dev] [bugs] st clears up upon resize and other little things

[Roberto E. Vargas Caballero]

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 --git a/config.def.h b/config.def.h
index fd09d72..8450f42 100644
--- a/config.def.h
+++ b/config.def.h
@@ -245,8 +245,7 @@ static Key key[] = {
{ XK_KP_Delete, ControlMask,"\033[3;5~",+1,0,0},
{ XK_KP_Delete, ShiftMask,  "\033[2K",  -1,0,0},
{ XK_KP_Delete, ShiftMask,  "\033[3;2~",+1,0,0},
-   { XK_KP_Delete, XK_ANY_MOD, "\033[P",   -1,0,0},
-   { XK_KP_Delete, XK_ANY_MOD, "\033[3~",  +1,0,0},
+   { XK_KP_Delete, XK_ANY_MOD, "\033[3~",   0,0,0},
{ XK_KP_Multiply,   XK_ANY_MOD, "\033Oj",   +2,0,0},
{ XK_KP_Add,XK_ANY_MOD, "\033Ok",   +2,0,0},
{ XK_KP_Enter,  XK_ANY_MOD, "\033OM",   +2,0,0},
@@ -300,8 +299,7 @@ static Key key[] = {
{ XK_Delete,ControlMask,"\033[3;5~",+1,0,0},
{ XK_Delete,ShiftMask,  "\033[2K",  -1,0,0},
{ XK_Delete,ShiftMask,  "\033[3;2~",+1,0,0},
-   { XK_Delete,XK_ANY_MOD, "\033[P",   -1,0,0},
-   { XK_Delete,XK_ANY_MOD, "\033[3~",  +1,0,0},
+   { XK_Delete,XK_ANY_MOD, "\033[3~",   0,0,0},
{ XK_BackSpace, XK_NO_MOD,  "\177",  0,0,0},
{ XK_Home,  ShiftMask,  "\033[2J",   0,   -1,0},
{ XK_Home,  ShiftMask,  "\033[1;2H", 0,   +1,0},

Re: [dev] [st/dwm] Alt-Shift-C and Mod1-Shift-C

[Roberto E . Vargas Caballero]

> 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 running in the terminal. In fact, I think all the
shortcuts should be allocated in that space.

Regards,

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

[Roberto E . Vargas Caballero]

> 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.

Best regards,

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

[Roberto E . Vargas Caballero]

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 of the terminal.
Some person already talked about the draft that Evan Gates wrote
for an external scrollback buffer tool, which would also solve
this problem. I would like to do some work in that tool, but I am
really, really busy. I cannot maintain st, write scc and write that
tool.

If there is some person interested I can guide him for that tool,
which is a very basic tool. It only has to create a pseudo tty
and keep the content of the lines and intercept some sequence
to rewrite the content of the terminal when the user wants to
scroll. The prototype of Evan demostrated that it is feasible.


Best regards,

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

[Roberto E . Vargas Caballero]

> purposes. Both approaches are better than writing your own configuration
> parser.

You can write your parser configurator using:


scanf(" %40s = %40s", key, value);

Regards,

Re: [dev] [st] [PATCH 1/2] Fix commented out code

[Roberto E . Vargas Caballero]

> 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,

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

[Roberto E . Vargas Caballero]

> 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't have to implement anything about vt, you only
have to keep a list of lines, nothing else. When the user wants
to scrollback you move your pointer n lines back and then print
everything to the terminal. It is a very simple tool. You can take
a look to the draft that Evan wrote here in [1].


Regards,


[1] http://ix.io/1vQQ

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

[Roberto E . Vargas Caballero]

> 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

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

[Roberto E . Vargas Caballero]

> 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 repeat again, if someone wants to work
in the tool [1] I can guide him. I have repeated the same sentence
in the last 4 mails, because a lot of ppl is talking about that
but nobody writes a simple line of code. Please, begin to work in
the tool or stop this discussion (this last sentence is not for you
Anselm, if for everybody in this mailing list).

Regards,

[1] http://ix.io/1vQQ

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

[Roberto E . Vargas Caballero]

> 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 repeat again, if someone wants to work
in the tool [1] I can guide him. I have repeated the same sentence
in the last 4 mails, because a lot of ppl is talking about that
but nobody writes a simple line of code. Please, begin to work in
the tool or stop this discussion (this last sentence is not for you
Anselm, if for everybody in this mailing list).

Regards,

[1] http://ix.io/1vQQ

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

[Roberto E . Vargas Caballero]

> 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 repeat again, if someone wants to work
in the tool [1] I can guide him. I have repeated the same sentence
in the last 4 mails, because a lot of ppl is talking about that
but nobody writes a simple line of code. Please, begin to work in
the tool or stop this discussion (this last sentence is not for you
Anselm, if for everybody in this mailing list).

Regards,

[1] http://ix.io/1vQQ

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

[Roberto E . Vargas Caballero]

> 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 the width of the terminal sucks. I really
hate when ps cut the argument list and I have to use ps whatever | cat
to see it.

And, yes if you have cursor addressing is stupid even think about
scrollback. What state do you expect when you go back in the history?
before of after moving the cursor and rewriting? what attributes?.
Sadly, this is the same problem with copy/pasting tabs from a terminal.

printf "\t\b\ba"

What do you have to copy there? a tab and after the tab a a?, or convert
any blank space between characters to spaces?. You can see that the only
solution consisten solution is the second and sadly means that you cannot
copy tabs from one terminal to other.

Regards,

Re: [dev] st: different keybindings not in man page

[Roberto E . Vargas Caballero]

> 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,

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

[Roberto E . Vargas Caballero]

> 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

[dev] Moving scc

[Roberto E. Vargas]

Hi,

It is long time since I began to collaborate with suckless,
I think almost 6 years. In that time I send patches for a lot
of different projects, but the majority of them were for st,
becoming eventually the maintainer of it. But this mail is not
about all these projects, it is about scc, the main target of
my patches in the last 3 years. Scc began as kcc, some years
before joining to suckless, as a personal project, that due to
my implication with suckless I renamed to scc and I moved into
suckless.org, becoming an official suckless project since that
moment.

A lot of different things happened since that moment, some of
them in my life, and some of them in the suckless community.
Due to these changes, I don't feel scc as a suckless project
anymore, and as project founder, main contributor (I think
I wrote about 95% of the code) and maintainer, I have taken
the decision of moving scc away from suckless.

After this mail, the new official community where scc is going
to be developed is bitreich [1], and you can find the new
repository in [2].

Best regards,
Roberto Vargas


[1] gopher://bitreich.org
[2] gopher://bitreich.org/1/scm/scc/log.gph

Re: [dev] [st] How to make it distinguish Control-p from Control-P?

[Roberto E. Vargas Caballero]

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,

Re: [dev] [st] shift + backspace

[Roberto E. Vargas Caballero]

,p

Re: [dev] freetype2/fc pain

[Roberto E. Vargas Caballero]

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 am not talking about that. Only saying that freetype was a 
really
bad idea and we should try to search something different.

> I agree its useful. (Complex) fall-back font support has been on my mind also.
> An idea could be of instead of supporting fallback fonts we could write some
> font merge script (pre-runtime).

Yes, this is as also a good idea. Maybe we can implement some table
to relate glyph and font.

Regards,

Re: [dev] freetype2/fc pain

[Roberto E. Vargas Caballero]

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.

Re: [dev] freetype2/fc pain

[Roberto E. Vargas Caballero]

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.

Re: [dev] freetype2/fc pain

[Roberto E. Vargas Caballero]

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. ;)
> 
> (Note that we still need fontconfig for loading and configuring fonts. It 
> still makes our lives easier.)
> 
> Also, I believe freetype is essential. st has one visual component and that?s 
> text. st should render it good. At least that?s what people will consider 
> suck-less.

We can go to simple x fonts, is much simpler. Suckless is about simplicity of 
the code.

Re: [dev] freetype2/fc pain

[Roberto E. Vargas Caballero]

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 also think that adding freetype was a really
bad idea. Maybe we should begin to think about going one step back.

> I barely use multihead setups and I don't give a f*ck about

Well, multihead is a very common setup today, but as always it is only
a question of being used to don't use it.

> anti-aliasing. This whole freetype2 move seems utterly wrong. I didn't
> see it as critical before, but now I more and more conclude it has to
> go.

Indeed.

Roberto.

Re: [dev] freetype2/fc pain

[Roberto E. Vargas Caballero]

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 small and I think in this case was more
about splitting the big file than introducing abstractions. The functions
that are called from st.c are the same before or after the split.

[dev] Patches for st

[Roberto E. Vargas Caballero]

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] Fix style issue

---
 st.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/st.c b/st.c
index 81973ee..2ecf8f3 100644
--- a/st.c
+++ b/st.c
@@ -366,7 +366,8 @@ static const char base64_digits[] = {
 char
 base64dec_getc(const char **src)
 {
-   while (**src && !isprint(**src)) (*src)++;
+   while (**src && !isprint(**src))
+   (*src)++;
return **src ? *((*src)++) : '=';  /* emulate padding if string ends */
 }
 
-- 
2.26.0

>From 9a847d761579f7bec8a24ddcf8034d7600c9b4a8 Mon Sep 17 00:00:00 2001
From: "Roberto E. Vargas Caballero" 
Date: Fri, 10 Apr 2020 22:50:23 +0200
Subject: [PATCH 4/4] Add terminfo entries for backspace mode

St used to use backspace as BS until the commit 230d0c8, but due
to general lack of knowledge of lusers, we moved to the most common
configuration in linux to avoid answering the same question 3 times
per month. With the most common configuration we have a backspace
that returns a DEL, and we have a Delete key that doesn't return a
DEL character neither a BS.

When dealing with devices connected using a serial line (or even
with Plan9) it is more common Backspace as BS and Delete as DEL. For
this reason, st is not always the best tool when you talk with a
serial device.

This patch adds new terminfo entries for Backspace as BS and Delete
as DEL. A patch for confg.h is also added, to make easier switch
between both configurations.
---
 configs/backspace.diff | 30 ++
 st.info| 10 ++
 2 files changed, 40 insertions(+)
 create mode 100644 configs/backspace.diff

diff --git a/configs/backspace.diff b/configs/backspace.diff
new file mode 100644
index 000..cdbf4f4
--- /dev/null
+++ b/configs/backspace.diff
@@ -0,0 +1,30 @@
+--- config.h   2020-04-11 09:22:38.386974190 +0200
 config.h   2020-04-11 09:47:50.267056817 +0200
+@@ -64,7 +64,7 @@
+ static int bellvolume = 0;
+ 
+ /* default TERM value */
+-char *termname = "st-256color";
++char *termname = "st-bs-256color";
+ 
+ /*
+  * spaces per tab
+@@ -265,7 +265,7 @@
+   { XK_KP_Delete, ShiftMask,  "\033[2K",  -1,0},
+   { XK_KP_Delete, ShiftMask,  "\033[3;2~",+1,0},
+   { XK_KP_Delete, XK_ANY_MOD, "\033[P",   -1,0},
+-  { XK_KP_Delete, XK_ANY_MOD, "\033[3~",  +1,0},
++  { XK_KP_Delete, XK_ANY_MOD, "\0177",+1,0},
+   { XK_KP_Multiply,   XK_ANY_MOD, "\033Oj",   +2,0},
+   { XK_KP_Add,XK_ANY_MOD, "\033Ok",   +2,0},
+   { XK_KP_Enter,  XK_ANY_MOD, "\033OM",   +2,0},
+@@ -333,8 +333,7 @@
+   { XK_Delete,ShiftMask,  "\033[2K",  -1,0},
+   { XK_Delete,ShiftMask,  "\033[3;2~",+1,0},
+   { XK_Delete,XK_ANY_MOD, "\033[P",   -1,0},
+-  { XK_Delete,XK_ANY_MOD, "\033[3~",  +1,0},
+-  { XK_BackSpace, XK_NO_MOD,  "\177",  0,0},
++  { XK_Delete,XK_ANY_MOD, "\0177",+1,0},
+   { XK_BackSpace, Mod1Mask,   "\033\177",  0,0},
+   { XK_Home,  ShiftMask,  "\033[2J",   0,   -1},
+   { XK_Home,  ShiftMask,  "\033[1;2H", 0,   +1},
diff --git a/st.info b/st.info
index 78ffd30..1df490b 100644
--- a/st.info
+++ b/st.info
@@ -220,3 +220,13 @@ st-meta-256color| simpleterm with meta key and 256 colors,
smm=\E[?1034h,
rs2=\E[4l\E>\E[?1034h,
is2=\E[4l\E>\E[?1034h,
+
+st-bs| simpleterm with backspace as backspace,
+   use=st,
+   kbs=\010,
+   kdch1=\177,
+
+st-bs-256color| simpleterm with backspace as backspace and 256colors,
+   use=st-256color,
+   kbs=\010,
+   kdch1=\177,
-- 
2.26.0

>From 6d02a2710b3ecdd1874c3a34c5d9fc2e19747c73 Mon Sep 17 00:00:00 2001
From: "Roberto E. Vargas Caballero" 
Date: Fri, 10 Apr 2020 22:25:46 +0200
Subject: [PATCH 2/4] ttyread: Test for EOF while reading tty

When
If a read operation returns 0 then it means that
we arrived to the end of the file, and new reads
will return 0 unless you do some other operation
such as lseek(). This case happens with  usb-232
adapters when they are unplugged.
---
 st.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/st.c b/st.c
index 5f2352a..81973ee 100644
--- a/st.c
+++ b/st.c
@@ -823,17 +823,24 @@ ttyread(void)
int

Re: [dev] ST 'loginShell'

[Roberto E. Vargas Caballero]

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 variable
>  * 4: value of shell in /etc/passwd
>  * 5: value of shell in config.h
>  */
> 
> Tried options 1, 3 and 5, but even if some of them work, they are
> low in precedence list... Any ideas?
> 

You can also try option 2 with utmp. It creates an entry in utmp
and it executes a login shell.


Regards,

Re: [dev] getting rid of cmake builds

[Roberto E. Vargas Caballero]

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:
> 
>   .POSIX:
>   .DEFAULT:
>   ./configure
>   $(MAKE) -f makefile $@

I used this technique in scc at the beginning (in my case for inclusion
dependencies, not for configurE), but it was a bit confusing for people
and then I switched it to other solution that I think is  worse.  Maybe
it is time to go back and use this solution again.

Regards,

Re: [dev] getting rid of cmake builds

[Roberto E. Vargas Caballero]

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 single translation unit.

> problem adapting to a different compiler or compiler flags. In fact,
> it's *easier* to do than a makefile (which I also said on my previous

easier than in a Makefile? In a Makefile (in a good well written) you
only have to pass a different CFLAGS value, but in the shell script you
have to edit the shell script itself.

>   $ gcc -o exe src.c
>   $ clang -o exe src.c   # no need to "clean" anything
> 
> Doing cross-platform is also easy by just making your core application
> "platform-agonistic" and having the "platform layer" provide platform
> specific functionality. For example, here's a hypothetical
> `app-windows.c` file:

that is not about build systems, is about software design:

OBJS = main.o src-$(SYS).o
SYS = posix

app: $(OBJS)
$(CC) -o $@ $(LDFLAGS) $(OBJS)

if you compile in posix, then you only use `make`, if you compile in windows
you use `make SYS=windows`.

Makefiles are really simple, but for some reason that I don't understand
people like to write horrible and complex Makefiles.

Regards,

Re: [dev] getting rid of cmake builds

[Roberto E. Vargas Caballero]

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 file to trigger
> re-build more reliably. But as I've said, it's a solution to a self-made
> problem.

I don't think a build system should care about it. The build system should
care only about building what is required with the set of flags that you pass
in the command line. This is derivated from the UNIX principle "Mechanisms,
not policy" [1]. What happens if I want to apply the set of flags to only
one file? If you want to build everything with a different set of flags just
clean and build. This is very well summarized in the quote "Unix was not
designed to stop you from doing stupid things, because that would also stop
you from doing clever things" [2]

> There is no shell script involved. You invoke the compiler directly with
> whatever flags you please. There's no need to track dependencies or
> flags.

Did you see any flags in my example? If I want debug symbols then I just
write `make CFLAGS=-g`. and it knows what is the compiler to be used.
I don't want to know anything about compiler or set of options, I just
want to execute make and get the binary.

> And this is no longer the 50s, we have enough memory to build a couple
> thousand line of code without *requiring* splitting things into multiple
> intermediate object files to avoid going OOM (even with bloated
> compilers like gcc/clang with optimization enabled).

That is just another version of "it works for me". Don't assume anything
about build hosts. If you don't like it you are free of using jave instead,
I am pretty sure java programmers would like more this kind of things.

> Incremental builds are not free. And for small projects, the complexities
> they bring is (IMO) much higher compared to the benefits (which are
> either non-existent or negligible for small projects).

Do you think the Makefile that I wrote was complex? It was just a list of
objects. Can you explain me where is the complexity? and also, can you
explain me how you solve the problem of duplicated static symbols?

Regards,

[1] 
https://www.linuxtopia.org/online_books/programming_books/art_of_unix_programming/ch01s06_3.html?
[2] 
https://quotefancy.com/quote/1711236/Douglas-Gwyn-Unix-was-not-designed-to-stop-you-from-doing-stupid-things-because-that

Re: [dev] [edit] Introducing edit, a simple text editor

[Roberto E. Vargas Caballero]

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,

Re: [dev] [st] Incorrect colours in 88-colour mode with urwid

[Roberto E. Vargas Caballero]

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 different way.
Maybe a flat C program printing hardcoded sequences can be better
to remove layers.

Roberto Vargas,

Re: [dev] [surf] webkit

[Roberto E. Vargas Caballero]

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 problems with some pages.
It is hard to kow the patches that you distribution adds to the upstream
project.


Roberto Vargas.

Re: [dev] Automatic C header dependency tracking for the redo build-system

[Roberto E. Vargas Caballero]

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 only non portable thing is the -MMD option (gcc and clang support
> though).

-include is not portable. Also, not related to the original topic,
but in general is better to just define OBJ instead of defining SRC,
because you as a object generator are interested in the objects, no
in the sources. It can drive to problems because the standard does not
define how the expansion is done in inference rules and things like:

$(OBJ): 


don't work in nmake if OBJ is a expansion of SRC.


Regards,

Re: [dev] Replace ranlib(1) calls?

[Roberto E. Vargas Caballero]

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 one recognized object file[1]. Additionally, the `s` option 
> exists
> which does exactly the same as ranlib(1)[2].

Well, I disagree about ranlib to be obsolete. Ar is guaranteed to add an
index in COFF and ELF systems, but not in a.out. I also know that 99.99%
of the people will ignore such systems, but I personally care about them.
Also, using ranlib doesn't harm so I personally don't see the advantage
of removing it.

> ar rcs files...
> 
> which not only makes the creation of static libraries more portable,
> but also simpler.

More portable? It is just the opposite, if you use ranlib you can support
systems where ar doesn't create an index in the archive (for example if
you use scc ar :P).

Regards,

Re: [dev] Re: [st] incorrect italic, bold, bold italic versions

[Roberto E. Vargas Caballero]

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,

Re: [dev] [st] incorrect italic, bold, bold italic versions

[Roberto E. Vargas Caballero]

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[] = {
>   "font0",
>   "font1",
>   "font2",
>   };
> 
> And ST would/should prioritize `font0` and then fallback to
> `font1 -> font2 -> ..` etc before attempting it's own heuristics.


I agree with you, it seems a more reasonable way of dealing with the issue.
I don't know what Evil_Bob thinks about it, but I personally would go
to introduce that change in the mainline of st.

Regards,

Re: [dev] Replace ranlib(1) calls?

[Roberto E. Vargas Caballero]

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 part of any standard and our Makefiles are full of them.
as(1), ld(1), and cc(1) are not part of POSIX and we keep using them.
Again, Please stop doing this kind of patches and center in changes
that actually improve code. If we find a system where using ranli is
a problem then we can revisit this.


Roberto,

Re: [dev] Replace ranlib(1) calls?

[Roberto E. Vargas Caballero]

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-legalese), it helps to make ranlib more and more superfluous
> and promote the best practice, which is why I pushed your described
> change for libgrapheme[0].

There is a big important reason why scc ar does not generates a link table,
because then ar can handle any type of files, because ar is just an archiver.
Making ar(1) to generate symbol tables means that ar has to do detection
of type files, meaning that it has to support all the possible binary formats.

At this moment scc ar is able to generate libraries for any system, without
a symbol table yes, but thay are going to work. In this point we have several
standard to consider. POSIX does not enter in binary formats, it is out of
the scope of the standard, and htis is why as(1) and ld(1) are out of the
specification, and it does not mean that you should not use them, it is just
that they cannot be standarized. ELF specification implies that ar should
generate a symbol table, but not a.out ar. If you want to be sure that you
have a symbl table then you *need* ranlib, otherwise it depends of the system
where you execute.

Again, ranlib(1) is out of POSIX because it cannot standarize this kind of
topics, not because it is legacy. In fact, MacOS requires use of ranlib (or
at least it needed the last time that I tested scc in MacOS). You cannot
know what system require it or not, so the only safe option is to use ranlib.

Regards,

Re: [dev] [dwm] [st] benefits (or not) of -march=x86-64-v3 and gcc optimizations

[Roberto E. Vargas Caballero]

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, that's why I'm posting here.

There are interactive programs, so almost all the time is wasted waiting
for user input. Don't try to optimize for things that don't need to be
optimized ;)

Regards,

Re: [dev] sbm dmenu bookmarker

[Roberto E. Vargas Caballero]

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 complete!

> screenhots etc.
> https://equwal.com/posts/sbm
> the "code"
> https://github.com/equwal/sbm

It seems nice, I will give it a try.

> It's still rough around the edges, I'd like to be able to have some
> input validation (no duplicate links) and plumbing options (browse
> where? copy to what?).

I think is nice to copy to primary.


I saw that you use bash in the shebang, but you actually don't use any bash
feature. Did you consider to make it POSIX compliant?

Regards,

Re: [dev] [sbase] expr segmentation fault

[Roberto E. Vargas Caballero]

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 build linux using sbase
> due to expr segmentation fault:

Randy Palamar sent a patch that fixed the issue. I just merged it
in master.

Regards,

[dev] [sbase] Defining scope of sbase and ubase

[Roberto E. Vargas Caballero]

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 for the POSIX commands that cannot be
implemented in a portable way.  Saying that, it is obvious that
there are programs in sbase that are not part of POSIX:

- md5sum
- sha256sum
- sha384sum
- sha512sum
- sponge
- sync
- tar
- install

and maybe some others. At this point is not clear to me what to do
with tools like tac or shuf. There was a small discussion about
this topic in the irc channel, and it was proposed to add a 3rd
repository to contain all these tools that are not part of POSIX
(a bit like the moretools package).  From my point of view, the
main drawback of it is that it requires a 3rd -box program (currently
we have sbase-box and ubase-box). The current situation it not good,
because the two -box are not sharing the library, and the disk space
is duplicated (main reason of -box is to minimize disk space for
restricted environments), and a 3rd -box would make the situation
even worse. But in the other hand, I don't want to add more non
POSIX tools in sbase (in fact, I personally would like to remove
the current non POSIX tools).

I would like to move the discussion here and see what alternatives
we have and how to proceed in this case.

Regards,

[dev] [sbase] New branch for sbase+ubase

[Roberto E. Vargas Caballero]

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 I was considering
something like:

- posix (tools defined by POSIX)
- misc (helpful tools not defined by POSIX).
- linux (tools that only make sense in linux)
- curses-terminfo (tools with dependency of terminfo, like clean and 
reset).
- curses-dummy (curses tools implementation without using terminfo).
- libutil (library with utility functions)
- libsys (library with system dependant functions).


The separation between curses and curses-dummy is because we have
currently some curses tools implemented using hardcoded sequences
instead of using terminfo to locate the correct sequences for the
terminal used. While this would work in the majority of terminal
emulators (because almost all of them emulate vt100 compatible
emulatros) it would not work in many cases. It is a good idea
to keep them because it reduces the dependencies of the project,
and it makes easier to bootstrap systems. But I think we can also
implement the correct solutions and select what is the option
at build time.

it was commented to have functions that isolated the system dependencies
between different systems, and I thought that instead of adding them
to libutil it was better to define a new library only for that
purpose.

Please, give your opinion.

Regards,

Re: [dev] [sbase] New branch for sbase+ubase

[Roberto E. Vargas Caballero]

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 the Makefile
> (PORTABLE set vs NONPORTABLE), but I think it is better to explicitly
> separate in different
> directories portable from non-portable tools. If we don't, we are making
> sbase a Linux-only
> project (the only implementation for ps becomes a Linux-only one, and we
> would need to fork
> sbase to make it available to other platforms; same for all the other
> tools from ubase), which
> I find a bit sad considering the goals of portability of sbase

The idea is that everything is portable. Let's take the example of
ps.  We can extract the non portable bits of ps into the libsys
library (or whatever name we like), so the code in posix/ is portable.
In some cases it would mean to remove some functionalities or worst
performance, but it is not a problem because we can keep in ubase
the optimized versions.  For example, sbase has a portable dd and
ubase has a customized linux dd version.

>   - I think Mattias Andrée scheme is better than this one. With a
> directory-base separation
> (between categories of utilities, based on somewhat arbitrary factors
> (standards, rather than
> say, minimalness, or use-case, or platform or implementation, etc.)), we
> cannot have overlapping
> categories, which is quite problematic. For example, if we wished to
> have a category for
> "shell-only usage" (such as clear, or cols), we couldn't implement it in
> an easy way, because
> this category overlaps with misc/, curses-dummy/, and maybe others too.

I don't get why we should have categories like "shell-only", or why
we should have so high level of customization. Having some categories
makes sense, but going to the level of user custom lists is too
much in my opinion. The separation between posix/ and misc/ is there
because may people raised the concern that they didn't use tools
like sponge, tac or shuf ever, so it is questionable to include
them, but as there are other people that use them we add the option
to include them.  The curses tools have the problem that include a
strong dependency with a complex library, and it is desirable to
skip them, because it can be very problematic to build them in some
cases. Having the unix/ category is there for all the tools that
were part of POSIX previously and/or were part of UNIX historically
but for different reasons are not part of POSIX today.  Having a
POSIX only set of tools has the advantage of being a tool to check
if your shell script is portable or not.

What is the reasoning for categories like "shell-only"?

> What I suggest to fix both problems:
>   - separate on the grounds of portability/nonportability. In other words,
> something along the lines
> of:
>libutil/
>portable/
>  ls.c
>  cols.c

As commented before, all the tools must be portable, except of
course linux specific tools. After talking with quinq he liked the
idea because then tools for Openbsd can be easily added just adding
a new openbsd directory.

> This more or less reproduces the sbase/ubase separation, but allowing
> future OSes to come in
> the future rather than just Linux (so, for example, *maybe* OpenBSD

I put only linux because at this moment we only have linux specific tools,
if we add OpenBSD tools then we can have the openbsd directory. Of course
that it would mean that if you add linux and openbsd at the same time
your build will fail, just don't do stupid things.

>   - Allow for categories _inside the Makefile_. We could have something
> like:
>POSIXTOOLS = portable/ls unportable/$(OS)/ps.c ...
>MISCTOOLS = portable/sponge.c portable/cols.c portable/rev.c ...
>INTERACTIVETOOLS = portable/cols.c portable/clear.c ...
>...
>BIN = $(POSIXTOOLS) $(MISCTOOLS) $(LINUXTOOLS)

At this stage and with the configuration that we want to have I
think we have to get rid of the monolithic approach and just define
the directories that we want to include in our build:

all: posix misc curses

and every directory with simple Makefiles.

> This allows for such grouping, while also allowing overlapping
> categories. This also doesn't
> hinder the useful semantic sbase/ubase separation (which is especially
> handy when working on
> non-Linux OSes). I think overall that sbase/ubase is the most useful
> distinction, so it should
> be treated specially, and not as part of the build-system (but more as
> part of the directory
> organization).

As commented, the idea is to have all the tools written with portable
code. Tools in POSIX are implemented in all the systems, so they
have a way to be implemented.  At this moment I just began to
classify the tools, that is 

Re: [dev] [sbase] Defining scope of sbase and ubase

[Roberto E. Vargas Caballero]

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 complex than the one that we have now.

I am going to import the history of ubase into sbase and
I will push to a new branch. Meanwhile, I am going to
keep frozen the pending patches that we have in the hackers
mailing list until the migration is done. I would ask
later to the authors to resend them adjusted to the structure
of the project. Please, raise your concerns if you consider
that something else should be done.

More mails are expected in specific threads while we
progress with the migration.

Regards,