Applied, thanks!
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.
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.
Th
On Tue, May 05, 2015 at 06:25:29PM +0200, Silvan Jegen wrote:
> Signed-off-by: Silvan Jegen
What's the point in signing off on patches where you're the sole author?
Seems like redundant clutter to me.
Eric
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' ty
On Tue, May 05, 2015 at 07:37:01PM +0100, Connor Lane Smith wrote:
> On 5 May 2015 at 19:31, suigin 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 u
Hi,
On 5 May 2015 at 19:31, suigin 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 feeling we should typedef uint_lea
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 insertio
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
> >
We use the fork/exec pattern to execute an external command. Two functions
using this approach are implemented in this patch.
1. exec_external_cmd
uses the pipe function to write to the stdin of the executed command
and read from its stdout.
The data being sent to the external command's stdin co
Replacing the first '/' allows the 's' command name to be correctly
identified even though it is part of its own argument.
This is hacky because afterwards we will add the '/' back in before
calling the 'sed' program.
Signed-off-by: Silvan Jegen
---
vis.c | 2 +-
1 file changed, 1 insertion(+),
Signed-off-by: Silvan Jegen
---
vis.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/vis.c b/vis.c
index cf157f7..628f511 100644
--- a/vis.c
+++ b/vis.c
@@ -1782,7 +1782,7 @@ static bool exec_cmdline_command(const char *cmdline) {
}
char *s = param;
-
Signed-off-by: Silvan Jegen
---
vis.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/vis.c b/vis.c
index 051f256..cf157f7 100644
--- a/vis.c
+++ b/vis.c
@@ -1714,8 +1714,10 @@ static Filerange parse_range(char **cmd) {
break;
default:
+1 for option 3)
Why would anybody want to trust somebody that creates malicious
archives like that?
A symlink in an archive should just be a symlink, nothing more.
-Truls
On Mon, Apr 27, 2015 at 08:12:42PM +0100, Nick wrote:
> One thing the patch doesn't cover is an archive using a symlink to
> somewhere like ../../ and then putting a file in symlink/newfile
> (hence sending it to ../../newfile). I only thought of that when
> reading the bsdtar manpage[0].
>
> I
Thanks, applied both patches.
On 5 May 2015 at 00:01, Eric Pruitt wrote:
> On Mon, May 04, 2015 at 11:47:18PM +0200, Hiltjo Posthuma wrote:
>> I think the use of uncommon "VL Gothic" and "WenQuanYi Micro Hei" is a
>> bit strange atleast. But yea maybe it should be left unchanged, it's
>> easy enough to change anyway.
>
> They
17 matches
Mail list logo
