@dschuyler Do you think it'll soon be time to make a setup.py file, deploy the program to pip or something so we can install it as a program? Then we'll no longer have to start the program with python ./PATHNAME/ci_edit !

Just leaving this issue up here as a TODO for the future. It might be a better idea to get the color schemes, menus, and other minor things working before doing this.

This just causes a whole bunch of errors. I'll try to list out each one.

• Drag the window so that you make the height smaller. Then hold enter and the program will break once the cursor goes past the terminal screen.
• Drag the window so that the width is smaller. This will cause a grey area to expand and block the text that is on the screen.
• Increase the size of the window. The size of the window objects (like the text buffer, line numbers, etc) will not increase with the size of the window.

If I open a large file and use ctrl+g, t (or b) to jump to the top or bottom of the file (with no other edits in the file), the file will be seen as dirty. Dirty meaning that the * is shown next to the file path and ctrl-q will prompt to ask about saving the modified file.

It looks like removing and self.redoIndex != len(self.redoChain) from the following code in app/mutator.py will fix the issue. I don't recall why that test is part of that if-statment.

aaxu@ do you recall?

    # When the redoChain is trimmed we may lose the saved at.
    # Trim only when there is a non-trivial action.
    if change[0] == 'm' and self.redoIndex != len(self.redoChain):
      newTrivialChange = True
    else:

--startup references a variable logStartup that doesn't seem to be defined. Maybe you forgot to change this to True?

The redoChain doesn't seem to be saved anywhere. I'm intending to handle this in #10 using cPickle.

This can be reproduced by the following steps

1. Start up the program with no file name
2. Type anything in the text editor
3. Enter interactive quit using CTRL + Q
4. Press 'y' to save.
5. Error message will appear and program will not exit.

I'm not really sure how to describe this, but I'll make a short gif here..

At the beginning, I'm demonstrating that the cursor is working as intended. However, after I insert a space after 'the', that brownish box appears and seems to follow my cursor. Near the end it also gets stuck near the 80 character line.

This happens when you start up the text editor without specifying a file name. When you enter InteractiveFind or InteractiveGoTo mode and try to save, it will say there was an Error saving the file.

If you have only one line of text and your cursor is at the end of the line, find will not work properly. Also, regardless of where your cursor is, if you keep pressing findNext, it will have weird behaviors like nothing will be highlighted.

If you have text selected and you press page up/down, everything in between the old cursor position and the new one becomes selected. Is this a bug or a feature?

I ran into some issues when testing out the program on various machines. On both my Arch Linux OS and Ubuntu 16.04 OS, the values for the shortcuts listed seem to differ per system. I have listed what I have gathered from testing below. All the ones listed are different from the ones currently in the code, the rest are the same.

ArchLinux

• KEY_ALT_LEFT = 546
• KEY_ALT_RIGHT = 561
• KEY_ALT_SHIFT_LEFT = 547
• KEY_ALT_SHIFT_RIGHT = 562
• KEY_CTRL_DOWN = 528
• KEY_CTRL_SHIFT_DOWN = 529
• KEY_CTRL_LEFT = 548
• KEY_CTRL_SHIFT_LEFT = 549
• KEY_CTRL_RIGHT = 563
• KEY_CTRL_SHIFT_RIGHT = 564
• KEY_CTRL_UP = 569
• KEY_CTRL_SHIFT_UP = 570
• KEY_ALT_A = (97,). I had to find this key through another terminal in Arch. Read note below
• KEY_ALT_B = (98,)
• KEY_ALT_C = (99,)
• KEY_ALT_S = (115,)

Ubuntu 16.04

• KEY_ALT_LEFT = 543
• KEY_ALT_RIGHT = 558
• KEY_ALT_SHIFT_LEFT = 544
• KEY_ALT_SHIFT_RIGHT = 559
• KEY_CTRL_DOWN = 525
• KEY_CTRL_SHIFT_DOWN = 526
• KEY_CTRL_LEFT = 545
• KEY_CTRL_SHIFT_LEFT = 546
• KEY_CTRL_RIGHT = 560
• KEY_CTRL_SHIFT_RIGHT = 561
• KEY_CTRL_UP = 566
• KEY_CTRL_SHIFT_UP = 567
• KEY_ALT_A = (97,)
• KEY_ALT_B = (98,)
• KEY_ALT_C = (99,)
• KEY_ALT_S = (115,)

NOTE: In some cases, I think the OS shortcuts and some terminal shortcuts take precedence over being inputs for the terminal. For example, on Ubuntu, my terminal can't detect CTRL+ALT+T because that is the OS shortcut to open a new terminal. In my case, specifically for Arch, I had to use another terminal because KEY_ALT_A opened up an option and thus couldn't be detected as an input. This case can be seen on both Arch Linux and Ubuntu when I try to use the KEY_SHIFT_F10 shortcut, which can't be detected since it pops up an option instead. In some other terminals, (I tested multiple in Arch Linux), the CTRL_SHIFT_* keys as well as a few others cannot be detected, but they didn't seem to be a shortcut for anything in particular. However, I don't think this note is a high priority matter since most of the important shortcuts seem to be detected with the default terminals.

I'd like to implement this shortcut to select the current line. Do you think that this is appropriate? It may take me a little while because I want to understand the code and structure of the program first.

The entire window starts out grey. Every character you type turns the grey spot into a black spot. This issue was caused after one of the recent commits to the master branch.

I'm not sure if it was intentional, but the labels in labeled line didn't seem to have the right color IMO. They were using the default color, which is based on the color of the background of the terminal you are using. Thus, for the Ubuntu default terminal, the window would look something like this:

Seems to be having some weird interaction with the 80 char line.

in a file, type

A
B

then undo so that only A is shown
Save
Press ctrl+y to redo

Problem: B does not reappear.

I was thinking about how the tab key works and wanted your opinion on some things @dschuyler.

• When the selection mode is none, should we just insert a tab and move the cursor to the end of it rather than indent the whole line and have the cursor at the beginning of the line?

• When the selection mode is not none and we tab, should we keep the cursor at the current position or keep it moving to the beginning of the line?

• Let's say that there is a colon and then a new line. The new line operator will put the cursor on an indented spot on the next line, a few spaces after the beginning of the previous line. Should we have tab jump to this position if the cursor is before this position?
  For example:

for x in lst:
xx|yyyyyy

If the cursor is in some position with an x, them jump to the vertical bar if a tab is inserted (all selection modes).

Pressing END, HOME, CTRL_RIGHT, CTRL_LEFT, CTRL_SHIFT_LEFT, CTRL_SHIFT_RIGHT, CTRL_G to go to any line, doesn't actually shift the view to show the cursor. When the cursor goes out of bounds, it's appear in the bottom right of the program.

This also happens when scrollCol > 0 and you use backspace with cursorCol = scrollCol (meaning the cursor is at the first visible column of the text buffer and the view is shifted to the right). Backspacing will cause the cursor to enter the LineNumber's view.

Example here:

I tried running the program on another system, and it seems to error out. The program is crashing because it's trying to import bookmarks.py which doesn't exist anymore, but I'm not sure why it doesn't error on our current systems. Do you have any idea why this occurs?

Do you think it'll be better if we undo and redo new lines the same way we do mouse actions? That is, we return a new line character if we see one after a redo. However, we only redo 2 different types of actions at a time, so if the redo chain was something like (insert, mouse, newLines), we would only undo the newLines (until there are no more left), then the mouse action.

Is this a feature that has yet to be fully implemented? I see the groundwork laid out, but It doesn't seem to be functional (or I'm just using it wrong). What is InteractivePrediction supposed to do?

Someday I'd like to provide multiple views that look into the same file (TextBuffer).
This is similar to the split (either horizontal or vertical) that other editors provide.
We may want to provide for multiple views on the same screen looking at different files first (since that's expected to be an easier task).

When the cursor position is at the end of a line and you save and reopen the file, the cursor is moved to the 2nd to last position of the line. That is, if I type the word "RIGHT", save, and reopen the file, the cursor is at "RIGH|T" rather than "RIGHT|".

There is an assertion error in doMoveLines inside the Mutator class. I think it's because the to variable is changed before the assertion checked, thus failing the assertion.

The error can be reproduced as follows:

1. Start up the text editor with any document with more than 2 lines
2. Make any selection such that the top of the selection is not on the very first line
3. Perform CTRL + SHIFT + UP and the program will crash.

Not sure of full repro steps. I need to follow up on this.

info text_buffer.py 842 mouseRelease: mouse release 10 0
detail mutator.py 355 undoOne: undo
detail mutator.py 409 undoOne: undo move
error ci_program.py 534 wrapped_ci: Traceback (most recent call last):
error ci_program.py 534 wrapped_ci: File "/usr/local/google/home/dschuyler/github/ci_edit/app/ci_program.py", line 529, in wrapped_ci
prg.run()
error ci_program.py 534 wrapped_ci: File "/usr/local/google/home/dschuyler/github/ci_edit/app/ci_program.py", line 502, in run
self.commandLoop()
error ci_program.py 534 wrapped_ci: File "/usr/local/google/home/dschuyler/github/ci_edit/app/ci_program.py", line 97, in commandLoop
self.refresh()
error ci_program.py 534 wrapped_ci: File "/usr/local/google/home/dschuyler/github/ci_edit/app/ci_program.py", line 466, in refresh
k.refresh()
error ci_program.py 534 wrapped_ci: File "/usr/local/google/home/dschuyler/github/ci_edit/app/window.py", line 767, in refresh
self.topInfo.onChange()
error ci_program.py 534 wrapped_ci: File "/usr/local/google/home/dschuyler/github/ci_edit/app/window.py", line 555, in onChange
if tb.isDirty():
error ci_program.py 534 wrapped_ci: File "/usr/local/google/home/dschuyler/github/ci_edit/app/mutator.py", line 99, in isDirty
self.redoChain[self.redoIndex][0] == 'm') or
error ci_program.py 534 wrapped_ci: IndexError: list index out of range

If you remove a bookmark, the message displayed will always be "No bookmarks to remove."
This should be because the bookmarkRemove function does not return True/False properly and bookmarkCommand function in interactive_prompt.py checks for this value in order to set the correct message.

these days i have been always seeing ci_edit source code, everything is ok but i can not run it on pycharm. below is the error stacktrace when i ran Ci_program:

Traceback (most recent call last):
  File "/Applications/PyCharm.app/Contents/helpers/pydev/pydev_run_in_console.py", line 71, in <module>
    globals = run_file(file, None, None)
  File "/Applications/PyCharm.app/Contents/helpers/pydev/pydev_run_in_console.py", line 31, in run_file
    pydev_imports.execfile(file, globals, locals)  # execute the script
  File "/Users/crabime/Development/PythonDevelopment/github/ci_edit/app/ci_program.py", line 611, in <module>
    run_ci()
  File "/Users/crabime/Development/PythonDevelopment/github/ci_edit/app/ci_program.py", line 602, in run_ci
    curses.wrapper(wrapped_ci)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/curses/wrapper.py", line 22, in wrapper
    stdscr = curses.initscr()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/curses/__init__.py", line 33, in initscr
    fd=_sys.__stdout__.fileno())
_curses.error: setupterm: could not find terminfo database

I had tried these ways:

• add TERM=xterm-256color and TERMINFO=/usr/share/terminfo/78 in path which located in ~/.bash_profile，that doesn't work, such error still appear
• **add such environment variables into pycharm program run/debug configuration directly,**still doesn't work.

so far, i have tried all the way but still can not debug curses program. and here is the link to the question i putted forward in stackoverflow but still nobody knows,hope someone can save me out.

Current OS version: OS X 10.11.4
System Platform: Darwin

If your cursor is at the beginning of a line (say line 4) and you perform SHIFT_UP to select previous lines, the created bookmark will include line 4. This means that you can remove the bookmark if your cursor is on line 4. I don't know if this should be a bug or a feature, but it may cause some confusion since there is no visual display that shows that this line is part of the bookmark.

I think it makes more sense if this is a bug? What are your thoughts?

Make terminal paste things from clipboard (that you copied outside of the program) be able to paste inside the program with CTRL+V, or the paste function.

Currently, things copied to clipboard can be pasted inside the program with CTRL+SHIFT+V which is how you typically paste in a terminal. However, the format may sometimes be incorrect. Also, it is not possible to copy something from the program to the clipboard and paste it outside of the program.

I have a couple questions regarding how we should design this function.
Currently, selected text prior to entering interactive find will be transformed into a single regex line. However, if the selected text contains more than one line, then the regex search will contain \n characters, but this will make it so that the search will not match to anything since we have a carriageReturn function that handles this. Not sure if there will be a easy way to handle this..

Another weird thing that I noticed is that if you copy and paste several lines into the search area, only the first line will be used for searching,

I also have a few ideas of how to make the interface better:

• Have two mode, one for regex and one for standard search. If the program is in standard search, then do not convert the selected text to a regex line. If not, then convert.
• Maybe make the window increase in lines (up to a certain point, say 5 lines) so the user can see a bit more if their search contains multiple lines.
• Make cursor blink in the InteractiveFind window so it is clear that the user is editing the search when in InteractiveFind.

Let me know your thoughts on this and how you think we should re-design this to accommodate multiple lines or if it is even necessary sine it's not very common (at least from personal experience).

