Xiki: A shell console with GUI features. | Hacker News Reader

Xiki: A shell console with GUI features.

xiki.org

366 pointsrkrkrk21118 comments

The home page needs bigger calls to action. I wasn’t confident about the screencast link being useful because it was so small. I also had to hunt for the installation link – it turns out it’s under the “Code” section.

The “hero unit” at the top should contain a big link to install it (appropriately worded to indicate that it’s just sending you to instructions in a README on GitHub). Another big button link to the screencasts would probably help, since most people won’t understand what Xiki is without them. Alternatively, have a “features” page with a list of features and large, static screenshot demonstrating each of them.

Great advice, thanks!

agreed. put a video on the homepage

Here's a direct link to the screencasts (which I totally missed the first time I checked the front page).

http://xiki.org/screencasts/

Yeah, I love the idea, but I had to hunt for the install for a while too.. For a second I started to wonder if this was another good kickstarter idea that was unlikely to ever come to pass... very happy that is not the case.

Or how about at least some idea of what doing whatever you'd be doing, does? For example:

"Type and double-click Type a word, any word. Then double click on it or type control-return (or command-return). For example type: git, bootstrap, mysql, mongo, rails, node, coffee, js, dom, jquery, svg, ruby code, file paths, url's, shell commands, etc."

I can type and double click on any word in this text box. It doesn't do anything, but I can poke at them all I want. Or, how about this:

"Wiki inspired Everything is editable text. Type commands anywhere. Edit the output. (Vs. typing commands at the bottom, and read-only output.) Intermix menus, headings, bullet points, wherever you want. Xiki == executable wiki."

Why would I want to do any of that? Edit the output of commands?

Maybe I lack imagination, but even though the tool provides many interesting solutions, it doesn't seem to "scratch an itch" for any problems I need to solve.

The screencast narrator asks a number of intriguing "what if you could XYZ" questions, but it doesn't actually answer them, leaving the listener to come up with useful applications. Well, what if I could do all those things? I would like to have heard more about what higher-level problem(s) these solutions address, and why these are better solutions than what I'm already using. Something motivated the developer(s) to write this, but I can't immediately tell what that motivation was.

You don't lack imagination, but I bet you didn't really try to think about what you could do.

When you first dive into Linux, you learn that you have a thousand different simple commands. And you feel kinda lost. Then you start using them in ways their programmers never imagined. And you chain them with pipes and do some really cool shit.

You do that because nobody told you what they were for, they just were.

You do that because nobody told you what they were for, they just were.

I do that because I've seen previous examples of these things, often cases of solving a real problem, and then go from there.

Yes there are times I see some set of tools and just mess with them and make stuff up, but really I only have so many hours in a day for that and other things.

FWIW I think most people dive into Linux because they already had an idea of what they expected it to do for them.

Perhaps Xiki really can do assorted cool and novel things. Or maybe it just does familiar things in a cool way. That's much less interesting to me.

Your mentioning people “start[ing] using [commands] in ways their programmers never imagined” reminded me, a shell newbie, of something I had read a long time ago, which was that people who use `cat` to output a single file’s contents are using the program for something other than its intended purpose. That inspired me to experiment to find the correct way of echoing file contents.

I think the correct way is the `<` operator. `>` writes to a file, and `<` is the inverse, so it reads from a file. One shouldn’t `cat some-file.txt` or `cat some-file.txt | wc -l`; one should `< some-file.txt` or `< some-file.txt | wc -l`. `cat` is only necessary when you supply to it multiple arguments, as in `cat first-file.txt second-file.txt`.

Of course, `cat` still works for outputting file contents, as it has for me all this time. But it just feels more “right” and “safe” to use the operator that is built for that purpose.

I just wanted to mention that discovery in case anyone else wondered the same thing when they read the words about using commands in unintended ways.

Given the proximity of `<` and `>`, and the fact that `> somefile.txt` will silently truncate the file, I would take issue with the "safeness" claim :P

Also, `< file.txt | wc` doesn't work (at least not in bash; zsh (my install/plugin combo, at least) apparently tries to map the lone `< file.txt` to `less -R file.txt`...which spits out an error. Anyway, omitting the pipe will work: `< file.txt wc -l`

