and syntax highlighting. two rabbits with one shot (sorry, glenda)
On Thu, Mar 13, 2008 at 8:52 PM, <[EMAIL PROTECTED]> wrote:
> >> cpu% grep home crash.txt
> >> take me back home
> >
> > http://mirtchovski.com/screenshots/ffmpeg.gif
>
> A question in total innocence: What does Vim really buy you?
it buys you a negative. I won't have to hear people whine a
>> cpu% grep home crash.txt
>> take me back home
>
> http://mirtchovski.com/screenshots/ffmpeg.gif
A question in total innocence: What does Vim really buy you?
++L
> That might be an interesting case for Plan 9 GCC port - May I also
> suggest XeTeX? I didn't check it fully, but it directly uses
> TrueType/OpenType fonts. Unfortunately, it outputs only PDF or it's
> own internal xdvi format (incompatible with normal dvi).
Slighty, but not altogether off topic
A question for Jonathan et al.: What is required of an operating
system to port XeTeX to it successfully? A C compiler? C++?
OS-level support for OpenType? Is porting freetype sufficient? A
different library?
I'm asking mainly because of Plan 9, a UNIX-like OS with a C compiler
(but no C++) t
It may be difficult. XeTeX needs a fonts management layer to handle
Truetype/Opentype fonts, such as fontconfig in Linux.
I am not sure if there is such a library in Plan9.
On Fri, Mar 14, 2008 at 6:12 AM, Paweł Lasek <[EMAIL PROTECTED]> wrote:
> That might be an interesting case for Plan 9 GCC p
That's great! Thank you for your work.
On Fri, Mar 14, 2008 at 12:33 AM, stefanha <[EMAIL PROTECTED]> wrote:
> I am porting Vim and have made the first tarballs available. See
> http://vmsplice.net/9vim.html.
>
> If you are interested, please try it and let me know how it goes. It
> is usabl
i submitted a patch, ahciupd2.
- erik
for your ahci hba:
it appears that i am delinquent in submitting patches. i think
that your vid/did combination is not in the sources driver. there
are also some other fixes that also need to be applied. i'll try to
get this submitted in the next few days.
for your ethernet driver:
i'm not sur
On Wed, Mar 12, 2008 at 6:54 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> > Just for kicks, I have tried rebuilding another kernel with the fresh
> > sources and this modified sdiahci.c but it fails with the errors
> > attached in build.txt.
>
> the build warnings are harmless. it has to do
> cpu% grep home crash.txt
> take me back home
http://mirtchovski.com/screenshots/ffmpeg.gif
That might be an interesting case for Plan 9 GCC port - May I also
suggest XeTeX? I didn't check it fully, but it directly uses
TrueType/OpenType fonts. Unfortunately, it outputs only PDF or it's
own internal xdvi format (incompatible with normal dvi).
On Wed, Mar 12, 2008 at 7:17 PM, Joel C. Salo
So it turns out that I can build a kernel that will boot Axel's old
paqdisk without a problem, but if I use my own kernel with my own
freshly created paqdisk, I get the crash below:
root is from (paq)[paq]:
paq...paqfs: sysfatal reading block: /dev/flash/ramdisk:
version...panic: boot process
On Thu, Mar 13, 2008 at 11:58 AM, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
>
> Hi folks,
>
> as abaco doesn't yet have CSS support, I intend to write some
> tiny CSS parser/loader.
>
> If we represent the CSS contents as an tree structure, we basicly
> have these node types:
>
> * media type
On Thu, Mar 13, 2008 at 3:24 PM, andrey mirtchovski
<[EMAIL PROTECTED]> wrote:
> i thought :colorscheme only worked for vim -g :)
>
> oh well, here's a reproducible bug:
>
> start vim, type :colorscheme ron (or whatever you like from
> /lib/vim/vimfiles/color/), hit 'i', try to type some text. c
On Thu, Mar 13, 2008 at 10:55 AM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> plan 9 supports utf16. that is codpoints u+ — u+f.
To be pedantic, UTF-16 has the ability to represent characters in the
'astral planes' via surrogate pairs (pairs of character in the range
U+D800–U+DFFF); Plan
> it would require recompiling everything,
> but i don't believe it would require changes
> to code beyond the utf routines in the c library.
> i do not believe there are many places (if any)
> that presume to know the value of UTFmax.
you just pointed one out yesterday -- in devatach().
- erik
> plan 9 supports utf16. that is codpoints u+ — u+f. there is no
> support for 32bit characters.
this is correct except for the use of the term utf16,
which is a character encoding, not a character set.
the subject line is correct - plan 9 doesn't support
codes beyond the BMP.
> to sup
i thought :colorscheme only worked for vim -g :)
oh well, here's a reproducible bug:
start vim, type :colorscheme ron (or whatever you like from
/lib/vim/vimfiles/color/), hit 'i', try to type some text. crash log
attached.
parr% vim
vim 383: suicide: sys: trap: fault read addr=0x4 pc=0x0014181e
> so, is the color scheme fixed? can we get something resembling gvim's
> "delek" color scheme (black letters on white background, light grey
> selections)? that would make vim stand out against everything else
> much less.
"colo delek" in $home/lib/vimrc doesn't seem to work
but "colo evening" d
so, is the color scheme fixed? can we get something resembling gvim's
"delek" color scheme (black letters on white background, light grey
selections)? that would make vim stand out against everything else
much less.
> PS: Please avoid flamewar :).
too late!
- erik
you are my hero. now do the same for firefox ;)
no, seriously: thanks for the effort!
I am porting Vim and have made the first tarballs available. See
http://vmsplice.net/9vim.html.
If you are interested, please try it and let me know how it goes. It
is usable, but do not rely on it yet.
Things that currently do not work:
* Shell execution (including :sh, !, :make, vimdiff, man
there was a fontfs years ago.
Oleg was working on the abaco port, he tweaked some stuff yesterday
you can get it from http://abaco.oitobits.net
On Thu, Mar 13, 2008 at 11:33 AM, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
> * Enrico Weigelt <[EMAIL PROTECTED]> wrote:
> >
> > now another problem:
I see. Thanks.
On Thu, Mar 13, 2008 at 10:55 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> plan 9 supports utf16. that is codpoints u+ — u+f. there is no
> support for 32bit characters. to support larger characters, the starting
> point
> would be changing Rune from ushort to ulon
plan 9 supports utf16. that is codpoints u+ — u+f. there is no
support for 32bit characters. to support larger characters, the starting point
would be changing Rune from ushort to ulong and changing constants like
UTFmax and fixing chartorune and runetochar. (and finding all the places
Hi folks,
as abaco doesn't yet have CSS support, I intend to write some
tiny CSS parser/loader.
If we represent the CSS contents as an tree structure, we basicly
have these node types:
* media type: container for holding media-specific data.
per default we're operating in "all". to make it
* Enrico Weigelt <[EMAIL PROTECTED]> wrote:
>
> now another problem: abaco expects some fonts in
> /usr/local/plan9/fonts.
>
> Seems we need some convenient way for relocating fonts.
> Maybe an even an fontserver ? ;-)
I've now manually tweaked the pathes in the source, but this
isn't really a
Hi,
I did an experiment to test if the programs in Plan9 could support the
codes beyond Unicode-BMP.
The result is not so good.
Let's repeat it:
Take U+01000 code for example. Create a file and fill it with only
one character U+01 encoded
in UTF-8.
Note that It is could be done with Vim on
> There's already something wrong here -- if spec contains bad
> UTF then buf will overflow all the time.
that's a good gotcha! i'd have naively assumed that
sprint(buf, "%s", s) was equivalent to strcpy(buf, s).
i wonder how many other bits of code are potentially broken because
of this.
31 matches
Mail list logo
