On Fri, Oct 18, 2013 at 10:24:41PM +, Mihail Zenkov wrote:
> Thanks Jochen! This implementation really tiny and useful for many
> people. Maybe we can create st-sb branch for it (like before for utf)
> ?
It is a complicated point. A lot of people like it a lot, and a lot of
people hate it a lo
"Roberto E. Vargas Caballero" wrote:
> It is a complicated point. A lot of people like it a lot, and a lot of
> people hate it a lot, so I don't know what is the next step here. As far as
> I know there are these solutions:
>
> - Ignore the patch
> - create a wiki where publish these kind of patc
2013/10/19 Mark Edgar :
> A series of patches for consideration.
>
> The first patch is purely aesthetic: it cleans up column headings (comments)
> and internal tabs in the shortcuts/key/mshortcuts tables in config.def.h. It
> also renames the fields in Key to match the nicer names given in
> confi
On Sat, Oct 19, 2013 at 02:39:14AM +0300, Otto Modinos wrote:
> You can use shift+{pgup,pgdown} to scroll in the linux tty.
>
Well it seems it does not work for me on raspberry, not that it is a huge loss,
as I said I got used to this.
On Fri, Oct 18, 2013 at 11:49:07PM +0200, Markus Wichmann wrote:
> Hi all,
>
> Now my question: Does someone here have a personal vendetta against
> S_ISVTX?
Not me, unless anyone objects, feel free to send in some patches.
Thanks,
sin
> I wouldn't have thought scrollback editing was generally seen as
> useful - why would people want that? Scrollback history files also
> don't sound that interesting.
I always thought the way people use 9term and edit and then re-send
certain commands is great. But the more I used it the clearer
HTML is there, other kinds of XML are avoidable. SVG is irrelevant,
cause nobody uses it.
Don't forget: you don't need to read XML specs to write working HTML.
On 10/19/13, Alexander S. wrote:
> 2013/10/18 Dmitrij D. Czarkoff :
>> Szymon Olewniczak said:
>>> Another advantage of XML is its adapta
Roberto E. Vargas Caballero said:
> What should we do?
May it be isolated so that it could be enabled/disabled during compilation?
--
Dmitrij D. Czarkoff
On Sat, Oct 19, 2013 at 05:00:44AM +0400, Alexander S. wrote:
> 4) we need some standard way to separate file names in a stream.
> Basically, ^@ is our only refuge, because path can contain any other
> character. But maybe newline is good enough?
Why not just play it safe? Would it really add any
Alexander S. said:
>> SVG and MathML are probably the best arguments against XML ever. I am
>> yet to see two SVG libraries that would render sufficiently complex
>> spec-complient SVG equally. And I have no hope for seeing any
>> spec-complient SVG rendering library ever.
>
> I'd not agree that SV
Szymon Olewniczak said:
>> s/HTML/XML+XSLT/g is quite a revolution.
> But it's something whitch I can use in my application straight away
> without forcing user to change their web browsers.
You aren't really about replacing HTML with XML+XSLT; you are about
*generating* HTML with XML+XSLT, are y
Apologies for the spam, some typos here… though you likely knew what I
meant.
On Fri, Oct 18, 2013 at 10:41:55AM -0400, Alex Pilon wrote:
> No. ‘du -0 | cut -f 2-’, at least.
`du -a …`
> du -a \
> | cut -f 2- \
> | while read -rd f; do
`while read -rd '' f; do`
Still not portable outside o
On 2013-10-19 11:47, Alex Pilon wrote:
> On Sat, Oct 19, 2013 at 05:00:44AM +0400, Alexander S. wrote:
> > 4) we need some standard way to separate file names in a stream.
> > Basically, ^@ is our only refuge, because path can contain any other
> > character. But maybe newline is good enough?
>
> W
I loathe XML, but I think the OPs bigger point was: hey look, here is
a way that we can try and create a space between the suck of the web
and our code. So we support browsers through XSLT, and do something
slightly more sane with XML. I think that's a pretty valid suggestion.
IMO, this doesn't go
Evan Buswell dixit:
>playing with that adds symbolic references and uses binary instead of
>utf-8 strings); RST is better for structured text---though I'm not
Oh yeah, let’s all do binary now instead of passing around plaintext!
Wait. No!
Pointing out Unix/Plan 9 way works just fine,
//mirabilo
Evan Buswell said:
> But OTOH, I do like the idea of separating the translation-to-html bit
> from the generate-sensible-output bit. XSLT may have done this poorly,
> but it's on the right track (and what else works better for this, Awk?
> Perl? m4?). I mean, I take the point that we can't really m
It's still UTF-8 in practice. It's just IMO not the job of parsers of
this sort to start enforcing or translating the character set of
strings. All the parser has to look for is \" " and \\. I can care
that this is UTF-8 when I need to, and not care otherwise. I didn't
start replacing commas with n
Evan Buswell said:
> I can care that this is UTF-8 when I need to, and not care otherwise.
I would love to see the code that detects whether you care or not.
--
Dmitrij D. Czarkoff
I'm really not saying something very profound here, so I'm a bit
confused by the sarcastic response. For certain things it's pointless
and inefficient to parse something and then deparse it later. It's not
like you're gonna put UTF-8 parsing into cat.
On Sat, Oct 19, 2013 at 4:33 PM, Dmitrij D. Cz
Evan Buswell said:
> I'm really not saying something very profound here, so I'm a bit
> confused by the sarcastic response. For certain things it's pointless
> and inefficient to parse something and then deparse it later. It's not
> like you're gonna put UTF-8 parsing into cat.
This brings you int
Evan Buswell dixit:
>like you're gonna put UTF-8 parsing into cat.
cat is just a sendfile, it’s not doing anything with the content.
On the other hand, for a data exchange format, some measure of
data types is a commodity. JSON is not binary-safe, true, but the
Unix/Plan 9 way doesn’t need it to
21 matches
Mail list logo
