[dev] [vis] dw near the end of the line

Recently, the question of the correctness of vim's behavior of 2dw on the first of three lines of one word each came up on the vim mailing list (it turns out that it's not correct according to POSIX, but is shared with traditional vi). At that time, I wasn't able to build vis to see what it

[dev] Re: st: keys and infocmp

Greg Reagle writes: > Hello. If there are any man pages or articles or FAQs about this topic > that would be good to read, please refer to them. > > Running Xubuntu 12.04 and the latest st on a ThinkPad laptop, these are > the results I get, correlated with the results of

[dev] Re: Bug in join.c

Mattias Andrée writes: > I think this patch should be included. But I don't see > how it is of substance. It will never occur with two's > complement or ones' complement. Only, signed magnitude > representatiion. Any sensible C compiler for POSIX > systems will only use two's

[dev] Bug in join.c

I was going through sbase checking with -Wall -Wextra -pedantic -Werror, and among a bunch of noise errors relating to signed/unsigned comparisons, I found one with actual substance: the result of getline is being converted to size_t before comparing to -1 to check for error. diff --git a/join.c

[dev] Re: [sbase] Portability

Dimitris Papastamos writes: > sbase should only contain code that runs on POSIX systems (with some > minor exceptions) and fallback implementations for non-standardized > interfaces that can be implemented portably on top of POSIX interfaces. So there's no place for fallback

[dev] [sbase] Portability

I downloaded and built sbase for my OSX system to test the cal program, and noticed (and fixed locally) several issues. Before posting any patches, I wanted to ask - philosophically speaking, how much effort should sbase put towards supporting systems that don't support the latest-and-greatest

[dev] Re: [farbfeld] announce

FRIGN writes: > I guess a better way to do that would be to use greyscale-farbfeld > files There doesn't appear to be such a thing, unless you mean just have R=G=B and A=65535. Which, to me, seems to suck about as much as using ASCII for a header that can be parsed with fscanf. I

[dev] Re: [farbfeld] announce

FRIGN writes: > Hello fellow hackers, > > I'm very glad to announce farbfeld to the public, a lossless image > format as a successor to "imagefile" with a better name and some > format-changes reflecting experiences I made since imagefile has > been released. (snip description of

[dev] Re: a suckless hex editor

Greg Reagle writes: > I agree that it is a "poor man's" hex editor. I am having fun with it, even > if > it is a toy. I don't have the desire to write a sophisticated hex editor > (besides they already exist). > > I like that the small shell script can turn any editor

Re: [dev] st: selecting text affects both primary and clipbaord

On Fri, Feb 20, 2015, at 12:38, sta...@cs.tu-berlin.de wrote: * k...@shike2.com 2015-02-20 17:39 I agree here, it shouldn't modiy the CLIPBOARD seletction. Sometime is good to have different things in both selections. If nobady claims about it I will apply your patch. I'd leave it as is,

Re: [dev] surf questions

On Thu, Jan 22, 2015, at 16:47, Raphaël Proust wrote: When you have a vertical line in a text, indicating where the character you type will appear: it's called a caret. Or, more relevantly to a (mostly) read-only application like a web browser, to enable you to precisely position it with the

Re: [dev] [sbase] [PATCH] Rewrite tr(1) in a sane way

On Fri, Jan 9, 2015, at 18:39, FRIGN wrote: C3B6 is 'ö' and makes sense to allow specifying it as \50102 (in the pure UTF-8-sense of course, nothing to do with collating). Why would someone want to use the decimal value of the UTF-8 bytes, rather than the unicode codepoint? Why are you using

Re: [dev] [sbase] [PATCH-UPDATE] Rewrite tr(1) in a sane way

On Sat, Jan 10, 2015, at 16:47, Markus Wichmann wrote: You wanted to be Unicode compatible, right? Because in that case I expect [:alpha:] to be the class of all characters in General Category L (that is, Lu, Ll, Lt, Lm, or Lo). That includes a few more characters than just A-Z and a-z. And I

Re: [dev] [sbase] [PATCH-UPDATE] Rewrite tr(1) in a sane way

