
Xiki: A shell console with GUI features. - rkrkrk21
http://xiki.org/
======
roryokane
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.

~~~
trogdoro
Great advice, thanks!

~~~
lurchpop
agreed. put a video on the homepage

------
davidp
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.

~~~
vasco
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.

~~~
roryokane
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.

~~~
brian_cloutier

        $ < 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.

~~~
sciurus
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>

------
aiurtourist
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.

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

~~~
TallGuyShort
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.

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

[http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi...](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html#tag_20_152)

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>)

~~~
slurgfest
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.

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

~~~
jff
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.

~~~
trogdoro
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.

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

------
jamesbritt
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.

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

------
antihero
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)

~~~
regularfry
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.

~~~
gnosis
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.

------
freshhawk
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.

------
hollerith
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.

~~~
barrkel
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.

~~~
pserwylo
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.

~~~
Garoof
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.

------
bithive123
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.

------
mcantor
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!

~~~
trogdoro
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.

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

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

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

~~~
trogdoro
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.

~~~
tylerlarson
Can you share the code for your textmate version please.

------
nadinengland
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>

~~~
saidajigumi
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.

------
ned
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?

~~~
trogdoro
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.

------
systems
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 ...

------
eschulte
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>

~~~
hollerith
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.

~~~
eschulte
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).

~~~
hollerith
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.

------
d0m
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.

------
Bro_Merch
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.

~~~
trogdoro
> 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!

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

------
wffurr
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?

~~~
tarice
_> 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..

~~~
trogdoro
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.

------
gdw2
Reminds me of the ipython notebook.

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

------
platz
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?

------
GrandTheftR
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.

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

~~~
Derbasti
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.

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

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

~~~
trogdoro
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).

------
focuser
The Screencasts page seems broken in Chrome?

update: works in Safari though.

------
hcarvalhoalves
Download links?

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

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

------
bonaldi
This looks superb -- inspired by MPW?

~~~
trogdoro
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.

~~~
salgernon
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 $)

------
ericmoritz
Hmm, someone is reinventing Emacs.

~~~
batista
Yes, god forbid someone does that...

------
ericbogs
Let's have a Xiki.

