I get the following error:

$ cargo test
    Updating git repository `https://github.com/gchp/rustbox`
    Updating registry `https://github.com/rust-lang/crates.io-index`
    Updating git repository `https://github.com/gchp/termbox-sys`
 Downloading docopt v0.6.16
   Compiling termbox-sys v0.0.2 (https://github.com/gchp/termbox-sys#e8352762)
   Compiling docopt v0.6.16
/Users/ruipacheco/.cargo/registry/src/github.com-1ecc6299db9ec823/docopt-0.6.16/src/parse.rs:45:34: 45:40 error: unresolved import `std::collections::hash_map::Vacant`. There is no `Vacant` in `std::collections::hash_map`
/Users/ruipacheco/.cargo/registry/src/github.com-1ecc6299db9ec823/docopt-0.6.16/src/parse.rs:45 use std::collections::hash_map::{Vacant, Occupied};
                                                                                                                                 ^~~~~~
/Users/ruipacheco/.cargo/registry/src/github.com-1ecc6299db9ec823/docopt-0.6.16/src/parse.rs:45:42: 45:50 error: unresolved import `std::collections::hash_map::Occupied`. There is no `Occupied` in `std::collections::hash_map`
/Users/ruipacheco/.cargo/registry/src/github.com-1ecc6299db9ec823/docopt-0.6.16/src/parse.rs:45 use std::collections::hash_map::{Vacant, Occupied};
                                                                                                                                         ^~~~~~~~
error: aborting due to 2 previous errors
Build failed, waiting for other jobs to finish...
Could not compile `docopt`.

To learn more, run the command again with --verbose.

First things first I am not a pro at Rust and its only a proposal and nothing more.

Iota is a text Editor and I think every text editor needs syntax highlighting. I don't know if termbox/rustbox offers this, but it would be a great journey. And how to do this? Thats the point where I think #51 comes to rescue. Toml, Yaml or JSON, a simple Language Definition would be (yaml example):

# Go
extension: *.go
keywords: func type #... 

Keywords would be readed as array, and will be registered with the colors given. And at opening a new file, Iota would check the file extension, if the file extension known, it will be set.

Also I think writing this everything in one file (languages.toml or languages.iota) would be nice so its a little bit more hackable.

What you think about this? I would help implementing, but first then I need to start learning Rust.

Good Evening.

git pull cargo build --release ./target/release/iota

and then

fish: Job 1, './target/release/iota ' terminated by signal SIGILL (Illegal instruction)

(I'm using the fish shell)

Still slightly inconsistent with vim with deleting words at the end of a line/blank lines. Also I'm not very happy about using a boolean in the Direction enum for the different vim word matching types, thinking maybe adding another enum that defines the word edge matching might be the way to go. Would allow for adding in whatever emacs bindings there are for moving by word easily.

So, with those above caveats this is more of a review/discussion request than a serious pull request, yet.

I'd like to relicense the project under the GPL.

Obviously, this would mean that code contributed already to this project under the MIT license would need to be relicensed. In order to do this I would like the contributors of said code permission to have their contributions relicensed.

If you've contributed code to Iota up to this point, can you comment below and let me know if you are happy for your contributions to be relicensed under the GPL. Alternatively, if you're not happy for this, please also comment below or email me (email address in commit log).

Thanks!

After $cargo build, run & get this error. How deal with it?

$ ./target/iota
Illegal instruction (core dumped)

PS. Ubuntu 14.04 LTS x64; Nightly Build's rustc and cargo.

Currently there are just two unsafe blocks of code in the project. I'd like to remove them and only use safe code if possible.

I'm not sure if the current design will work without the unsafe code, though. Might be worth evaluating to see if its worth redesigning just to remove it.

Hey, I left a comment on your HN posting about The Craft of Text Editing. I've been thinking about both a) implementing a text editor & b) learning Rust for several months now, and I'd like to contribute. I fiddled with a text editor in Python a while ago, which is when I found that book.

I notice that buffer.rs implements the buffer as a vector of vectors of chars. This is the obvious way to do it, but as I discovered from The Craft of Text Editing, its much more efficient to implement it as a gap buffer - a resizing array with with a moveable gap (see chapter 6 or Wikipedia for more info). A generic gap buffer seems like a good introduction to Rust, so I've started working on it. Ultimately I'll implement the same API as the current buffer and submit a pull request?

Opened by ./target/iota src/main.rs and just did something like Pg-Down, Pg-Down, Enter, Enter, Pg-Down, Pg-Down

Panick

task '<main>' panicked at 'index out of bounds: the len is 21 but the index is 21', src/iota/lib.rs:1
Options:                                                                                             task '<unnamed>' panicked at 'sending on a closed channel', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libstd/comm/mod.rs:555
";                                                                             

Disclaimer: I'm new into Rust ecosystem, so I don't know what details to provide or how to obtain stacktrace et cetera ... If anything I'm wiling to provide you with more details.

env RUST_BACKTRACE=1 ./target/release/iota --vi
thread '<main>' panicked at 'index out of bounds: the len is 0 but the index is 0', ../src/libcollections/vec.rs:1134
stack backtrace:
   1:     0x55e8bfa2d130 - sys::backtrace::tracing::imp::write::hf66cd359dc225f8a0nu
   2:     0x55e8bfa2f75b - panicking::default_handler::_<closure>::closure.42795
   3:     0x55e8bfa2f324 - panicking::default_handler::h74bfdb4a758a82e9EFy
   4:     0x55e8bfa215f6 - sys_common::unwind::begin_unwind_inner::h9d3a2e7a2c681f25ygt
   5:     0x55e8bfa21a78 - sys_common::unwind::begin_unwind_fmt::h4fadd261b35ed9d7Eft
   6:     0x55e8bfa2c771 - rust_begin_unwind
   7:     0x55e8bfa5c37f - panicking::panic_fmt::h596d44ac9aaebe47nYL
   8:     0x55e8bfa5c4f2 - panicking::panic_bounds_check::hb399db976cf4f929tXL
   9:     0x55e8bf9acd24 - buffer::Buffer::get_object_index::hee931b9597f98e70Xqa
  10:     0x55e8bf9b0b46 - view::View::move_mark::h50c3269b4d699f3cXIb
  11:     0x55e8bf9a7192 - main::h07af46f8e193902eeda
  12:     0x55e8bfa2efc4 - sys_common::unwind::try::try_fn::h3732045691669936705
  13:     0x55e8bfa2c708 - __rust_try
  14:     0x55e8bfa2ebfd - rt::lang_start::h2071a016df0a133cKxy
  15:     0x7f998bb4357f - __libc_start_main
  16:     0x55e8bf9a4cb8 - _start
  17:                0x0 - <unknown>

This is a rough-around-the-edges take on implementing a general purpose key-sequence => command binding framework. See also #30.

The KeyMap holds a Trie that maps Key nodes to editor Commands, with a bit of state to keep track of incoming key presses.

The editor can then feed keystrokes to the KeyMap, and receive either a matching Command, a Continue signaling a partial result that needs more keys to disambiguate, or a None indicating that no match was found and the key should be handled normally.

I don't really know what I'm doing here, so there's certainly a lot of room for cleanup and improvements.

Hi,

This PR adds a simple page up and page down implementation. At the moment forward or backward 12 lines (a half of 24 lines in standard old consoles).

PD: Maybe a better feature will be moving a Kind::Paragraph? Please let me know.

cargo build
   Compiling termbox-sys v0.2.10
error: could not find native static library `termbox`, perhaps an -L flag is missing?
error: aborting due to previous error
error: Could not compile `termbox-sys`.
To learn more, run the command again with --verbose.

i use fedora, how install termbox?

I'm sorry if this is a completely inappropriate place to take up my questions regarding some things in this text editor, but I can't seem to find any description of how the thought process was when designing this text editor (and I can't contact the owner of the repo directly).

I kind of understand the idea behind the Mark and MarkPosition, but what makes me bewildered is, the Buffer Struct contains a HashMap with marks in it - how is this kept valid at all, when insertion and deletion of characters in the buffer is made? I can't seem to find anything in the source code either, or maybe I am completely missing the purpose of this all together?

Since it indexes into the GapBuffer (and since GapBuffer is a 1D array, basically) through an absolute index, any insertion or deletion before a mark, will completely invalidate it, if no update is made to that entry in the hashmap, at every insertion and deletion, which (if many marks are saved) could lead to quite the overhead, no?

Or what is the purpose of this HashMap, at first, I thought I thought it was some container for keeping track of positions in the text, (like a bookmarking feature the end user can use, hence my question on validation of the marks and their purpose). But after looking through the source code, that doesn't seem to be it's purpose neither. Could you be so kind and explain briefly to me the purpose of that HashMap?

Anyway, awesome project, has me inspired to writing my own rusty project.

I would like to write my own keybindings for iota, for example in Json. Example:

[
  {
    "keys": [
      {
        "mode": "Ctrl",
        "key": "x"
      },
      {
        "mode": "Ctrl",
        "key": "c"
      }
    ],
    "CommandInfo": {
      "command_name": "editor::quit",
      "args": null
    }
  }
]