Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conque reacts badly to being closed or hidden #12

Closed
GoogleCodeExporter opened this issue Dec 28, 2015 · 11 comments
Closed

Conque reacts badly to being closed or hidden #12

GoogleCodeExporter opened this issue Dec 28, 2015 · 11 comments

Comments

@GoogleCodeExporter
Copy link

* What steps will reproduce the problem?
start Vim with two files loaded
Split the window (:sb)
Start ConqueTerm zsh
ESC, :close (in my configuration this leaves a buffer loaded but hidden)
:sb (fails)
:sb 2 (works, splits to other file)
:b 3 (go back to zsh)
Weirdness ensues.

* What is the expected output? What do you see instead?

I expect the window to go away and come back again, unscathed.  Instead
closing the window seems to've really messed up the entire editor state.

* What version of the product are you using? On what operating system?

1.0 of Conque, vim 7.1, patches 1-314, python 2.5.2, Debian Linux

* Please provide any additional information below.

Vim settings and version:

:set
--- Options ---
  autoindent          lazyredraw          smarttab
  autowrite           linebreak           splitbelow
  backspace=2         mouse=a             splitright
  backup              report=0          nostartofline
  backupext=.bak      ruler               textwidth=78
noequalalways         scroll=18           ttimeoutlen=300
  helplang=en         scrolloff=3         ttyfast
  hidden              shiftwidth=2        ttymouse=xterm2
  history=1000        showbreak=+         window=37
  ignorecase          showcmd           nowrapscan
  incsearch           showmatch           t_Co=16
  laststatus=2        smartcase
  complete=.,w,b,u,t
  diffopt=filler,iwhite
  fileencodings=ucs-bom,utf-8,default,latin1
  path=.,/usr/include
  statusline=%<%f %(%h%m%r[fo=%{&formatoptions}]%{VarSet(&paste,' [P
ASTE]')}%)%=%l,%c%V %{Percent()}%% %P
  viminfo=!,'100,s10

:ver
VIM - Vi IMproved 7.1 (2007 May 12, compiled Oct 17 2008 18:04:59)
Included patches: 1-314
Compiled by jamessan@debian.org
Huge version with GTK2 GUI.  Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset
 +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist
+cmdline_info +comments +cryptv +cscope +cursorshape
+dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags +eval
+ex_extra +extra_search +farsi +file_in_path +find_in_path +folding
 -footer +fork() +gettext -hangul_input +iconv +insert_expand
+jumplist +keymap +langmap +libcall +linebreak +lispindent
+listcmds +localmap +menu +mksession +modify_fname +mouse
+mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm
+mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg
-osfiletype +path_extra +perl +postscript +printer +profile +python
 +quickfix +reltime +rightleft +ruby +scrollbind +signs
+smartindent -sniff +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white +tcl +terminfo +termresponse
+textobjects +title +toolbar +user_commands +vertsplit +virtualedit
 +visual +visualextra +viminfo +vreplace +wildignore +wildmenu
+windows +writebackup +X11 -xfontset +xim +xsmp_interact
+xterm_clipboard -xterm_save
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -I/u
sr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2
.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/inclu
de/libpng12 -I/usr/include/pixman-1     -g -O2 -O2 -g -Wall    -D_RE
ENTRANT -D_GNU_SOURCE -DDEBIAN  -I/usr/local/include -D_LARGEFILE_SO
URCE -D_FILE_OFFSET_BITS=64  -I/usr/lib/perl/5.10/CORE  -I/usr/inclu
de/python2.5 -pthread -I/usr/include/tcl8.4  -D_REENTRANT=1  -D_THRE
AD_SAFE=1  -D_LARGEFILE64_SOURCE=1  -I/usr/lib/ruby/1.8/i486-linux
Linking: gcc   -L.  -rdynamic -Wl,-export-dynamic  -Wl,-E  -Wl,--as-
needed -L/usr/local/lib -o vim   -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1
.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2
.0 -lgmodule-2.0 -lglib-2.0   -lXt -lncurses -lselinux  -lacl -lgpm
-Wl,-E  -L/usr/local/lib  -L/usr/lib/perl/5.10/CORE -lperl -L/usr/li
b/python2.5/config -lpython2.5 -lutil -Xlinker -export-dynamic -Wl,-
O1 -Wl,-Bsymbolic-functions -L/usr/lib -ltcl8.4 -lieee -lruby1.8 -lm

Original issue reported on code.google.com by lmclapp68@gmail.com on 7 May 2010 at 7:23

@GoogleCodeExporter
Copy link
Author

Good catch. Thanks.

Original comment by nicora...@gmail.com on 7 May 2010 at 7:51

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

r190 says "fix issues #7 and #12" but it doesn't fix this issue for me. 
Using Vim 7.2 if that's relevant. 

Original comment by DragonWi...@gmail.com on 11 May 2010 at 12:56

@GoogleCodeExporter
Copy link
Author

Thanks for the feedback. I'm planning on releasing 1.1 in the next week or so, 
so I'd
like to make sure this is working.

I could definitely reproduce the bug before r190. In particular, I would get 
messages
about "referring to a deleted window" or something like that.

I no longer get any issues after r190, testing on both 7.1 and 7.2, Python 2.3 
and 2.6.

Can you provide the error messages, if any, that are displayed?

Also, make sure you're successfully using the updated code. If you try applying 
r190
as a patch against 1.0 stuff will definitely not work. You'd need to remove 1.0 
files
first and only use what's in the development trunk.


Original comment by nicora...@gmail.com on 11 May 2010 at 2:47

@GoogleCodeExporter
Copy link
Author

I manually replaced files and observed the same behavior. I'll try to make a 
quick
screencast to show you what I'm seeing. 

Original comment by DragonWi...@gmail.com on 11 May 2010 at 4:35

@GoogleCodeExporter
Copy link
Author

http://www.youtube.com/watch?v=-QaFlqUIBOo

Original comment by DragonWi...@gmail.com on 11 May 2010 at 5:29

@GoogleCodeExporter
Copy link
Author

Thanks.

r191 may resolve this finally.


Original comment by nicora...@gmail.com on 11 May 2010 at 6:30

@GoogleCodeExporter
Copy link
Author

Yep, it looks like it's working now.

Original comment by DragonWi...@gmail.com on 11 May 2010 at 12:40

@GoogleCodeExporter
Copy link
Author

Installed r191.  Most issues fixed.  However ":sb" in edited file with no target
still fails after loading ConqueTerm zsh.

Steps:

Start vim with at least 2 files (I used 151; most of my tree for this project); 
Vim
opens first file (of course).
:sb (works)
:ConqueTerm zsh (works, leaves me in zsh window)
ESC in zsh window to exit insert mode
^W k to move to text file
:sb (fails)
:sb 2 (works)

Similarly:

Start vim with 151 files; Vim opens first file (of course)
:sb
:sb
:sb
:sb
^W =
(Now have 4 equal-sized windows on file 1; cursor in bottom window)
:ConqueTerm zsh (works, leaves me in zsh window)
ESC in zsh window to exit insert mode
^W k to move to window 3
:sb   or   :sb 1    both move cursor to window 1, whereas they should have 
split the
window again
:sb 2 (seems to work as expected)

Thanks for the quick response!

Original comment by lmclapp68@gmail.com on 11 May 2010 at 1:44

@GoogleCodeExporter
Copy link
Author

See if r192 helps. I was setting the 'switchbuf' option, to help with the <F9>
command. But I'm happy to remove it and let that behavior be up to the user.

Original comment by nicora...@gmail.com on 12 May 2010 at 11:36

@GoogleCodeExporter
Copy link
Author

r192 did it.  Didn't know about 'switchbuf' option!  :)  Thanks!

Original comment by lmclapp68@gmail.com on 13 May 2010 at 1:33

@GoogleCodeExporter
Copy link
Author

Fix released with 1.1

Original comment by nicora...@gmail.com on 28 May 2010 at 5:57

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant