On Fri, Aug 31, 2012 at 09:14:14AM EDT, joe M wrote:
> On Fri, Aug 31, 2012 at 1:27 AM, Chris Jones <cjns1989@gmail.com> wrote:
> > On Thu, Aug 30, 2012 at 01:34:10PM EDT, joe M wrote:
[..]
> Hope the above helps. Please let me know if you need more information.
I'm not an expert in Vim or termcap/terminfo by a long way... :-)
I'm still not sure you are actually executing the code you compiled, but
I'll trust you on that. If you are confident the executables in /bin and
/usr/bin are the ones you compiled yourself, I nevertheless suggest you
run all your tests invoking them via their full path (/usr/bin/vim and
/bin/vi).
I also thought that a possible explanation of the inconsistent behavior
might be caused by the fact that 'vi' was using termcap and 'vim' was
using terminfo.. and that there might be escape sequence discrepancies
between the two on your system --something that I believe should not
happen, since a given terminal's capabilities remain the same and its
termcap and terminfo escape sequences should therefore be identical.
Another thing: _my understanding_ is that when both terminfo and termcap
are implemented, Vim chooses terminfo 'automatically' at configure time.
cf. :help startup-terminal.
And then there is the fact that I see '+terminfo' in the output of both
the 'vi --version' and the 'vim --version' that you pasted in your
previous post. (cf. :h +terminfo).
Besides, 'man 5 termcap' has the following: 'The termcap database is an
obsolete facility for describing the capabilities of character-cell
termi‐ nals and printers. It is retained only for capability with old
programs; new ones should use the ter‐ minfo(5) database and associated
libraries.'
Don't see any good reason Vim would use an 'obsolete facility' unless it
had to.
In no particular order, a few additional questions/remarks that might
help clarify:
1. What distribution are you running?
2. Did you run the default version of vi/vim before you compiled your
own from source?
3. If so, are you positive you removed the prior version?
4. Not suggesting a workaround, but did you try running the same test on
a different terminal.. & see what happens..? xterm is probably already
installed on your system¹, if not, you could also try good ole rxvt?
5. Conversely, how about temporarily removing your compiled version and
installing your distro's default version and running a test. If the
problem goes away, this might suggest that the different behavior is
caused by one of the --enable-option that you specify at ./configure
time..?
6. Would it make sense to generate both executables using the same
./configure options.. check whether you still have the problem?
7. Just in case, is there a TERMCAP environment variable exported to
your terminal session before you run vi/vim:
% env | grep TERMCAP
8. As to builtin terminals.. I'm still running vim 7.2 and when I do
a ':set term=xxx' there is no mention of urxvt or rxvt in my list of
builtin terminals. Is this also what happens with vim 7.3?
9. Is termcap implemented on your system? On debian I apparently have it
as part of the libncurses5-dev package.
Naturally, the above are not really meant as questions, but rather,
stuff I would ask myself if I had the same problem and that might help
investigate².
CJ
¹ Note that in the case of xterm, you can {en/dis}able the alternate
screen capability by holding down the CTRL key and middle-clicking:
This brings up a menu where you can check/uncheck 'Enable alternate
screen switching'.
² As to the disappearing lines, (the 'seq 1000' test), when I disable
alternate screen switching, I find that roughly one screen worth of
numbers are overwritten by the Vim screen that remains visible after
I exit. I have something like 91 lines on my terminal and when
I scroll back, the last number I see is 909.. immediately followed by
the last visible contents of the Vim session --i.e. if I was looking
at an empty buffer, I see a bash prompt, then vim's tabline, followed
by a number of empty lines and then the status line and lastly my bash
prompt at the bottom of the screen. I would imagine this is expected
behavior (?).
--
WHAT YOU SAY??
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Friday, August 31, 2012
Re: problems at the first few steps in the vimTutor
Thank you very much :)
--
View this message in context: http://vim.1045645.n5.nabble.com/problems-at-the-first-few-steps-in-the-vimTutor-tp5710499p5710505.html
Sent from the Vim - General mailing list archive at Nabble.com.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
--
View this message in context: http://vim.1045645.n5.nabble.com/problems-at-the-first-few-steps-in-the-vimTutor-tp5710499p5710505.html
Sent from the Vim - General mailing list archive at Nabble.com.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: vim: TOhtml: doesn't work with range [please ignore]
weird...it works. when it didn't, it's only that file in a couple of
others that didn't work...
anyway, please ignore and sorry about the message.
I'll post if same issue happens.
regards
On 08/31/2012 12:03 PM, ping wrote:
> hi guys:
> I don't really know what happened, but it looks my TOhtml doesn't work
> with any range at all.
> I tried visual select ('<,'>), line number, .. none work.
> per help TOhtml it should work, how to debug this?
>
>
> regards
> ping
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
others that didn't work...
anyway, please ignore and sorry about the message.
I'll post if same issue happens.
regards
On 08/31/2012 12:03 PM, ping wrote:
> hi guys:
> I don't really know what happened, but it looks my TOhtml doesn't work
> with any range at all.
> I tried visual select ('<,'>), line number, .. none work.
> per help TOhtml it should work, how to debug this?
>
>
> regards
> ping
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
vim: TOhtml: doesn't work with range
hi guys:
I don't really know what happened, but it looks my TOhtml doesn't work
with any range at all.
I tried visual select ('<,'>), line number, .. none work.
per help TOhtml it should work, how to debug this?
regards
ping
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
I don't really know what happened, but it looks my TOhtml doesn't work
with any range at all.
I tried visual select ('<,'>), line number, .. none work.
per help TOhtml it should work, how to debug this?
regards
ping
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: problems at the first few steps in the vimTutor
hansn, Fri 2012-08-31 @ 03:53:10-0700:
> I am on windows so i located the tutor file and excetuted it from
> there. But in step 1.2 it sais to type ' :q! ' to quit the tutor, and
> then enter 'vimtutor' from the shell.
>
> First off, when i type :q! , no shell appears, the tutor simply quits.
> Secondly the vimtutor command (according to the :help vimtutor
> information i read) this command does not work on windows.
>
> Sincerely, a guy who first saw vim a couple hours ago.
There is no actual question in your message, so I will assume you are
simply confused about why this is happening and are asking for an
explanation.
Simply put, the vimtutor is written from the perspective of a Unix user,
where things do in fact work as the tutor file describes. Typically,
such a user will have launched vimtutor by typing `vimtutor` in the
shell, and upon exiting, will be returned to a shell prompt. Obviously
this is not the case on Windows, where shell usage is generally less
common. Although Vim is officially supported on Windows, it and its
predecessors have a long Unix parentage, and therefore it is not too
surprising that some of its behavior is less than intuitive on a
platform of a fundamentally different nature.
If you simply do not know what to do next, all you need to do is restart
the vimtutor the same way you launched it the first time, scroll down to
where you were when you quit, and continue.
If you are reporting this as a bug, then probably the best solution
would be to provide an alternative vimtutor file that makes more sense
on Windows, which can be used in place of the more Unix-oriented
existing tutor file when Vim is compiled for Windows.
> I am on windows so i located the tutor file and excetuted it from
> there. But in step 1.2 it sais to type ' :q! ' to quit the tutor, and
> then enter 'vimtutor' from the shell.
>
> First off, when i type :q! , no shell appears, the tutor simply quits.
> Secondly the vimtutor command (according to the :help vimtutor
> information i read) this command does not work on windows.
>
> Sincerely, a guy who first saw vim a couple hours ago.
There is no actual question in your message, so I will assume you are
simply confused about why this is happening and are asking for an
explanation.
Simply put, the vimtutor is written from the perspective of a Unix user,
where things do in fact work as the tutor file describes. Typically,
such a user will have launched vimtutor by typing `vimtutor` in the
shell, and upon exiting, will be returned to a shell prompt. Obviously
this is not the case on Windows, where shell usage is generally less
common. Although Vim is officially supported on Windows, it and its
predecessors have a long Unix parentage, and therefore it is not too
surprising that some of its behavior is less than intuitive on a
platform of a fundamentally different nature.
If you simply do not know what to do next, all you need to do is restart
the vimtutor the same way you launched it the first time, scroll down to
where you were when you quit, and continue.
If you are reporting this as a bug, then probably the best solution
would be to provide an alternative vimtutor file that makes more sense
on Windows, which can be used in place of the more Unix-oriented
existing tutor file when Vim is compiled for Windows.
Re: Colourising command line
On Thursday, 30 August 2012 16:05:40 UTC+1, Ben Fritz wrote:
> I alluded to it without making it explicit, but while you can make Vim do pretty much anything by modifying the source, I think you'll have better luck using regular syntax highlighting commands to accomplish what you want in the command-line window instead of the command-line itself. The command-line window is a special buffer but you can give it filetype and syntax just like any other buffer. I think by default it gets the normal "vim" filetype and syntax applied, but you could readily change this. You could then use whatever syntax file you come up with to highlight vim scripts in files as well as when typed as commands.
>
> Doing it with a syntax file applied to the command-window, you get the added bonus of being able to share your work with others who don't want to apply your patch to Vim, and additionally you don't risk the need to update your patch with every new upstream version of Vim.
Thank you for this new information.
I'm in line with your own thinking, though would prefer to engineer a solution which can be applied to the command line as well. That's what I primarily use - partly because it's quicker than the additional typing involved with entering and exiting command mode, and partly because one-liners are more common than multiline commands, e.g. common application of search and replace.
It's probably best for me to not comment further until I know more about what's possible without source code modification from my own investigation, but if what you say is true - that syntax highlighting can be applied to the command window but not the command line - then my natural impulse is to modify Vim's source code to add syntax highlighting to the command line. This would be a generic modification that should receive no complaint from other developers or users since it in no way affects default behaviour of the editor, and it would allow creation of syntax highlighting rules which could be shared by both command line and command window.
Cheers,
David
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> I alluded to it without making it explicit, but while you can make Vim do pretty much anything by modifying the source, I think you'll have better luck using regular syntax highlighting commands to accomplish what you want in the command-line window instead of the command-line itself. The command-line window is a special buffer but you can give it filetype and syntax just like any other buffer. I think by default it gets the normal "vim" filetype and syntax applied, but you could readily change this. You could then use whatever syntax file you come up with to highlight vim scripts in files as well as when typed as commands.
>
> Doing it with a syntax file applied to the command-window, you get the added bonus of being able to share your work with others who don't want to apply your patch to Vim, and additionally you don't risk the need to update your patch with every new upstream version of Vim.
Thank you for this new information.
I'm in line with your own thinking, though would prefer to engineer a solution which can be applied to the command line as well. That's what I primarily use - partly because it's quicker than the additional typing involved with entering and exiting command mode, and partly because one-liners are more common than multiline commands, e.g. common application of search and replace.
It's probably best for me to not comment further until I know more about what's possible without source code modification from my own investigation, but if what you say is true - that syntax highlighting can be applied to the command window but not the command line - then my natural impulse is to modify Vim's source code to add syntax highlighting to the command line. This would be a generic modification that should receive no complaint from other developers or users since it in no way affects default behaviour of the editor, and it would allow creation of syntax highlighting rules which could be shared by both command line and command window.
Cheers,
David
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: vim window clears the terminal history
On Fri, Aug 31, 2012 at 1:27 AM, Chris Jones <cjns1989@gmail.com> wrote:
> On Thu, Aug 30, 2012 at 01:34:10PM EDT, joe M wrote:
>
> [..]
>
>> Anyway, just a heads-up if anyone is interested.
>
> I certainly do. Thanks for bringing this to the list's attention.
>
> Reading through the thread, I'm pretty sure you stated somewhere along
> the line that the behavior you reported occurs when you run 'vim' and
> does not occur when you run 'vi'.
>
> On my (debian) system, vi and vim both point to the same executable.
>
> And here at least, whatever the terminal, both behave the same way in
> this respect, namely that the screen before I invoke vi/vim is not
> restored to its initial state -- that's the way I have set it up to suit
> my requirements.
>
> I find it a little suspicious that the same executable should behave
> differently regarding something that is not clearly related to editing
> itself and differences between vi and vim dure to their different
> capabilities just because you invoke the program in two different ways.
>
> Mind you, there may be a good reason for that, and I am just not aware
> of it.
>
> All the same, assuming you are running your tests on the same system,
> something you may want to check is the full path of the vi and the vim
> executable. So that we know precisely what gets executed.
>
> This should provide the full path:
>
> | % type vim
> | vim is /usr/bin/vim
> | % type vi
> | vi is /usr/bin/vi
>
> You could then use the file command to determine if they point directly
> to a vi/vim executable:
>
> | % file /path/to/vim
> | % file /path/to/vi
>
> If this is the case, you should see something like this:
>
> | /usr/bin/vim: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
>
> If not, you are pointing to a soft link to another file, that may also
> be a soft link.. etc.
>
> | % file /usr/bin/vi
> | /usr/bin/vi: symbolic link to `/etc/alternatives/vi'
>
> In such circumstances, you can determine the 'final' target of your
> commands via the 'readlink command'.
>
> To illustrate, here's what it looks like on my system:
>
> | % type vi
> | vi is /usr/bin/vi
> |
> | % readlink -f /usr/bin/vi
> | /usr/bin/vim.gtk
>
>
> | % type vim
> | vi is /usr/bin/vim
> |
> | % readlink -f /usr/bin/vim
> | /usr/bin/vim.gtk
>
> Thanks,
>
> CJ
>
> --
> WHAT YOU SAY??
>
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
Hello CJ,
Thanks for responding.
On my system, I am building vi and vim differently. In my case, I
think vi is not using the systems' terminfo whereas vim does. Anyway,
I think there is something in rxvt-unicode-256color's terminfo that
affects how the latest vim from the mercurial repo responds/behaves.
Below is my build script for vi and vim
sed -i \
-e 's,/\* #define FEAT_XTERM_SAVE \*/,#define FEAT_XTERM_SAVE,g'\
src/feature.h
echo "CFLAGS: $CFLAGS"
echo "CXXFLAGS: $CXXFLAGS"
echo "LDFLAGS: $LDFLAGS"
./configure --prefix=/usr \
--mandir=/usr/man \
--with-vim-name=vim \
--with-features=huge \
--with-x=yes \
--disable-gui \
--enable-multibyte \
--enable-luainterp \
--enable-perlinterp \
--enable-pythoninterp \
--enable-python3interp=dynamic \
--enable-tclinterp \
--enable-rubyinterp \
--enable-cscope \
--disable-acl \
--disable-sysmouse \
--disable-nls \
--disable-darwin \
--disable-largefile \
--disable-gpm \
--enable-xim \
--enable-fontset \
--enable-xsmp_interact
make VIMRTDIR=
cd src && \
make VIMRTDIR= DESTDIR=$PKG \
installvimbin installruntime installlinks \
&& cd ..
mv $PKG/usr/share/vim/vimrc_example.vim $PKG/usr/share/vim/vimrc
rm -r $PKG/usr/{man/man?/vimtutor*,share/vim/{tutor,macros}}
rm $PKG/usr/share/vim/*/README.txt
ln -sf vim $PKG/usr/bin/evim
ln -sf /bin/vi $PKG/usr/bin/vi
ln -sf vim.1.gz $PKG/usr/man/man1/ex.1.gz
ln -sf vim.1.gz $PKG/usr/man/man1/vi.1.gz
ln -sf vim.1.gz $PKG/usr/man/man1/rvim.1.gz
ln -sf vim.1.gz $PKG/usr/man/man1/view.1.gz
ln -sf vim.1.gz $PKG/usr/man/man1/rview.1.gz
ln -sf vim.1.gz $PKG/usr/man/man1/gvim.1.gz
./configure --prefix=/ \
--datarootdir=/usr/share \
--with-vim-name=vi \
--without-x \
--disable-gui \
--enable-multibyte \
--disable-gpm \
--disable-nls \
--with-features=tiny
make VIMRTDIR=
cd src/ && make VIMRTDIR= DESTDIR=$PKG installvimbin && cd ..
./configure --prefix=/usr \
--with-vim-name=gvim \
--with-x \
--with-features=huge \
--enable-gui=gtk2 \
--enable-multibyte \
--enable-luainterp \
--enable-perlinterp \
--enable-pythoninterp \
--enable-python3interp=dynamic \
--enable-tclinterp \
--enable-rubyinterp \
--enable-cscope \
--enable-gpm \
--enable-xim \
--enable-fontset \
--enable-xsmp_interact \
--disable-darwin \
--disable-largefile \
--disable-acl \
--disable-sysmouse \
--disable-nls
make VIMRTDIR=
cd src && make VIMRTDIR= DESTDIR=$PKG installvimbin && cd ..
install -d $PKG/usr/share/{applications,pixmaps}
my vi and vim executables:
--(/bin)
ls -altr vi
-rwxr-xr-x 1 root root 743704 Aug 30 13:44 vi
--(/bin)
ls -altr /usr/bin/vim
-rwxr-xr-x 1 root root 2228360 Aug 30 13:44 /usr/bin/vim
--(/bin)
/bin/vi --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 30 2012 13:44:25)
Included patches: 1-646
Compiled by root@master
Tiny version without GUI. Features included (+) or not (-):
-arabic -autocmd -balloon_eval -browse +builtin_terms -byte_offset -cindent
-clientserver -clipboard -cmdline_compl -cmdline_hist -cmdline_info -comments
-conceal -cryptv -cscope -cursorbind -cursorshape -dialog -diff -digraphs -dnd
-ebcdic -emacs_tags -eval -ex_extra -extra_search -farsi -file_in_path
-find_in_path -float -folding -footer +fork() -gettext -hangul_input +iconv
-insert_expand -jumplist -keymap -langmap -libcall -linebreak -lispindent
-listcmds -localmap -lua -menu -mksession -modify_fname -mouse -mouse_dec
-mouse_gpm -mouse_jsbterm -mouse_netterm -mouse_sysmouse -mouse_xterm
-mouse_urxvt -mouse_sgr +multi_byte -multi_lang -mzscheme -netbeans_intg
-path_extra -perl -persistent_undo -printer -profile -python -python3 -quickfix
-reltime -rightleft -ruby -scrollbind -signs -smartindent -sniff -startuptime
-statusline -sun_workshop -syntax -tag_binary -tag_old_static -tag_any_white
-tcl +terminfo -termresponse -textobjects -title -toolbar -user_commands
-vertsplit -virtualedit -visual -viminfo -vreplace +wildignore -wildmenu
-windows +writebackup -X11 -xfontset -xim -xsmp -xterm_clipboard +xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -pipe -ftracer
-fgcse-after-reload -march=core2 -mcx16 -msahf -mpclmul -mpopcnt
-msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64
--param l2-cache-size=3072 -mtune=generic -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1
Linking: gcc -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common
-Wl,--as-needed -o vi -lm -lncurses -lelf -lnsl -lacl -lattr
-ldl
--(/bin)
/usr/bin/vim --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 30 2012 13:44:16)
Included patches: 1-646
Compiled by root@master
Huge version without GUI. Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con +diff +digraphs
-dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path
+find_in_path +float +folding -footer +fork() -gettext -hangul_input +iconv
+insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent
+listcmds +localmap +lua +menu +mksession +modify_fname +mouse -mouseshape
+mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm -mouse_sysmouse
+mouse_xterm +mouse_urxvt +mouse_sgr +multi_byte +multi_lang -mzscheme
+netbeans_intg +path_extra +perl +persistent_undo +postscript +printer +profile
+python -python3 +quickfix +reltime +rightleft +ruby +scrollbind +signs
+smartindent -sniff +startuptime +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"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -pipe -ftracer
-fgcse-after-reload -march=core2 -mcx16 -msahf -mpclmul -mpopcnt
-msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64
--param l2-cache-size=3072 -mtune=generic -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1 -I/usr/include -D_LARGEFILE64_SOURCE=1
Linking: gcc -L. -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common
-rdynamic -Wl,-export-dynamic -Wl,-E
-Wl,-rpath,/usr/lib/perl5/5.12/linux-thread-multi/CORE -Wl,-O1
-Wl,--hash-style=gnu -Wl,--sort-common -Wl,--as-needed -o vim -lSM
-lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -lncurses -lelf -lnsl
-ldl -L/usr/lib -llua -Wl,-E
-Wl,-rpath,/usr/lib/perl5/5.12/linux-thread-multi/CORE
-fstack-protector -L/usr/lib/perl5/5.12/linux-thread-multi/CORE
-lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
-L/usr/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm
-Xlinker -export-dynamic -L/usr/lib -ltcl8.5 -ldl -lieee -lm -Wl,-R
-Wl,/usr/lib -L/usr/lib -lruby -lpthread -lrt -ldl -lcrypt -lm
-L/usr/lib
--(/bin)
Hope the above helps. Please let me know if you need more information.
Thanks,
Joe
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> On Thu, Aug 30, 2012 at 01:34:10PM EDT, joe M wrote:
>
> [..]
>
>> Anyway, just a heads-up if anyone is interested.
>
> I certainly do. Thanks for bringing this to the list's attention.
>
> Reading through the thread, I'm pretty sure you stated somewhere along
> the line that the behavior you reported occurs when you run 'vim' and
> does not occur when you run 'vi'.
>
> On my (debian) system, vi and vim both point to the same executable.
>
> And here at least, whatever the terminal, both behave the same way in
> this respect, namely that the screen before I invoke vi/vim is not
> restored to its initial state -- that's the way I have set it up to suit
> my requirements.
>
> I find it a little suspicious that the same executable should behave
> differently regarding something that is not clearly related to editing
> itself and differences between vi and vim dure to their different
> capabilities just because you invoke the program in two different ways.
>
> Mind you, there may be a good reason for that, and I am just not aware
> of it.
>
> All the same, assuming you are running your tests on the same system,
> something you may want to check is the full path of the vi and the vim
> executable. So that we know precisely what gets executed.
>
> This should provide the full path:
>
> | % type vim
> | vim is /usr/bin/vim
> | % type vi
> | vi is /usr/bin/vi
>
> You could then use the file command to determine if they point directly
> to a vi/vim executable:
>
> | % file /path/to/vim
> | % file /path/to/vi
>
> If this is the case, you should see something like this:
>
> | /usr/bin/vim: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
>
> If not, you are pointing to a soft link to another file, that may also
> be a soft link.. etc.
>
> | % file /usr/bin/vi
> | /usr/bin/vi: symbolic link to `/etc/alternatives/vi'
>
> In such circumstances, you can determine the 'final' target of your
> commands via the 'readlink command'.
>
> To illustrate, here's what it looks like on my system:
>
> | % type vi
> | vi is /usr/bin/vi
> |
> | % readlink -f /usr/bin/vi
> | /usr/bin/vim.gtk
>
>
> | % type vim
> | vi is /usr/bin/vim
> |
> | % readlink -f /usr/bin/vim
> | /usr/bin/vim.gtk
>
> Thanks,
>
> CJ
>
> --
> WHAT YOU SAY??
>
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
Hello CJ,
Thanks for responding.
On my system, I am building vi and vim differently. In my case, I
think vi is not using the systems' terminfo whereas vim does. Anyway,
I think there is something in rxvt-unicode-256color's terminfo that
affects how the latest vim from the mercurial repo responds/behaves.
Below is my build script for vi and vim
sed -i \
-e 's,/\* #define FEAT_XTERM_SAVE \*/,#define FEAT_XTERM_SAVE,g'\
src/feature.h
echo "CFLAGS: $CFLAGS"
echo "CXXFLAGS: $CXXFLAGS"
echo "LDFLAGS: $LDFLAGS"
./configure --prefix=/usr \
--mandir=/usr/man \
--with-vim-name=vim \
--with-features=huge \
--with-x=yes \
--disable-gui \
--enable-multibyte \
--enable-luainterp \
--enable-perlinterp \
--enable-pythoninterp \
--enable-python3interp=dynamic \
--enable-tclinterp \
--enable-rubyinterp \
--enable-cscope \
--disable-acl \
--disable-sysmouse \
--disable-nls \
--disable-darwin \
--disable-largefile \
--disable-gpm \
--enable-xim \
--enable-fontset \
--enable-xsmp_interact
make VIMRTDIR=
cd src && \
make VIMRTDIR= DESTDIR=$PKG \
installvimbin installruntime installlinks \
&& cd ..
mv $PKG/usr/share/vim/vimrc_example.vim $PKG/usr/share/vim/vimrc
rm -r $PKG/usr/{man/man?/vimtutor*,share/vim/{tutor,macros}}
rm $PKG/usr/share/vim/*/README.txt
ln -sf vim $PKG/usr/bin/evim
ln -sf /bin/vi $PKG/usr/bin/vi
ln -sf vim.1.gz $PKG/usr/man/man1/ex.1.gz
ln -sf vim.1.gz $PKG/usr/man/man1/vi.1.gz
ln -sf vim.1.gz $PKG/usr/man/man1/rvim.1.gz
ln -sf vim.1.gz $PKG/usr/man/man1/view.1.gz
ln -sf vim.1.gz $PKG/usr/man/man1/rview.1.gz
ln -sf vim.1.gz $PKG/usr/man/man1/gvim.1.gz
./configure --prefix=/ \
--datarootdir=/usr/share \
--with-vim-name=vi \
--without-x \
--disable-gui \
--enable-multibyte \
--disable-gpm \
--disable-nls \
--with-features=tiny
make VIMRTDIR=
cd src/ && make VIMRTDIR= DESTDIR=$PKG installvimbin && cd ..
./configure --prefix=/usr \
--with-vim-name=gvim \
--with-x \
--with-features=huge \
--enable-gui=gtk2 \
--enable-multibyte \
--enable-luainterp \
--enable-perlinterp \
--enable-pythoninterp \
--enable-python3interp=dynamic \
--enable-tclinterp \
--enable-rubyinterp \
--enable-cscope \
--enable-gpm \
--enable-xim \
--enable-fontset \
--enable-xsmp_interact \
--disable-darwin \
--disable-largefile \
--disable-acl \
--disable-sysmouse \
--disable-nls
make VIMRTDIR=
cd src && make VIMRTDIR= DESTDIR=$PKG installvimbin && cd ..
install -d $PKG/usr/share/{applications,pixmaps}
my vi and vim executables:
--(/bin)
ls -altr vi
-rwxr-xr-x 1 root root 743704 Aug 30 13:44 vi
--(/bin)
ls -altr /usr/bin/vim
-rwxr-xr-x 1 root root 2228360 Aug 30 13:44 /usr/bin/vim
--(/bin)
/bin/vi --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 30 2012 13:44:25)
Included patches: 1-646
Compiled by root@master
Tiny version without GUI. Features included (+) or not (-):
-arabic -autocmd -balloon_eval -browse +builtin_terms -byte_offset -cindent
-clientserver -clipboard -cmdline_compl -cmdline_hist -cmdline_info -comments
-conceal -cryptv -cscope -cursorbind -cursorshape -dialog -diff -digraphs -dnd
-ebcdic -emacs_tags -eval -ex_extra -extra_search -farsi -file_in_path
-find_in_path -float -folding -footer +fork() -gettext -hangul_input +iconv
-insert_expand -jumplist -keymap -langmap -libcall -linebreak -lispindent
-listcmds -localmap -lua -menu -mksession -modify_fname -mouse -mouse_dec
-mouse_gpm -mouse_jsbterm -mouse_netterm -mouse_sysmouse -mouse_xterm
-mouse_urxvt -mouse_sgr +multi_byte -multi_lang -mzscheme -netbeans_intg
-path_extra -perl -persistent_undo -printer -profile -python -python3 -quickfix
-reltime -rightleft -ruby -scrollbind -signs -smartindent -sniff -startuptime
-statusline -sun_workshop -syntax -tag_binary -tag_old_static -tag_any_white
-tcl +terminfo -termresponse -textobjects -title -toolbar -user_commands
-vertsplit -virtualedit -visual -viminfo -vreplace +wildignore -wildmenu
-windows +writebackup -X11 -xfontset -xim -xsmp -xterm_clipboard +xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -pipe -ftracer
-fgcse-after-reload -march=core2 -mcx16 -msahf -mpclmul -mpopcnt
-msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64
--param l2-cache-size=3072 -mtune=generic -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1
Linking: gcc -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common
-Wl,--as-needed -o vi -lm -lncurses -lelf -lnsl -lacl -lattr
-ldl
--(/bin)
/usr/bin/vim --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 30 2012 13:44:16)
Included patches: 1-646
Compiled by root@master
Huge version without GUI. Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con +diff +digraphs
-dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path
+find_in_path +float +folding -footer +fork() -gettext -hangul_input +iconv
+insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent
+listcmds +localmap +lua +menu +mksession +modify_fname +mouse -mouseshape
+mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm -mouse_sysmouse
+mouse_xterm +mouse_urxvt +mouse_sgr +multi_byte +multi_lang -mzscheme
+netbeans_intg +path_extra +perl +persistent_undo +postscript +printer +profile
+python -python3 +quickfix +reltime +rightleft +ruby +scrollbind +signs
+smartindent -sniff +startuptime +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"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -pipe -ftracer
-fgcse-after-reload -march=core2 -mcx16 -msahf -mpclmul -mpopcnt
-msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64
--param l2-cache-size=3072 -mtune=generic -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1 -I/usr/include -D_LARGEFILE64_SOURCE=1
Linking: gcc -L. -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common
-rdynamic -Wl,-export-dynamic -Wl,-E
-Wl,-rpath,/usr/lib/perl5/5.12/linux-thread-multi/CORE -Wl,-O1
-Wl,--hash-style=gnu -Wl,--sort-common -Wl,--as-needed -o vim -lSM
-lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -lncurses -lelf -lnsl
-ldl -L/usr/lib -llua -Wl,-E
-Wl,-rpath,/usr/lib/perl5/5.12/linux-thread-multi/CORE
-fstack-protector -L/usr/lib/perl5/5.12/linux-thread-multi/CORE
-lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
-L/usr/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm
-Xlinker -export-dynamic -L/usr/lib -ltcl8.5 -ldl -lieee -lm -Wl,-R
-Wl,/usr/lib -L/usr/lib -lruby -lpthread -lrt -ldl -lcrypt -lm
-L/usr/lib
--(/bin)
Hope the above helps. Please let me know if you need more information.
Thanks,
Joe
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
problems at the first few steps in the vimTutor
I am on windows so i located the tutor file and excetuted it from there.
But in step 1.2 it sais to type ' :q! ' to quit the tutor, and then enter
'vimtutor' from the shell.
First off, when i type :q! , no shell appears, the tutor simply quits.
Secondly the vimtutor command (according to the :help vimtutor information i
read) this command does not work on windows.
Sincerely, a guy who first saw vim a couple hours ago.
--
View this message in context: http://vim.1045645.n5.nabble.com/problems-at-the-first-few-steps-in-the-vimTutor-tp5710499.html
Sent from the Vim - General mailing list archive at Nabble.com.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
But in step 1.2 it sais to type ' :q! ' to quit the tutor, and then enter
'vimtutor' from the shell.
First off, when i type :q! , no shell appears, the tutor simply quits.
Secondly the vimtutor command (according to the :help vimtutor information i
read) this command does not work on windows.
Sincerely, a guy who first saw vim a couple hours ago.
--
View this message in context: http://vim.1045645.n5.nabble.com/problems-at-the-first-few-steps-in-the-vimTutor-tp5710499.html
Sent from the Vim - General mailing list archive at Nabble.com.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Thursday, August 30, 2012
Re: vim window clears the terminal history
On Thu, Aug 30, 2012 at 01:34:10PM EDT, joe M wrote:
[..]
> Anyway, just a heads-up if anyone is interested.
I certainly do. Thanks for bringing this to the list's attention.
Reading through the thread, I'm pretty sure you stated somewhere along
the line that the behavior you reported occurs when you run 'vim' and
does not occur when you run 'vi'.
On my (debian) system, vi and vim both point to the same executable.
And here at least, whatever the terminal, both behave the same way in
this respect, namely that the screen before I invoke vi/vim is not
restored to its initial state -- that's the way I have set it up to suit
my requirements.
I find it a little suspicious that the same executable should behave
differently regarding something that is not clearly related to editing
itself and differences between vi and vim dure to their different
capabilities just because you invoke the program in two different ways.
Mind you, there may be a good reason for that, and I am just not aware
of it.
All the same, assuming you are running your tests on the same system,
something you may want to check is the full path of the vi and the vim
executable. So that we know precisely what gets executed.
This should provide the full path:
| % type vim
| vim is /usr/bin/vim
| % type vi
| vi is /usr/bin/vi
You could then use the file command to determine if they point directly
to a vi/vim executable:
| % file /path/to/vim
| % file /path/to/vi
If this is the case, you should see something like this:
| /usr/bin/vim: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
If not, you are pointing to a soft link to another file, that may also
be a soft link.. etc.
| % file /usr/bin/vi
| /usr/bin/vi: symbolic link to `/etc/alternatives/vi'
In such circumstances, you can determine the 'final' target of your
commands via the 'readlink command'.
To illustrate, here's what it looks like on my system:
| % type vi
| vi is /usr/bin/vi
|
| % readlink -f /usr/bin/vi
| /usr/bin/vim.gtk
| % type vim
| vi is /usr/bin/vim
|
| % readlink -f /usr/bin/vim
| /usr/bin/vim.gtk
Thanks,
CJ
--
WHAT YOU SAY??
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
[..]
> Anyway, just a heads-up if anyone is interested.
I certainly do. Thanks for bringing this to the list's attention.
Reading through the thread, I'm pretty sure you stated somewhere along
the line that the behavior you reported occurs when you run 'vim' and
does not occur when you run 'vi'.
On my (debian) system, vi and vim both point to the same executable.
And here at least, whatever the terminal, both behave the same way in
this respect, namely that the screen before I invoke vi/vim is not
restored to its initial state -- that's the way I have set it up to suit
my requirements.
I find it a little suspicious that the same executable should behave
differently regarding something that is not clearly related to editing
itself and differences between vi and vim dure to their different
capabilities just because you invoke the program in two different ways.
Mind you, there may be a good reason for that, and I am just not aware
of it.
All the same, assuming you are running your tests on the same system,
something you may want to check is the full path of the vi and the vim
executable. So that we know precisely what gets executed.
This should provide the full path:
| % type vim
| vim is /usr/bin/vim
| % type vi
| vi is /usr/bin/vi
You could then use the file command to determine if they point directly
to a vi/vim executable:
| % file /path/to/vim
| % file /path/to/vi
If this is the case, you should see something like this:
| /usr/bin/vim: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
If not, you are pointing to a soft link to another file, that may also
be a soft link.. etc.
| % file /usr/bin/vi
| /usr/bin/vi: symbolic link to `/etc/alternatives/vi'
In such circumstances, you can determine the 'final' target of your
commands via the 'readlink command'.
To illustrate, here's what it looks like on my system:
| % type vi
| vi is /usr/bin/vi
|
| % readlink -f /usr/bin/vi
| /usr/bin/vim.gtk
| % type vim
| vi is /usr/bin/vim
|
| % readlink -f /usr/bin/vim
| /usr/bin/vim.gtk
Thanks,
CJ
--
WHAT YOU SAY??
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
restore last cursor position does not work anymore on my system
Hi,
I use the following code in ~/.vimrc to enable custor restoration. But
it stops working. I suspect that it is due to the recent system
upgrade. I posted the vim --version below. Could anybody take a look
if this is due to some vim option is disabled? Thanks!
" From Bram:
" When editing a file, always jump to the last known cursor position.
" Don't do it when the position is invalid or when inside an event
handler
" (happens when dropping a file on gvim).
" DF - Also do not do this if the file resides in the $TEMP directory,
" chances are it is a different file with the same name.
" This comes from the $VIMRUNTIME/vimrc_example.vim file
" Suresh Govindachar, September 24, 2004 19:57
" I have made a modification: Do not open the fold in
" the special case of the cursor being on the edge of
" an increasing fold. So, the fold will not be opened
" in the following two cases:
"
" 1) cursor is on line 1
" 2) cursor is on the edge of a fold and the
" foldlevel of the previous line is smaller than
" that of the current line.
" I also created an augroup.
augroup JumpCursorOnEdit
au!
autocmd BufReadPost *
\ if expand("<afile>:p:h") !=? $TEMP |
\ if line("'\"") > 1 && line("'\"") <= line("$") |
\ let JumpCursorOnEdit_foo = line("'\"") |
\ let b:doopenfold = 1 |
\ if (foldlevel(JumpCursorOnEdit_foo) >
foldlevel(JumpCursorOnEdit_foo - 1)) |
\ let JumpCursorOnEdit_foo = JumpCursorOnEdit_foo - 1
|
\ let b:doopenfold = 2 |
\ endif |
\ exe JumpCursorOnEdit_foo |
\ endif |
\ endif
" Need to postpone using "zv" until after reading the modelines.
autocmd BufWinEnter *
\ if exists("b:doopenfold") |
\ exe "normal zv" |
\ if(b:doopenfold > 1) |
\ exe "+".1 |
\ endif |
\ unlet b:doopenfold |
\ endif
augroup END
~$ vim --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Feb 28 2012 13:49:48)
Included patches: 1-154
Modified by pkg-vim-maintainers@lists.alioth.debian.org
Compiled by buildd@
Huge version with GTK2-GNOME GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset
+cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info
+comments
+conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui
+diff
+digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search
+farsi
+file_in_path +find_in_path +float +folding -footer +fork() +gettext
-hangul_input +iconv +insert_expand +jumplist +keymap +langmap
+libcall
+linebreak +lispindent +listcmds +localmap +lua +menu +mksession
+modify_fname
+mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm
+mouse_netterm
-mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme
+netbeans_intg
-osfiletype +path_extra +perl +persistent_undo +postscript +printer
+profile
+python -python3 +quickfix +reltime +rightleft +ruby +scrollbind
+signs
+smartindent -sniff +startuptime +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 -
pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/
include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-
pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/
usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/
usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/
libpng12 -pthread -DORBIT2=1 -D_REENTRANT -I/usr/include/gtk-2.0 -I/
usr/include/gdk-pixbuf-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-
linux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-
linux-gnu/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/
gail-1.0 -I/usr/include/freetype2 -I/usr/include/atk-1.0 -I/usr/lib/
x86_64-linux-gnu/gtk-2.0/include -I/usr/include/cairo -I/usr/include/
gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/
include/libgnomeui-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/
2 -I/usr/include/gnome-keyring-1 -I/usr/include/libgnome-2.0 -I/usr/
include/libbonoboui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/
include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/
orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-
activation-2.0 -I/usr/include/libxml2 -Wall -g -O2 -
D_FORTIFY_SOURCE=1 -I/usr/include/tcl8.5 -D_REENTRANT=1 -
D_THREAD_SAFE=1 -D_LARGEFILE64_SOURCE=1
Linking: gcc -L. -Wl,-Bsymbolic-functions -rdynamic -Wl,-export-
dynamic -Wl,-E -Wl,-Bsymbolic-functions -Wl,--as-needed -o vim -
pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0
-lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -
lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -
lglib-2.0 -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnomevfs-2 -
lgnomecanvas-2 -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -
lORBit-2 -lart_lgpl_2 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -
lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -
lfreetype -lfontconfig -lgconf-2 -lgmodule-2.0 -lgobject-2.0 -
lgthread-2.0 -lrt -lglib-2.0 -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -
lSM -lICE -lm -ltinfo -lnsl -lselinux -lacl -lattr -lgpm -ldl -L/
usr/lib -llua5.1 -Wl,-E -fstack-protector -L/usr/local/lib -L/usr/
lib/perl/5.12/CORE -lperl -ldl -lm -lpthread -lcrypt -L/usr/lib/
python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -
export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions -L/usr/lib -ltcl8.5 -
ldl -lpthread -lieee -lm -lruby1.8 -lpthread -lrt -ldl -lcrypt -lm
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
I use the following code in ~/.vimrc to enable custor restoration. But
it stops working. I suspect that it is due to the recent system
upgrade. I posted the vim --version below. Could anybody take a look
if this is due to some vim option is disabled? Thanks!
" From Bram:
" When editing a file, always jump to the last known cursor position.
" Don't do it when the position is invalid or when inside an event
handler
" (happens when dropping a file on gvim).
" DF - Also do not do this if the file resides in the $TEMP directory,
" chances are it is a different file with the same name.
" This comes from the $VIMRUNTIME/vimrc_example.vim file
" Suresh Govindachar, September 24, 2004 19:57
" I have made a modification: Do not open the fold in
" the special case of the cursor being on the edge of
" an increasing fold. So, the fold will not be opened
" in the following two cases:
"
" 1) cursor is on line 1
" 2) cursor is on the edge of a fold and the
" foldlevel of the previous line is smaller than
" that of the current line.
" I also created an augroup.
augroup JumpCursorOnEdit
au!
autocmd BufReadPost *
\ if expand("<afile>:p:h") !=? $TEMP |
\ if line("'\"") > 1 && line("'\"") <= line("$") |
\ let JumpCursorOnEdit_foo = line("'\"") |
\ let b:doopenfold = 1 |
\ if (foldlevel(JumpCursorOnEdit_foo) >
foldlevel(JumpCursorOnEdit_foo - 1)) |
\ let JumpCursorOnEdit_foo = JumpCursorOnEdit_foo - 1
|
\ let b:doopenfold = 2 |
\ endif |
\ exe JumpCursorOnEdit_foo |
\ endif |
\ endif
" Need to postpone using "zv" until after reading the modelines.
autocmd BufWinEnter *
\ if exists("b:doopenfold") |
\ exe "normal zv" |
\ if(b:doopenfold > 1) |
\ exe "+".1 |
\ endif |
\ unlet b:doopenfold |
\ endif
augroup END
~$ vim --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Feb 28 2012 13:49:48)
Included patches: 1-154
Modified by pkg-vim-maintainers@lists.alioth.debian.org
Compiled by buildd@
Huge version with GTK2-GNOME GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset
+cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info
+comments
+conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui
+diff
+digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search
+farsi
+file_in_path +find_in_path +float +folding -footer +fork() +gettext
-hangul_input +iconv +insert_expand +jumplist +keymap +langmap
+libcall
+linebreak +lispindent +listcmds +localmap +lua +menu +mksession
+modify_fname
+mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm
+mouse_netterm
-mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme
+netbeans_intg
-osfiletype +path_extra +perl +persistent_undo +postscript +printer
+profile
+python -python3 +quickfix +reltime +rightleft +ruby +scrollbind
+signs
+smartindent -sniff +startuptime +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 -
pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/
include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-
pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/
usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/
usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/
libpng12 -pthread -DORBIT2=1 -D_REENTRANT -I/usr/include/gtk-2.0 -I/
usr/include/gdk-pixbuf-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-
linux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-
linux-gnu/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/
gail-1.0 -I/usr/include/freetype2 -I/usr/include/atk-1.0 -I/usr/lib/
x86_64-linux-gnu/gtk-2.0/include -I/usr/include/cairo -I/usr/include/
gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/
include/libgnomeui-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/
2 -I/usr/include/gnome-keyring-1 -I/usr/include/libgnome-2.0 -I/usr/
include/libbonoboui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/
include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/
orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-
activation-2.0 -I/usr/include/libxml2 -Wall -g -O2 -
D_FORTIFY_SOURCE=1 -I/usr/include/tcl8.5 -D_REENTRANT=1 -
D_THREAD_SAFE=1 -D_LARGEFILE64_SOURCE=1
Linking: gcc -L. -Wl,-Bsymbolic-functions -rdynamic -Wl,-export-
dynamic -Wl,-E -Wl,-Bsymbolic-functions -Wl,--as-needed -o vim -
pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0
-lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -
lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -
lglib-2.0 -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnomevfs-2 -
lgnomecanvas-2 -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -
lORBit-2 -lart_lgpl_2 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -
lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -
lfreetype -lfontconfig -lgconf-2 -lgmodule-2.0 -lgobject-2.0 -
lgthread-2.0 -lrt -lglib-2.0 -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -
lSM -lICE -lm -ltinfo -lnsl -lselinux -lacl -lattr -lgpm -ldl -L/
usr/lib -llua5.1 -Wl,-E -fstack-protector -L/usr/local/lib -L/usr/
lib/perl/5.12/CORE -lperl -ldl -lm -lpthread -lcrypt -L/usr/lib/
python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -
export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions -L/usr/lib -ltcl8.5 -
ldl -lpthread -lieee -lm -lruby1.8 -lpthread -lrt -ldl -lcrypt -lm
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: ASCIIfication (removal of accent, cedilla, etc)
Or slightly simpler:
function! AEIOU() "! :help [=* equivalence class
for x in split("aeiouny", '\zs')
execute ':%s/[[='.x.'=]]/'.x.'/g'
endfor
endf "usage :silent! call AEIOU()
"! :help digraph-table
" Test on:
"? ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
Bill
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
function! AEIOU() "! :help [=* equivalence class
for x in split("aeiouny", '\zs')
execute ':%s/[[='.x.'=]]/'.x.'/g'
endfor
endf "usage :silent! call AEIOU()
"! :help digraph-table
" Test on:
"? ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
Bill
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Different behavior expanding snippet directly or through inoremap
Hi, I use the snippet plugin ultisnips.
Assume I have two snippets:
snippet snip1 "snippet1" !w
( $1 - $2 )$0
endsnippet
snippet snip2 "snippet2" !w
[ $1 - $2 ]$0
endsnippet
I use <c-j> to expand the snippets and move forward to the next placeholder:
inoremap <NL> <c-r>=UltiSnips_ExpandSnippetOrJump()<CR>
I also use the imaps
inoremap `1 snip1<C-R>=UltiSnips_ExpandSnippetOrJump()<CR>
inoremap `2 snip2<C-R>=UltiSnips_ExpandSnippetOrJump()<CR>
If I type snip1 then expand with <c-j> and this inside type snip2 and expand again, I can type <c-j> sucessuvely until I jump out the inner snippet and then the outer snippet.
On the other hand if I use `1 to expand the snippet and then inside the first snippet type `2 and expand the second snippet I can type <c-j> to navigate outside the inner snippet but not outside the outer snippet.
This is strange because in my mind the imap should translate to what I type directly.
I already asked the author of the snippet plugin and he has no idea why this happens...
Does anyone have any idea?
Thank you,
Jorge
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Assume I have two snippets:
snippet snip1 "snippet1" !w
( $1 - $2 )$0
endsnippet
snippet snip2 "snippet2" !w
[ $1 - $2 ]$0
endsnippet
I use <c-j> to expand the snippets and move forward to the next placeholder:
inoremap <NL> <c-r>=UltiSnips_ExpandSnippetOrJump()<CR>
I also use the imaps
inoremap `1 snip1<C-R>=UltiSnips_ExpandSnippetOrJump()<CR>
inoremap `2 snip2<C-R>=UltiSnips_ExpandSnippetOrJump()<CR>
If I type snip1 then expand with <c-j> and this inside type snip2 and expand again, I can type <c-j> sucessuvely until I jump out the inner snippet and then the outer snippet.
On the other hand if I use `1 to expand the snippet and then inside the first snippet type `2 and expand the second snippet I can type <c-j> to navigate outside the inner snippet but not outside the outer snippet.
This is strange because in my mind the imap should translate to what I type directly.
I already asked the author of the snippet plugin and he has no idea why this happens...
Does anyone have any idea?
Thank you,
Jorge
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: http://www.vim.org/maillist.php references a broken FAQ page (no content)
Hi Bram!
On Do, 30 Aug 2012, Bram Moolenaar wrote:
>
> Aleksey Tsalolikhin wrote:
>
> > Hi. I'm new to vim. I was looking for the mailing list and the FAQ.
> >
> > I'd like to report that http://www.vim.org/maillist.php references a
> > broken FAQ page (there is no content on any of the page on the FAQ
> > site and http://vimdoc.sourceforge.net/vimdocschemes.html gives an
> > error)
>
> I fixed the link to the FAQ. Thanks for reporting this.
I have lately maintained the faq (and the corresponding Vim plugin) at
https://vimhelp.appspot.com/vim_faq.txt.html
regards,
Christian
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
On Do, 30 Aug 2012, Bram Moolenaar wrote:
>
> Aleksey Tsalolikhin wrote:
>
> > Hi. I'm new to vim. I was looking for the mailing list and the FAQ.
> >
> > I'd like to report that http://www.vim.org/maillist.php references a
> > broken FAQ page (there is no content on any of the page on the FAQ
> > site and http://vimdoc.sourceforge.net/vimdocschemes.html gives an
> > error)
>
> I fixed the link to the FAQ. Thanks for reporting this.
I have lately maintained the faq (and the corresponding Vim plugin) at
https://vimhelp.appspot.com/vim_faq.txt.html
regards,
Christian
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: ASCIIfication (removal of accent, cedilla, etc)
Hi Benjamin!
[reformated]
On Mi, 29 Aug 2012, Benjamin R. Haskell wrote:
> On Wed, 29 Aug 2012, Tim Chase wrote:
>
> >I've got some Portuguese text that I need to perform some
> >transformations on to make them ASCII (7-bit). That means
> >removing accent marks, cedillas, tildes, etc.
>
> Just to cover my bases: this seems like a bad idea in general. I
> don't know much about Portuguese, but one of the minimal pairs
> listed in the Wikipedia article for Portuguese phonology¹ is:
>
> pensamos "we think"
> vs.
> pensámos "we thought"
>
>
> >Is there some fast transform in Vim that I've missed, or an easy
> >way to go about this?
>
> In most contexts, Unicode strings are stored in Normal Form C (NFC),
> which means they're equivalent to having passed through Canonical
> Decomposition followed by Canonical Composition. This means that
> any characters that have "combined" codepoints are so combined.
>
> Characters in Unicode strings stored in Normal Form D (NFD) (==
> Canonical Decomposition) have their "combined" codepoints split into
> the base codepoint and "combining character" codepoints.
>
> As a practical example, the string "é" is:
>
> in NFC:
>
> U+00E9 LATIN SMALL LETTER E WITH ACUTE
>
> in NFD:
>
> U+0065 LATIN SMALL LETTER E
> U+0301 COMBINING ACUTE ACCENT
>
> Unicode consortium has full details².
The interesting part is you can add many many combining chars together
to create even new Chars, that don't exist as precombined separate
glyphs. And BTW: for decomposed chars, the 'delcombined' option can be
useful.
One of the major drawbacks is that this will probably cause a lot of
interoperability issues when exchanging data between Unix and Mac OS X,
because on Unix the NFC form is used, while Mac OS X saves data in NFD
form. I already have seen problems like this:
#v+
chrisbra@R500:~/charset$ ls
ä ä
chrisbra@R500:~/charset$ ls |xxd
0000000: 61cc 880a c3a4 0a a......
#v-
So one filename consists of
U+0061 LATIN SMALL LETTER A
U+0308 COMBINING DIAERESIS
while the other filename is stored as
U+00E4 LATIN SMALL LETTER A WITH DIAERESIS
In this case you can convert the filenames using convmv and using the
--nfc or --nfd switch.
I also have seen queries from developers, why sometimes data looks
totally garbled. After investigating, this happened because of NFC/NFD
confusion (or programs not correctly converting those chars).
> The 'icu' project³ (International Components for Unicode) has a
> converter similar to `iconv` called `uconv`, which also lets you
> specify a transliterator to run over the input. So, to get rid of
> accents, cedillas, tildes, etc, you can convert your text into
> Unicode NFD, then convert it to ASCII and discard any characters not
> in ASCII (which includes the combining accent marks).
>
> Assuming the text is encoded in the same encoding as your current
> locale and you're in a Unicode locale, you can pipe it through:
>
> uconv -t ASCII -x nfd -c
>
> -t ASCII = convert to ASCII (t = to/target)
> -x nfd = use the NFD transliterator
> -c = discard any characters that don't have equivalents in the target
>
> If your source data is in a different encoding and/or you're not in
> a Unicode locale (or just a differently-encoded locale), you might
> have to be more explicit, e.g.:
>
> uconv -f SOURCE-ENCODING -t ASCII -x nfd -c
>
> (where SOURCE-ENCODING could be, e.g. ISO-8859-1 or ISO-8859-15 --
> full list from running `uconv -l`)
Thanks Benjamin, that is really useful. I didn't know about uconv and
this looks interesting. Unfortunately, this doesn't work really well.
Consider this test file:
#v+
chrisbra@R500:~/charset$ cat file_utf8_nfc.txt èéêëē
ß
ü
€
Æ
Office
ế
2⁵
chrisbra@R500:~/charset$ uconv -f utf-8 -t ASCII -x nfd -c
file_utf8_nfc.txt eeeee
u
Oce
e
2
#v-
Slightly better is, to transliterate into NFKD (which allows to
transform single glyphs into similar letters) form, before deleting
non-ascii Chars, so this also doesn't work correctly.
#v+
chrisbra@R500:~/charset$ uconv -f utf-8 -t ASCII -x nfkd -c
file_utf8_nfc.txt eeeee
u
Office
e
25
#v-
As you can see, this doesn't work really well, for some more exotic
chars. Even the German Eszett 'ß', which should be not so unknown, can't
be converted to ss, which should certainly be possible.
In this case, iconv still works better:
#v+
chrisbra@R500:~/charset$ iconv -f utf-8 -t ascii//translit file_utf8_nfc.txt
eeeee
ss
ue
EUR
AE
Office
e
2?
#v-
The //translit means, to convert using approximation if a char cannot be
converted directly.
To come back to Vim, it should be possible, to use Vims iconv() function
together with the //translit string, to strip those diacritics, but
unfortunately, this doesn't seem to work very well (and also doesn't
seem to work on Windows at all, although my Vim has +iconv/dyn and I
have iconv.dll¹ lying around):
:%s#.#\=iconv(submatch(0), 'utf-8', 'ascii//translit')#g
produces:
?????
ss
?
EUR
AE
Office
?
2?
For German readers, I'll have also blogged about this at:
https://blog.256bit.org/archives/768-Das-Problem-mit-UTF-8-Teil2.html
https://blog.256bit.org/archives/724-Das-Problem-mit-UTF-8.html
For reference, I'll save this file below
http://www.256bit.org/~chrisbra/utf8_mail.html
in case google groups mangles the characters and browsers seem to be
better in rendering multibyte characters.
¹) In case you are looking for a iconv.dll for windows, you can download
it from here:
http://sourceforge.net/projects/gettext/files/latest/download
and while you are at it, you should possibly also download intl.dll from
http://sourceforge.net/projects/gettext/files/gettext-win32/0.13.1/gettext-runtime-0.13.1.bin.woe32.zip
regards,
Christian
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
[reformated]
On Mi, 29 Aug 2012, Benjamin R. Haskell wrote:
> On Wed, 29 Aug 2012, Tim Chase wrote:
>
> >I've got some Portuguese text that I need to perform some
> >transformations on to make them ASCII (7-bit). That means
> >removing accent marks, cedillas, tildes, etc.
>
> Just to cover my bases: this seems like a bad idea in general. I
> don't know much about Portuguese, but one of the minimal pairs
> listed in the Wikipedia article for Portuguese phonology¹ is:
>
> pensamos "we think"
> vs.
> pensámos "we thought"
>
>
> >Is there some fast transform in Vim that I've missed, or an easy
> >way to go about this?
>
> In most contexts, Unicode strings are stored in Normal Form C (NFC),
> which means they're equivalent to having passed through Canonical
> Decomposition followed by Canonical Composition. This means that
> any characters that have "combined" codepoints are so combined.
>
> Characters in Unicode strings stored in Normal Form D (NFD) (==
> Canonical Decomposition) have their "combined" codepoints split into
> the base codepoint and "combining character" codepoints.
>
> As a practical example, the string "é" is:
>
> in NFC:
>
> U+00E9 LATIN SMALL LETTER E WITH ACUTE
>
> in NFD:
>
> U+0065 LATIN SMALL LETTER E
> U+0301 COMBINING ACUTE ACCENT
>
> Unicode consortium has full details².
The interesting part is you can add many many combining chars together
to create even new Chars, that don't exist as precombined separate
glyphs. And BTW: for decomposed chars, the 'delcombined' option can be
useful.
One of the major drawbacks is that this will probably cause a lot of
interoperability issues when exchanging data between Unix and Mac OS X,
because on Unix the NFC form is used, while Mac OS X saves data in NFD
form. I already have seen problems like this:
#v+
chrisbra@R500:~/charset$ ls
ä ä
chrisbra@R500:~/charset$ ls |xxd
0000000: 61cc 880a c3a4 0a a......
#v-
So one filename consists of
U+0061 LATIN SMALL LETTER A
U+0308 COMBINING DIAERESIS
while the other filename is stored as
U+00E4 LATIN SMALL LETTER A WITH DIAERESIS
In this case you can convert the filenames using convmv and using the
--nfc or --nfd switch.
I also have seen queries from developers, why sometimes data looks
totally garbled. After investigating, this happened because of NFC/NFD
confusion (or programs not correctly converting those chars).
> The 'icu' project³ (International Components for Unicode) has a
> converter similar to `iconv` called `uconv`, which also lets you
> specify a transliterator to run over the input. So, to get rid of
> accents, cedillas, tildes, etc, you can convert your text into
> Unicode NFD, then convert it to ASCII and discard any characters not
> in ASCII (which includes the combining accent marks).
>
> Assuming the text is encoded in the same encoding as your current
> locale and you're in a Unicode locale, you can pipe it through:
>
> uconv -t ASCII -x nfd -c
>
> -t ASCII = convert to ASCII (t = to/target)
> -x nfd = use the NFD transliterator
> -c = discard any characters that don't have equivalents in the target
>
> If your source data is in a different encoding and/or you're not in
> a Unicode locale (or just a differently-encoded locale), you might
> have to be more explicit, e.g.:
>
> uconv -f SOURCE-ENCODING -t ASCII -x nfd -c
>
> (where SOURCE-ENCODING could be, e.g. ISO-8859-1 or ISO-8859-15 --
> full list from running `uconv -l`)
Thanks Benjamin, that is really useful. I didn't know about uconv and
this looks interesting. Unfortunately, this doesn't work really well.
Consider this test file:
#v+
chrisbra@R500:~/charset$ cat file_utf8_nfc.txt èéêëē
ß
ü
€
Æ
Office
ế
2⁵
chrisbra@R500:~/charset$ uconv -f utf-8 -t ASCII -x nfd -c
file_utf8_nfc.txt eeeee
u
Oce
e
2
#v-
Slightly better is, to transliterate into NFKD (which allows to
transform single glyphs into similar letters) form, before deleting
non-ascii Chars, so this also doesn't work correctly.
#v+
chrisbra@R500:~/charset$ uconv -f utf-8 -t ASCII -x nfkd -c
file_utf8_nfc.txt eeeee
u
Office
e
25
#v-
As you can see, this doesn't work really well, for some more exotic
chars. Even the German Eszett 'ß', which should be not so unknown, can't
be converted to ss, which should certainly be possible.
In this case, iconv still works better:
#v+
chrisbra@R500:~/charset$ iconv -f utf-8 -t ascii//translit file_utf8_nfc.txt
eeeee
ss
ue
EUR
AE
Office
e
2?
#v-
The //translit means, to convert using approximation if a char cannot be
converted directly.
To come back to Vim, it should be possible, to use Vims iconv() function
together with the //translit string, to strip those diacritics, but
unfortunately, this doesn't seem to work very well (and also doesn't
seem to work on Windows at all, although my Vim has +iconv/dyn and I
have iconv.dll¹ lying around):
:%s#.#\=iconv(submatch(0), 'utf-8', 'ascii//translit')#g
produces:
?????
ss
?
EUR
AE
Office
?
2?
For German readers, I'll have also blogged about this at:
https://blog.256bit.org/archives/768-Das-Problem-mit-UTF-8-Teil2.html
https://blog.256bit.org/archives/724-Das-Problem-mit-UTF-8.html
For reference, I'll save this file below
http://www.256bit.org/~chrisbra/utf8_mail.html
in case google groups mangles the characters and browsers seem to be
better in rendering multibyte characters.
¹) In case you are looking for a iconv.dll for windows, you can download
it from here:
http://sourceforge.net/projects/gettext/files/latest/download
and while you are at it, you should possibly also download intl.dll from
http://sourceforge.net/projects/gettext/files/gettext-win32/0.13.1/gettext-runtime-0.13.1.bin.woe32.zip
regards,
Christian
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: http://www.vim.org/maillist.php references a broken FAQ page (no content)
Aleksey Tsalolikhin wrote:
> Hi. I'm new to vim. I was looking for the mailing list and the FAQ.
>
> I'd like to report that http://www.vim.org/maillist.php references a
> broken FAQ page (there is no content on any of the page on the FAQ
> site and http://vimdoc.sourceforge.net/vimdocschemes.html gives an
> error)
I fixed the link to the FAQ. Thanks for reporting this.
--
ARTHUR: Who are you?
TALL KNIGHT: We are the Knights Who Say "Ni"!
BEDEVERE: No! Not the Knights Who Say "Ni"!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> Hi. I'm new to vim. I was looking for the mailing list and the FAQ.
>
> I'd like to report that http://www.vim.org/maillist.php references a
> broken FAQ page (there is no content on any of the page on the FAQ
> site and http://vimdoc.sourceforge.net/vimdocschemes.html gives an
> error)
I fixed the link to the FAQ. Thanks for reporting this.
--
ARTHUR: Who are you?
TALL KNIGHT: We are the Knights Who Say "Ni"!
BEDEVERE: No! Not the Knights Who Say "Ni"!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: vim: how to substitute ^H into an delete action
really nice, all concern removed now.
so to conclude: this is the best practice so far for use in vimscripting:
.w/o warning
----
:g/[\b]/while getline('.') =~ '[^\b]\b' | s/[^\b]\b//g | endwhile
----
or
.w/ (harmless) warning
----
:while 1 | %s/[^\b]\b//g | endwhile
----
I tested both.
On 08/29/2012 10:13 AM, Ben Fritz wrote:
> On Tuesday, August 28, 2012 11:25:41 PM UTC-5, John Little wrote:
>> What's wrong with
>>
>> %s/[^\b]\b//g
>>
>> repeated till it finds nothing? Or do it once to check it out, then get vim to repeat it:
>>
>> :while 1 | %s///g | endwhile
>>
>> Regards, John
>
> Nothing wrong with that. Actually it's pretty clever to have an infinite loop ended only by the "no matches" error when you've removed them all. I was avoiding the error by using a :g and repeating a substitute on each line until there were no longer any matches with an explicit check. Your way is not as clear at first glance but almost certainly faster and more efficient. I've got to remember to take advantage of the "error-ends-X" behavior in mappings, macros, and loops more often.
>
> Using \b instead of a literal ^H also removes the problem of yanking and executing the command. I didn't know about \b (since I almost never have text with a literal backspace character). Thanks for sharing!
>
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
so to conclude: this is the best practice so far for use in vimscripting:
.w/o warning
----
:g/[\b]/while getline('.') =~ '[^\b]\b' | s/[^\b]\b//g | endwhile
----
or
.w/ (harmless) warning
----
:while 1 | %s/[^\b]\b//g | endwhile
----
I tested both.
On 08/29/2012 10:13 AM, Ben Fritz wrote:
> On Tuesday, August 28, 2012 11:25:41 PM UTC-5, John Little wrote:
>> What's wrong with
>>
>> %s/[^\b]\b//g
>>
>> repeated till it finds nothing? Or do it once to check it out, then get vim to repeat it:
>>
>> :while 1 | %s///g | endwhile
>>
>> Regards, John
>
> Nothing wrong with that. Actually it's pretty clever to have an infinite loop ended only by the "no matches" error when you've removed them all. I was avoiding the error by using a :g and repeating a substitute on each line until there were no longer any matches with an explicit check. Your way is not as clear at first glance but almost certainly faster and more efficient. I've got to remember to take advantage of the "error-ends-X" behavior in mappings, macros, and loops more often.
>
> Using \b instead of a literal ^H also removes the problem of yanking and executing the command. I didn't know about \b (since I almost never have text with a literal backspace character). Thanks for sharing!
>
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
vim: conqterm: high cpu if buffer pause for long time
hi nico/other conqterm users:
it looks this is quite reproducible.
let's say I run a long task in conqterm , and for some reason I pause it
(by entering normal mode). then I forget about it and keep using my PC
for other works...
some days later I'll find the CPU high, top shows "telnet" process is
100% running. I have to find that session out and resume it (by entering
insert mode), then I got a bunch of cached output from terminal
(received from the devices that I conqterm in).
I never run into such an issue without conqterm, any hint of the
reason/workaround?
thanks!
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
it looks this is quite reproducible.
let's say I run a long task in conqterm , and for some reason I pause it
(by entering normal mode). then I forget about it and keep using my PC
for other works...
some days later I'll find the CPU high, top shows "telnet" process is
100% running. I have to find that session out and resume it (by entering
insert mode), then I got a bunch of cached output from terminal
(received from the devices that I conqterm in).
I never run into such an issue without conqterm, any hint of the
reason/workaround?
thanks!
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: How do I define function for toggling textwidth (and echoing along)?
Am 25.08.2012 11:07, schrieb Santosh Kumar:
> By default I have textwidth set to 78:
> set textwidth=78
>
> By this setting if I type more than 78 characters in a line, those
> will be moved to next line.
> I want a mapping that will toogle that textwidth to 0 (or say disable
> textwidth), so that I can type long sentences in a single line.
>
> Currently I have this mapping:
> nnoremap <silent> <leader>tw :exe "set textwidth=" . (&tw ? 0 : 78)<cr>
This one is more verbose, without visual clutter:
:nn <expr> <Leader>tw printf(":setl tw=%d<CR>", &tw==0 ? 78 : 0)
> This does the work but I don't get notified if the work has been done.
> All I want is along with toggling the setting I should be notified
> (i.e. if textwidth is zero then show textwidth=0 at statusline).
An example how to play with the statusline:
:h 'stl
" standard statusline
" set statusline=%<%f\ %h%m%r%=%-14.(%l,%c%V%)\ %P
set statusline=%<%f\ %h%m%r%{TwLeft()}%=%-14.(%l,%c%V%)\ %P
" remaining textwidth
func! TwLeft()
let ioff = mode()==#"i" ? 1 : 0
if &tw == 0 || virtcol(".") > &tw + ioff
return ""
else
let left = &tw + ioff - virtcol(".")
return printf('[%d %s left]', left, left==1 ? "char" : "chars")
endif
endfunc
--
Andy
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> By default I have textwidth set to 78:
> set textwidth=78
>
> By this setting if I type more than 78 characters in a line, those
> will be moved to next line.
> I want a mapping that will toogle that textwidth to 0 (or say disable
> textwidth), so that I can type long sentences in a single line.
>
> Currently I have this mapping:
> nnoremap <silent> <leader>tw :exe "set textwidth=" . (&tw ? 0 : 78)<cr>
This one is more verbose, without visual clutter:
:nn <expr> <Leader>tw printf(":setl tw=%d<CR>", &tw==0 ? 78 : 0)
> This does the work but I don't get notified if the work has been done.
> All I want is along with toggling the setting I should be notified
> (i.e. if textwidth is zero then show textwidth=0 at statusline).
An example how to play with the statusline:
:h 'stl
" standard statusline
" set statusline=%<%f\ %h%m%r%=%-14.(%l,%c%V%)\ %P
set statusline=%<%f\ %h%m%r%{TwLeft()}%=%-14.(%l,%c%V%)\ %P
" remaining textwidth
func! TwLeft()
let ioff = mode()==#"i" ? 1 : 0
if &tw == 0 || virtcol(".") > &tw + ioff
return ""
else
let left = &tw + ioff - virtcol(".")
return printf('[%d %s left]', left, left==1 ? "char" : "chars")
endif
endfunc
--
Andy
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: vim window clears the terminal history
On Thu, Aug 30, 2012 at 10:26 AM, joe M <joe9mail@gmail.com> wrote:
> u, Aug 30, 2012 at 8:05 AM, John Little <John.B.Little@gmail.com> wrote:
>> On Thursday, August 30, 2012 1:47:49 AM UTC+12, joe M wrote:
>>
>>> Thanks a lot for your analysis. Your observations are spot-on.
>>
>> I'm not sure now. I've installed rxvt-unicode-256color (from the Ubuntu oneiric/universe repository), and it has what I thought was the problematic initialization string, but does not show your problem with vim.
>>
>> The infocmp -C output is different from yours, in that mine complains:
>>
>> # (untranslatable capabilities removed to fit entry within 1023 bytes)
>>
>> I'll append the terminfo output (not using -C). You might like to use tic to compile this, perhaps it's a later version than yours.
>>
>> Perhaps you have some other kludge interfering with the alternate display switch. Some people dislike it, especially for viewing man pages, and use various means to turn it off.
>>
>> Regards, John
>>
>> Reconstructed via infocmp from file: /usr/share/terminfo/r/rxvt-unicode-256color
>> rxvt-unicode-256color|rxvt-unicode terminal with 256 colors (X Window System),
>> am, bce, bw, ccc, eo, hs, km, mc5i, mir, msgr, npc, xenl, xon,
>> btns#5, colors#256, cols#80, it#8, lines#24, lm#0, ncv#0,
>> pairs#32767,
>> acsc=+C\,D-A.B0E``aaffgghFiGjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
>> bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
>> clear=\E[H\E[2J, cnorm=\E[?25h, cr=^M,
>> csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
>> cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
>> cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
>> cvvis=\E[?25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
>> dl1=\E[M, dsl=\E]2;\007, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
>> el1=\E[1K, enacs=, flash=\E[?5h$<20/>\E[?5l, fsl=^G,
>> home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
>> ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=^J, indn=\E[%p1%dS,
>> initc=\E]4;%p1%d;rgb\:%p2%{65535}%*%{1000}%/%4.4X/%p3%{65535}%*%{1000}%/%4.4X/%p4%{65535}%*%{1000}%/%4.4X\E\\,
>> is1=\E[!p,
>> is2=\E[r\E[m\E[2J\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l,
>> kDC=\E[3$, kEND=\E[8$, kHOM=\E[7$, kIC=\E[2$, kLFT=\E[d,
>> kNXT=\E[6$, kPRV=\E[5$, kRIT=\E[c, ka1=\EOw, ka3=\EOy,
>> kb2=\EOu, kbs=\177, kc1=\EOq, kc3=\EOs, kcbt=\E[Z,
>> kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
>> kdch1=\E[3~, kel=\E[8\^, kend=\E[8~, kent=\EOM, kf1=\E[11~,
>> kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[25~,
>> kf14=\E[26~, kf15=\E[28~, kf16=\E[29~, kf17=\E[31~,
>> kf18=\E[32~, kf19=\E[33~, kf2=\E[12~, kf20=\E[34~,
>> kf3=\E[13~, kf4=\E[14~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~,
>> kf8=\E[19~, kf9=\E[20~, kfnd=\E[1~, khome=\E[7~,
>> kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~, kslt=\E[4~,
>> mc0=\E[i, mc4=\E[4i, mc5=\E[5i, op=\E[39;49m, rc=\E8,
>> rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B,
>> rmam=\E[?7l, rmcup=\E[r\E[?1049l, rmir=\E[4l, rmkx=\E>,
>> rmso=\E[27m, rmul=\E[24m, rs1=\Ec,
>> rs2=\E[r\E[m\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l,
>> s0ds=\E(B, s1ds=\E(0, s2ds=\E*B, s3ds=\E+B, sc=\E7,
>> setab=\E[48;5;%p1%dm, setaf=\E[38;5;%p1%dm,
>> setb=%?%p1%{7}%>%t\E[48;5;%p1%dm%e\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m%;,
>> setf=%?%p1%{7}%>%t\E[38;5;%p1%dm%e\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m%;,
>> sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m%?%p9%t\E(0%e\E(B%;,
>> sgr0=\E[m\E(B, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
>> smcup=\E[?1049h, smir=\E[4h, smkx=\E=, smso=\E[7m,
>> smul=\E[4m, tbc=\E[3g, tsl=\E]2;, u6=\E[%i%d;%dR, u7=\E[6n,
>> u8=\E[?1;2c, u9=\E[c, vpa=\E[%i%p1%dd,
>>
>> --
>> You received this message from the "vim_use" maillist.
>> Do not top-post! Type your reply below the text you are replying to.
>> For more information, visit http://www.vim.org/maillist.php
>
> Hello John,
>
> Thanks for responding.
>
> My infocmp is the same as yours. My infocmp is attached.
>
>> Perhaps you have some other kludge interfering with the alternate display switch. Some people dislike it, especially for viewing man pages, and use various means to turn it off.
>
> That is an interesting observation. Will have to check on this.
>
> Thanks
> Joe
Looks like this has something to do with 9.15 rxvt-unicode behaviour
and the latest vim from mercurial repo.
"The way urxvt works in this case that it just positions the cursor to
the top row and then just erases everything below that point. This
means you lose valuable lines from the scrollback. Example: type "seq
1000", press ctr-L. Now you won't see the last lines of the command's
output!" -- this is exactly what is happening in my case.
I got that from https://bbs.archlinux.org/viewtopic.php?id=129302
But, the patch noted in that discussion is not helping.
Anyway, just a heads-up if anyone is interested.
Thanks
Joe
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> u, Aug 30, 2012 at 8:05 AM, John Little <John.B.Little@gmail.com> wrote:
>> On Thursday, August 30, 2012 1:47:49 AM UTC+12, joe M wrote:
>>
>>> Thanks a lot for your analysis. Your observations are spot-on.
>>
>> I'm not sure now. I've installed rxvt-unicode-256color (from the Ubuntu oneiric/universe repository), and it has what I thought was the problematic initialization string, but does not show your problem with vim.
>>
>> The infocmp -C output is different from yours, in that mine complains:
>>
>> # (untranslatable capabilities removed to fit entry within 1023 bytes)
>>
>> I'll append the terminfo output (not using -C). You might like to use tic to compile this, perhaps it's a later version than yours.
>>
>> Perhaps you have some other kludge interfering with the alternate display switch. Some people dislike it, especially for viewing man pages, and use various means to turn it off.
>>
>> Regards, John
>>
>> Reconstructed via infocmp from file: /usr/share/terminfo/r/rxvt-unicode-256color
>> rxvt-unicode-256color|rxvt-unicode terminal with 256 colors (X Window System),
>> am, bce, bw, ccc, eo, hs, km, mc5i, mir, msgr, npc, xenl, xon,
>> btns#5, colors#256, cols#80, it#8, lines#24, lm#0, ncv#0,
>> pairs#32767,
>> acsc=+C\,D-A.B0E``aaffgghFiGjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
>> bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
>> clear=\E[H\E[2J, cnorm=\E[?25h, cr=^M,
>> csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
>> cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
>> cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
>> cvvis=\E[?25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
>> dl1=\E[M, dsl=\E]2;\007, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
>> el1=\E[1K, enacs=, flash=\E[?5h$<20/>\E[?5l, fsl=^G,
>> home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
>> ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=^J, indn=\E[%p1%dS,
>> initc=\E]4;%p1%d;rgb\:%p2%{65535}%*%{1000}%/%4.4X/%p3%{65535}%*%{1000}%/%4.4X/%p4%{65535}%*%{1000}%/%4.4X\E\\,
>> is1=\E[!p,
>> is2=\E[r\E[m\E[2J\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l,
>> kDC=\E[3$, kEND=\E[8$, kHOM=\E[7$, kIC=\E[2$, kLFT=\E[d,
>> kNXT=\E[6$, kPRV=\E[5$, kRIT=\E[c, ka1=\EOw, ka3=\EOy,
>> kb2=\EOu, kbs=\177, kc1=\EOq, kc3=\EOs, kcbt=\E[Z,
>> kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
>> kdch1=\E[3~, kel=\E[8\^, kend=\E[8~, kent=\EOM, kf1=\E[11~,
>> kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[25~,
>> kf14=\E[26~, kf15=\E[28~, kf16=\E[29~, kf17=\E[31~,
>> kf18=\E[32~, kf19=\E[33~, kf2=\E[12~, kf20=\E[34~,
>> kf3=\E[13~, kf4=\E[14~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~,
>> kf8=\E[19~, kf9=\E[20~, kfnd=\E[1~, khome=\E[7~,
>> kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~, kslt=\E[4~,
>> mc0=\E[i, mc4=\E[4i, mc5=\E[5i, op=\E[39;49m, rc=\E8,
>> rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B,
>> rmam=\E[?7l, rmcup=\E[r\E[?1049l, rmir=\E[4l, rmkx=\E>,
>> rmso=\E[27m, rmul=\E[24m, rs1=\Ec,
>> rs2=\E[r\E[m\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l,
>> s0ds=\E(B, s1ds=\E(0, s2ds=\E*B, s3ds=\E+B, sc=\E7,
>> setab=\E[48;5;%p1%dm, setaf=\E[38;5;%p1%dm,
>> setb=%?%p1%{7}%>%t\E[48;5;%p1%dm%e\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m%;,
>> setf=%?%p1%{7}%>%t\E[38;5;%p1%dm%e\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m%;,
>> sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m%?%p9%t\E(0%e\E(B%;,
>> sgr0=\E[m\E(B, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
>> smcup=\E[?1049h, smir=\E[4h, smkx=\E=, smso=\E[7m,
>> smul=\E[4m, tbc=\E[3g, tsl=\E]2;, u6=\E[%i%d;%dR, u7=\E[6n,
>> u8=\E[?1;2c, u9=\E[c, vpa=\E[%i%p1%dd,
>>
>> --
>> You received this message from the "vim_use" maillist.
>> Do not top-post! Type your reply below the text you are replying to.
>> For more information, visit http://www.vim.org/maillist.php
>
> Hello John,
>
> Thanks for responding.
>
> My infocmp is the same as yours. My infocmp is attached.
>
>> Perhaps you have some other kludge interfering with the alternate display switch. Some people dislike it, especially for viewing man pages, and use various means to turn it off.
>
> That is an interesting observation. Will have to check on this.
>
> Thanks
> Joe
Looks like this has something to do with 9.15 rxvt-unicode behaviour
and the latest vim from mercurial repo.
"The way urxvt works in this case that it just positions the cursor to
the top row and then just erases everything below that point. This
means you lose valuable lines from the scrollback. Example: type "seq
1000", press ctr-L. Now you won't see the last lines of the command's
output!" -- this is exactly what is happening in my case.
I got that from https://bbs.archlinux.org/viewtopic.php?id=129302
But, the patch noted in that discussion is not helping.
Anyway, just a heads-up if anyone is interested.
Thanks
Joe
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: ASCIIfication (removal of accent, cedilla, etc)
On Aug 30, 7:20 am, Tim Chase <v...@tim.thechases.com> wrote:
> On 08/29/12 21:46, Salman Halim wrote:
>
> >> I've got some Portuguese text that I need to perform some
> >> transformations on to make them ASCII (7-bit). That means
> >> removing accent marks, cedillas, tildes, etc.
>
> >> Is there some fast transform in Vim that I've missed, or an
> >> easy way to go about this?
>
> > I don't believe there is something that will figure out the
> > non-accented version of a given character, but you could do
> > something similar using tr() by passing in "èéêëē" and "eeeee",
> > for example.
>
> Thanks to everybody for their suggestions. Playing around a little,
> I went with using equivalence classes:
>
> :%s/[[=a=]]/a/g|%s/[[=e=]]/e/g|...
>
> which is still tedious, but at least a little less so. If there's
> some magic method I've missed (this happens to be a work thing, so
> I'm stuck on Win32 without the conversion utility mentioned
> elsewhere in the thread), I'd love to know how to improve this.
>
> -tim
" Something like:
function! AEIOU()
for x in ["a","e","i","o","u","n","y"]
execute ':%s/[[='.x.'=]]/'.x.'/g'
endfor
endf " :call AEIOU()
" Test on:
"? èéêëē
ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
Bill
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> On 08/29/12 21:46, Salman Halim wrote:
>
> >> I've got some Portuguese text that I need to perform some
> >> transformations on to make them ASCII (7-bit). That means
> >> removing accent marks, cedillas, tildes, etc.
>
> >> Is there some fast transform in Vim that I've missed, or an
> >> easy way to go about this?
>
> > I don't believe there is something that will figure out the
> > non-accented version of a given character, but you could do
> > something similar using tr() by passing in "èéêëē" and "eeeee",
> > for example.
>
> Thanks to everybody for their suggestions. Playing around a little,
> I went with using equivalence classes:
>
> :%s/[[=a=]]/a/g|%s/[[=e=]]/e/g|...
>
> which is still tedious, but at least a little less so. If there's
> some magic method I've missed (this happens to be a work thing, so
> I'm stuck on Win32 without the conversion utility mentioned
> elsewhere in the thread), I'd love to know how to improve this.
>
> -tim
" Something like:
function! AEIOU()
for x in ["a","e","i","o","u","n","y"]
execute ':%s/[[='.x.'=]]/'.x.'/g'
endfor
endf " :call AEIOU()
" Test on:
"? èéêëē
ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
Bill
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: ASCIIfication (removal of accent, cedilla, etc)
Tim Chase wrote:
> On 08/29/12 21:46, Salman Halim wrote:
> >> I've got some Portuguese text that I need to perform some
> >> transformations on to make them ASCII (7-bit). That means
> >> removing accent marks, cedillas, tildes, etc.
> >>
> >> Is there some fast transform in Vim that I've missed, or an
> >> easy way to go about this?
> >
> > I don't believe there is something that will figure out the
> > non-accented version of a given character, but you could do
> > something similar using tr() by passing in "èéêëē" and "eeeee",
> > for example.
>
> Thanks to everybody for their suggestions. Playing around a little,
> I went with using equivalence classes:
>
> :%s/[[=a=]]/a/g|%s/[[=e=]]/e/g|...
>
> which is still tedious, but at least a little less so. If there's
> some magic method I've missed (this happens to be a work thing, so
> I'm stuck on Win32 without the conversion utility mentioned
> elsewhere in the thread), I'd love to know how to improve this.
>
> -tim
Something like the following to simplify:
function! AEIOU()
for x in ["a","e","i","o","u"]
execute ':%s/[[='.x.'=]]/'.x.'/g'
endfor
endf " :call AEIOU()
Bill
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> On 08/29/12 21:46, Salman Halim wrote:
> >> I've got some Portuguese text that I need to perform some
> >> transformations on to make them ASCII (7-bit). That means
> >> removing accent marks, cedillas, tildes, etc.
> >>
> >> Is there some fast transform in Vim that I've missed, or an
> >> easy way to go about this?
> >
> > I don't believe there is something that will figure out the
> > non-accented version of a given character, but you could do
> > something similar using tr() by passing in "èéêëē" and "eeeee",
> > for example.
>
> Thanks to everybody for their suggestions. Playing around a little,
> I went with using equivalence classes:
>
> :%s/[[=a=]]/a/g|%s/[[=e=]]/e/g|...
>
> which is still tedious, but at least a little less so. If there's
> some magic method I've missed (this happens to be a work thing, so
> I'm stuck on Win32 without the conversion utility mentioned
> elsewhere in the thread), I'd love to know how to improve this.
>
> -tim
Something like the following to simplify:
function! AEIOU()
for x in ["a","e","i","o","u"]
execute ':%s/[[='.x.'=]]/'.x.'/g'
endfor
endf " :call AEIOU()
Bill
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Colourising command line
On Thursday, August 30, 2012 2:50:18 AM UTC-5, N David Brown wrote:
> I'm a professional programmer so that's entirely feasible, thank you for letting me know.
>
> I haven't looked into how to accomplish the task, it would be a waste of effort were there an existing plugin. All I've done is search for such a plugin, found nothing, then consulted this mailing list as a final check.
>
I alluded to it without making it explicit, but while you can make Vim do pretty much anything by modifying the source, I think you'll have better luck using regular syntax highlighting commands to accomplish what you want in the command-line window instead of the command-line itself. The command-line window is a special buffer but you can give it filetype and syntax just like any other buffer. I think by default it gets the normal "vim" filetype and syntax applied, but you could readily change this. You could then use whatever syntax file you come up with to highlight vim scripts in files as well as when typed as commands.
Doing it with a syntax file applied to the command-window, you get the added bonus of being able to share your work with others who don't want to apply your patch to Vim, and additionally you don't risk the need to update your patch with every new upstream version of Vim.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> I'm a professional programmer so that's entirely feasible, thank you for letting me know.
>
> I haven't looked into how to accomplish the task, it would be a waste of effort were there an existing plugin. All I've done is search for such a plugin, found nothing, then consulted this mailing list as a final check.
>
I alluded to it without making it explicit, but while you can make Vim do pretty much anything by modifying the source, I think you'll have better luck using regular syntax highlighting commands to accomplish what you want in the command-line window instead of the command-line itself. The command-line window is a special buffer but you can give it filetype and syntax just like any other buffer. I think by default it gets the normal "vim" filetype and syntax applied, but you could readily change this. You could then use whatever syntax file you come up with to highlight vim scripts in files as well as when typed as commands.
Doing it with a syntax file applied to the command-window, you get the added bonus of being able to share your work with others who don't want to apply your patch to Vim, and additionally you don't risk the need to update your patch with every new upstream version of Vim.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
http://www.vim.org/maillist.php references a broken FAQ page (no content)
Hi. I'm new to vim. I was looking for the mailing list and the FAQ.
I'd like to report that http://www.vim.org/maillist.php references a broken FAQ page (there is no content on any of the page on the FAQ site and http://vimdoc.sourceforge.net/vimdocschemes.html gives an error)
Best,
Aleksey
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
I'd like to report that http://www.vim.org/maillist.php references a broken FAQ page (there is no content on any of the page on the FAQ site and http://vimdoc.sourceforge.net/vimdocschemes.html gives an error)
Best,
Aleksey
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: vim window clears the terminal history
u, Aug 30, 2012 at 8:05 AM, John Little <John.B.Little@gmail.com> wrote:
> On Thursday, August 30, 2012 1:47:49 AM UTC+12, joe M wrote:
>
>> Thanks a lot for your analysis. Your observations are spot-on.
>
> I'm not sure now. I've installed rxvt-unicode-256color (from the Ubuntu oneiric/universe repository), and it has what I thought was the problematic initialization string, but does not show your problem with vim.
>
> The infocmp -C output is different from yours, in that mine complains:
>
> # (untranslatable capabilities removed to fit entry within 1023 bytes)
>
> I'll append the terminfo output (not using -C). You might like to use tic to compile this, perhaps it's a later version than yours.
>
> Perhaps you have some other kludge interfering with the alternate display switch. Some people dislike it, especially for viewing man pages, and use various means to turn it off.
>
> Regards, John
>
> Reconstructed via infocmp from file: /usr/share/terminfo/r/rxvt-unicode-256color
> rxvt-unicode-256color|rxvt-unicode terminal with 256 colors (X Window System),
> am, bce, bw, ccc, eo, hs, km, mc5i, mir, msgr, npc, xenl, xon,
> btns#5, colors#256, cols#80, it#8, lines#24, lm#0, ncv#0,
> pairs#32767,
> acsc=+C\,D-A.B0E``aaffgghFiGjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
> bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
> clear=\E[H\E[2J, cnorm=\E[?25h, cr=^M,
> csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
> cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
> cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
> cvvis=\E[?25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
> dl1=\E[M, dsl=\E]2;\007, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
> el1=\E[1K, enacs=, flash=\E[?5h$<20/>\E[?5l, fsl=^G,
> home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
> ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=^J, indn=\E[%p1%dS,
> initc=\E]4;%p1%d;rgb\:%p2%{65535}%*%{1000}%/%4.4X/%p3%{65535}%*%{1000}%/%4.4X/%p4%{65535}%*%{1000}%/%4.4X\E\\,
> is1=\E[!p,
> is2=\E[r\E[m\E[2J\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l,
> kDC=\E[3$, kEND=\E[8$, kHOM=\E[7$, kIC=\E[2$, kLFT=\E[d,
> kNXT=\E[6$, kPRV=\E[5$, kRIT=\E[c, ka1=\EOw, ka3=\EOy,
> kb2=\EOu, kbs=\177, kc1=\EOq, kc3=\EOs, kcbt=\E[Z,
> kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
> kdch1=\E[3~, kel=\E[8\^, kend=\E[8~, kent=\EOM, kf1=\E[11~,
> kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[25~,
> kf14=\E[26~, kf15=\E[28~, kf16=\E[29~, kf17=\E[31~,
> kf18=\E[32~, kf19=\E[33~, kf2=\E[12~, kf20=\E[34~,
> kf3=\E[13~, kf4=\E[14~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~,
> kf8=\E[19~, kf9=\E[20~, kfnd=\E[1~, khome=\E[7~,
> kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~, kslt=\E[4~,
> mc0=\E[i, mc4=\E[4i, mc5=\E[5i, op=\E[39;49m, rc=\E8,
> rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B,
> rmam=\E[?7l, rmcup=\E[r\E[?1049l, rmir=\E[4l, rmkx=\E>,
> rmso=\E[27m, rmul=\E[24m, rs1=\Ec,
> rs2=\E[r\E[m\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l,
> s0ds=\E(B, s1ds=\E(0, s2ds=\E*B, s3ds=\E+B, sc=\E7,
> setab=\E[48;5;%p1%dm, setaf=\E[38;5;%p1%dm,
> setb=%?%p1%{7}%>%t\E[48;5;%p1%dm%e\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m%;,
> setf=%?%p1%{7}%>%t\E[38;5;%p1%dm%e\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m%;,
> sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m%?%p9%t\E(0%e\E(B%;,
> sgr0=\E[m\E(B, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
> smcup=\E[?1049h, smir=\E[4h, smkx=\E=, smso=\E[7m,
> smul=\E[4m, tbc=\E[3g, tsl=\E]2;, u6=\E[%i%d;%dR, u7=\E[6n,
> u8=\E[?1;2c, u9=\E[c, vpa=\E[%i%p1%dd,
>
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
Hello John,
Thanks for responding.
My infocmp is the same as yours. My infocmp is attached.
> Perhaps you have some other kludge interfering with the alternate display switch. Some people dislike it, especially for viewing man pages, and use various means to turn it off.
That is an interesting observation. Will have to check on this.
Thanks
Joe
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> On Thursday, August 30, 2012 1:47:49 AM UTC+12, joe M wrote:
>
>> Thanks a lot for your analysis. Your observations are spot-on.
>
> I'm not sure now. I've installed rxvt-unicode-256color (from the Ubuntu oneiric/universe repository), and it has what I thought was the problematic initialization string, but does not show your problem with vim.
>
> The infocmp -C output is different from yours, in that mine complains:
>
> # (untranslatable capabilities removed to fit entry within 1023 bytes)
>
> I'll append the terminfo output (not using -C). You might like to use tic to compile this, perhaps it's a later version than yours.
>
> Perhaps you have some other kludge interfering with the alternate display switch. Some people dislike it, especially for viewing man pages, and use various means to turn it off.
>
> Regards, John
>
> Reconstructed via infocmp from file: /usr/share/terminfo/r/rxvt-unicode-256color
> rxvt-unicode-256color|rxvt-unicode terminal with 256 colors (X Window System),
> am, bce, bw, ccc, eo, hs, km, mc5i, mir, msgr, npc, xenl, xon,
> btns#5, colors#256, cols#80, it#8, lines#24, lm#0, ncv#0,
> pairs#32767,
> acsc=+C\,D-A.B0E``aaffgghFiGjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
> bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
> clear=\E[H\E[2J, cnorm=\E[?25h, cr=^M,
> csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
> cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
> cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
> cvvis=\E[?25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
> dl1=\E[M, dsl=\E]2;\007, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
> el1=\E[1K, enacs=, flash=\E[?5h$<20/>\E[?5l, fsl=^G,
> home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
> ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=^J, indn=\E[%p1%dS,
> initc=\E]4;%p1%d;rgb\:%p2%{65535}%*%{1000}%/%4.4X/%p3%{65535}%*%{1000}%/%4.4X/%p4%{65535}%*%{1000}%/%4.4X\E\\,
> is1=\E[!p,
> is2=\E[r\E[m\E[2J\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l,
> kDC=\E[3$, kEND=\E[8$, kHOM=\E[7$, kIC=\E[2$, kLFT=\E[d,
> kNXT=\E[6$, kPRV=\E[5$, kRIT=\E[c, ka1=\EOw, ka3=\EOy,
> kb2=\EOu, kbs=\177, kc1=\EOq, kc3=\EOs, kcbt=\E[Z,
> kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
> kdch1=\E[3~, kel=\E[8\^, kend=\E[8~, kent=\EOM, kf1=\E[11~,
> kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[25~,
> kf14=\E[26~, kf15=\E[28~, kf16=\E[29~, kf17=\E[31~,
> kf18=\E[32~, kf19=\E[33~, kf2=\E[12~, kf20=\E[34~,
> kf3=\E[13~, kf4=\E[14~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~,
> kf8=\E[19~, kf9=\E[20~, kfnd=\E[1~, khome=\E[7~,
> kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~, kslt=\E[4~,
> mc0=\E[i, mc4=\E[4i, mc5=\E[5i, op=\E[39;49m, rc=\E8,
> rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B,
> rmam=\E[?7l, rmcup=\E[r\E[?1049l, rmir=\E[4l, rmkx=\E>,
> rmso=\E[27m, rmul=\E[24m, rs1=\Ec,
> rs2=\E[r\E[m\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l,
> s0ds=\E(B, s1ds=\E(0, s2ds=\E*B, s3ds=\E+B, sc=\E7,
> setab=\E[48;5;%p1%dm, setaf=\E[38;5;%p1%dm,
> setb=%?%p1%{7}%>%t\E[48;5;%p1%dm%e\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m%;,
> setf=%?%p1%{7}%>%t\E[38;5;%p1%dm%e\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m%;,
> sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m%?%p9%t\E(0%e\E(B%;,
> sgr0=\E[m\E(B, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
> smcup=\E[?1049h, smir=\E[4h, smkx=\E=, smso=\E[7m,
> smul=\E[4m, tbc=\E[3g, tsl=\E]2;, u6=\E[%i%d;%dR, u7=\E[6n,
> u8=\E[?1;2c, u9=\E[c, vpa=\E[%i%p1%dd,
>
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
Hello John,
Thanks for responding.
My infocmp is the same as yours. My infocmp is attached.
> Perhaps you have some other kludge interfering with the alternate display switch. Some people dislike it, especially for viewing man pages, and use various means to turn it off.
That is an interesting observation. Will have to check on this.
Thanks
Joe
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: ASCIIfication (removal of accent, cedilla, etc)
On 08/29/12 21:46, Salman Halim wrote:
>> I've got some Portuguese text that I need to perform some
>> transformations on to make them ASCII (7-bit). That means
>> removing accent marks, cedillas, tildes, etc.
>>
>> Is there some fast transform in Vim that I've missed, or an
>> easy way to go about this?
>
> I don't believe there is something that will figure out the
> non-accented version of a given character, but you could do
> something similar using tr() by passing in "èéêëē" and "eeeee",
> for example.
Thanks to everybody for their suggestions. Playing around a little,
I went with using equivalence classes:
:%s/[[=a=]]/a/g|%s/[[=e=]]/e/g|...
which is still tedious, but at least a little less so. If there's
some magic method I've missed (this happens to be a work thing, so
I'm stuck on Win32 without the conversion utility mentioned
elsewhere in the thread), I'd love to know how to improve this.
-tim
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
>> I've got some Portuguese text that I need to perform some
>> transformations on to make them ASCII (7-bit). That means
>> removing accent marks, cedillas, tildes, etc.
>>
>> Is there some fast transform in Vim that I've missed, or an
>> easy way to go about this?
>
> I don't believe there is something that will figure out the
> non-accented version of a given character, but you could do
> something similar using tr() by passing in "èéêëē" and "eeeee",
> for example.
Thanks to everybody for their suggestions. Playing around a little,
I went with using equivalence classes:
:%s/[[=a=]]/a/g|%s/[[=e=]]/e/g|...
which is still tedious, but at least a little less so. If there's
some magic method I've missed (this happens to be a work thing, so
I'm stuck on Win32 without the conversion utility mentioned
elsewhere in the thread), I'd love to know how to improve this.
-tim
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: vim window clears the terminal history
On Thursday, August 30, 2012 1:47:49 AM UTC+12, joe M wrote:
> Thanks a lot for your analysis. Your observations are spot-on.
I'm not sure now. I've installed rxvt-unicode-256color (from the Ubuntu oneiric/universe repository), and it has what I thought was the problematic initialization string, but does not show your problem with vim.
The infocmp -C output is different from yours, in that mine complains:
# (untranslatable capabilities removed to fit entry within 1023 bytes)
I'll append the terminfo output (not using -C). You might like to use tic to compile this, perhaps it's a later version than yours.
Perhaps you have some other kludge interfering with the alternate display switch. Some people dislike it, especially for viewing man pages, and use various means to turn it off.
Regards, John
Reconstructed via infocmp from file: /usr/share/terminfo/r/rxvt-unicode-256color
rxvt-unicode-256color|rxvt-unicode terminal with 256 colors (X Window System),
am, bce, bw, ccc, eo, hs, km, mc5i, mir, msgr, npc, xenl, xon,
btns#5, colors#256, cols#80, it#8, lines#24, lm#0, ncv#0,
pairs#32767,
acsc=+C\,D-A.B0E``aaffgghFiGjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
clear=\E[H\E[2J, cnorm=\E[?25h, cr=^M,
csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
cvvis=\E[?25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
dl1=\E[M, dsl=\E]2;\007, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
el1=\E[1K, enacs=, flash=\E[?5h$<20/>\E[?5l, fsl=^G,
home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=^J, indn=\E[%p1%dS,
initc=\E]4;%p1%d;rgb\:%p2%{65535}%*%{1000}%/%4.4X/%p3%{65535}%*%{1000}%/%4.4X/%p4%{65535}%*%{1000}%/%4.4X\E\\,
is1=\E[!p,
is2=\E[r\E[m\E[2J\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l,
kDC=\E[3$, kEND=\E[8$, kHOM=\E[7$, kIC=\E[2$, kLFT=\E[d,
kNXT=\E[6$, kPRV=\E[5$, kRIT=\E[c, ka1=\EOw, ka3=\EOy,
kb2=\EOu, kbs=\177, kc1=\EOq, kc3=\EOs, kcbt=\E[Z,
kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
kdch1=\E[3~, kel=\E[8\^, kend=\E[8~, kent=\EOM, kf1=\E[11~,
kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[25~,
kf14=\E[26~, kf15=\E[28~, kf16=\E[29~, kf17=\E[31~,
kf18=\E[32~, kf19=\E[33~, kf2=\E[12~, kf20=\E[34~,
kf3=\E[13~, kf4=\E[14~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~,
kf8=\E[19~, kf9=\E[20~, kfnd=\E[1~, khome=\E[7~,
kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~, kslt=\E[4~,
mc0=\E[i, mc4=\E[4i, mc5=\E[5i, op=\E[39;49m, rc=\E8,
rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B,
rmam=\E[?7l, rmcup=\E[r\E[?1049l, rmir=\E[4l, rmkx=\E>,
rmso=\E[27m, rmul=\E[24m, rs1=\Ec,
rs2=\E[r\E[m\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l,
s0ds=\E(B, s1ds=\E(0, s2ds=\E*B, s3ds=\E+B, sc=\E7,
setab=\E[48;5;%p1%dm, setaf=\E[38;5;%p1%dm,
setb=%?%p1%{7}%>%t\E[48;5;%p1%dm%e\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m%;,
setf=%?%p1%{7}%>%t\E[38;5;%p1%dm%e\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m%;,
sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m%?%p9%t\E(0%e\E(B%;,
sgr0=\E[m\E(B, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
smcup=\E[?1049h, smir=\E[4h, smkx=\E=, smso=\E[7m,
smul=\E[4m, tbc=\E[3g, tsl=\E]2;, u6=\E[%i%d;%dR, u7=\E[6n,
u8=\E[?1;2c, u9=\E[c, vpa=\E[%i%p1%dd,
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> Thanks a lot for your analysis. Your observations are spot-on.
I'm not sure now. I've installed rxvt-unicode-256color (from the Ubuntu oneiric/universe repository), and it has what I thought was the problematic initialization string, but does not show your problem with vim.
The infocmp -C output is different from yours, in that mine complains:
# (untranslatable capabilities removed to fit entry within 1023 bytes)
I'll append the terminfo output (not using -C). You might like to use tic to compile this, perhaps it's a later version than yours.
Perhaps you have some other kludge interfering with the alternate display switch. Some people dislike it, especially for viewing man pages, and use various means to turn it off.
Regards, John
Reconstructed via infocmp from file: /usr/share/terminfo/r/rxvt-unicode-256color
rxvt-unicode-256color|rxvt-unicode terminal with 256 colors (X Window System),
am, bce, bw, ccc, eo, hs, km, mc5i, mir, msgr, npc, xenl, xon,
btns#5, colors#256, cols#80, it#8, lines#24, lm#0, ncv#0,
pairs#32767,
acsc=+C\,D-A.B0E``aaffgghFiGjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
clear=\E[H\E[2J, cnorm=\E[?25h, cr=^M,
csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
cvvis=\E[?25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
dl1=\E[M, dsl=\E]2;\007, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
el1=\E[1K, enacs=, flash=\E[?5h$<20/>\E[?5l, fsl=^G,
home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=^J, indn=\E[%p1%dS,
initc=\E]4;%p1%d;rgb\:%p2%{65535}%*%{1000}%/%4.4X/%p3%{65535}%*%{1000}%/%4.4X/%p4%{65535}%*%{1000}%/%4.4X\E\\,
is1=\E[!p,
is2=\E[r\E[m\E[2J\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l,
kDC=\E[3$, kEND=\E[8$, kHOM=\E[7$, kIC=\E[2$, kLFT=\E[d,
kNXT=\E[6$, kPRV=\E[5$, kRIT=\E[c, ka1=\EOw, ka3=\EOy,
kb2=\EOu, kbs=\177, kc1=\EOq, kc3=\EOs, kcbt=\E[Z,
kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
kdch1=\E[3~, kel=\E[8\^, kend=\E[8~, kent=\EOM, kf1=\E[11~,
kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[25~,
kf14=\E[26~, kf15=\E[28~, kf16=\E[29~, kf17=\E[31~,
kf18=\E[32~, kf19=\E[33~, kf2=\E[12~, kf20=\E[34~,
kf3=\E[13~, kf4=\E[14~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~,
kf8=\E[19~, kf9=\E[20~, kfnd=\E[1~, khome=\E[7~,
kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~, kslt=\E[4~,
mc0=\E[i, mc4=\E[4i, mc5=\E[5i, op=\E[39;49m, rc=\E8,
rev=\E[7m, ri=\EM, rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B,
rmam=\E[?7l, rmcup=\E[r\E[?1049l, rmir=\E[4l, rmkx=\E>,
rmso=\E[27m, rmul=\E[24m, rs1=\Ec,
rs2=\E[r\E[m\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l,
s0ds=\E(B, s1ds=\E(0, s2ds=\E*B, s3ds=\E+B, sc=\E7,
setab=\E[48;5;%p1%dm, setaf=\E[38;5;%p1%dm,
setb=%?%p1%{7}%>%t\E[48;5;%p1%dm%e\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m%;,
setf=%?%p1%{7}%>%t\E[38;5;%p1%dm%e\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m%;,
sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m%?%p9%t\E(0%e\E(B%;,
sgr0=\E[m\E(B, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
smcup=\E[?1049h, smir=\E[4h, smkx=\E=, smso=\E[7m,
smul=\E[4m, tbc=\E[3g, tsl=\E]2;, u6=\E[%i%d;%dR, u7=\E[6n,
u8=\E[?1;2c, u9=\E[c, vpa=\E[%i%p1%dd,
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: ASCIIfication (removal of accent, cedilla, etc)
Andy Wokula wrote:
> Am 30.08.2012 04:36, schrieb Tim Chase:
>
>> I've got some Portuguese text that I need to perform some
>> transformations on to make them ASCII (7-bit). That means removing
>> accent marks, cedillas, tildes, etc.
>>
>> Is there some fast transform in Vim that I've missed, or an easy way
>> to go about this?
>>
>> Thanks,
>>
>> -tim
>
>
> From the pattern point of view, there are equivalence classes:
> /[[=
>
> Maybe this can be used in:
> :%s/[[=e=]]/e/g
> etc.
You need a fairly recent version of Vim for this feature to work
with non-latin1 characters since equivalent classes [[=.=]] were
improved in this patch ftp://ftp.vim.org/pub/vim/patches/7.3/7.3.259
Regards
-- Dominique
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> Am 30.08.2012 04:36, schrieb Tim Chase:
>
>> I've got some Portuguese text that I need to perform some
>> transformations on to make them ASCII (7-bit). That means removing
>> accent marks, cedillas, tildes, etc.
>>
>> Is there some fast transform in Vim that I've missed, or an easy way
>> to go about this?
>>
>> Thanks,
>>
>> -tim
>
>
> From the pattern point of view, there are equivalence classes:
> /[[=
>
> Maybe this can be used in:
> :%s/[[=e=]]/e/g
> etc.
You need a fairly recent version of Vim for this feature to work
with non-latin1 characters since equivalent classes [[=.=]] were
improved in this patch ftp://ftp.vim.org/pub/vim/patches/7.3/7.3.259
Regards
-- Dominique
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: ASCIIfication (removal of accent, cedilla, etc)
Am 30.08.2012 04:36, schrieb Tim Chase:
> I've got some Portuguese text that I need to perform some
> transformations on to make them ASCII (7-bit). That means removing
> accent marks, cedillas, tildes, etc.
>
> Is there some fast transform in Vim that I've missed, or an easy way
> to go about this?
>
> Thanks,
>
> -tim
From the pattern point of view, there are equivalence classes:
/[[=
Maybe this can be used in:
:%s/[[=e=]]/e/g
etc.
--
Andy
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> I've got some Portuguese text that I need to perform some
> transformations on to make them ASCII (7-bit). That means removing
> accent marks, cedillas, tildes, etc.
>
> Is there some fast transform in Vim that I've missed, or an easy way
> to go about this?
>
> Thanks,
>
> -tim
From the pattern point of view, there are equivalence classes:
/[[=
Maybe this can be used in:
:%s/[[=e=]]/e/g
etc.
--
Andy
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Colourising command line
I'm a professional programmer so that's entirely feasible, thank you for letting me know.
I haven't looked into how to accomplish the task, it would be a waste of effort were there an existing plugin. All I've done is search for such a plugin, found nothing, then consulted this mailing list as a final check.
Thanks,
David
On Wednesday, 29 August 2012 15:30:46 UTC+1, Ben Fritz wrote:
> On Wednesday, August 29, 2012 7:57:31 AM UTC-5, N David Brown wrote:
>
> > Is anyone aware of a plugin which will colorise the Vim command line? I'm about to create one to facilitate regex composition and want to ensure it's necessary first.
>
> >
>
> > Sincere thanks,
>
> >
>
> > David
>
>
>
> I don't know of one. And I actually don't think it's possible. How were you planning on accomplishing it?
>
>
>
> It is almost certainly possible to do in the command-line window with normal syntax highlighting, but I doubt you'll be successful without modifying the Vim source to color the command-line itself.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
I haven't looked into how to accomplish the task, it would be a waste of effort were there an existing plugin. All I've done is search for such a plugin, found nothing, then consulted this mailing list as a final check.
Thanks,
David
On Wednesday, 29 August 2012 15:30:46 UTC+1, Ben Fritz wrote:
> On Wednesday, August 29, 2012 7:57:31 AM UTC-5, N David Brown wrote:
>
> > Is anyone aware of a plugin which will colorise the Vim command line? I'm about to create one to facilitate regex composition and want to ensure it's necessary first.
>
> >
>
> > Sincere thanks,
>
> >
>
> > David
>
>
>
> I don't know of one. And I actually don't think it's possible. How were you planning on accomplishing it?
>
>
>
> It is almost certainly possible to do in the command-line window with normal syntax highlighting, but I doubt you'll be successful without modifying the Vim source to color the command-line itself.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Wednesday, August 29, 2012
Re: ASCIIfication (removal of accent, cedilla, etc)
The tl;dr version, pipe it through:
uconv -t ASCII -x nfd -c
On Wed, 29 Aug 2012, Tim Chase wrote:
> I've got some Portuguese text that I need to perform some
> transformations on to make them ASCII (7-bit). That means removing
> accent marks, cedillas, tildes, etc.
Just to cover my bases: this seems like a bad idea in general. I don't
know much about Portuguese, but one of the minimal pairs listed in the
Wikipedia article for Portuguese phonology¹ is:
pensamos "we think"
vs.
pensámos "we thought"
> Is there some fast transform in Vim that I've missed, or an easy way
> to go about this?
In most contexts, Unicode strings are stored in Normal Form C (NFC),
which means they're equivalent to having passed through Canonical
Decomposition followed by Canonical Composition. This means that any
characters that have "combined" codepoints are so combined.
Characters in Unicode strings stored in Normal Form D (NFD) (==
Canonical Decomposition) have their "combined" codepoints split into the
base codepoint and "combining character" codepoints.
As a practical example, the string "é" is:
in NFC:
U+00E9 LATIN SMALL LETTER E WITH ACUTE
in NFD:
U+0065 LATIN SMALL LETTER E
U+0301 COMBINING ACUTE ACCENT
Unicode consortium has full details².
The 'icu' project³ (International Components for Unicode) has a
converter similar to `iconv` called `uconv`, which also lets you specify
a transliterator to run over the input. So, to get rid of accents,
cedillas, tildes, etc, you can convert your text into Unicode NFD, then
convert it to ASCII and discard any characters not in ASCII (which
includes the combining accent marks).
Assuming the text is encoded in the same encoding as your current
locale and you're in a Unicode locale, you can pipe it through:
uconv -t ASCII -x nfd -c
-t ASCII = convert to ASCII (t = to/target)
-x nfd = use the NFD transliterator
-c = discard any characters that don't have equivalents in the target
If your source data is in a different encoding and/or you're not in a
Unicode locale (or just a differently-encoded locale), you might have to
be more explicit, e.g.:
uconv -f SOURCE-ENCODING -t ASCII -x nfd -c
(where SOURCE-ENCODING could be, e.g. ISO-8859-1 or ISO-8859-15 -- full
list from running `uconv -l`)
--
Best,
Ben
¹: http://en.wikipedia.org/wiki/Portuguese_phonology
²: http://unicode.org/reports/TR15/
³: http://icu-project.org
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
uconv -t ASCII -x nfd -c
On Wed, 29 Aug 2012, Tim Chase wrote:
> I've got some Portuguese text that I need to perform some
> transformations on to make them ASCII (7-bit). That means removing
> accent marks, cedillas, tildes, etc.
Just to cover my bases: this seems like a bad idea in general. I don't
know much about Portuguese, but one of the minimal pairs listed in the
Wikipedia article for Portuguese phonology¹ is:
pensamos "we think"
vs.
pensámos "we thought"
> Is there some fast transform in Vim that I've missed, or an easy way
> to go about this?
In most contexts, Unicode strings are stored in Normal Form C (NFC),
which means they're equivalent to having passed through Canonical
Decomposition followed by Canonical Composition. This means that any
characters that have "combined" codepoints are so combined.
Characters in Unicode strings stored in Normal Form D (NFD) (==
Canonical Decomposition) have their "combined" codepoints split into the
base codepoint and "combining character" codepoints.
As a practical example, the string "é" is:
in NFC:
U+00E9 LATIN SMALL LETTER E WITH ACUTE
in NFD:
U+0065 LATIN SMALL LETTER E
U+0301 COMBINING ACUTE ACCENT
Unicode consortium has full details².
The 'icu' project³ (International Components for Unicode) has a
converter similar to `iconv` called `uconv`, which also lets you specify
a transliterator to run over the input. So, to get rid of accents,
cedillas, tildes, etc, you can convert your text into Unicode NFD, then
convert it to ASCII and discard any characters not in ASCII (which
includes the combining accent marks).
Assuming the text is encoded in the same encoding as your current
locale and you're in a Unicode locale, you can pipe it through:
uconv -t ASCII -x nfd -c
-t ASCII = convert to ASCII (t = to/target)
-x nfd = use the NFD transliterator
-c = discard any characters that don't have equivalents in the target
If your source data is in a different encoding and/or you're not in a
Unicode locale (or just a differently-encoded locale), you might have to
be more explicit, e.g.:
uconv -f SOURCE-ENCODING -t ASCII -x nfd -c
(where SOURCE-ENCODING could be, e.g. ISO-8859-1 or ISO-8859-15 -- full
list from running `uconv -l`)
--
Best,
Ben
¹: http://en.wikipedia.org/wiki/Portuguese_phonology
²: http://unicode.org/reports/TR15/
³: http://icu-project.org
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: ASCIIfication (removal of accent, cedilla, etc)
To reply to my own post, check out vim.wikia.com/wiki/Remove_diacritical_signs_from_characters
Salman
Salman
CDIV Fyle nae founde.
On 29, اگست 2012, at 22:36, Tim Chase <vim@tim.thechases.com> wrote:I've got some Portuguese text that I need to perform sometransformations on to make them ASCII (7-bit). That means removingaccent marks, cedillas, tildes, etc.Is there some fast transform in Vim that I've missed, or an easy wayto go about this?Thanks,-tim
I don't believe there is something that will figure out the non-accented version of a given character, but you could do something similar using tr() by passing in "èéêëē" and "eeeee", for example.
Tedious, yes, but only needs to be done a few times and shouldn't be a very painful function that takes a range of lines and does this over them.
Hope this helps,
Salman
Re: ASCIIfication (removal of accent, cedilla, etc)
On 29, اگست 2012, at 22:36, Tim Chase <vim@tim.thechases.com> wrote:
> I've got some Portuguese text that I need to perform some
> transformations on to make them ASCII (7-bit). That means removing
> accent marks, cedillas, tildes, etc.
>
> Is there some fast transform in Vim that I've missed, or an easy way
> to go about this?
>
> Thanks,
>
> -tim
I don't believe there is something that will figure out the non-accented version of a given character, but you could do something similar using tr() by passing in "èéêëē" and "eeeee", for example.
Tedious, yes, but only needs to be done a few times and shouldn't be a very painful function that takes a range of lines and does this over them.
Hope this helps,
Salman
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> I've got some Portuguese text that I need to perform some
> transformations on to make them ASCII (7-bit). That means removing
> accent marks, cedillas, tildes, etc.
>
> Is there some fast transform in Vim that I've missed, or an easy way
> to go about this?
>
> Thanks,
>
> -tim
I don't believe there is something that will figure out the non-accented version of a given character, but you could do something similar using tr() by passing in "èéêëē" and "eeeee", for example.
Tedious, yes, but only needs to be done a few times and shouldn't be a very painful function that takes a range of lines and does this over them.
Hope this helps,
Salman
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
ASCIIfication (removal of accent, cedilla, etc)
I've got some Portuguese text that I need to perform some
transformations on to make them ASCII (7-bit). That means removing
accent marks, cedillas, tildes, etc.
Is there some fast transform in Vim that I've missed, or an easy way
to go about this?
Thanks,
-tim
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
transformations on to make them ASCII (7-bit). That means removing
accent marks, cedillas, tildes, etc.
Is there some fast transform in Vim that I've missed, or an easy way
to go about this?
Thanks,
-tim
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Autocmds
On Wednesday, August 29, 2012 5:36:53 PM UTC-5, Jan wrote:
> On Wednesday, 29 August, 2012 at 15:28:47 BST, Ben Fritz wrote:
>
> >> But FileType autocmds get executed at every display of the buffer, not just when loading the file.
>
> >
>
> >This didn't sound right, but I did an experiment, and by default it is quite true. In my setup, actually, it is also true.
>
> >
>
> >But if you set the 'hidden' option, it is no longer true. FileType only fires when actually reading the file with 'hidden' set, for me at least.
>
>
>
> Aha, I didn't think about hidden! Good catch. I see the same behaviour when I set it, too, which solves my problem -- thanks!
>
>
>
> >I don't have 'hidden' set because I am forgetful and don't like risking that I might do a bunch of work, go to compile, and realize I forgot to save a header file or something.
>
>
>
> Is there something about setting hidden that stops vim warning when you try to exit without "!" (eg. :qa)?
>
Nope, but I tend to leave Vim running after editing so that doesn't help me too much. If I did quick edits in Vim and then quit Vim before compiling that could solve my problem. Or doing :wa right before. But sometimes I have stuff I'm not ready to save yet.
Come to think of it, I have stuff I don't want to save infrequently enough that doing :wa might be a good idea anyway.
Related options (can be used together with or independently from 'hidden' depending on what you want Vim to do when you close a file or quit) are 'confirm' and 'autowriteall'. I personally set 'confirm' and neither of the others.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> On Wednesday, 29 August, 2012 at 15:28:47 BST, Ben Fritz wrote:
>
> >> But FileType autocmds get executed at every display of the buffer, not just when loading the file.
>
> >
>
> >This didn't sound right, but I did an experiment, and by default it is quite true. In my setup, actually, it is also true.
>
> >
>
> >But if you set the 'hidden' option, it is no longer true. FileType only fires when actually reading the file with 'hidden' set, for me at least.
>
>
>
> Aha, I didn't think about hidden! Good catch. I see the same behaviour when I set it, too, which solves my problem -- thanks!
>
>
>
> >I don't have 'hidden' set because I am forgetful and don't like risking that I might do a bunch of work, go to compile, and realize I forgot to save a header file or something.
>
>
>
> Is there something about setting hidden that stops vim warning when you try to exit without "!" (eg. :qa)?
>
Nope, but I tend to leave Vim running after editing so that doesn't help me too much. If I did quick edits in Vim and then quit Vim before compiling that could solve my problem. Or doing :wa right before. But sometimes I have stuff I'm not ready to save yet.
Come to think of it, I have stuff I don't want to save infrequently enough that doing :wa might be a good idea anyway.
Related options (can be used together with or independently from 'hidden' depending on what you want Vim to do when you close a file or quit) are 'confirm' and 'autowriteall'. I personally set 'confirm' and neither of the others.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Typing "â" problem
On Monday, August 27, 2012 2:35:21 PM UTC-3, Chris Jones wrote:
> Have you reported these issues to the maintainers of these plugins..?
>
Sorry for the late reply. I have been unbelievably busy. I'm going to report the issue today.
>
> Note, that per the README file of the auto-pairs plugin, it is possible
>
> to disable or reassign the built-in mappings by setting global g: Vim
>
> variables in your ~/.vimrc.
>
Yeah. I'll take a look at that as well.
Thanks.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> Have you reported these issues to the maintainers of these plugins..?
>
Sorry for the late reply. I have been unbelievably busy. I'm going to report the issue today.
>
> Note, that per the README file of the auto-pairs plugin, it is possible
>
> to disable or reassign the built-in mappings by setting global g: Vim
>
> variables in your ~/.vimrc.
>
Yeah. I'll take a look at that as well.
Thanks.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Autocmds
On Wednesday, 29 August, 2012 at 15:28:47 BST, Ben Fritz wrote:
>> But FileType autocmds get executed at every display of the buffer, not just when loading the file.
>
>This didn't sound right, but I did an experiment, and by default it is quite true. In my setup, actually, it is also true.
>
>But if you set the 'hidden' option, it is no longer true. FileType only fires when actually reading the file with 'hidden' set, for me at least.
Aha, I didn't think about hidden! Good catch. I see the same behaviour when I set it, too, which solves my problem -- thanks!
>I don't have 'hidden' set because I am forgetful and don't like risking that I might do a bunch of work, go to compile, and realize I forgot to save a header file or something.
Is there something about setting hidden that stops vim warning when you try to exit without "!" (eg. :qa)?
--
.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
>> But FileType autocmds get executed at every display of the buffer, not just when loading the file.
>
>This didn't sound right, but I did an experiment, and by default it is quite true. In my setup, actually, it is also true.
>
>But if you set the 'hidden' option, it is no longer true. FileType only fires when actually reading the file with 'hidden' set, for me at least.
Aha, I didn't think about hidden! Good catch. I see the same behaviour when I set it, too, which solves my problem -- thanks!
>I don't have 'hidden' set because I am forgetful and don't like risking that I might do a bunch of work, go to compile, and realize I forgot to save a header file or something.
Is there something about setting hidden that stops vim warning when you try to exit without "!" (eg. :qa)?
--
.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Colourising command line
On Wednesday, August 29, 2012 7:57:31 AM UTC-5, N David Brown wrote:
> Is anyone aware of a plugin which will colorise the Vim command line? I'm about to create one to facilitate regex composition and want to ensure it's necessary first.
>
> Sincere thanks,
>
> David
I don't know of one. And I actually don't think it's possible. How were you planning on accomplishing it?
It is almost certainly possible to do in the command-line window with normal syntax highlighting, but I doubt you'll be successful without modifying the Vim source to color the command-line itself.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> Is anyone aware of a plugin which will colorise the Vim command line? I'm about to create one to facilitate regex composition and want to ensure it's necessary first.
>
> Sincere thanks,
>
> David
I don't know of one. And I actually don't think it's possible. How were you planning on accomplishing it?
It is almost certainly possible to do in the command-line window with normal syntax highlighting, but I doubt you'll be successful without modifying the Vim source to color the command-line itself.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Autocmds
On Wednesday, August 29, 2012 6:52:04 AM UTC-5, Jan wrote:
> On Tuesday, 28 August, 2012 at 04:12:26 BST, Ben Fritz wrote:
>
> >> When I try this:
>
> >>
>
> >> autocmd BufRead * if &ft == 'perl' | setlocal makeprg=perl\ -cw\ % | endif
>
> >>
>
> >> makeprg doesn't get set, I guess because vim sets the filetype to "perl" only after BufRead has happened (the :help doesn't say). The :help does hint at using BufWinEnter instead, which works for this case, but it seems suboptimal having these autocmd commands executed every time I display the buffer, when really I only need them executed the once, after buffer read/load.
>
> >
>
> >The event you want for the loading of the file is FileType. As mentioned before.
>
>
>
> But FileType autocmds get executed at every display of the buffer, not just when loading the file.
>
>
This didn't sound right, but I did an experiment, and by default it is quite true. In my setup, actually, it is also true.
But if you set the 'hidden' option, it is no longer true. FileType only fires when actually reading the file with 'hidden' set, for me at least.
Looking again at :help 'hidden', I see that when it is not set, the buffer is "unloaded" when it is abandoned. Unloading a buffer frees the text, so the next time you edit the buffer Vim must re-read the file, therefore re-triggering all the associated autocmds.
I don't have 'hidden' set because I am forgetful and don't like risking that I might do a bunch of work, go to compile, and realize I forgot to save a header file or something. But I know a LOT of people think 'hidden' is useful enough that it ought to be the default. I guess in this situation Vim behaves somewhat surprisingly without 'hidden' set. At this point I wonder how many of my autocmds would break were I to set 'hidden'...
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> On Tuesday, 28 August, 2012 at 04:12:26 BST, Ben Fritz wrote:
>
> >> When I try this:
>
> >>
>
> >> autocmd BufRead * if &ft == 'perl' | setlocal makeprg=perl\ -cw\ % | endif
>
> >>
>
> >> makeprg doesn't get set, I guess because vim sets the filetype to "perl" only after BufRead has happened (the :help doesn't say). The :help does hint at using BufWinEnter instead, which works for this case, but it seems suboptimal having these autocmd commands executed every time I display the buffer, when really I only need them executed the once, after buffer read/load.
>
> >
>
> >The event you want for the loading of the file is FileType. As mentioned before.
>
>
>
> But FileType autocmds get executed at every display of the buffer, not just when loading the file.
>
>
This didn't sound right, but I did an experiment, and by default it is quite true. In my setup, actually, it is also true.
But if you set the 'hidden' option, it is no longer true. FileType only fires when actually reading the file with 'hidden' set, for me at least.
Looking again at :help 'hidden', I see that when it is not set, the buffer is "unloaded" when it is abandoned. Unloading a buffer frees the text, so the next time you edit the buffer Vim must re-read the file, therefore re-triggering all the associated autocmds.
I don't have 'hidden' set because I am forgetful and don't like risking that I might do a bunch of work, go to compile, and realize I forgot to save a header file or something. But I know a LOT of people think 'hidden' is useful enough that it ought to be the default. I guess in this situation Vim behaves somewhat surprisingly without 'hidden' set. At this point I wonder how many of my autocmds would break were I to set 'hidden'...
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: vim: how to substitute ^H into an delete action
On Tuesday, August 28, 2012 11:25:41 PM UTC-5, John Little wrote:
> What's wrong with
>
> %s/[^\b]\b//g
>
> repeated till it finds nothing? Or do it once to check it out, then get vim to repeat it:
>
> :while 1 | %s///g | endwhile
>
> Regards, John
Nothing wrong with that. Actually it's pretty clever to have an infinite loop ended only by the "no matches" error when you've removed them all. I was avoiding the error by using a :g and repeating a substitute on each line until there were no longer any matches with an explicit check. Your way is not as clear at first glance but almost certainly faster and more efficient. I've got to remember to take advantage of the "error-ends-X" behavior in mappings, macros, and loops more often.
Using \b instead of a literal ^H also removes the problem of yanking and executing the command. I didn't know about \b (since I almost never have text with a literal backspace character). Thanks for sharing!
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> What's wrong with
>
> %s/[^\b]\b//g
>
> repeated till it finds nothing? Or do it once to check it out, then get vim to repeat it:
>
> :while 1 | %s///g | endwhile
>
> Regards, John
Nothing wrong with that. Actually it's pretty clever to have an infinite loop ended only by the "no matches" error when you've removed them all. I was avoiding the error by using a :g and repeating a substitute on each line until there were no longer any matches with an explicit check. Your way is not as clear at first glance but almost certainly faster and more efficient. I've got to remember to take advantage of the "error-ends-X" behavior in mappings, macros, and loops more often.
Using \b instead of a literal ^H also removes the problem of yanking and executing the command. I didn't know about \b (since I almost never have text with a literal backspace character). Thanks for sharing!
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Oracle 11g SQL + PL/SQL + SQL*Plus + RDBMS syntax support
On Wed, Aug 29, 2012 at 12:59 PM, Szilard Barany <szitya@gmail.com> wrote:
> No it does not cover for code folding. I will consider that as I see benefit in it. I am not sure how difficult it is to implement yet, but it will take time. Therefore, the first version that I would like to see be released would only contain a (hopefully) full set of keywords/reserved words for proper syntax highlighting.
OK, folding PL/SQL code is not easy at all and I guess writing a
correct syntax file
can be a hairy problem, I actually tried few months ago and gave up (but I'm no
vim-syntax-files expert)
Probably writing one that does not take care of all edge cases would
be easier, but
I'm not sure that would fit in an official Vim distribution.
--
Alessio Bolognino
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
> No it does not cover for code folding. I will consider that as I see benefit in it. I am not sure how difficult it is to implement yet, but it will take time. Therefore, the first version that I would like to see be released would only contain a (hopefully) full set of keywords/reserved words for proper syntax highlighting.
OK, folding PL/SQL code is not easy at all and I guess writing a
correct syntax file
can be a hairy problem, I actually tried few months ago and gave up (but I'm no
vim-syntax-files expert)
Probably writing one that does not take care of all edge cases would
be easier, but
I'm not sure that would fit in an official Vim distribution.
--
Alessio Bolognino
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: vim window clears the terminal history
Hello John,
Thanks a lot for your analysis. Your observations are spot-on.
I took my t_is string and started echo'ing it on the terminal by
removing different escape codes and realised that "\E[2J" is
responsible for clearing the terminal.
I removed that and echoed the rest and this is what I received:
--(/tmp) -- my shell prompt
infocmp -C rxvt-unicode-256color
# Reconstructed via infocmp from file:
/usr/share/terminfo/r/rxvt-unicode-256color
# (untranslatable capabilities removed to fit entry within 1023 bytes)
rxvt-unicode-256color|rxvt-unicode terminal with 256 colors (X Window System):\
:am:bw:eo:hs:km:mi:ms:xn:xo:\
:co#80:it#8:li#24:lm#0:\
:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\
:K1=\EOw:K2=\EOu:K3=\EOy:K4=\EOq:K5=\EOs:LE=\E[%dD:\
:RI=\E[%dC:SF=\E[%dS:SR=\E[%dT:UP=\E[%dA:ae=\E(B:al=\E[L:\
:as=\E(0:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:\
:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:\
:dl=\E[M:do=^J:ds=\E]2;\007:ec=\E[%dX:ei=\E[4l:fs=^G:\
:ho=\E[H:i1=\E[!p:ic=\E[@:im=\E[4h:\
:is=\E[r\E[m\E[2J\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l:\
:k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:\
:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:\
:kI=\E[2~:kN=\E[6~:kP=\E[5~:kb=\177:kd=\E[B:ke=\E>:\
:kh=\E[7~:kl=\E[D:kr=\E[C:ks=\E=:ku=\E[A:le=^H:mb=\E[5m:\
:md=\E[1m:me=\E[0m:mr=\E[7m:nd=\E[C:rc=\E8:sc=\E7:\
:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ta=^I:\
:te=\E[r\E[?1049l:ti=\E[?1049h:ts=\E]2;:ue=\E[24m:\
:up=\E[A:us=\E[4m:vb=\E[?5h\E[?5l:ve=\E[?25h:vi=\E[?25l:\
:vs=\E[?25h:
--(/tmp)
echo "\E[r\E[m\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l"
r
" | 180x71 |
pts/3@master\E[r\E[m\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l
--(/tmp)
The above behaviour is what I want from vim:
I changed vimrc with these different settings and realise that they
are not affecting vim's behaviour with respect to the blank screen (I
can see some changes in how vim is acting when changing t_IS though)
"set t_is=\E[r\E[m\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l
set t_IS=\E[r\E[m\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l
" set t_is=
" set t_IS=
This made me think that changing the terminfo is a better idea.
I changed the terminfo as below, by removing the t_is in the terminfo files:
--(/tmp)
infocmp -C xterm
# Reconstructed via infocmp from file: /usr/share/terminfo/x/xterm
xterm|xterm terminal emulator (X Window System):\
:am:bs:km:mi:ms:xn:\
:co#80:it#8:li#24:\
:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\
:K2=\EOE:LE=\E[%dD:RI=\E[%dC:SF=\E[%dS:SR=\E[%dT:\
:UP=\E[%dA:ae=\E(B:al=\E[L:as=\E(0:bl=^G:bt=\E[Z:cd=\E[J:\
:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:\
:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=^J:ec=\E[%dX:\
:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E[!p\E[?3;4l\E[4l\E>:\
:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:\
:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:kI=\E[2~:kN=\E[6~:\
:kP=\E[5~:kb=^H:kd=\EOB:ke=\E[?1l\E>:kh=\EOH:kl=\EOD:\
:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:mb=\E[5m:md=\E[1m:\
:me=\E[0m:mm=\E[?1034h:mo=\E[?1034l:mr=\E[7m:nd=\E[C:\
:rc=\E8:\
:..sa=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m:\
:sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ta=^I:\
:te=\E[?1049l:ti=\E[?1049h:ue=\E[24m:up=\E[A:us=\E[4m:\
:vb=\E[?5h\E[?5l:ve=\E[?12l\E[?25h:vi=\E[?25l:\
:vs=\E[?12;25h:
--(/tmp)
infocmp -C rxvt-unicode-256color
# Reconstructed via infocmp from file: /home/j/.terminfo/r/rxvt-unicode-256color
rxvt-unicode-256color|rxvt-unicode terminal with 256 colors (X Window System):\
:am:bw:eo:hs:km:mi:ms:xn:xo:\
:co#80:it#8:li#24:lm#0:\
:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\
:K1=\EOw:K2=\EOu:K3=\EOy:K4=\EOq:K5=\EOs:LE=\E[%dD:\
:RI=\E[%dC:SF=\E[%dS:SR=\E[%dT:UP=\E[%dA:ae=\E(B:al=\E[L:\
:as=\E(0:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:\
:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:\
:dl=\E[M:do=^J:ds=\E]2;\007:ec=\E[%dX:ei=\E[4l:fs=^G:\
:ho=\E[H:i1=\E[!p:ic=\E[@:im=\E[4h:is=:k1=\E[11~:k2=\E[12~:\
:k3=\E[13~:k4=\E[14~:k5=\E[15~:k6=\E[17~:k7=\E[18~:\
:k8=\E[19~:k9=\E[20~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:\
:kb=\177:kd=\E[B:ke=\E>:kh=\E[7~:kl=\E[D:kr=\E[C:ks=\E=:\
:ku=\E[A:le=^H:mb=\E[5m:md=\E[1m:me=\E[0m:mr=\E[7m:nd=\E[C:\
:nw=^M^J:rc=\E8:sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:\
:st=\EH:ta=^I:te=\E[r\E[?1049l:ti=\E[?1049h:ts=\E]2;:\
:ue=\E[24m:up=\E[A:us=\E[4m:vb=\E[?5h\E[?5l:ve=\E[?25h:\
:vi=\E[?25l:vs=\E[?25h:
--(/tmp)
infocmp -C rxvt-unicode-256color | grep -i is
:ho=\E[H:i1=\E[!p:ic=\E[@:im=\E[4h:is=:k1=\E[11~:k2=\E[12~:\
--(/tmp)
infocmp -C xterm | grep -i is
:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E[!p\E[?3;4l\E[4l\E>:\
--(/tmp)
even with export TERM=xterm or rxvt-unicode-256color, I am still
getting the same behaviour.
It might be a lot simpler if I can tell vim to behave as vi does. But,
even if I do that, I probably will have issues with colors in files,
etc. Any thoughts on this, please?
I noticed this in my terminfo file: cl=\E[H\E[2J: and removed the
\E[2J from that and tried it. But, that did not change the behavioiur
much.
At this point, I guess, the only option is to read up on the terminfo
codes and see what else could be affecting it.
Can you please let me know if you can think of any better ideas?
Thanks
Joe
On Wed, Aug 29, 2012 at 2:58 AM, John Little <John.B.Little@gmail.com> wrote:
> See my post in vim_use. I reckon the initialization string is the culprit. If it is sent before ti, it clears the stuff you want kept, and if after, makes vim not use the alternate buffer.
>
> Regards, John Little
>
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Thanks a lot for your analysis. Your observations are spot-on.
I took my t_is string and started echo'ing it on the terminal by
removing different escape codes and realised that "\E[2J" is
responsible for clearing the terminal.
I removed that and echoed the rest and this is what I received:
--(/tmp) -- my shell prompt
infocmp -C rxvt-unicode-256color
# Reconstructed via infocmp from file:
/usr/share/terminfo/r/rxvt-unicode-256color
# (untranslatable capabilities removed to fit entry within 1023 bytes)
rxvt-unicode-256color|rxvt-unicode terminal with 256 colors (X Window System):\
:am:bw:eo:hs:km:mi:ms:xn:xo:\
:co#80:it#8:li#24:lm#0:\
:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\
:K1=\EOw:K2=\EOu:K3=\EOy:K4=\EOq:K5=\EOs:LE=\E[%dD:\
:RI=\E[%dC:SF=\E[%dS:SR=\E[%dT:UP=\E[%dA:ae=\E(B:al=\E[L:\
:as=\E(0:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:\
:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:\
:dl=\E[M:do=^J:ds=\E]2;\007:ec=\E[%dX:ei=\E[4l:fs=^G:\
:ho=\E[H:i1=\E[!p:ic=\E[@:im=\E[4h:\
:is=\E[r\E[m\E[2J\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l:\
:k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:\
:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:\
:kI=\E[2~:kN=\E[6~:kP=\E[5~:kb=\177:kd=\E[B:ke=\E>:\
:kh=\E[7~:kl=\E[D:kr=\E[C:ks=\E=:ku=\E[A:le=^H:mb=\E[5m:\
:md=\E[1m:me=\E[0m:mr=\E[7m:nd=\E[C:rc=\E8:sc=\E7:\
:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ta=^I:\
:te=\E[r\E[?1049l:ti=\E[?1049h:ts=\E]2;:ue=\E[24m:\
:up=\E[A:us=\E[4m:vb=\E[?5h\E[?5l:ve=\E[?25h:vi=\E[?25l:\
:vs=\E[?25h:
--(/tmp)
echo "\E[r\E[m\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l"
r
" | 180x71 |
pts/3@master\E[r\E[m\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l
--(/tmp)
The above behaviour is what I want from vim:
I changed vimrc with these different settings and realise that they
are not affecting vim's behaviour with respect to the blank screen (I
can see some changes in how vim is acting when changing t_IS though)
"set t_is=\E[r\E[m\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l
set t_IS=\E[r\E[m\E[?7;25h\E[?1;3;4;5;6;9;66;1000;1001;1049l\E[4l
" set t_is=
" set t_IS=
This made me think that changing the terminfo is a better idea.
I changed the terminfo as below, by removing the t_is in the terminfo files:
--(/tmp)
infocmp -C xterm
# Reconstructed via infocmp from file: /usr/share/terminfo/x/xterm
xterm|xterm terminal emulator (X Window System):\
:am:bs:km:mi:ms:xn:\
:co#80:it#8:li#24:\
:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\
:K2=\EOE:LE=\E[%dD:RI=\E[%dC:SF=\E[%dS:SR=\E[%dT:\
:UP=\E[%dA:ae=\E(B:al=\E[L:as=\E(0:bl=^G:bt=\E[Z:cd=\E[J:\
:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:\
:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=^J:ec=\E[%dX:\
:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E[!p\E[?3;4l\E[4l\E>:\
:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:\
:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:kI=\E[2~:kN=\E[6~:\
:kP=\E[5~:kb=^H:kd=\EOB:ke=\E[?1l\E>:kh=\EOH:kl=\EOD:\
:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:mb=\E[5m:md=\E[1m:\
:me=\E[0m:mm=\E[?1034h:mo=\E[?1034l:mr=\E[7m:nd=\E[C:\
:rc=\E8:\
:..sa=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m:\
:sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ta=^I:\
:te=\E[?1049l:ti=\E[?1049h:ue=\E[24m:up=\E[A:us=\E[4m:\
:vb=\E[?5h\E[?5l:ve=\E[?12l\E[?25h:vi=\E[?25l:\
:vs=\E[?12;25h:
--(/tmp)
infocmp -C rxvt-unicode-256color
# Reconstructed via infocmp from file: /home/j/.terminfo/r/rxvt-unicode-256color
rxvt-unicode-256color|rxvt-unicode terminal with 256 colors (X Window System):\
:am:bw:eo:hs:km:mi:ms:xn:xo:\
:co#80:it#8:li#24:lm#0:\
:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\
:K1=\EOw:K2=\EOu:K3=\EOy:K4=\EOq:K5=\EOs:LE=\E[%dD:\
:RI=\E[%dC:SF=\E[%dS:SR=\E[%dT:UP=\E[%dA:ae=\E(B:al=\E[L:\
:as=\E(0:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:\
:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:\
:dl=\E[M:do=^J:ds=\E]2;\007:ec=\E[%dX:ei=\E[4l:fs=^G:\
:ho=\E[H:i1=\E[!p:ic=\E[@:im=\E[4h:is=:k1=\E[11~:k2=\E[12~:\
:k3=\E[13~:k4=\E[14~:k5=\E[15~:k6=\E[17~:k7=\E[18~:\
:k8=\E[19~:k9=\E[20~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:\
:kb=\177:kd=\E[B:ke=\E>:kh=\E[7~:kl=\E[D:kr=\E[C:ks=\E=:\
:ku=\E[A:le=^H:mb=\E[5m:md=\E[1m:me=\E[0m:mr=\E[7m:nd=\E[C:\
:nw=^M^J:rc=\E8:sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:\
:st=\EH:ta=^I:te=\E[r\E[?1049l:ti=\E[?1049h:ts=\E]2;:\
:ue=\E[24m:up=\E[A:us=\E[4m:vb=\E[?5h\E[?5l:ve=\E[?25h:\
:vi=\E[?25l:vs=\E[?25h:
--(/tmp)
infocmp -C rxvt-unicode-256color | grep -i is
:ho=\E[H:i1=\E[!p:ic=\E[@:im=\E[4h:is=:k1=\E[11~:k2=\E[12~:\
--(/tmp)
infocmp -C xterm | grep -i is
:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E[!p\E[?3;4l\E[4l\E>:\
--(/tmp)
even with export TERM=xterm or rxvt-unicode-256color, I am still
getting the same behaviour.
It might be a lot simpler if I can tell vim to behave as vi does. But,
even if I do that, I probably will have issues with colors in files,
etc. Any thoughts on this, please?
I noticed this in my terminfo file: cl=\E[H\E[2J: and removed the
\E[2J from that and tried it. But, that did not change the behavioiur
much.
At this point, I guess, the only option is to read up on the terminfo
codes and see what else could be affecting it.
Can you please let me know if you can think of any better ideas?
Thanks
Joe
On Wed, Aug 29, 2012 at 2:58 AM, John Little <John.B.Little@gmail.com> wrote:
> See my post in vim_use. I reckon the initialization string is the culprit. If it is sent before ti, it clears the stuff you want kept, and if after, makes vim not use the alternate buffer.
>
> Regards, John Little
>
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Subscribe to:
Posts (Atom)