On Sat, Jan 10, 2015, at 19:11, Ian D. Scott wrote: On Sat, Jan 10, 2015 at 06:56:45PM -0500, random...@fastmail.us wrote: Actually, ẞ, capital of ß, was added in Unicode 5.1. There are probably others letters with this issue, however. My main point was that you've got to be careful that

Re: [dev] [sbase] [PATCH] Rewrite tr(1) in a sane way

On Fri, Jan 9, 2015, at 18:08, FRIGN wrote: This is madness. If you want the bytes to be collated, I don't see where you're getting that either of us want the bytes to be collated. I don't even know what you mean by collated, since collating is not what tr does, except when ordering ranges.

Re: [dev] [sbase] [PATCH] Rewrite tr(1) in a sane way

On Fri, Jan 9, 2015, at 17:48, FRIGN wrote: Did you read what I said? I explicitly went away from POSIX in this regard, because no human would write tr '\303\266o' 'o\303\266'. POSIX doesn't require people to write it, it just requires that it works. POSIX has no problem with also allowing a

Re: [dev] [sbase] [PATCH] Rewrite tr(1) in a sane way

On Fri, Jan 9, 2015, at 16:44, Nick wrote: Quoth FRIGN: - UTF-8: not allowed in POSIX, but in my opinion a must. This finally allows you to work with UTF-8 streams without problems or unexpected behaviour. I fully agree (unsurprisingly). Anything that relies on the

Re: [dev] problem report for sbase/cal

On Mon, Dec 15, 2014, at 11:47, Greg Reagle wrote: January 2015 is supposed to start on a Thursday. January 2014 started on a Wednesday - maybe it's worth investigating whether cal -3 that spans two years isn't using the correct year for some of the months.

Re: [dev] Object-Oriented C for interface safety?

On Thu, Nov 27, 2014, at 07:27, koneu wrote: Greetings. The two things that really make OO languages worthwhile in my opinion are polymorphism and inheritance. Doing polymorphism and data/code hiding in C is easy enough with const function pointers. You can just define public interfaces in

Re: [dev] [sbase] style

On Wed, Nov 19, 2014, at 16:44, k...@shike2.com wrote: C90, or any version of standard C, does not have a concept of system headers, other than giving implementations permission to place their own implementation-defined files in places searched by #include h-char-sequence. At this

Re: [dev] why avoid install?

On Thu, Nov 20, 2014, at 14:40, Markus Wichmann wrote: Not always. One thing that reliably gets on people's nerves here is shared libraries. And those aren't protected with that ETXTBSY thing. The reason is that the MAP_DENYWRITE flag became the irrecoverable source of a DoS attack and had

Re: [dev] why avoid install?

On Wed, Nov 19, 2014, at 09:55, Dimitris Papastamos wrote: Regarding your question on cp -f then the answer is not quite. cp -f will try to unlink the destination if it fails to open it for whatever reason. And if the target is running and writing to a running binary is a problem, opening

Re: [dev] [sbase] style

On Wed, Nov 19, 2014, at 13:51, k...@shike2.com wrote: system headers should come first, then a newline, then libc headers then a newline then local headers. I usually do just the inverse, first libc headers and later system headers. the libc headers are guaranteed to work

Re: [dev] Patches to fix . for insert and change commands

On Tue, Nov 18, 2014, at 17:59, Stephen Paul Weber wrote: I've written up patches to make it so that I, a, A, s, ce, etc can be repeated properly with . -- not sure if I'm doing this the Right Way, but it seems to work in my tests. Feedback appreciated. Patches attached. Haven't looked

Re: [dev] fsbm

On Fri, Nov 7, 2014, at 02:03, k...@shike2.com wrote: I disagree, check the size before of calling strcpy. If you want to avoid security risk you also have to check the output of strlcpy to detect truncations, so you don't win anything. In both cases you have to add a comparision, so it is

Re: [dev] fsbm

