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

2016-02-13 Thread Random832
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 does.

[dev] Re: st: keys and infocmp

2015-12-14 Thread Random832
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 infocmp. I got the > o

[dev] Re: Bug in join.c

2015-12-14 Thread Random832
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 complement; otherwise

[dev] Bug in join.c

2015-12-14 Thread Random832
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 b

[dev] Re: [sbase] Portability

2015-11-26 Thread Random832
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 implementations _of_

[dev] [sbase] Portability

2015-11-25 Thread Random832
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 POS

[dev] Re: [farbfeld] announce

2015-11-18 Thread Random832
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 think it'd be m

[dev] Re: [farbfeld] announce

2015-11-17 Thread Random832
Andrew Gwozdziewycz writes: > Well, for one, it's a binary encoding, not ASCII. I'm not sure why that makes it better, unless you meant for space consumption (which I suppose is somehow very important for uncompressed raster image formats) in which case you're ignoring the fact that PPM has a for

[dev] Re: [farbfeld] announce

2015-11-17 Thread Random832
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 format) How is

[dev] Re: a suckless hex editor

2015-11-13 Thread Random832
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 into a hex editor. > BTW

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

2015-02-20 Thread random832
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 i

Re: [dev] surf questions

2015-01-23 Thread random832
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 k

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

2015-01-10 Thread random832
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-UPDATE] Rewrite tr(1) in a sane way

2015-01-10 Thread random832
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

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

2015-01-10 Thread random832
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] Rewrite tr(1) in a sane way

2015-01-09 Thread random832
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

2015-01-09 Thread random832
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 allow

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

2015-01-09 Thread random832
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

Re: [dev] problem report for sbase/cal

2014-12-15 Thread random832
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?

2014-11-27 Thread random832
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 interface

Re: [dev] why avoid install?

2014-11-20 Thread random832
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 h

Re: [dev] [sbase] style

2014-11-20 Thread random832
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 > > . > > At this point I

Re: [dev] [sbase] style

2014-11-19 Thread random832
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 wo

Re: [dev] why avoid install?

2014-11-19 Thread random832
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, openi

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

2014-11-18 Thread random832
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 looke

Re: [dev] fsbm

2014-11-08 Thread random832
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] fsbm

2014-11-08 Thread random832
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] c++-style comments [was fsbm]

2014-11-06 Thread random832
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] c++-style comments [was fsbm]

2014-11-06 Thread random832
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] [sbase] [PATCH 1/2] Fix symbolic mode parsing in parsemode

2014-11-03 Thread random832
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 on

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

2014-11-01 Thread random832
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 pax/cac

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

2014-11-01 Thread random832
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

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

2014-10-27 Thread random832
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] [PATCH] [st] Use inverted defaultbg/fg for selection when bg/fg are the same

2014-10-27 Thread random832
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] SGI Irix look (4Dwm)

2014-10-22 Thread random832
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 d

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

2014-10-13 Thread random832
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

2014-10-13 Thread random832
uot;); > @@ -1172,7 +1174,7 @@ execsh(void) { > unsetenv("TERMCAP"); > setenv("LOGNAME", pw->pw_name, 1); > setenv("USER", pw->pw_name, 1); > - setenv("SHELL", args[0], 1); > + setenv("SHELL", sh, 1); > setenv("HOME", pw->pw_dir, 1); > setenv("TERM", termname, 1); > setenv("WINDOWID", buf, 1); > @@ -1184,7 +1186,7 @@ execsh(void) { > signal(SIGTERM, SIG_DFL); > signal(SIGALRM, SIG_DFL); > > - execvp(args[0], args); > + execvp(prog, args); > exit(EXIT_FAILURE); > } > > Guys, what do you think about it? > > Regards, > > -- Random832

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

2014-10-13 Thread random832
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 c

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

2014-10-12 Thread random832
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 log

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

2014-10-11 Thread random832
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 ge

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

2014-10-10 Thread random832
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 get

Re: [dev] Ideas for using sic

2014-10-01 Thread random832
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 chan

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

2014-09-25 Thread random832
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 :.-,.join Why not just map it t

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

2014-09-24 Thread random832
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 J, only J). I do this all the time.

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

2014-09-24 Thread random832
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.

Re: [dev] [st] Understading st behaviour

2014-04-16 Thread random832
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,

Re: [dev] What is bad with Python

2014-03-13 Thread random832
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 els

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

2014-01-28 Thread random832
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

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

2013-12-03 Thread random832
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. Thi

Re: [dev] suckless shell prompt?

2013-11-26 Thread random832
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?

2013-11-26 Thread random832
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 differen

Re: [dev] suckless shell prompt?

