OK. You completely miss the point.

Emacs' shell wrapper is just that: shell wrapper. Typing anywhere but at command prompt makes no sense. Command goes at the bottom. Output after it. Command at the bottom. Output. Rinse and repeat. You can't have (a) commands/outputs out of order, (b) non-shell commands or (c) re-execute in-place part of output as command.

Probably you simply never met with such problems so it is hard for you to even realize where from I'm (and apparently authors of xiki are) coming.

Well, you really have to try it first to understand the difference.

Browsing a directory in VIM - ':E' - shows you the content of directory in a buffer. What xiki demo shows is more of ^X^F (because you edit the path right in the editor window, with the rest of your text) but allowing you to actually dynamically run ^X^F on different parts of the dir/file name, changing content of the window accordingly. IOW, while ':E' is a dedicated browser, xiki does something like ^X^F to allow to edit/browse/etc inline, right in the middle of the text file, at any time when you need it.

And that's where the "innovation" comes. The tools to do all the things exist. But they all have different (and typically graphical) user interfaces. Xiki/etc try to combine the tools by putting them into an text editor, and making their output interactive and/or ready to be fed to the another tool. Because despite all the chrome, the basic nature of the content of the editor's window doesn't change: it is plain text. Commands are just text lines. Output are just text lines. It all becomes alive when special macro is run, which looks at the current line and tries to decide what to do with it.

Another way to look at it, and the way I often use my VIM hack, is that the same text file serves dual purpose: it is at the same time the script and the output of the script. The script and its output are interleaved. (That for example allows a very nice minor perk: rerun any command, flip between undo/redo and see the differences between then and now.)

I can't. Because I do not use Xiki. I use something much simpler coded in VIM.

But the paradigm as I use it, in VIM terms: the command and the output are kept in the same editor window. You can apply exiting VIM functions to both - commands and output. You can save and load both at the same time - since in the essence it is an ordinary text file. With a special ':g//' I can rerun all the statements in file at once. Or I can selectively rerun only particular ones by the mask. I can ':w' and it is all made persistent. (My small creation was born first as a text file to keep the shell pipelines I use often. But with a VIM macro I have integrated also the output of the commands into the file. And then I given names to the commands. And then I allowed in pipes to refer to other pipes by the given names. After adding folding, it is still mostly looks like a text file with shell pipelines. Replaced bunch of terminals I used to keep open to run small monitoring/diagnostic commands. And a calculator, which I use most often (iow, a text file full of formulas, which I can copy/paste/modify and recalculate).)

Xiki, being a cross of Ruby and a text editor, apparently does more: it recognizes and presents as interactive not only the shell commands, but also the file system hierarchy, the Ruby code, the SQL statements, the CSS, the HTML, and probably more.

I already do something similar in VIM, and xiki is far from been the same as ":r!". You probably should watch the first screencast.

The xiki thing is basically a Ruby shell, with built-in free-form text editor. But primarily it is a wrapper around the Ruby. Thus it limits its appeal to mostly Ruby users and developers.

The concept is definitely interesting. It basically brings back to CLI some capabilities that many have given up to GUIs. Adding something like this to an editor like VIM is definitely possible, but not trivial, since VIM's support for scripting and scripted buffers is very limited.

OTOH the xiki reminds me of what Emacs does to the shell prompt. Unfortunately, Emacs' integration with the shell ends with the repetition of commands and copy-paste from the buffer. Xiki goes a step further.

The test is ridiculous.

In any (Perl) program more complicated that helloworld (and in Perl terms that could be already pretty sophisticated piece of code) most of the time would be spent on calling functions.

All the test accomplishes, is testing how well Perl itself is implemented. And that we know already. (This test is basically biased against Java, or in fact, any language with immutable strings. Java just tops it off with slow IO.)

That's the problem: performance of Perl5 with any kind of largish framework would be pretty miserable because Perl's interpretation model is not designed to handle it.

Literally all interpreters decades ago went with p-code interpreters - and only Perl5 is still stuck with the traditional interpretation by (slightly optimized) syntax tree.

In my personal tests I have seen a clear dependency between performance and the size of optree: larger the optree, slower the code.

With any kind of sizable framework, the optree would be enormous. While bytecode allows for more aggressive optimization (inlining or IPO or profile based optimizations; after all, bytecode is just data), optree is very hard to modify (it is structured and inter- and intra-linked).

Remote display is used only if you are locked into the Windows. And comes with bunch of little problems, of which stuck keys and broken clipboard (until server restart) are though most annoying, the least. Recently admins where I work had to reboot PDC simply because a disconnected remote session got stuck and server didn't allow new sessions because RDP supports only one session.

But that's on Windows, where people have no choice. On *NIX, there is no good reason to choose RDP/VNC over X+ssh. But if you wish, you can RDP/VNC too.

Do you even know what you are talking about? Wayland's official statement is that network support is out of scope. Because Wayland is an interface to *local* graphical subsystem.

As network support goes, Wayland has only recently gained support for the X protocol (aka X Server can use Wayland as a display driver).

That's just ridiculous. Since when the reliability is measured in how many petabytes can be written?

Spinning disks can be forced into inefficient patterns, speeding up the wear on mechanics.

SSDs can be easily forced to do a whole erase/write cycle just by writing single bytes into the wrong sector.

There is no need to waste bus bandwidth with a petabyte of data.

The problem was never the amount of the information.

The problem was always the IO pattern which might accelerate the wear of the the media.

You linked to the list of bugs *fixed* in 3.6

Vast majority of the later bugs were actually caused by the major internal redesigns starting with the version 4: new JS engine (which changed 3 or 4 times) and reworked layout engine. And IIRC there was even one UI security bug, where web-site could trick new FireFox into displaying green verified label for a compromised site.

I'm not saying that 3.6 is perfectly secure. But with AdBlock, FlashBlock and NoScript, it is probably more secure than the recent FireFox out of box. The add-ons cut off the major exploit vectors at the root.

Just where it is in 3.6.

In 29+ the option simply isn't available.

That sounds interesting. Tell me more.

Can one place the close button on the right side in the tab bar? So that I do not have to look at the specific tab in the tab bar while closing tabs in a bulk?

Comparing recent Chrome and FireFox versions, the only real difference is that Chrome still doesn't have a properly functional AdBlock.

But some animations used by web sites are smoother in Chrome, while still jerky in FireFox.

If you do not use AdBlock, or want smoother graphics at cost of ads, keep the Chrome.

If you want AdBlock, then use FireFox.

If you want just a reliable browser, and you are on up-to-date Windows, then better use IE. Ironic as it is, YouTube works better in IE (and FireFox) than in Chrome.

Brrrr.... Close button is still on each tab... The annoying "+" new tab button irrationally placed in the tab bar... Brrr....

Unpredictable and unreliable UI is as unpredictable and unreliable as always.

Care to elaborate what are those customization options?

I have the 29 on my Ubuntu VM, and I see much much less options than, e.g. my desktop's 3.6.

Or just install the 3.6. Works too.

I'm not sure about the whole scope of the lay off, but many of the departed were translators and testers. Definitely not "paper pushers".

(My office is near. Some people stopped showing up for the lunch breaks. Asked few other neighbors and learned that Nintendo in the location laid off 160 out of 600.)