On Fri, Nov 7, 2014, at 05:11, Dimitris Papastamos wrote: It is generally unlikely that the string has been validated to be an integer before getting to atoi(). With atoi() you cannot distinguish between an invalid integer and 0. Generally speaking, it should never be used. What if you

Re: [dev] c++-style comments [was fsbm]

On Thu, Nov 6, 2014, at 12:34, Louis Santillan wrote: In a color syntax highlighting editor, doSomething(); takes on normal highlighting when enabled, and takes on comment colored highlighting when disabled. Visually, that's slightly improved over something like #ifdef DEBUG

Re: [dev] c++-style comments [was fsbm]

On Thu, Nov 6, 2014, at 16:47, Sylvain BERTRAND wrote: Linus T. does let closed source modules live (even so the GNU GPLv2 gives legal power to open the code, or block binary blob distribution, like what happens with mpeg video or 3D texture compression), There's a significant amount of

Re: [dev] [sbase] [PATCH 1/2] Fix symbolic mode parsing in parsemode

On Sun, Nov 2, 2014, at 17:24, Michael Forney wrote: I found quite a lot of bugs, so I ended up pretty much rewriting as I followed the spec¹. How about +X? I noticed there were no test cases for that. +X acts like +x provided either the file is a directory or the file already has at least one

Re: [dev] [sbase] [PATCH 1/4] tar: Don't crash when get{pw,gr}uid fails

On Sat, Nov 1, 2014, at 16:57, Dimitris Papastamos wrote: On Sat, Nov 01, 2014 at 08:36:37PM +, Michael Forney wrote: - snprintf(h-uname, sizeof h-uname, %s, pw-pw_name); - snprintf(h-gname, sizeof h-gname, %s, gr-gr_name); + snprintf(h-uname, sizeof h-uname, %s, pw ? pw-pw_name :

Re: [dev] [sbase] [PATCH 1/4] tar: Don't crash when get{pw,gr}uid fails

On Sat, Nov 1, 2014, at 18:01, Michael Forney wrote: It looks like GNU tar does¹, but BSD tar uses the string representation of the UID/GID. ¹ http://git.savannah.gnu.org/cgit/tar.git/tree/src/names.c#n66 I didn't think to look at a modern BSD (the relevant function is name_uid in

Re: [dev] [PATCH] [st] Use inverted defaultbg/fg for selection when bg/fg are the same

On Mon, Oct 27, 2014, at 08:20, FRIGN wrote: There's simply no reason to break consistency for some quirky irc-gag. But there's no compelling reason in the first place to visualize selection by inverting the colors. If you want consistency it can be achieved by having an actual selection color

Re: [dev] [PATCH] [st] Use inverted defaultbg/fg for selection when bg/fg are the same

On Mon, Oct 27, 2014, at 10:54, Martti Kühne wrote: This may sound trivial, but. How about you paste it somewhere else? Requires having another window already open that can accept arbitrary text (and not attempt to execute it as commands).

Re: [dev] SGI Irix look (4Dwm)

On Wed, Oct 22, 2014, at 14:01, Peter Hofmann wrote: I'm pretty sure that most people on the list will agree on this being just plain crazy. :-) It's a hack, it's ugly and it's anything but suckless. I won't go into further detail. This causes many, many problems. The only reason why

Re: [dev] [st][PATCH] Add support for utmp in st

On Sun, Oct 12, 2014, at 14:32, k...@shike2.com wrote: If the user doesn't like the key assignation on st he is free of changing it in his config.h (maybe we could add it to the FAQ). That doesn't mean that the question of what the default should be is not worth discussing. You didn't

Re: [dev] [st][PATCH] Add support for utmp in st

); } Guys, what do you think about it? Regards, -- Random832

Re: [dev] [st][PATCH] Add support for utmp in st (DISREGARD LAST)