`cat` by definition concatenates one or more files and spits the output to stdout, so using it on a single file is perfectly within the bounds of its definition (IMHO; I realize people get really zealous about this type of thing and I'm not trying to start a war).

> and the fact that `> somefile.txt` will silently truncate the file

Bash has the "set -C" option to toggle on "no-overwrite" mode for redirection operators.

But it's obnoxiously not set by default.

This might screw up some POSIX shell scripts if they expect to be able to write a tmp file or overwrite one if it already exists.

zsh also has a "setopt NO_CLOBBER", but it's also not the default (unfortunately).

Default behavior:

  % touch foo
  % echo bar > foo
  % cat foo
  bar
  % rm foo

No clobber mode:

  % setopt NO_CLOBBER
  % touch foo
  % echo bar > foo
  zsh: file exists: foo

Manual override:

  % echo bar >| foo
  % cat foo
  bar

Cat catenates, it doesn't nearly always concatenate :-)

    $ < some-file.txt | wc -l

doesn't work. You should run

    $ wc -l <some-file.txt

Although in most cases the program you're using is capable of reading from both stdin and from a file. So you'd really just run

    $ wc -l some-file.txt

When you see characters like '|', '<', and '>' the things you're playing with are called pipes. (There's a decent wikipedia article on 'Pipeline (UNIX)' that talks more about them) Having tons of commands that do specific things wouldn't be very useful if you couldn't compose them (in the function composition sense), and pipes are the tools you use to combine them. This is where the 'using commands in ways never imagined by their authors' really comes from.

To be pedantic, > and < aren't pipes, only | is. A pipeline means that stdout of the first program is stdin for the next program. > and < set stdout or stdin to a file, not another program.

http://en.wikipedia.org/wiki/Pipeline_%28Unix%29

http://en.wikipedia.org/wiki/Redirection_%28computing%29

I assume he meant:

  $ < some-file.txt ws -l

(without the pipe). '<' works at the beginning of the command just as well as it works at the end, meaning you can basically do:

  s/^cat \(.*\)|/\<\1

cat will actually launch a separate process, while redirection will not. Unless you're working on a very old machine or a low-spec embedded system, this shouldn't make much practical difference.

"< some-file.txt | wc -l" doesn't work for me. "< some-file.txt wc -l" does. I actually wasn't aware of the latter syntax; and now that I think about it, I'm actually not sure if I've ever used redirection in combination with piped commands.

(I don't do a whole lot of shell scripting, and I exclusively used DOS, Windows, and OS/2 during my most formative years, so my reflex is to reach for an actual programming language to do nontrivial things, because even though I've been using Linux for years as my main OS, the fact that I now have a competent shell available still hasn't completely sunk in. I was amazed when I discovered the xargs command and its --max-procs option; I'd written a Python script to do much the same thing.)

There are other screencasts on xiki.org/screencasts that go into detail about specific scenarios. Some of them are a little out of date but the general idea is till the same. The one on web development is decent but needs an update. More screencasts to come soon.

I've gotten similar feedback, re imagining what it would be used for. The simplest use case is probably the "shell terminal but better" one. You can narrow down the output of shell commands, and make reusable files with notes as you run stuff (for yourself to use later on, or for other people). You can nest the commands underneath directory paths to avoid having to CD. You can change parts of the paths to re-run the same commands in a parallel dir structure in a different place (even a remote server). You can search command history in a specific dir and re-run commands (vs bash history showing you commands that were run in any dir). You can post any notes you made on the web or email them to people, for others to help others get started using stuff.

Going a bit higher-level, Xiki sort of lets you have "paths" (kind of analogous to url's) for many different things - database records, running commands in specific dirs, running a line of javascript in your browser, changing the style of a div, firing off a button click on a web page given its id, running unit tests, showing runnable (and modifiable) example code for various frameworks, etc. Most people probably agree that having paths for files and web pages is pretty useful. Having paths to other things can be useful for many of the same reasons.

As much as I love to see people iterate on the boring old command line, this will never catch on.

1) It's too difficult to remember all the tricks to make it useful, and the cost of memorizing tricks that I saw in the first screencast isn't worth the efficiency it provides.

