Thus said "Joe Mistachkin" on Sun, 20 Jul 2014 11:11:08 -0700:
> I'm looking for some feedback and/or suggestions on how to improve it.
I imagine this is mostly useful for long commit comments that are broken
up with multiple lines and perhaps other ASCII formatting (like spaces)?
I tried it a
Thus said Stephan Beal on Tue, 22 Jul 2014 19:01:27 +0200:
> One would think i'd be more conscious of how i throw around byte vs
> character :/. i'm still not clear on the whole char-vs-code point bit,
> though.
The whole char-vs-codepoint has always been unclear for me, no matter
how many
My bindings for curses are pretty low-level, and I build functions to sort
of act as macros where I want convenience, fwiw. I think it's important to
honor the existing culture (ie: addressing in lines, columns versus more
typical x,y) even though it's not how one might build it today.
$0.02
-bch
On Tue, Jul 22, 2014 at 8:45 PM, Stephan Beal wrote:
> Will post screenshots if/when i've got something interesting to show.
>
A very basic hierarchical window class demonstrated in the white box here:
http://wanderinghorse.net/wh/tmp/termbox-poc-window1.png
The inner black box with text is a
On 7/22/2014 9:38 AM, Michai Ramakers wrote:
I was wondering how many of you use 'open --nested' to have nested workdirs?
Tcl nests whatever repositories you want checked out into subdirectories
of pkgs. Each nested repository is expected to further nest the
Tclconfig repository (itcl and th
On 22 July 2014 21:18, Matt Welland wrote:
> We are using -nested very successfully to break a large area of related but
> mostly independent sub-areas into multiple fossils. I'm very happy with it.
>
> BTW, the whole reason why the modern SCM approach used by fossil, git etc.
> is so powerful is
We are using -nested very successfully to break a large area of related but
mostly independent sub-areas into multiple fossils. I'm very happy with it.
BTW, the whole reason why the modern SCM approach used by fossil, git etc.
is so powerful is because the number of degrees of freedom were reduced
On Tue, Jul 22, 2014 at 9:04 PM, Andreas Kupries
wrote:
> Not necessarily. If the operations are done on the window buffer
> itself no transform is required. It happens implicitly when the window
> buffer is blitted into the main for presentation.
>
i'm currently building Window as (basically) a
NOTE: In Unix there is the handy shortcut that you can leave off the target
location:
ln -s foo/bar
will create the link:
bar -> foo/bar
Quite handy and yet another reason for the parameter ordering used on
Linux/Unix.
On Tue, Jul 22, 2014 at 9:46 AM, Warren Young wrote:
> On 7/22/2014 10:4
On Tue, Jul 22, 2014 at 11:45 AM, Stephan Beal wrote:
> On Tue, Jul 22, 2014 at 8:21 PM, Andreas Kupries
> wrote:
>>
> i (coincidentally) emails the author asking about the ability to
> save/restore blocks. No answer yet, but it was only an hour or so ago.
Heh.
> Looking at the "godit" link fr
On Tue, Jul 22, 2014 at 8:21 PM, Andreas Kupries
wrote:
> Having heard about termbox only through this thread I just had a quick
> look over the API ...
>
> The blit() function seems to be the core for windowing, copying a
> cell-rectangle into the main termbox buffer.
>
> Have a display-list of
On Tue, Jul 22, 2014 at 10:56 AM, Stephan Beal wrote:
> On Tue, Jul 22, 2014 at 7:33 PM, Gour wrote:
>>
>> Have you seen https://github.com/nsf/godit - text editor?
>
>
> i hadn't until now. It seems he implemented all of those features in script
> code. i was hoping someone had written them in C
On Tue, Jul 22, 2014 at 7:33 PM, Gour wrote:
> Have you seen https://github.com/nsf/godit - text editor?
>
i hadn't until now. It seems he implemented all of those features in script
code. i was hoping someone had written them in C already. Maybe the time i
saved wrapping termbox (only heard abo
Stephan Beal writes:
> c) higher-level widgets like string input. That gets complex quickly if you
> want to support any basic line editing.
Have you seen https://github.com/nsf/godit - text editor?
Sincerely,
Gour
--
Even the intelligent are bewildered in determining what is action
and wha
On Tue, Jul 22, 2014 at 1:01 PM, Stephan Beal wrote:
> One would think i'd be more conscious of how i throw around byte vs
> character :/. i'm still not clear on the whole char-vs-code point bit,
> though.
>
Code points also include non-character entities such as "zero width
non-breaking space",
On Tue, Jul 22, 2014 at 6:47 PM, Ron W wrote:
> On Tue, Jul 22, 2014 at 11:48 AM, Stephan Beal
> wrote:
>
>> So the range is used, but it encodes to two UTF-8 characters.
>>
>
> Actually, 1 Unicode character encoded in to 2 UTF-8 bytes.
>
One would think i'd be more conscious of how i throw aro
On Tue, Jul 22, 2014 at 3:29 PM, Stephan Beal wrote:
> On Tue, Jul 22, 2014 at 3:21 PM, Konstantin Khomoutov <
> flatw...@users.sourceforge.net> wrote:
>
>> 1. http://godoc.org/github.com/nsf/termbox-go
>>
>
> And we're halfway to one in s2 (which means, by extension, libfossil):
>
For completen
On Tue, Jul 22, 2014 at 11:48 AM, Stephan Beal
wrote:
> On Tue, Jul 8, 2014 at 9:37 PM, Stephan Beal
> wrote:
>
>> No characters between 128 and 255 are valid UTF-8, to avoid confusion
>> with the many encodings which use that range.
>>
>
> For the record, that's apparently wrong. My local man p
On 7/22/2014 10:43, Warren Young wrote:
the mklink command has its options in reverse order
I shouldn't say "option" here. I mean the two path names you have to
give to both mklink and ln:
$ ln source symlink-target
C:\> mklink symlink-target source
On 7/22/2014 10:22, Ron W wrote:
Yes, I know that modern versions of Windows
support symlinks, but I was getting eros from the command so I just did
nested check outs instead.
Native symlinks on Windows are a mess.
First, the mklink command has its options in reverse order as compared
to ln(
On Tue, Jul 22, 2014 at 10:38 AM, Michai Ramakers
wrote:
> Hello,
>
> I was wondering how many of you use 'open --nested' to have nested
> workdirs?
>
I have used it on MS Windows on a few occasions where I might otherwise
have used symbolic links (Yes, I know that modern versions of Windows
sup
Thus said Michai Ramakers on Tue, 22 Jul 2014 17:58:24 +0200:
> I don't / didn't use branches other than trunk (which still breaks,
> using your example - good).
Yes, this should work with trunk as long as there are no commits that
follow the one which caused the exclusion of artifacts from
On 22 July 2014 17:29, Andy Bradford wrote:
> Thus said Michai Ramakers on Tue, 22 Jul 2014 12:35:03 +0200:
>
>> I can't seem to reproduce what you describe - either that, or I'm
>> missing the point (did you mean 'merge' as in 'fossil merge'?). I'm
>> assuming you left out 'fossil add'
On Tue, Jul 8, 2014 at 9:37 PM, Stephan Beal wrote:
> No characters between 128 and 255 are valid UTF-8, to avoid confusion with
> the many encodings which use that range.
>
For the record, that's apparently wrong. My local man pages (and
experimentation with the termbox API) say otherwise:
Thus said Michai Ramakers on Tue, 22 Jul 2014 12:35:03 +0200:
> I can't seem to reproduce what you describe - either that, or I'm
> missing the point (did you mean 'merge' as in 'fossil merge'?). I'm
> assuming you left out 'fossil add' (or 'addremove') twice in your
> example.
Yes,
Thus said Stephan Beal on Tue, 22 Jul 2014 11:36:56 +0200:
> Only one: Keep it up! That was impressive investigatory work! It seems
> to me that you've discovered that fossil does indeed (unintentionally)
> support a form of branch-specific sync ;).
Yes, it's a feature, all those who want bra
On Tue, Jul 22, 2014 at 4:38 PM, Michai Ramakers
wrote:
> I was wondering how many of you use 'open --nested' to have nested
> workdirs?
>
nope
> A long time ago I asked here how/why/if people divided multiple-target
> project-trees into repos; some (like me) use one big repo for all, and
> so
Hello,
I was wondering how many of you use 'open --nested' to have nested workdirs?
A bit of background:
A long time ago I asked here how/why/if people divided multiple-target
project-trees into repos; some (like me) use one big repo for all, and
some use many small repos.
So this is not a real
Konstantin Khomoutov
writes:
> I mean, if you're about writing some full-screen terminal front-end for
> Fossil in Go it might be simpler to use termbox.
>
> 1. http://godoc.org/github.com/nsf/termbox-go
Yeah, I was thinking about that one. Not sure if I'd write full app with
it 'cause I plan to
Stephan Beal writes:
> Thanks again, Gour, for saving me the headache of doing yet another curses
> binding!
Well, ncurses are simply not human, so next time I'd gladly recommend
against it with clear conscience. ;:)
Sincerely,
Gour
--
One who restrains the senses of action but whose mind dw
On Tue, Jul 22, 2014 at 3:21 PM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:
> 1. http://godoc.org/github.com/nsf/termbox-go
>
And we're halfway to one in s2 (which means, by extension, libfossil):
const tb = s2.loadModule2('mod_termbox').termbox,
sleep = s2.time.sleep;
tb.in
On Tue, 22 Jul 2014 13:54:25 +0200
Gour wrote:
> > MUCH easier than curses, it would seem, and a wider range of display
> > colors. Isn't as portable, but it only needs to be portable to Unix
> > platforms.
>
> I plan to possibly use it with Go (language).
FWIW, there's a popular minimal suppo
On Tue, Jul 22, 2014 at 1:54 PM, Gour wrote:
> Well, Fossil spoils one with simplicity & power. ;)
>
Indeed, it has been trivial so far:
[stephan@host:~/cvs/fossil/cwal/s2]$ cat tb.s2
const tb = s2.loadModule2('mod_termbox').termbox;
tb.init();
s2.time.sleep(3);
tb.shutdown();
[stephan@host:~/c
Stephan Beal writes:
> MUCH easier than curses, it would seem, and a wider range of display
> colors. Isn't as portable, but it only needs to be portable to Unix
> platforms.
I plan to possibly use it with Go (language).
> And only 12 functions in its API! Compare that with over 200 in
> curse
On Tue, Jul 22, 2014 at 12:58 PM, Stephan Beal
wrote:
> On Tue, Jul 22, 2014 at 12:54 PM, Gour wrote:
>
>> Have you ever thought about termbox:
>>
>> https://code.google.com/p/termbox/ ?
>>
>
> Wasn't aware of it until now, but i am certainly looking at it now. Thanks!
>
MUCH easier than curses
On Tue, Jul 22, 2014 at 12:54 PM, Gour wrote:
> Have you ever thought about termbox:
>
> https://code.google.com/p/termbox/ ?
>
Wasn't aware of it until now, but i am certainly looking at it now. Thanks!
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Free
Stephan Beal writes:
> Curses is difficult to work with and has some of the worst API naming
> conventions one can imagine, but there's something entrancing about
> it, as if it was embedded in my DNA 1000 generations back. i can't
> help it.
Have you ever thought about termbox:
https://code.go
On Tue, Jul 22, 2014 at 12:50 PM, Michai Ramakers
wrote:
> there, it became default again:
>
> http://fossil-scm.org/index.html/info/8364065c45ec839d01e0a0535ebd754f81e9cac4
Ah, i missed that.
> >> 00:00:00 [b58cc4d981] initial empty check-in (user: michai tags: trunk)
> >> +++ no more data (
On 22 July 2014 11:48, Stephan Beal wrote:
> On Tue, Jul 22, 2014 at 11:35 AM, Michai Ramakers
> wrote:
>>
>> (FWIW, I know there have been flaws in this area before, and although
>> I am not a dev having/willing to deal with them, I agree with Jan that
>
> AFAIR i reverted that to not be the def
On 22 July 2014 10:27, Andy Bradford wrote:
> Thus said "Andy Bradford" on 12 Jul 2014 13:36:58 -0600:
>
>> 2) The artifact rid was in the unclustered table, but when
>> create_cluster() ran it prematurely removed it from the table.
>
> I have been able to successfully reproduce/cau
Hi, all,
for some reason i cannot explain, i've always been fascinated by that
absolutely horrible API known as "curses" (specifically, the every so
slightly more modern "ncurses"). Curses is difficult to work with and has
some of the worst API naming conventions one can imagine, but there's
somet
On Tue, Jul 22, 2014 at 11:37 AM, Michai Ramakers
wrote:
> of course, forgot something:
>
> This is fossil version 1.30 [619fa857c9] 2014-07-19 19:20:25 UTC
>
> (i.e. trunk of this moment)
>
Good man :).
FWIW, as a note to those who generally like to use "officially released
versions" - the maj
On Tue, Jul 22, 2014 at 11:35 AM, Michai Ramakers
wrote:
> (FWIW, I know there have been flaws in this area before, and although
> I am not a dev having/willing to deal with them, I agree with Jan that
>
AFAIR i reverted that to not be the default behaviour (IMO it should not be
because it's a l
On 22 July 2014 11:35, Michai Ramakers wrote:
>
> while toying around with Andy Bradford's fix/analysis, found something
> else, which seems related to the no-initial-commit feature which is
> recent default in trunk.
>
> ...
of course, forgot something:
This is fossil version 1.30 [619fa857c9]
On Tue, Jul 22, 2014 at 10:27 AM, Andy Bradford
wrote:
> Suggestions?
>
Only one: Keep it up! That was impressive investigatory work! It seems to
me that you've discovered that fossil does indeed (unintentionally) support
a form of branch-specific sync ;).
--
- stephan beal
http://wanderi
Hello,
while toying around with Andy Bradford's fix/analysis, found something
else, which seems related to the no-initial-commit feature which is
recent default in trunk.
(FWIW, I know there have been flaws in this area before, and although
I am not a dev having/willing to deal with them, I agree
Thus said "Andy Bradford" on 12 Jul 2014 13:36:58 -0600:
> 2) The artifact rid was in the unclustered table, but when
> create_cluster() ran it prematurely removed it from the table.
I have been able to successfully reproduce/cause this. When a large
number of artifacts are bein
47 matches
Mail list logo