2013-11-22 Thread random832
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 _possi

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

2013-11-07 Thread random832
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 mo

Re: [dev] Suckless remote shell?

2013-11-07 Thread random832
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 So

Re: [dev] st: bracketed paste mode

2013-09-19 Thread random832
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 exam

Re: [dev] [sbase] sponge v2

2013-07-05 Thread random832
On Tue, Jul 2, 2013, at 13:42, Calvin Morrison wrote: > doesn't sponge soak up into memory, not into a file? Sponge's "killer feature" is that it doesn't open the output file until after the input is finished. Using it in a pipeline removes this, because it's something else instead of sponge writi

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

2013-06-15 Thread random832
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 behav

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

2013-06-15 Thread random832
ready stores utf8; but then I ended up not being able 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...

2013-06-14 Thread random832
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) > ..

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

2013-06-14 Thread random832
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.

Re: [dev] [sbase] changes to test

2013-05-30 Thread random832
fore I have time to write a manpage - test has a _lot_ of options. -- Random832

Re: [dev] [sbase] changes to test

2013-05-30 Thread random832
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".

[dev] [sbase] changes to test

2013-05-30 Thread random832
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 being

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

2013-05-27 Thread random832
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] upload via html?

2013-05-26 Thread Random832
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?

2013-05-26 Thread Random832
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 that

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

2013-05-24 Thread Random832
On 05/24/2013 07:13 PM, Strake wrote: And you spend a day on wikipedia or tvtropes and you've got two hundred HTML viewers open? Yes. I meant as opposed to the usual dozen. The viewer sends a "go" message back to the fetcher, which kills the old viewer and loads the new one, and can keep a UR

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

2013-05-24 Thread random832
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 viewer

Re: [dev] upload via html?

2013-05-14 Thread random832
On Tue, May 14, 2013, at 8:50, Martti Kühne wrote: > On Tue, May 14, 2013 at 2:44 PM, wrote: > > 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. > > How is lack of

Re: [dev] upload via html?

2013-05-14 Thread random832
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

2013-05-05 Thread Random832
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 shou

Re: [dev] [st] RFC halt function

2013-04-25 Thread random832
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

Re: [dev] st: Large pile of code

2013-04-24 Thread random832
On Wed, Apr 24, 2013, at 15:32, Kent Overstreet wrote: > I switched to gnu99 for typeof() - it makes it possible to write min > and max macros that don't evaluate their arguments twice, and IMO is a > very worthwhile extension. Wait, you switched _to_ gnu99? For _that_? A) Why do min and max need

Re: [dev] st: Large pile of code

2013-04-24 Thread random832
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 al

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

2013-04-23 Thread Random832
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 behavi

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

2013-04-23 Thread random832
does 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

2013-04-23 Thread random832
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) && s

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

2013-04-23 Thread random832
On Tue, Apr 23, 2013, at 14:34, Roberto E. Vargas Caballero wrote: > From: "Roberto E. Vargas Caballero" > > 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 selection, becaus

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

2013-04-23 Thread random832
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 term

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

2013-04-23 Thread random832
for brightening the background for ATTR_BLINK. -- Random832

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

2013-04-23 Thread random832
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 screensh

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

2013-04-23 Thread random832
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

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

2013-04-23 Thread random832
s to the next window with activity, meta-1 goes to window 1, etc. -- Random832

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

2013-04-23 Thread Random832
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] double-width usage

2013-04-23 Thread Random832
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 layo

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

2013-04-21 Thread Random832
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 buf

[dev] Need help implementing combining characters

2013-04-21 Thread Random832
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 combining

Re: [dev] [st] wide characters

2013-04-15 Thread random832
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 ma

Re: [dev] [st] wide characters

2013-04-15 Thread random832
On Mon, Apr 15, 2013, at 15:16, Strake wrote: > On 15/04/2013, 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 this is. >

Re: [dev] [st] wide characters

2013-04-15 Thread random832
On Mon, Apr 15, 2013, at 10:58, Martti Kühne wrote: > On Sun, Apr 14, 2013 at 2:56 AM, Random832 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 usa

Re: [dev] [st] wide characters

2013-04-14 Thread Random832
On 04/14/2013 02:10 AM, Christoph Lohmann wrote: Greetings. On Sun, 14 Apr 2013 08:10:22 +0200 Random832 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, particularly since the

Re: [dev] [st] wide characters

2013-04-13 Thread Random832
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 Unic

[dev] [st] wide characters

2013-04-13 Thread Random832
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, particul

Re: [dev] [st] windows port?

2013-04-11 Thread random832
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 agno

[dev] [sbase] cp and security

2011-06-23 Thread Random832
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(),