Re: [dev] [st] [patch] clipboard properties burn after reading

> there. The only two event types that get through to this code > are PropertyNotify and SelectionNotify and for both of them property > should be deleted. Indeed. If Christoph has not problems with it, I will push this commit. Regards,

Re: [dev] [st][PATCH] Use XftFontMatch in place of FcFontMatch.

Hi Markus, > This change allows st to correctly render fonts given in point sizes, > bringing its behavior in line with other software: dwm, dmenu, tabbed, > etc: > > FC_DEBUG=1 st -f Terminus:size=10 I think __20h__ should take a look to this patch, he is the expert in fonts (thankfully for me

Re: [dev] [st] [patch] clipboard properties burn after reading

On Fri, May 20, 2016 at 02:00:34PM +0200, hiro wrote: > please point out a working version of synergy. > after the latest degradation into a startup company all their crap has > stopped working for me. I didn't notice (nor care). I still use 1.4.15 and that worked pretty stable for my setup (two

Re: [dev] [st] [patch] clipboard properties burn after reading

slightly related: please point out a working version of synergy. after the latest degradation into a startup company all their crap has stopped working for me.

[dev] [st] [patch] clipboard properties burn after reading

Hey everyone, I use synergy (for input device sharing) on a daily basis and experienced this rather annoying bug in combination with st: Whenever I paste something from another machine to st, pasting succeeded only the first time. After about a year of being annoyed by this bug (it's just too

[dev] [st][PATCH] Use XftFontMatch in place of FcFontMatch.

This change allows st to correctly render fonts given in point sizes, bringing its behavior in line with other software: dwm, dmenu, tabbed, etc: FC_DEBUG=1 st -f Terminus:size=10 -Mark From 9d5447b61340038499ad74f37e9d1b012d3c720e Mon Sep 17 00:00:00 2001 From: Mark Edgar

Re: [dev] [st] [patch] Remove redundant xtermclear code

Greetings. On Mon, 07 Mar 2016 14:33:54 +0100 Ton van den Heuvel wrote: > In case anything gets drawn in drawregion, xdrawglyphfontspecs ensures > that the region that needs to be drawn to is cleaned up. In case this > patch is not accepted; the current code contains

[dev] [st] [patch] Remove redundant xtermclear code

In case anything gets drawn in drawregion, xdrawglyphfontspecs ensures that the region that needs to be drawn to is cleaned up. In case this patch is not accepted; the current code contains an issue; -xtermclear(0, y, term.col, y); +xtermclear(0, y, term.col-1, y); Ton diff

Re: [dev] [st] [PATCH] Fix extra bracketed paste markers when pasting >8kb

Greetings. On Fri, 25 Sep 2015 20:16:54 +0200 dequis wrote: > Before this patch, when pasting over BUFSIZE (8192 bytes here), st would > do the following: > > \e[200~...8192 bytes...\e[201~\e[200~...remaining bytes...\e[201~ > > With this patch, the start marker is only

[dev] [st] [PATCH] Fix extra bracketed paste markers when pasting >8kb

Before this patch, when pasting over BUFSIZE (8192 bytes here), st would do the following: \e[200~...8192 bytes...\e[201~\e[200~...remaining bytes...\e[201~ With this patch, the start marker is only sent when the offset is 0 (at the beginning of selnotify) and the end marker is only sent

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

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

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

On Fri, 12 Jun 2015 11:34:26 -0700 Matthew Wesley wes...@google.com wrote: Hey Matthew, Added Google to the LICENSE to the copyright list to meet our legal requirements. we had this discussion before and the reasons have already been told. Adding a company to a license is a risk we won't

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

On Fri, Jun 12, 2015 at 11:58 AM, Evan Gates evan.ga...@gmail.com wrote: In most cases authors of small patches are not added to the LICENSE of suckless projects. -emg Understandable, given the number of contributors of 3-line changes. I've confirmed the corporate requirement for such a

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

On Fri, Jun 12, 2015 at 01:22:08PM -0700, Matthew Wesley wrote: On Fri, Jun 12, 2015 at 1:00 PM, FRIGN d...@frign.de wrote: we had this discussion before and the reasons have already been told. Adding a company to a license is a risk we won't take. We prefer to deny these patches in favor

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

On Fri, Jun 12, 2015 at 2:34 PM, Matthew Wesley wes...@google.com wrote: Added Google to the LICENSE to the copyright list to meet our legal requirements. --- LICENSE | 1 + st.c| 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/LICENSE b/LICENSE index

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

Can you provide some of the history? Nothing in the st commit history showed a previous Google contribution. If previous patches were able to get through without a Google entry in LICENSE, I may be able to take that precedent to our open source team. On Fri, Jun 12, 2015 at 11:51 AM, Lee Fallat

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

On Fri, Jun 12, 2015 at 11:56 AM, Matthew Wesley wes...@google.com wrote: Can you provide some of the history? Nothing in the st commit history showed a previous Google contribution. If previous patches were able to get through without a Google entry in LICENSE, I may be able to take that

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

On Fri, Jun 12, 2015 at 1:00 PM, FRIGN d...@frign.de wrote: we had this discussion before and the reasons have already been told. Adding a company to a license is a risk we won't take. We prefer to deny these patches in favor of staying away from possible risks of this nature, so please either

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

On Fri, Jun 12, 2015 at 10:00:45PM +0200, FRIGN wrote: On Fri, 12 Jun 2015 11:34:26 -0700 Added Google to the LICENSE to the copyright list to meet our legal requirements. we had this discussion before and the reasons have already been told. Adding a company to a license is a risk we won't

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

On Fri, Jun 12, 2015 at 2:20 PM, Dimitris Papastamos s...@2f30.org wrote: Can you not get an exemption from your employer so you can freely contribute to this project under your own name? It's possible, but does require more review. Given the trivial nature of my patch, and the fact that

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

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

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

Hi, 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. Regards, Michael diff --git a/st.1 b/st.1 index 9548c1a..1d9646a 100644 --- a/st.1 +++ b/st.1 @@ -1,151

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

On 05/28/15 00:49, Michael Reed wrote: Hi, 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. Regards, Michael Apologies, I wasn't aware the

[dev] [st] [PATCH] set selection to IDLE on clear

From 3823c33f284a9c11d3db7a020957775b6d59d4e3 Mon Sep 17 00:00:00 2001 From: v4hn m...@v4hn.de Date: Thu, 14 May 2015 15:36:57 +0200 Subject: [PATCH] set selection to IDLE on clear Otherwise a tangling bmotion event will consider the selection still valid and selnormalize segfaults because of an

[dev] [st] [PATCH] Small bugfix for makeglyphfontspecs call in drawregion

Hi, Here's a patch that fixes a bug when calling `makedrawglyphfontspecs' in `drawregion'. Wasn't offseting the pointer into the input glyphs array by `x1'. The bug isn't causing any problems currently, because `drawregion' is always called with `x1' and `y1' values of 0, but if this ever changes

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

Applied, thanks!

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

Applied, thanks!

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

Here's a third version of the patch with some minor changes. It removes the curly braces around the body of the `if' clause in `xmakeglyphfontspecs' that checks for ATTR_WDUMMY. It simplifies some of the conditional logic in `xdrawglyphfontspecs', by pulling out the check to see if `base.fg' is

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

Hello, I have another patch here for review that optimizes the performance of glyph drawing, primarily when using non-unit kerning values, and fixes a few other minor issues. It's dependent on the earlier patch from me that stores unicode codepoints in a Rune type, typedef'd to uint_least32_t.

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

I've discovered a deficiency with full-width characters in the original patch, I wasn't handling the ATTR_WDUMMY mode attribute properly. I've attached the updated the patch to fix this, and I've tested it out with CJK characters and SJIS art, seems to be working correctly now. Sorry about that.

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

Hi all, here's a patch that changes occurences of long to uint_least32_t where it's being used to store UTF-32 codepoints, as was previously discussed. Other cases where long is used are preserved as is. --- st.c | 50 +- 1 file changed, 25

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

On Tue, May 05, 2015 at 07:37:01PM +0100, Connor Lane Smith wrote: Hi, I get the feeling we should typedef uint_least32_t Rune, as in libutf, so we don't have to have this long-winded and somewhat cryptic type everywhere. cls No prob, here's the same patch, but using a `Rune' typedef.

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

On Mon, May 04, 2015 at 12:47:38PM +0200, Roberto E. Vargas wrote: 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

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

Hi, On 5 May 2015 at 19:31, suigin suigin@national.shitposting.agency wrote: Hi all, here's a patch that changes occurences of long to uint_least32_t where it's being used to store UTF-32 codepoints, as was previously discussed. Other cases where long is used are preserved as is. I get the

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

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,

Re: [dev] [st] [PATCH] Fix sigchld

Hi, I am going to apply the original patch. I think there is space for improvements, so new patches are welcome. Regards,

Re: [dev] [st PATCH 1/3] xloadcols: remove cp variable

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

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

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

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

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

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

Hi, I'm personally in favour of using dup2. It is quite clear that dup2(cmdfd, STDIN_FILENO) duplicates the fd into the position of STDIN_FILENO. That's what it says. On the other hand, the combination of close(STDIN_FILENO) and dup(cmdfd) is less efficient (two syscalls) and also means that the

Re: [dev] [st] [PATCH] Fix sigchld

* Martti Kühne mysat...@gmail.com [2015-04-28 09:40]: The initial patch seems to cover edge cases I fail to grasp and probably doesn't cover all scenarios. I've implemented URL selection into st, where I need to start dmenu and the browser. See the patch attached. I'm open to push this one to

Re: [dev] [st] [PATCH] Fix sigchld

The initial patch seems to cover edge cases I fail to grasp and probably doesn't cover all scenarios. Could someone please tell me why SIGCHLD should be received while requiring waitpid to WNOHANG, and why st prints an error message for nonzero exit status instead of propagating it? I haven't

Re: [dev] [st] [PATCH] Fix sigchld

* koneu kone...@googlemail.com [2015-04-28 05:05]: Patch attached. st stops responding after spawning a command. signature.asc Description: Digital signature

Re: [dev] [st] [PATCH] Fix sigchld

Indeed the second question applies for koneu's patch, too. I want the shell's exit status reflected in the terminal's. Otherwise, to retreive the shell's exit status, one needs to make silly use of pipe(), in case one uses st as an output layer, for whatever reason. cheers! mar77i

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

I have applied a version of this patch with short size. typedef struct { char c[UTF_SIZ]; /* character code */ - ushort mode; /* attribute flags */ - uint32_t fg; /* foreground */ - uint32_t bg; /* background */ + ushort mode; /* attribute flags

Re: [dev] [st] [PATCH] Fix sigchld

Hi, Only wait for termination of the shell. ... - if(waitpid(pid, stat, 0) 0) + if((p = waitpid(pid, stat, WNOHANG)) 0) die(Waiting for pid %hd failed: %s\n, pid, strerror(errno)); I don't understand this patch. The master process only has one child, the shell, so

Re: [dev] [st PATCH 1/3] xloadcols: remove cp variable

With the pointer loop, you need to understand the context of the surrounding for loop to understand what this statement is executing. I can’t tell anything from just this one line of code other than that a method is being called with what appear to be a pointer (based on the assumption that

Re: [dev] [st] [PATCH] Fix sigchld

Hi Roberto, * Roberto E. Vargas Caballero k...@shike2.com [2015-04-27 10:42]: I don't understand this patch. The master process only has one child, the shell, so you only can wait for it. If you receives the signal is because the child already died, so I don't see the point of adding WNOHANG.

Re: [dev] [st] [PATCH] Fix sigchld

On April 27, 2015 11:31:22 AM CEST, Jochen Sprickerhof d...@jochen.sprickerhof.de wrote: * koneu kone...@googlemail.com [2015-04-27 11:25]: On April 27, 2015 11:23:52 AM CEST, Jochen Sprickerhof d...@jochen.sprickerhof.de wrote: I'm spawning other process from st (dmenu and surf for urlview).

Re: [dev] [st] [PATCH] Fix sigchld

* koneu kone...@googlemail.com [2015-04-27 11:25]: On April 27, 2015 11:23:52 AM CEST, Jochen Sprickerhof d...@jochen.sprickerhof.de wrote: I'm spawning other process from st (dmenu and surf for urlview). Without checking the pid, st stops working if some other child finishes. Without

Re: [dev] [st] [PATCH] Fix sigchld

On April 27, 2015 11:23:52 AM CEST, Jochen Sprickerhof d...@jochen.sprickerhof.de wrote: Hi Roberto, * Roberto E. Vargas Caballero k...@shike2.com [2015-04-27 10:42]: I don't understand this patch. The master process only has one child, the shell, so you only can wait for it. If you receives

Re: [dev] [st] [PATCH] Clarify calculation precedence for '' and '?'

Applied, thanks.

Re: [dev] [st] [PATCH] Use %u for uint

Applied, thanks.

Re: [dev] [st] [PATCH] len assignment is never used

Applied, thanks.

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

On April 27, 2015 10:29:25 AM CEST, Roberto E. Vargas Caballero k...@shike2.com wrote: typedef struct { uint_least32_t u; uint_least32_t mode:12; uint_least32_t fg:10; uint_least32_t bg:10; } Glyph; The size of this struct is only one byte less than if the same of the

Re: [dev] [st] [PATCH] Fix sigchld

Hi, Only wait for termination of the shell. ... - if(waitpid(pid, stat, 0) 0) + if((p = waitpid(pid, stat, WNOHANG)) 0) die(Waiting for pid %hd failed: %s\n, pid, strerror(errno)); I don't understand this patch. The master process only has one child, the shell, so

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

Hi, Matter of style maybe. It's still annoying to have noise in the build. I don't admit this types of commits about quiting some compiler. First point, warnings are not part of the standard, so you are free of take care of them or not. If you don't like to have noise add some flags to your

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

typedef struct { uint_least32_t u; uint_least32_t mode:12; uint_least32_t fg:10; uint_least32_t bg:10; } Glyph; The size of this struct is only one byte less than if the same of the struct using shorts. You can test it if you want. Regards,

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

On Mon, Apr 27, 2015 at 10:09:20AM +0200, Roberto E. Vargas Caballero wrote: I have applied a version of this patch with short size. Okay, thanks! Please, be careful with your commits, because this patch and the other you sent have a lot of white spaces changes that are not needed. Okay, I

Re: [dev] [st PATCH 1/3] xloadcols: remove cp variable

On Apr 27, 2015, at 2:21 AM, Roberto E. Vargas Caballero k...@shike2.com wrote: Again, read [1], section The use of pointers. Maybe you don't agree with it, but almost all the people here agree with it. Your link shows the use of `node[i].left` as a perfectly valid example when an

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

On Mon, Apr 27, 2015 at 10:31:38AM +0200, koneu wrote: Add to that, non-int bit fields are a GNU extension. You're right. It works because uint_least32_t happens to be a typedef of unsigned int for x86_64. Changing it so that it reads: typedef struct { uint_least32_t u; unsigned

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

On Mon, Apr 27, 2015 at 10:29:25AM +0200, Roberto E. Vargas Caballero wrote: typedef struct { uint_least32_t u; uint_least32_t mode:12; uint_least32_t fg:10; uint_least32_t bg:10; } Glyph; The size of this struct is only one byte less than if the same of the struct

Re: [dev] [st] [PATCH] Fix sigchld

Jochen Sprickerhof wrote: * koneu kone...@googlemail.com [2015-04-27 11:42]: waitpid and WNOHANG is not the way to go though. Use wait Why? wait is just convenience for waitpid. Also, it didn't work for me. Can you send a patch if you think there is a better way to do it? and check the

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

On Mon, Apr 27, 2015 at 07:34:01AM -0700, suigin wrote: As you can see, it's actually 2 bytes less. This is because a struct is usually aligned to the maximum alignment of all fields. A 16-bit ushort has a 2-byte alignment on x86_64, so this forces the struct to also have an alignment of

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

On Mon, Apr 27, 2015 at 06:56:59AM -0700, suigin wrote: What's the general process and ettiquete for submitting patches, do we submit them to solely to this mailing list, or should they also be pushed via git for review? Non-maintainers like us can't push to the repository. Mailing list only.

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

On Mon, Apr 27, 2015 at 10:55:48AM +0200, Roberto E. Vargas Caballero wrote: Matter of style maybe. It's still annoying to have noise in the build. I don't admit this types of commits about quiting some compiler. Ideally, that's fine, and I'd very much agree with you. However, practically,

Re: [dev] [st] [PATCH] Fix sigchld

* koneu kone...@googlemail.com [2015-04-27 11:42]: waitpid and WNOHANG is not the way to go though. Use wait Why? wait is just convenience for waitpid. Also, it didn't work for me. Can you send a patch if you think there is a better way to do it? and check the pid against the shell's to decide

Re: [dev] [st PATCH 1/3] xloadcols: remove cp variable

On Wed, Apr 22, 2015 at 4:14 PM, Garrick Peterson garri...@gmail.com wrote: [...] for (cp = dc.col; cp dc.col[LEN(dc.col)]; ++cp) Forgive my ignorance of the LEN macro, but doesn’t this rely on accessing a memory address outside of the allocated array? Wouldn’t that cause problems if

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

On Wed, Apr 22, 2015 at 05:26:37AM -0700, suigin wrote: Another solution would be to allow people to typedef the color index type used by Glyph in config.h, and move the definitions for Glyph, TCursor and Term below where config.h is included in st.c? That way, it makes it easy to

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

On Wed, Apr 22, 2015 at 09:28:10AM +0200, Roberto E. Vargas Caballero wrote: We don't have any opportunity of having a race condition, so there is no reason to use dup2 instead of dup. So I wil keep the current version. Matter of style maybe. It's still annoying to have noise in the build.

Re: [dev] [st PATCH 1/3] xloadcols: remove cp variable

On Apr 22, 2015, at 1:05 AM, Roberto E. Vargas Caballero k...@shike2.com wrote: mihail.zenkov: IMHO in this particular case index version much better for reading and understanding. So, you think that is more understable: XftColorFree(xw.dpy, xw.vis, xw.cmap, dc.col[i]); I

[dev] [st] [PATCH] Use %u for uint

Signed-off-by: Daniel Martí mv...@mvdan.cc --- st.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/st.c b/st.c index 0204b2e..d5bf8f1 100644 --- a/st.c +++ b/st.c @@ -1746,7 +1746,7 @@ tdefcolor(int *attr, int *npar, int l) { b = attr[*npar + 4];

[dev] [st] [PATCH] len assignment is never used

Signed-off-by: Daniel Martí mv...@mvdan.cc --- st.c | 1 - 1 file changed, 1 deletion(-) diff --git a/st.c b/st.c index 57cb052..6f236ec 100644 --- a/st.c +++ b/st.c @@ -864,7 +864,6 @@ mousereport(XEvent *e) { + ((state ControlMask) ? 16 : 0); } - len =

[dev] [st] [PATCH] Clarify calculation precedence for '' and '?'

Signed-off-by: Daniel Martí mv...@mvdan.cc --- st.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/st.c b/st.c index d5bf8f1..57cb052 100644 --- a/st.c +++ b/st.c @@ -859,9 +859,9 @@ mousereport(XEvent *e) { } if(!IS_SET(MODE_MOUSEX10)) { -

[dev] [st] [PATCH] Fix sigchld

Only wait for termination of the shell. --- st.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/st.c b/st.c index 0204b2e..1615609 100644 --- a/st.c +++ b/st.c @@ -1245,10 +1245,14 @@ execsh(void) { void sigchld(int a) { int stat, ret; + pid_t p; -

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

We don't have any opportunity of having a race condition, so there is no reason to use dup2 instead of dup. So I wil keep the current version.

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

On Tue, Apr 21, 2015 at 07:03:57PM +0200, Roberto E. Vargas Caballero wrote: Sorry, I didn't realize it was possible to use colors above 256, neglected to see it in config.def.h. My bad. Maybe, a solution can be modify colorname to: 63 static const char *colorname[256] = { and force

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

Another solution would be to allow people to typedef the color index type used by Glyph in config.h, and move the definitions for Glyph, TCursor and Term below where config.h is included in st.c? That way, it makes it easy to customize it for a low memory profile. Here's another patch that

Re: [dev] [st PATCH 3/3] Move common code to xloadcolor.

Applied, thanks.

Re: [dev] [st PATCH 2/3] Use LEN(dc.col) instead of LEN(colorname).

Applied. Thanks.

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

On Tue, Apr 21, 2015 at 10:32:26AM -0700, Eric Pruitt wrote: On Tue, Apr 21, 2015 at 07:03:57PM +0200, Roberto E. Vargas Caballero wrote: The problem here is that st was designed in this way, and to change it is going to generate segfault in all the users that update the st version without

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

On Tue, Apr 21, 2015 at 07:03:57PM +0200, Roberto E. Vargas Caballero wrote: The problem here is that st was designed in this way, and to change it is going to generate segfault in all the users that update the st version without changing the config file. Is that really a concern? My st builds

Re: [dev] [st][PATCH v2] Add tty line support

+ if (opt_line) { + if((cmdfd = open(opt_line, O_RDWR)) 0) + die(open line failed: %s\n, strerror(errno)); + close(STDIN_FILENO); + dup(cmdfd); + stty(); + return; Is the duplication of the cmdfd without saving

Re: [dev] [st PATCH 1/3] xloadcols: remove cp variable

On Tue, Apr 21, 2015 at 07:54:27AM +0200, Roberto E. Vargas Caballero wrote: Hi, - Color *cp; if(loaded) { - for (cp = dc.col; cp dc.col + LEN(dc.col); ++cp) - XftColorFree(xw.dpy, xw.vis, xw.cmap, cp); + for (i = 0; i LEN(dc.col);

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

At least we can safely reduce to uint16_t now.

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

On Tue, Apr 21, 2015 at 07:03:57PM +0200, Roberto E. Vargas Caballero wrote: Guys, are you using colors upper 256? I use it for my background and cursor colours.

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

--- st.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/st.c b/st.c index 0204b2e..adf0b62 100644 --- a/st.c +++ b/st.c @@ -1298,8 +1298,7 @@ ttynew(void) { if (opt_line) { if((cmdfd = open(opt_line, O_RDWR)) 0) die(open line

[dev] [st] [PATCH] Optimize memory footprint of line buffers

Hello, I noticed that the Glyph struct was using more memory than was needed. Considering that the fg and bg colors have values that are always in the range of [0, 255], there is no need to use a uint32_t for them. A single byte each would suffice. Furthermore, assuming default alignment and

Re: [dev] [st][PATCH v2] Add tty line support

On Tue, Apr 14, 2015 at 12:35:52PM +0200, Roberto E. Vargas Caballero wrote: + if (opt_line) { + if((cmdfd = open(opt_line, O_RDWR)) 0) + die(open line failed: %s\n, strerror(errno)); + close(STDIN_FILENO); + dup(cmdfd); +

Re: [dev] [st] [PATCH] Do not set terminal title based on stty arguments.

Applied, thanks.

Re: [dev] [st PATCH 1/3] xloadcols: remove cp variable

I prefer the pointer version. I don't know why an index version is better in this case. The reference here is [1], section The use of pointers. IMHO in this particular case index version much better for reading and understanding.

Re: [dev] [st] [PATCH] Optimize memory footprint of line buffers

Hi, Hello, I noticed that the Glyph struct was using more memory than was needed. Considering that the fg and bg colors have values that are always in the range of [0, 255], there is no need to use a uint32_t for them. A single byte each would suffice. Furthermore, assuming This is a good

[dev] [st] [PATCH] Do not set terminal title based on stty arguments.

--- st.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/st.c b/st.c index 0204b2e..3e706f7 100644 --- a/st.c +++ b/st.c @@ -4066,7 +4066,7 @@ run: if(argc 0) { /* eat all remaining arguments */ opt_cmd = argv; -

Re: [dev] [st] [PATCH] Remove WIN_REDRAW flag.

Applied, thanks.

Re: [dev] [st PATCH 1/3] xloadcols: remove cp variable

Hi, - Color *cp; if(loaded) { - for (cp = dc.col; cp dc.col + LEN(dc.col); ++cp) - XftColorFree(xw.dpy, xw.vis, xw.cmap, cp); + for (i = 0; i LEN(dc.col); i++) + XftColorFree(xw.dpy, xw.vis, xw.cmap, dc.col[i]);

Re: [dev] [st] [PATCH 3/5] Do not use floating point to calculate timeout

- drawtimeout.tv_nsec = (1000/xfps) * 1E6; + drawtimeout.tv_nsec = 10 / xfps; I like the patch, but not the comment. In the original code there is no floating point calculation at all; the division is integer, but is true that there is accuary lost. Maybe the

Re: [dev] [st] [PATCH 5/5] Monotonic clock cannot jump backwards.

Applied with minor changes in the comments.

Re: [dev] [st] [PATCH 3/3] Place memset arguments in the correct order.

- memset(term.trantbl, sizeof(term.trantbl), CS_USA); + memset(term.trantbl, CS_USA, sizeof(term.trantbl)); Uppss, good catch. Applied.

Re: [dev] [st] [PATCH 2/5] Replace for with while.

same as uint_fast32_t. uint_least32_t is 4 bytes almost always. int is not an option as it may be 2 bytes long. Not in Posix. Posix forces int to be at least 32 bits. Although the terminal emulation part is mostly portable, so I think is better don't relay on this point. Regards,

Re: [dev] [st] [PATCH 2/5] Replace for with while.

Are we discussing something for which #include stdint.h does not leave any questions open? int32_t, int_fast32_t or int_least32_t would probably be the solution here? Is there any problem with using stdint.h in general that I'm not aware of? cheers! mar77i

<    1   2   3   4   5   6   7   8   9   10   >