2) It's too difficult for new users to remember the tricks that are supposedly "better." It's a lot like Python vs. Perl -- Perl is a really smart and clever language, but you can type just a few characters more to write Python and it'll be a lot clearer as to what's going on.

The one exception to all of this is the MySQL stuff I saw. The MySQL prompt has sucked for a long, long time, and building SQL queries is something you do iteratively anyway.

All of the above said, I still think this is pretty neat. But I won't use it.

Couldn't both of those complaints apply to, say, Vim, the golden child of HN?

One big difference is that Vim has been a de facto standard for a very long time, and it's ubiquitous - you can trust just about any server to have vim installed - so the investment to learn it has a much more guaranteed pay-off.

Unless you work in an all windows environment :(

My condolences. I know your pain.

Solaris has only vi. Not vim. :-)

I agree. In fact, vi is a standard UNIX utility - see the POSIX-1.2008 specification:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi...

vim is the most popular implementation of vi, with lots of added bells and whistles

I'd say learn vi first; then learn the vim bells and whistles.

I have resources for learning vi at http://www.verticalsysadmin.com/vi.htm

I'm really into improving efficiency and I enjoy teaching people how to use vi. The class materials are publicly available and are based on Bill Joy's original paper introducing vi:

Basic vi: http://www.verticalsysadmin.com/vi/class/

Advanced vi: http://www.verticalsysadmin.com/vi/class/advanced.html

My next vi class will be in Columbus, Ohio at Ohio Linux Fest in a couple of weeks (http://ohiolinux.org/olfi2012/classes/editing-with-vi)

There is rarely any point learning vi if you are only ever going to use vim. (On many systems, vi is just a symlink to vim anyway).

If I had a nickel for every time someone justified not using vim's features by invoking a bizarre imaginary scenario where they were using vi to twiddle bits on a downed snowflake machine, I could buy a few fancy coffees.

It may gain a following yet. There are two schools of thought when it comes to productivity tools such as shells, editors, and programming languages. Some think they should be optimised for ease of learning; others, instead for power and efficiency to those who already know them.

As a user of Emacs, Blender, and Perl, I’m probably in the latter camp. And this tool seems like something I might enjoy using. But I don’t think that, as a rule, things should be designed this way unless there’s a very good reason to do so, backed by user research. I would not design a programming language like Perl, for example, because “people who program” will always outnumber “programmers” and it’s best to cater to the majority.

I'm using "PLSQL Developer" at work instead of console prompt (sqlplus in my case), and it works in similiar way to xexi (but the results are in tabbed, excel-like grid in the bottom - you can edit it, sort, filter, etc, instead of right inside the main window). But the interaction is similiar to that of screencast - you write a few queries in the main window, click and CTRL+ENTER to run a query, you can at any time change them like in normal editor, or edit results and save them if you want.

It works great, much faster than regular prompt. Shame it's only for oracle db.

> 2) It's too difficult for new users to remember the tricks that are supposedly "better." It's a lot like Python vs. Perl -- Perl is a really smart and clever language, but you can type just a few characters more to write Python and it'll be a lot clearer as to what's going on.

Doesn't this same argument lead to the conclusion that new users won't use Perl over Python or --to put it more inflammatorily-- that Python killed Perl? This is surely demonstrably incorrect.

This is purely anecdotal, but learning Perl is currently on my backburner in part due to its reputation. I did use it a bit in a bioinformatics class, and I have edited a few small Perl scripts, but Python simply works for me. Perl's reputation, if you could call it that, has negatively impacted my desire to learn the language.

(Maybe I'm worse off for it? Who knows. I mean no harm and don't want to impinge on anyone's feelings. I just don't see myself picking up Perl anytime soon. Just my own two cents, FWLIW.)

So, it's Acme? or well not per se acme, but plan9 terminal style.

Exactly my thought. Executing any text anywhere, browsing directories with a clip, so much of that demo made me wonder if the author had ever seen Acme or if it was an example of parallel evolution.

