Hi
Try this please which works out whether to use UTF-8 based on the same
rules as tmux uses on startup (-u or LANG/LC_ALL/etc).
Index: cmd-list-buffers.c
===
RCS file: /cvs/src/usr.bin/tmux/cmd-list-buffers.c,v
retrieving revision 1
Thank you for checking.
I am worried if users feel strange if outputs of list-buffers and
choose-buffer are different.
Also, I think the caller supports don't really matter because user who
has UTF-8 characters in buffer may use UTF-8 supported terminal.
I seem trimming at the RHS is nicer select
Hi
I applied this to OpenBSD now, with some changes.
Notably, I don't think we should do this for list-buffers because we
don't know if the caller supports UTF-8. It is fine for choose-buffer.
Also if we are appending ... or if we have double-width UTF-8, the width
could be >50 cells. That doesn
Hi - I think so but I need to look at it again, I have a few things to
look at when I have time. Thanks
On Tue, Apr 01, 2014 at 09:20:42AM +0900, Kosuke ASAMI wrote:
> Is this patch ok?
>
> 2014-03-10 4:03 GMT+09:00 Nicholas Marriott :
> > On Mon, Mar 10, 2014 at 12:47:46AM +0900, Kosuke ASAMI w
Is this patch ok?
2014-03-10 4:03 GMT+09:00 Nicholas Marriott :
> On Mon, Mar 10, 2014 at 12:47:46AM +0900, Kosuke ASAMI wrote:
>> The first zero check of 'len' seem to be unnecessary.
>>
>
> Yes you are right, thanks. Will look at this again and apply it later
> this week.
>
>> I have fixed the d
On Mon, Mar 10, 2014 at 12:47:46AM +0900, Kosuke ASAMI wrote:
> The first zero check of 'len' seem to be unnecessary.
>
Yes you are right, thanks. Will look at this again and apply it later
this week.
> I have fixed the decrement number from 'src' when an UTF-8 character
> doesn't finish.
>
> 2
The first zero check of 'len' seem to be unnecessary.
I have fixed the decrement number from 'src' when an UTF-8 character
doesn't finish.
2014-03-09 18:16 GMT+09:00 Nicholas Marriott :
> Actually I think this function is wrong because it reads over the end of
> src. len is the length of src, not
Actually I think this function is wrong because it reads over the end of
src. len is the length of src, not dst. We know there is always enough
space in dst.
I haven't time now to look at this closely or test it but maybe
something like:
diff --git a/utf8.c b/utf8.c
index 63723d7..b1f44bf 100644
I have tested, and it works fine!
However, there is a mistake in my first patch.
The flag needs to be cleared before next iteration. (like following diff)
I have attached the complete patch.
--
diff --git a/utf8.c b/utf8.c
index 10200dd..0465a32 100644
--- a/utf8.c
+++ b/utf8.c
@@ -379,
Hi
Here's it with a little tidying up. I didn't test this but can you take
a look?
diff --git a/cmd-choose-buffer.c b/cmd-choose-buffer.c
index d79f6fd..a46db3e 100644
--- a/cmd-choose-buffer.c
+++ b/cmd-choose-buffer.c
@@ -45,6 +45,7 @@ cmd_choose_buffer_exec(struct cmd *self, struct cmd_q *cmd
> Arguments the wrong way round?
Sorry, I have fixed it.
I have moved the method from compat/vis.c to utf8.c and renamed it.
2014-03-08 18:25 GMT+09:00 Nicholas Marriott :
> Hi
>
> vis.c is only built on some platforms so the new function would be
> better in utf8.c as something like utf8_strvi
Hi
vis.c is only built on some platforms so the new function would be
better in utf8.c as something like utf8_strvis.
Also this looks wrong:
- format_paste_buffer(ft, pb);
+ format_paste_buffer(wp, ft, pb);
Arguments the wrong way round?
On Sat, Mar 08, 2014 at 06:
I have implemented a better UTF-8 support for buffer_sample in
choose-buffer and list-buffers.
When an user enables UTF-8 on window option, choose-buffer and list-buffers
show UTF-8 characters if so. Otherwise, they do as until now.
utf8_buffers.patch
Description: Binary data
---
13 matches
Mail list logo