Sorry I accidentally hit shift-enter and apparently that makes my email client send. On Mon, Oct 13, 2014, at 14:38, k...@shike2.com wrote: But, why do you think is better DELETE than BACKSPACE? Because that is the character sent by the key in this position with this expected function (i.e. the

Re: [dev] [st][PATCH] Add support for utmp in st

On Sun, Oct 12, 2014, at 03:48, k...@shike2.com wrote: And the profile runs in the same tty that st opens. St by default executes a non login shell, so profile is not loaded, but utmp executes a login shell (because it creates the utmp session, so it is more logical for it to execute a login

Re: [dev] [st][PATCH] Add support for utmp in st

On Sat, Oct 11, 2014, at 04:07, k...@shike2.com wrote: Value of erase key for example, or in general the configuration of line kernel driver These can't come from the profile either; since st opens a new tty that is not the same device the user logged in on. (stty(1)). Backspace key in st

Re: [dev] [st][PATCH] Add support for utmp in st

On Tue, Sep 23, 2014, at 01:18, Roberto E. Vargas Caballero wrote: St runs an interactive shell and not a login shell, and it means that profile is not loaded. The default terminal configuration in some system is not the correct for st, but since profile is not loaded there is no way of

Re: [dev] Ideas for using sic

On Wed, Oct 1, 2014, at 12:57, q...@c9x.me wrote: On Mon, Sep 29, 2014 at 09:55:07PM -0700, Eric Pruitt wrote: rlwrap ./sic -h $IRC_HOST | tee -a irc-logs | grcat sic.grcat Hi, how does rlwrap deal with random text that gets inserted by sic when some data arrives on the channel?

Re: [dev] [RFC] Design of a vim like text editor

On Thu, Sep 25, 2014, at 08:57, Raphaël Proust wrote: I actually have my vimrc setting K as an upward J (i.e., join current line with the previous one) (although I haven't made the effort to make it work in visual mode because then I just use J): nnoremap K :.-,.joinCR Why not just map it to

Re: [dev] [RFC] Design of a vim like text editor

On Wed, Sep 24, 2014, at 15:21, Marc André Tanner wrote: x should not delete the end of line character (but this might be solved with the placement issue above) I (and a few others? Christian Neukirchen?) actually like the fact that the newline is treated like a normal character. You

Re: [dev] [RFC] Design of a vim like text editor

On Wed, Sep 24, 2014, at 15:36, Marc André Tanner wrote: - 'J' in visual mode is not implemented Why would one use it? To be able to select lines to be joined interactively instead of having to count the lines by hand (since there's no Jmovement, only countJ). I do this all the time.

Re: [dev] [st] Understading st behaviour

On Wed, Apr 16, 2014, at 4:19, Amadeus Folego wrote: It works! As I am using tmux just for the scrollback and paste capabilities I am not worried with losing sessions. Maybe I'll write a suckless multiplexer for this sometime. Eh - multiplexing refers to the multiple session capability, not

Re: [dev] What is bad with Python

On Wed, Mar 12, 2014, at 15:04, FRIGN wrote: Impressive, but better use $ LD_TRACE_LOADED_OBJECTS=1 t instead of $ ldd t next time to prevent arbitrary code-execution[1] in case you're dealing with unknown binaries. I don't know if it was here and you or somewhere else or someone else,

Re: [dev] [sbase] move mknod(1) to ubase

On Sat, Jan 25, 2014, at 17:46, Roberto E. Vargas Caballero wrote: Uhmm, it looks bad. If we want to be 100% POSIX complaint then we have to move mknod to ubase, and change the mknod system call of tar (and next archivers that could be implemented in sbase) to a system(mknod ...). The mknod

Re: [dev] portable photoshop-like lite application based on C?

On Tue, Dec 3, 2013, at 9:50, Markus Teich wrote: Mihail Zenkov wrote: ldd /usr/bin/gimp-2.8 Heyho, http://www.catonmat.net/blog/ldd-arbitrary-code-execution/ Considering that he probably _actually_ executes the very same gimp-2.8 binary all the time, your concern is misplaced. This

Re: [dev] suckless shell prompt?

On Mon, Nov 25, 2013, at 5:26, Martti Kühne wrote: Announcing a shell prompt and including git.h indeed makes no sense whatsoever. What part of git is useful when writing a shell interpreter? I'm sorry, I can't possibly imagine how this isn't apparent to you. Do you understand the difference

Re: [dev] suckless shell prompt?

On Tue, Nov 26, 2013, at 12:09, Bryan Bennett wrote: And sending that email calls into question your ability to either read a full thread or to recognize human names. In my defense, you'd already had it pointed out to you once and continued in your misconception without even understanding the

Re: [dev] suckless shell prompt?

On Thu, Nov 21, 2013, at 13:44, Martti Kühne wrote: Staring at the code in horror. Something about git and nyancat. Without running the code - I have trust issues from similar occasions - you're kidding, right? The nyancat thing is clearly just a little joke. As for git... you can't

Re: [dev] Suckless remote shell?

On Tue, Nov 5, 2013, at 9:43, Szabolcs Nagy wrote: you don't have large file support, The lack of large file support is entirely an artifact of the fact that the lseek listed on that page uses an int instead of an off_t. The existence of special APIs for large file support on e.g. Linux and

Re: [dev] Mailing list behavior - was: Question about arg.h

On Thu, Nov 7, 2013, at 11:42, Calvin Morrison wrote: Why do I top post? yes i am lazy! After being with gmail since it was in beta, I still don't have an option to god damned bottom-post by default!! Top posting or bottom posting isn't an option, it's determined by _where you click the

Re: [dev] st: bracketed paste mode

On Thu, Sep 19, 2013, at 10:51, Nick wrote: To check, how does this work exactly? Does X send the escape code to any window when pasting with middle click, and those which don't understand it just ignore it? And then once st has done the appropriate stuff with the pasted text, vim (for

Re: [dev] [st] Implementing non-latin support...

to actually come up with a solution for combining characters, so what do I know? There's a copy of my st.c attached to one of those emails, I think. -- Random832

Re: [dev] [st] Implementing non-latin support...

On Sat, Jun 15, 2013, at 0:35, Eon S. Jeon wrote: Thanks for your interest. Would you explain how you tested? I've done only few tests: echo vim. The cursor handling should be incomplete, because I used a very hacky method to workaround the innate ASCII-ism structure. For cursor behavior,

Re: [dev] [sbase] 64-bit type for split

On Tue, Jun 11, 2013, at 13:35, Galos, David wrote: In my implementation of split, the ability to split files into rather large chunks is important. However, c89 does not provide a 64-bit int type by default. Although I could manually emulate 64-bit counting, a uvlong would be far cleaner. Is

Re: [dev] [st] Implementing non-latin support...

On Fri, Jun 14, 2013, at 17:24, esj...@lavabit.com wrote: I'm currently working on non-latin character support. I uploaded my progress to github. Github URL: https://github.com/esjeon/st/tree/stable-nonlatin (branch 'stable-nonlatin', meaning it's based on stable(?) release 0.4.1) ... and

[dev] [sbase] changes to test

I had partially implemented the test/[ command a while ago, and then got distracted with other things and never came back to it - I remembered about it when I saw this other sbase patch. This version has binary operators (e.g. = != -gt -lt) implemented (limited to the r, and properly handles

Re: [dev] [sbase] changes to test

On Thu, May 30, 2013, at 10:09, random...@fastmail.us wrote: This version has binary operators (e.g. = != -gt -lt) implemented (limited to the r My client ate part of this sentence - It was limited to the range of intmax_t.

Re: [dev] [sbase] changes to test

to write a manpage - test has a _lot_ of options. -- Random832

Re: [dev] Re: Why HTTP is so bad?

On Sun, May 26, 2013, at 9:21, Dmitrij Czarkoff wrote: May it owe to the fact that this particular IPC protocol is *the* protocol used for nearly all IPC in the system? I have no idea what protocol you are talking about.

Re: [dev] Re: Why HTTP is so bad?

On 05/25/2013 12:55 AM, Strake wrote: Yes. Thus I can easily swap out any component, or insert mediators between components. For example, I could write my own fetcher to scrub the HTTP headers, or block ads; and I wouldn't need plug-ins to view PDFs or watch movies. Why is the requirement

Re: [dev] upload via html?

On 05/25/2013 07:29 PM, Nicolas Braud-Santoni wrote: Well, SFTP requires you to create a user account. (I'm aware that it may not be one with which you can SSH in). Some people might not want this. Everything runs as a user. You could use www-data, whatever anonymous FTP uses, or simply nobody.

Re: [dev] Re: Why HTTP is so bad?

On Fri, May 24, 2013, at 16:02, Strake wrote: Yes. A web browser ought to have a component to fetch documents and start the appropriate viewer, as in mailcap. The whole monolithic web browser model is flawed. And you spend a day on wikipedia or tvtropes and you've got two hundred HTML viewers

Re: [dev] upload via html?

On Mon, May 13, 2013, at 23:20, Sam Watkins wrote: HTTP PUT with ranges would be useful, could mount filesystems over HTTP. There's no standard HTTP directory listing.

[libutf] Re: [dev] [st][patch] not roll our own utf functions

On 05/05/2013 01:06 PM, Nick wrote: Hmm, I'm not sure that's the right decision. Maybe include the appropriate .c .h file for libutf in the source tree? That's what I do in a couple of projects. I don't have strong feelings about it, but libutf is pretty reasonable and I'm not convinced it

Re: [dev] [st] RFC halt function

On Thu, Apr 25, 2013, at 14:15, Christoph Lohmann wrote: Nice joke. Try to implement a scrollback buffer without bugs and flaw‐ lessly. Sincerely, Christoph Lohmann The buffer's the easy part. What's hard is actually implementing scrolling. I've been tempted to hack in a way to have

Re: [dev] st: Large pile of code

On Wed, Apr 24, 2013, at 9:32, Carlos Torres wrote: I like the seperation of term.c from st.c, I agree that makes reading st.c clearer. I can't comment on the removal of forward declarations, typedefs and static vars though the resulting difference is legible as well. (frankly code in

Re: [dev] [st] double-width usage

On 04/23/2013 03:07 AM, Christoph Lohmann wrote: Hello comrades, Here’s some RFC for people using double‐width characters in terminals in their daily life. Which applications do you use that handle double-width as you expect them? Do these applications use the double-width for the

Re: [dev] [st] [PATCH] 8bit-meta like xterm

On 04/23/2013 04:50 AM, Christoph Lohmann wrote: I am considering making this the default behaviour of st. Are there any arguments against it? I'm actually confused by what he means by most of the apps I tried didn't recognize the escape sequence, because every app I've ever used recognizes

Re: [dev] [st] [PATCH] 8bit-meta like xterm

with activity, meta-1 goes to window 1, etc. -- Random832

Re: [dev] [st] [PATCH] 8bit-meta like xterm

On Tue, Apr 23, 2013, at 10:30, Thorsten Glaser wrote: random...@fastmail.us dixit: Wait a minute... what exactly do you _expect_ meta to do? Using (for example) meta-a to type 0xE1 a with acute is _not_, in fact, the expected or intended behavior; it is a bug. And I don't think it will

Re: [dev] [st] double-width usage

On Tue, Apr 23, 2013, at 11:01, Silvan Jegen wrote: I saw, compiled and tested it but when using mutt only half of the (Japanese Kanji) characters would be drawn (so presumably only one character cell of a two-cell double character). If I wasn't at a conference I would deliver some screenshots

[dev] [st] colors and attributes, general question

the background for ATTR_BLINK. -- Random832

Re: [dev] [st] colors and attributes, general question

On Tue, Apr 23, 2013, at 11:53, Christoph Lohmann wrote: It’s the simple way of doing all the brigthening and reversing. St is keeping to what other terminals do. But since none of them keeps to any standard colors or good behaviour is this what makes st being what it is – a simple

Re: [dev] [PATCH] Fix selecting clearing and BCE

On Tue, Apr 23, 2013, at 14:34, Roberto E. Vargas Caballero wrote: From: Roberto E. Vargas Caballero k...@shike2.com The commit b78c5085f72 changed the st behaviour enabling BCE capability, that means erase regions using background color. Problem comes when you clear a region with a

Re: [dev] [PATCH] Fix selecting clearing and BCE

On Tue, Apr 23, 2013, at 16:21, Roberto E. Vargas Caballero wrote: In drawregion you have: 3172 bool ena_sel = sel.bx != -1; 3173 3174 if(sel.alt ^ IS_SET(MODE_ALTSCREEN)) 3175 ena_sel = 0; ... 3190 if(ena_sel *(new.c) selected(x,

Re: [dev] [PATCH] Fix selecting clearing and BCE

it stay reversed? If it goes away, what is the problem? Are you expecting it should go away immediately when it is erased? There is some merit to the idea that the selection should go away if any character within it is modified - maybe we should be talking about that. -- Random832

Re: [dev] [PATCH] Fix selecting clearing and BCE

On 04/23/2013 05:27 PM, Roberto E. Vargas Caballero wrote: It is very confusing see a hightlight blank line, that really is selecting the previous content of the line. If the selecting mark keeps in the screen it is only some garbage in it. If you can find other terminal emulator with this

[dev] Need help implementing combining characters

I've got the logic fully implemented (both for maintaining multiple characters in a single cell and for copying the selection) but I can't figure out how to make them draw correctly. I don't understand what the xdraws and drawregion function is doing. Current behavior is it draws the

Re: [dev] [st] Need help implementing combining characters

On 04/21/2013 12:45 PM, Carlos Torres wrote: Maybe send out what you have and others can better grok what you intend, and see how it may fit? I could do that, but I haven't actually modified the drawing code substantially yet, except to include the combining characters themselves in the

Re: [dev] [st] wide characters

On Mon, Apr 15, 2013, at 10:58, Martti Kühne wrote: On Sun, Apr 14, 2013 at 2:56 AM, Random832 random...@fastmail.us wrote: Okay, but why not work with a unicode code point as an int? -1 from me. It is utter madness to waste 32 (64 on x86_64) bits for a single glyph. A. current usage

Re: [dev] [st] wide characters

On Mon, Apr 15, 2013, at 15:16, Strake wrote: On 15/04/2013, random...@fastmail.us random...@fastmail.us wrote: On Mon, Apr 15, 2013, at 10:58, Martti Kühne wrote: According to a quick google those chars can become as wide as 6 bytes, No, they can't. I have no idea what your source on

Re: [dev] [st] wide characters

On Mon, Apr 15, 2013, at 15:36, Thorsten Glaser wrote: Actually, wint_t is the standard type to use for this. One could also use wchar_t but that may be an unsigned short on some systems, or a signed or unsigned int. Those systems aren't using wchar_t *or* wint_t for unicode, though. The main

Re: [dev] [st] wide characters

On 04/14/2013 02:10 AM, Christoph Lohmann wrote: Greetings. On Sun, 14 Apr 2013 08:10:22 +0200 Random832 random...@fastmail.us wrote: I am forced to ask, though, why character cell values are stored in utf-8 rather than as wchar_t (or as an explicitly unicode int) in the first place

[dev] [st] wide characters

I don't mean as in wchar_t, I mean as in characters (generally in East Asian languages) that are meant to take up two character cells. I am forced to ask, though, why character cell values are stored in utf-8 rather than as wchar_t (or as an explicitly unicode int) in the first place,

Re: [dev] [st] wide characters

On 04/13/2013 07:07 PM, Aurélien Aptel wrote: The ISO/IEC 10646:2003 Unicode standard 4.0 says that: The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing

Re: [dev] [st] windows port?

On Thu, Apr 11, 2013, at 10:59, Max DeLiso wrote: My aim is to create a minimalist terminal emulator for windows. I want a project whose relationship to the cmd/conhost/csrss triad is analogous to the relationship between st and xterm/x. I'm going to try and lift out of st all of the platform

[dev] [sbase] cp and security

I've written most of cp, but one issue keeps bugging me. I can't figure out how to get rid of race conditions within the constraints that sbase is implemented in (POSIX 2001, no XSI extensions). If we were using POSIX 2008 or XSI extensions, I could use the at() functions, or at least fchdir(),