Reminds me more of a Smalltalk workspace pane, except everything seems more disparate and random. It must be cool if you happen to use these particular tools, but I'd prefer something more minimalistic and generic, like the part where you can expand command output or execute it anywhere (just like in Smalltalk) or the part where you can assign on-click commands, and stuff like that. Something you can use for many different things. The rest looks overengineered and way too specific.

People have mentioned similarities with Smalltalk and other tools. If you know of a good screencast or something else that shows demos the Acme stuff it would be awesome if you could post the link in the comments.

http://www.youtube.com/watch?v=dopu3ZtdCsg is a good intro.

A Tour of the Acme Editor http://news.ycombinator.com/item?id=4533156

The plan9 shell is called rc:

http://doc.cat-v.org/plan_9/4th_edition/papers/rc

Yes, but the plan9 text editor/shell/IDE is called Acme: http://doc.cat-v.org/plan_9/4th_edition/papers/acme/

yes, but the shell isnt responsible for the terminal or the editing capabilities on the rio windows. unlike unix, plan9 has no ttys or cursor addressing or no ansi graphics.

everything is just (UTF-8) text.

the window system and acme allow you to edit whats on the screen. and theres a mechanism called the plumber that lets you execute various action depending on selected text.

see:

http://plan9.bell-labs.com/sys/doc/plumb.html

and

http://doc.cat-v.org/plan_9/3rd_edition/rio/

Previously posted:

http://news.ycombinator.com/item?id=4483750

http://news.ycombinator.com/item?id=3506613

As with the last time I tried it, it still doesn't work. Crashes right away trying to read from some tmp file.

Hmm, bummer. :( Join the google group and send the details. We'll get it fixed. http://groups.google.com/group/xiki

I guess I could give emacs a shot, just whenever I've seen people use it it looks like they're pressing a shitload of keys to do the most basic of stuff, despite having amazing macros to do rather complex stuff.

But aside from that, this looks fantastic, it'd be interesting to see if more text editors could be ported to it (e.g. Sublime Text 2)

In emacs, there is often stuff going on in the background that you may not notice by just watching somebody use it. For example, I could be setting the region, copying it and saving it to a register, when it looks like I'm just moving the cursor around a bit. This is true for quite a bit of the commands I use often. I also don't like having too much visual feedback, so it's even harder for others to follow what I'm doing.

Also, one you get used to the commands, it's often easier to use too many without thinking rather than planning out an efficient way to do something.

There’s a tradeoff involved. Sometimes the effort of planning is greater than that of doing it by hand. Usually I start a repetitive task, notice the repetition, then finish it off in a better way only if it’s less work than going on manually. There’s perhaps more value in noticing longer trends; for example, making a keybinding to duplicate the current line when you find yourself saying C-{a k k y y} more than is healthy.

You could also just do C-{a e Space y} ;)

I’m not sure what you mean.

Sorry, should've been C-{a Space e w y}.

Go to beginning of line, set mark, go to end of line, copy, paste.

I want to duplicate the current line, not just put it in the killring.

In ST2: Ctrl+C Ctrl+V (without anything selected).

It has been said that you can always spot an inexperienced emacs user because they haven't rebound the default key bindings yet. Not sure I agree with that personally, but it's certainly possible to come up with less keyboard intensive mappings if you want to.

Ah, yes, the old, "if you don't like the way it works, you have the freedom to change it," argument.

I'd rather start with something designed well enough that I am not tempted constantly to change it.

I tried using viper and vimpulse modes in emacs to get vim-style keybindings. The problem was that SLIME docs and most emacs tutorials assumed standard emacs keybindings.

In principle, you could convert all those docs and tutorials to use more vim-like keybindings, but that would be a lot of effort, and you'd have to learn emacs/SLIME with standard keybindings first.

Furthermore, if you rely on non-standard keybindings, you'd be completely lost when reading a conversation between typical emacs users, when they say stuff like "oh, just use C-X-a-b C-Y-c-d" or whatever (as they do in another post in this very thread).

For better or for worse, it seems the default keybindings in emacs are pretty tightly bound to its culture and ecosystem.

Sublime Text 2? Definitely :) http://www.sublimetext.com/forum/viewtopic.php?f=6&t=911...