os version: OS X 10.11.4
After cloning this project, I met three question:

1. First, ran this install.sh failed. Then checking this script file and echo SRC_PATH and APP_DIR, all return empty.
   and i changed such script file, here is change snippet which succeeded installing:

#Get current shell script directory name
SRC_PATH=$(cd "$(dirname "$0")"; pwd)
# Grab the directory name.
APP_DIR=${PWD##*/}

2. Second, there is not opt folder in os x and i made it manually, how about normal user? Should we make such directory while installing.

3. Third, i wrote a random text file using we command. After adding a line and want to save it. while cmd + s seems not working. it always let me store in another folder like desktop etc.so i wander if you can change the logic and just store this file and quit like vim.

When you drag the bottom of the terminal upward (must be done somewhat slowly) to make the window smaller, the stats line at the bottom gets shown twice.

Steps to reproduce

• Create a new file, add characters so it has at least 1 character in the file and then save.
• Re-open the file
• Select all the characters in the file (CTRL_A by default)
• Type anything to replace all the characters
• Save -> This will cause an error message to appear saying that the file did not save properly.
• Quit the program with CTRL_Q and press N to not save the file.
• Reopen the file. You should now see a corrupted file. It may or may not even open in the program properly, or the offset/data in the file is different from expected.

Ways to emulate this:

• Copy anything into your clipboard.
• Create a new file.
• Paste consecutively three times
• Save
• Reopen file
• Hold undo
• Weird behaviors will happen. The best behavior I've seen is that the redo chain just stops allowing you to undo, even when there is supposed to be more stuff. (ie, doing the steps above should leave one copy paste in your program). The worst behavior I've seen is where the views all freeze. I think you can still exit with CTRL_Q + y/n, but the visible screen looks like it froze. Another behavior is where the screen looks frozen, but once u click the text buffer, changes get updated as if the screen refreshed.

Scrolling down using the mouse wheel makes the window snap back to the cursor (if it is out of view) and does nothing if the cursor is in view.

Scrolling up works as intended.

I was going to move this sometime to be imported and saved at the same time as history so it supports multiple views, but wanted to check if it works properly. Is bookmarks a functional feature right now?

Right now, user prefs can be edited as json files in ~/.ci_edit/prefs/... (requiring reopening the editor).
Let's make those prefs editable and auto-refreshing from within the editor (without requiring reopening the editor).

This causes problems and can break future openings of ci_edit if you open up a new file and try to save. This is because self.fileEncoding is not initialized when you open a new file.

This bug only sometimes happens, but it seems to be reproducible if you keep trying for a little while.

Steps:

• python ci.py ci.py (I don't think file matters, since it also happened when I tried using install.sh). This error actually seems to occur more if no file is specified, so python ci.py
• CTRL_Q

Open any file and try to type on the 2nd line in the document. An index error should occur and the program will crash.

1. Make some edits
2. Undo some edits
3. Move cursor
   Problem: try to redo, there are no actions to redo and there should be.

See issue #5 for prior conversation.

Seems like a good feature to have for variable/function names. Maybe one that can be turned off/on.

When you're typing and the cursor goes past the width of the window, the view doesn't move along with the cursor, so you won't be able to see the cursor anymore. This does not happen if the cursor goes past the height of the window.

I traced this error to applyPalette in ci_program.py. setUpPalette has a try-catch block where it's try block and the catch block currently do the same thing, causing the crash. This happens because some terminals only support 8 colors so curses.COLORS will return 8 instead of 256. However, the default palette assumes there are 256 colors. I think that we should have maybe a barebones 8-bit colored version of the program to support these types of terminals. I may see if I can figure out how to play around with the color schemes, but you probably are better at dealing with this than I am @dschuyler.

Should we make it a default that when you search for a string in the text editor, it's automatically case insensitive?

This can be reproduced by the following steps:

1. Start a new document
2. Hold enter until you have enough lines to make the text buffer scroll up
3. Scroll up and place the cursor back on the first line.
4. Put your mouse over either the message line or status line
5. Scroll up using the mouse wheel

Expected behavior: Text buffer scrolls down
Actual behavior: Text buffer scrolls up, cursor moves down and all text in between is highlighted.

If you're typing and your cursor goes outside of the visible view, the scroll position isn't correctly adjusted.

Here i changed a file under /opt folder and save it with control + s, but it's useless. maybe it's a protected file but if there are some hint about such unwritten condition will be nice. and cmd + s will store command line text. i made a screen snapshot but it seems github issue can not upload image..