Whilst you do need to learn the basic editing keys to get anything done in emacs, a lot of the time you just use M-x which opens an auto-completing input for you to type a command. Also the built in help features such as apropos make things easier.

Actually not even that is true for every version for emacs. Auqumacs for OSX supports almost all standard editor commands like

Cmd - s Cmd - z Cmd - Shift - z Cmd - c Cmd - x Cmd - v

The only thing that doesn't work reliable for me is

Shift - left/right

to mark text.

That's really interesting stuff.

I've got a hobby project that I work on on and off that's similar (although I'm a vim guy no evil mouse clicks) with a heavy org-mode influence. Some of the features you demo in your screencasts are inspired.

I'll be following Xiki closely and probably stealing some of your ideas for my own project.

Good work, I'm glad to see people experimenting with new ideas in modern keyboard based power user interfaces.

I'd be more inclined to try this if I saw some indication that the designer(s) had studied Plan 9 or the best Smalltalk GUIs.

I tire of trying out software with new bright ideas not informed by a knowledge of the best of the old bright ideas.

EDIT: added the 4 words in italics.

While it's annoying to see mistakes of the past repeated, I personally find it more interesting to see new things not influenced by older ideas. There are things only the inexperienced can imagine; too much experience bakes in assumptions about the world which may not be fundamentally true. Deep knowledge can lead to manipulation and assembly of prefabricated thoughts, rather than a reexamination of the underlying principles behind those thoughts.

I take the attitude you exhibit when I have an inexpensive way to evaluate the work in question.

When I install and test-drive new software, however, I am less open-minded because I know of no real way to evaluate the new software without spending a lot of my time and energy learning about it.

This is a good point. I can't comment on Plan9 or Xiki, but I believe this was how Linus went about developing Git. I remember watching a video where he discussed his complete ignorance about CVS and SVN, and how that was a blessing.

Having said that, it is a bit disheartening when somebody solves a problem which is solved almost exactly the same way as several other solutions.

Um. And he was not so ignorant of BitKeeper. I also had the impression that it was not so much about ignorance of CVS and things as it was about disliking the way they did things. But I would not know for sure...

Not that I would tell these guys to go about their business this or that way or anything. Whatever works for them and so on. Though it would obviously be helpful to know which things it is similar to and how it compares to them when telling people what it's like.

I think the talk you are referring to is tech talk he gave at google:

http://www.youtube.com/watch?v=4XpnKHJAok8

Scientists call this 'Related Work'.

This would be fantastic as a sort of "dev/ops live wiki/shell" for small IT departments. I already spend time writing shell scripts and wiki pages so that my coworkers can perform some of my job functions while I'm gone, this takes it to a whole new level where the shell script is the documentation is the dashboard is the README. It's glorious.

This looks cool, but I spent 20 minutes trying to get it running and couldn't make it happen. Maybe the next time it gets posted on HN, the installation process will be a little more mature!

I didn't post it this time:)

Join the Xiki google group and we'll get your problems fixed! The install has been tested on Lion and the latest Ubuntu and there are some reports of success. A few weeks back we shifted gears to get "gem install xiki" working and improve the install process.

I'm waiting on allowance on that, but I can say on Ubuntu 12.04, I am not able to use the instructions given.

Hmm, I just got it running in a VM on 12.04 a few days ago. I'll try it again.

Same here, also pinged you on twitter to see if you plan on being in #xiki anytime soon.

Getting ready to jump on a train, but I'll try to pop in in a bit.

Thanks, if i'm not there I'll try you there again tomorrow.

At the moment, I don't have the cycles to join the group and follow up on getting it resolved. But FWIW:

The installation appeared to proceed successfully, but when I started emacs, I got errors about "ignore-errors" being void, and there was also an error in one of the various buffers about not being able to find "el4r-setup". I'm running OS X Lion, I created a new rvm gemset with 1.9.2-p290 to do the gem installation, and I didn't have to "sudo" anything for any of the installation steps.

Also, your install documentation could do with more hints on what to do once it's installed to figure out whether it's working or not. I started emacs, typed "ls" and double-clicked it, but I had (and have) no idea whether nothing happened because I was doing something wrong, or because it was broken.

"Vim support is very partially implemented" Well bleh :)

Much of Xiki has recently been extracted out into the 'xiki' shell command though. So when the vim Xiki client works, a lot of stuff will work (most of the menus). It just needs to grab the path based on where the cursor is, pass it to the 'xiki' shell command, and insert the results into the vim window (indented 2 spaces lower).

If any vim user in the bay area are interested in getting together and pair programming on knocking this out, ping me on twitter! The current vim xiki proof of concept uses the vim ruby api, which is actually pretty decent.

If you're on a Mac, you install AquaMacs which is very mac-like (shift-arrow-key to select, type to replace, etc.) and doesn't require emacs skills.

Another option is for vim people is Viper mode, which emulates vim from inside emacs (a lot of people like it apparently).

Related note, I was pairing with someone on Monday at Proto Night (protonight.com) and we got a very simple TextMate xiki client mostly working.

Can you share the code for your textmate version please.

Cool, it's different from other shells out there. I am still waiting on TermKit to become 1.0. https://github.com/unconed/TermKit#readme

Given that TermKit's last commit was nine months ago, I wouldn't hold my breath waiting. TermKit was a good, thought-provoking design prototype but I don't think it really nailed the next-gen-terminal sweet spot.

Hadn't seen TermKit. Looks pretty sharp!

Excellent, really cool. On OSX, this is what AppleScript and Automator should have been.

Would it be possible to tap into GUI applications via OSX UI Scripting, and maybe mirroring the app's menus with Wiki menus?

Yeah, totally. Someone should do that. I've brainstormed about it with a few XCode savvy friends. It would be super-slick if it were integrated into the Finder windows. So, you could drill into the dirs to get to a Xiki menu, and then drill into the Xiki menus in-place right in the OS.

I just made a Shoes menu (shoesrb.com) yesterday, though it's not checked in yet. Clicking Xiki menus that bring up custom native UI windows seems like it could have a lot of potential, though haven't really explored it. Might be interesting to try a shoes native interface for Xiki menus.

Another possible direction... Xiki has a web interface that you can enable. So you can to http://xiki and navigate menus. It probably wouldn't be too tough to make a native OSX app with an embedded browser that displays it.

well, the integrated database shell looks nice, specially since it should work against different db systems

i think if they limit their focus on have one shell to replace anything that have a shell ... yet offer a better shell experience, they will have a winner

i believe they could be going to too many features so far that those comments comparing it to emacs seem to have a point ...

Among the things that this resembles, I would include Org-mode for Emacs. Org-mode's support for execution of embedded code blocks provides very similar functionality (ships as part of Emacs 24). http://orgmode.org/manual/Working-With-Source-Code.html

What caused me to decide not to learn org mode is that it expects me to learn many new "keyboard shortcuts". (I am putting the term in quotes because it is not the standard Emacs terminology for the thing.) By "new" I mean "keyboard shortcuts" that are specific to org mode and not present in the rest of Emacs.

This xiki thing on the other hand seems to have only a few new "keyboard shortcuts", and consequently I would be more inclined to adopt it if I gets more traction (hackers who have tried it and like it).

I know a lot of people here like to do everything with the keyboard, but I am not one of them.

FWIW: Org-mode overloads C-c C-c and tab to the point where just using those two keys you can perform a huge portion of the Org-mode actions depending on your context (including executing code blocks).

I seem to remember that there are many, many keyboard shortcuts unique to org mode.

I distinctly recall shortcuts unique to org mode for moving a subtree up and down relative to a list of subtrees all at the same nesting level -- an operation done by dragging with the mouse in many or most other outliners. I know the dragging interface is harder to implement, but I find it more ergonomic.

I've been aware of Org Mode for a while. It's very slick. Sort of different philosophy but a few similarities (textual syntax for nesting / running commands, etc.).

That looks very promising and I'll surely give it a try. My goal would be to accelerate my current (ba|z)sh workflow to type commands. Sadly, it's not very effective. (Mostly using ctrl-p for last, ctrl-r to find previous command..)

Something interesting I see would be having a .project file in the repository where all the common commands are written. That would be a mix between a cheatsheet and a wiki. For instance, for django, you would have a Database section with some commands. which could dynamically be adapted to the current project. (Database or table names, etc.). Or, if south isn't installed yet, we could see the command to initiate it.. but then, it'll simply be the command to --auto migrate stuff.

Anyhow, really promising and I'm excited to give it a fair try.

The last time I saw this posted I installed it on 2 computers. One was running Mac OS 10.8.1, the other BackTrack 5r2. I have it installed on both and the command xiki-status returns "running" but I have not got it properly implemented in any text editor. I have tried in emacs and vim on both. If anyone gets it to work, especially in vim on Mac (which is very limited), please let me know as the instructions are not helpful, there is no helpful discussion on website and and the only option is to file a bug report. My problems aren't a bug, they are lack of info available.

I'm in the same boat. Should try to get anyone with desire to figure this out on freenode #xiki

> I have it installed on both and the command xiki-status returns "running"

That looks promising. Does like "xiki ip" work?

> the instructions are not helpful

Definitely upgrade so you get the latest gem, as the instructions have been updated lately. If you're still seeing errors join the google group (groups.google.com/group/xiki) and we'll get it figured out!

It's like Emacs... only not. ;-)

The plural of "URL" is "URLs". No apostrophe.

Looks like a neat idea. Not entirely clear what the "cmd-return" is supposed to do. Run a command?

> Not entirely clear what the "cmd-return" is supposed to do. Run a command?

My thought exactly. The website tells me to try the combination, as if advertising a feature, but never ends up telling me what the feature actually is..

Cmd-return "launches" whatever line the cursor is on. It's analogous to what return does in a shell console. Ctrl-return and double-clicking do the same thing.

When you launch a $... shell command it executes it and inserts the results. When you launch a url, it opens it in the browser. When you launch a dir path it lets you navigate the dir contents, etc.

Reminds me of the ipython notebook.

I saw a screencast of that lately. Pretty awesome stuff.

I like how it embeds of graphs in the text flow when working with pyplot, instead of opening a zillion windows.

Reminds me of a mathematica notebook, but I've never used ipython.

Characteristic of editing via Modes, previously seen: The Mother of All Demos: http://en.wikipedia.org/wiki/The_Mother_of_All_Demos

Are we going to see more of a return to Modal editing?

Works fine for me, for both aquaemacs and macvim. cool idea, still not sure how I can use this yet, but will give it more tries.

the doc need more details, still do not know how to save a menu.

It looks great, but is commandline about not touching the mouse, isn't it ?

No, the command line is about executing textual commands. Whether you use a mouse, a touch screen, speech recognition, a keyboard or something else to do that job is entirely up to you.

How does it work with environment switching tools like rbenv, rvm ?

my only concern is it looks messy. output is all over the place

You can type to narrow down after running anything. And its all just text so you can delete whatever you want, to narrow down the output (not practical on most shell consoles).

The Screencasts page seems broken in Chrome?

update: works in Safari though.

Download links?

It's github.com/trogdoro/xiki (under "Code").

Or you can do "gem install xiki" and it will guide you through setting it up.

This looks superb -- inspired by MPW?

Never used MPW nor seen it in action, but many people have told me there are similarities. Being able to type stuff and double-click on it, I think.

I'm working on making a page that highlights similarities between Xiki and various tools / paradigms.

One neat feature: you could specify regions of a window (text document) as a separate file, so you could perform redirections to and from. Of the window was "Fred" you could, eg:

Echo "main() {}" > {Fred}.$ cc -o mything {Fred}.$

(Of note, the actual syntax included high bit MacRoman characters, so you were actually using the "section" glyph rather than $)

MPW's unification of a command shell and an edit window took a little getting used to, but it was really, really useful once you learned the single trick. (Not to keep you in suspense: the ENTER key just inserted a newline, while COMMAND+ENTER executed the current line, or whatever was currently selected).

To this day I miss this ability on command shells. On Windows there is lame cut-and-paste (and it's disabled by default). It feels like cement galoshes, all that dead text just sitting there on the screen, useless and flat.

Hmm, someone is reinventing Emacs.

Yes, god forbid someone does that...

Let's have a Xiki.

Reply on news.ycombinator.com