Re: Hex viewer/editor with vim
Did anyone check how Cream(http://cream.sf.net/ ) does it? AFAIK its hex conversion is based on Vim's own(via xxd) but extended via Vim scripts. On Thu, Feb 10, 2011 at 5:36 AM, Ben Fritz fritzophre...@gmail.com wrote: On Feb 8, 4:25 pm, Peter de Ridder cavalie...@gmail.com wrote: Hi, Using vim do edit binary files isn't always that easy. With display+=uhex you can make unprintable characters show as hex, but the printable characters are still shown as normal characters. Using xxd so convert a file to hex gives a nice view of the file in both hex and printable characters. But editing is still a bit difficult even with hex editing helper scripts. e.g. insering or removing data isn't easy since all the xxd offsets number need to be renumbered. I noticed the other day that XXD has an option to do a raw dump or convert back from one, without using offsets. This should in theory allow easy insertion/deletion. I have toyed with the idea of tweaking my hex-edit autocmds to use just %!xxd to convert TO hex mode, but then strip off the addresses after conversion. Then to restore, additionally strip off the ASCII view and use the xxd option which only works with raw bytes. Just some random thoughts, I don't have any opinion on your patches as of yet. -- 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 -- Atilla Filiz -- 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
Re : tr() problem ?
Thanks James,
I'll use \u0440 as you suggested
D
De : James Vega james...@jamessan.com
À : vim_dev@googlegroups.com
Envoyé le : Mer 9 février 2011, 19h 10min 55s
Objet : Re: tr() problem ?
On Wed, Feb 9, 2011 at 12:04 PM, Dimitar DIMITROV mitk...@yahoo.fr wrote:
But this doesn't:
command! Translate call setline(line('.'), tr(getline('.'),
\'ABVGDEWZIJKLMNOPRSTUYFHXC$^}{!|Qabvgdewzijklmnoprstuyfhxc467][1\q',
\'АБВГДЕЖЗИЙКЛМНОПРСТУYФХXЦЧШЩЪЬЮЮЯабвгдежзийклмнопрстуyфхxцчшщъьююя'))
then :Translate on any line
The error is:
E475: Invalid argument:
ABVGDEWZIJKLMNOPRSTUYFHXC$^}{!|Qabvgdewzijklmnoprstuyfhxc467][1\q
This has something to do with how Vim is storing the U+0440 character
(which breaks down to \xd1\x80) in the to string. A minimal
reproduction can be done with this simplified version:
command! Translate echo tr(getline('.'), 'r', 'р')
and then use Translate with your cursor on the line defining the
command.
In fact, if you use the following erroneous version of the command, the
error string that Vim prints when you try to use :Translate will show
that the U+0440 character has been corrupted:
command! Translate echo tr(getline('.'), 'r', \'p')
I end up getting: E15: Invalid expression: \'рfeX')
Everything works fine if the command is defined using \u0440 instead
of the literal character.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
--
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_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
Re: Patch 7.3.117 (typo in configure message)
Tony Mechelynck wrote:
On 09/02/11 17:43, Bram Moolenaar wrote:
Patch 7.3.117
Problem:On some systems --as-needed does not work, because the tinfo
library is included indirectly from ncurses. (Charles Campbell)
Solution: In configure prefer using tinfo instead of ncurses.
Files: src/configure.in, src/auto/configure
*** ../vim-7.3.116/src/configure.in 2010-11-16 19:25:56.0 +0100
--- src/configure.in2011-02-09 17:28:16.0 +0100
***
*** 2618,2630
AC_MSG_RESULT([empty: automatic terminal library selection])
dnl On HP-UX 10.10 termcap or termlib should be used instead of
dnl curses, because curses is much slower.
! dnl Newer versions of ncurses are preferred over anything.
dnl Older versions of ncurses have bugs, get a new one!
dnl Digital Unix (OSF1) should use curses (Ronald Schild).
dnl On SCO Openserver should prefer termlib (Roger Cornelius).
case `uname -s 2/dev/null` in
! OSF1|SCO_SV)tlibs=ncurses curses termlib termcap;;
! *) tlibs=ncurses termlib termcap curses;;
esac
for libname in $tlibs; do
AC_CHECK_LIB(${libname}, tgetent,,)
--- 2618,2631
AC_MSG_RESULT([empty: automatic terminal library selection])
dnl On HP-UX 10.10 termcap or termlib should be used instead of
dnl curses, because curses is much slower.
! dnl Newer versions of ncurses are preferred over anything, except
! dnl when tinfo has been split off, it conains all we need.
^
should be: contains
Thanks for noticing.
--
hundred-and-one symptoms of being an internet addict:
228. You spend Saturday night making the counter on your home page
pass that 2000 mark.
/// Bram Moolenaar -- b...@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_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
[Patch] fix wrong drawin of cursorcolumn
Hi Bram, this oneliner fixes this issue from the todo-list , | When 'cursorcolumn' is set locally to a window, :new opens a window | with the same highlighting but 'cursorcolumn' is empty. (Tyru, 2010 Nov | 15) ` diff --git a/src/screen.c b/src/screen.c --- a/src/screen.c +++ b/src/screen.c @@ -2864,7 +2864,7 @@ /* Check for columns to display for 'colorcolumn'. */ color_cols = wp-w_p_cc_cols; -if (color_cols != NULL) +if (color_cols != NULL *wp-w_p_cc != NUL) draw_color_col = advance_color_col(VCOL_HLC, color_cols); #endif regards, Christian -- Melkt die Bäuerin die Kühe, hat der Bauer keine Mühe. -- 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
Re: tr() problem ?
On Wed, Feb 9, 2011 at 2:10 PM, James Vega james...@jamessan.com wrote:
On Wed, Feb 9, 2011 at 12:04 PM, Dimitar DIMITROV mitk...@yahoo.fr wrote:
But this doesn't:
command! Translate call setline(line('.'), tr(getline('.'),
\'ABVGDEWZIJKLMNOPRSTUYFHXC$^}{!|Qabvgdewzijklmnoprstuyfhxc467][1\q',
\'АБВГДЕЖЗИЙКЛМНОПРСТУYФХXЦЧШЩЪЬЮЮЯабвгдежзийклмнопрстуyфхxцчшщъьююя'))
then :Translate on any line
The error is:
E475: Invalid argument:
ABVGDEWZIJKLMNOPRSTUYFHXC$^}{!|Qabvgdewzijklmnoprstuyfhxc467][1\q
This has something to do with how Vim is storing the U+0440 character
(which breaks down to \xd1\x80) in the to string. A minimal
reproduction can be done with this simplified version:
command! Translate echo tr(getline('.'), 'r', 'р')
and then use Translate with your cursor on the line defining the
command.
In fact, if you use the following erroneous version of the command, the
error string that Vim prints when you try to use :Translate will show
that the U+0440 character has been corrupted:
command! Translate echo tr(getline('.'), 'r', \'p')
I end up getting: E15: Invalid expression: \'рfeX')
Everything works fine if the command is defined using \u0440 instead
of the literal character.
Another interesting data point is that the workaround of using \u0440
only works when building Vim without GUI support. Building with GUI
type of any support (I tried Athena, motif and Gtk2) causes the problem
to occur even when using \u0440 instead of р.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
--
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
Bug or feature? v:beval_winnr is zero-based
Bug or feature? Unlike all other window numbers (count for Ctrl-W w, return value from winnr() or tabpagewinnr(), etc.) which are 1-based (top window is 1), v:beval_winnr is zero-based (top window is 0), as can be ascertained with the following setting (in a Vim compiled with +balloon_eval, of course): :set beval bexpr='buf:'.v:beval_bufnr.'\ win:'.v:beval_winnr.'\ loc:'.v:beval_lnum.','.v:beval_col.'\ text:'.v:beval_text Then hovering the mouse over text being edited shows that win: is followed by a value one less than the current winnr(). AFAICT, this inconsistency is not documented (if it is, I couldn't find it). Also, with the same settings, one sees that v:beval_col is not a virtual column (screen column) but a byte offset from start-of-line. For instance, hard tabs are counted as one column each regardless of their actual displayed width. Since making v:beval_winnr one-based or v:beval_col virtual might break compatibility, I propose to leave the current behaviour unchanged, but to document it. For the record, I did this test with gvim 7.3.118 (Huge version with GTK2-GNOME GUI) running in GUI mode. AFAICT the ballon-eval feaure is not available in Console mode (no error, just no balloon). Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 21. Your dog has its own home page. -- 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
Re: Hex viewer/editor with vim
On Thu, Feb 10, 2011 at 4:35 AM, Tony Mechelynck antoine.mechely...@gmail.com wrote: IIUC, when 'encoding' is utf-8 and you are entering characters as hex, you would have to type E4B880, not 4E00, for the Chinese horizontal-bar number one (一 U+4E00, one character, three bytes), and F0A08480, not 20100 or 00020100, for the additional Chinese character Ā (U+20100, one character, four bytes)? Similarly for *any* character above U+007F when 'encoding' is set to utf-8? For instance, E9 when 'encoding' is latin1, but C3A9 when it is utf-8, for the lowercase e-acute, é, U+00E9, the most frequent accented letter in the French language? But see also :help i_CTRL-V_digit. Best regards, Tony. For hex insertion I'm thinking of a script. That would be easier as using i_CTRL-V_digit for every character. The script would only need to map [0-9a-zA-Z] to be able to capture the hex input and convert it to single characters. The script could probably solve the encoding problems. As for encoding itself, I think it still posses a problem for my current 'displaymode' patches. I looked at the documentation bit I didn't dig into it. I see there are quite a few encoding settings. For now I disable the encoding routines when displaying text and either 'hex' or 'dot', this was a fast hack and I wonder if it even works correct. I think it is better to disable encoding entirely when hex editing but I didn't look deep enough into the encoding settings. An alternative would be to allow encoding but document that there might be unexpected (but technically correct) output. The same as the tab character is still shown as a normal tab in 'hex' mode, 'list' needs to be set and 'listchars' shouldn't contain tab, for a tab to be displayed as hex. Suggestions on how encoding should be shown in 'hex' and 'dot' mode are welcome. Consider multi byte characters which can take up either 1 or 2 display cells. Regards, Peter -- 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
Re: Hex viewer/editor with vim
On Wed, Feb 9, 2011 at 11:00 AM, Xavier Wang weasley...@gmail.com wrote: thank you for you patch! I desired editing hex text in Vim in a long time. hex-columnview.patch can't compile in VC2008, you add preprocessing routine within a macro, and VC can not hand this. change all RET_WIN_BUF_CHARTABSIZE(curwin, curbuf, s, col #ifdef FEAT_HEX , sep #endif ) like macro to: # ifndef FEAT_HEX RET_WIN_BUF_CHARTABSIZE(curwin, curbuf, s, col) # else RET_WIN_BUF_CHARTABSIZE(curwin, curbuf, s, col, sep) # endif may resolve this problem. but when I set columnview, Vim behaves strange. it usually only show one or two line of text, and the nest of line are @, I don't know why it happens. and, maybe you can close the syntax highlights or add new highlights groups. and, how to show the original text after the hex text, so as in a normal hex editor? I didn't answer all your questions here before. The part about highlight groups I don't quite follow. I chose to keep the highlighting as is. It is possible to disable highlighting or chose another syntax to change the highlighting if you wish. To show both hex and normal side by side I suggest the following commands. set cpo-=n set hnu set cov=16,8,2 set list set wrap gg set scrollbind set dym=dot vsplit set dym=hex This should become either a :hexthis internal command or be part of a hex editing support vim script in the future. I looked into the 'columnview' @ problem. I fixed the patch so it should work with the new patch. I'm still wondering if I'm heading it the right direction with the columnview. I think I need to get more specific specifications to see if it can work this way or if I should take another approach. hex-columnview-fix1.patch: The patch should be applied in stead of the previous 'columnview' patch. The hex-hexnumber.patch needs to be applied. Suggestions on how columnview should work are welcome. Considering separations and line breaks based on bytes, column or virtual column, maybe even dependant if it is used for only line breaks or dependant on the 'diplaymode' setting, etc. Should 'columnview' line breaking only be active when 'wrap' is set of should it work independent so you can specify wrapping text on a fixed with which isn't the with of the window, like 'wrap' does now, going in that directions maybe take 'linebreak' into account. Also when 'columnview' is set to 20,8 should it place a separation on column 8 and 16 on every wrapped line part or should it place it at column 8 and 16 and on column 4(24-20) and 12(32-20) on the next wrapped line. Regards, Peter -- 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 hex-columnview-fix1.patch Description: Binary data
vim 7.3 configure fails to detect missing libiconv on SunOS 5.10
This occurs in src/auto/configure: When /lib/libiconv.so* is not present, the short program in configure which references iconv_open() compiles and links successfully, but if run it aborts due to the missing shared object: ld.so.1: conftest: fatal: libiconv.so.2: open failed: No such file or directory Since configure detects incorrectly that libiconv is available to be used, it defines HAVE_ICONV_H as 1 and adds -liconv to LIBS. This causes failures a little later on in the configuration process: checking for iconv_open()... yes; with -liconv checking for nl_langinfo(CODESET)... yes checking for strtod in -lm... yes checking for strtod() and other floating point functions... yes checking --disable-acl argument... no checking for acl_get_file in -lposix1e... no checking for acl_get_file in -lacl... no checking for POSIX ACL support... no checking for Solaris ACL support... yes checking for AIX ACL support... no checking --disable-gpm argument... no checking for gpm... no checking --disable-sysmouse argument... no checking for sysmouse... no checking for FD_CLOEXEC... yes checking for rename... yes checking for sysctl... not usable checking for sysinfo... not usable checking for sysinfo.mem_unit... no checking for sysconf... yes checking size of int... 0 checking size of long... 0 checking size of time_t... 0 checking size of off_t... configure: error: in `/home/jrw/vim73/src': configure: error: cannot compute sizeof (off_t) See `config.log' for more details. (exit status = 77) Note that size of int, long, time_t are detected as 0 due to this same problem. from config.log: configure:11509: checking size of int configure:11514: cc -o conftest -g -I/usr/local/include -L/usr/local/lib conftest.c -lm -ltermlib -lelf -lnsl -lsocket -liconv 5 conftest.c, line 192: warning: statement not reached configure:11514: $? = 0 configure:11514: ./conftest ld.so.1: conftest: fatal: libiconv.so.2: open failed: No such file or directory auto/configure: line 1716: 7786 Killed ./conftest$ac_exeext configure:11514: $? = 137 configure: program exited with status 137 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME | #define PACKAGE_TARNAME | #define PACKAGE_VERSION | #define PACKAGE_STRING | #define PACKAGE_BUGREPORT | #define PACKAGE_URL | #define UNIX 1 | #define STDC_HEADERS 1 | #define HAVE_SYS_WAIT_H 1 | #define FEAT_NORMAL 1 | #define USE_XSMP_INTERACT 1 | #define HAVE_LIBSOCKET 1 | #define HAVE_LIBNSL 1 | #define FEAT_NETBEANS_INTG 1 | #define HAVE_X11 1 | #define HAVE_GTK_MULTIHEAD 1 | #define HAVE_X11_SM_SMLIB_H 1 | #define HAVE_X11_XPM_H 1 | #define HAVE_X11_SUNKEYSYM_H 1 | #define FEAT_XIM 1 | #define HAVE_DATE_TIME 1 | #define HAVE_ATTRIBUTE_UNUSED 1 | #define HAVE_LIBELF 1 | #define HAVE_DIRENT_H 1 | #define HAVE_STDARG_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_SYS_SELECT_H 1 | #define HAVE_SYS_UTSNAME_H 1 | #define HAVE_FCNTL_H 1 | #define HAVE_SGTTY_H 1 | #define HAVE_SYS_IOCTL_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_TERMIO_H 1 | #define HAVE_ICONV_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_LANGINFO_H 1 | #define HAVE_MATH_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_STROPTS_H 1 | #define HAVE_ERRNO_H 1 | #define HAVE_SYS_RESOURCE_H 1 | #define HAVE_SYS_SYSTEMINFO_H 1 | #define HAVE_LOCALE_H 1 | #define HAVE_SYS_STREAM_H 1 | #define HAVE_TERMIOS_H 1 | #define HAVE_SYS_STATFS_H 1 | #define HAVE_POLL_H 1 | #define HAVE_SYS_POLL_H 1 | #define HAVE_PWD_H 1 | #define HAVE_UTIME_H 1 | #define HAVE_SYS_PARAM_H 1 | #define HAVE_LIBINTL_H 1 | #define HAVE_LIBGEN_H 1 | #define HAVE_SYS_ACL_H 1 | #define HAVE_SYS_SYSINFO_H 1 | #define HAVE_WCHAR_H 1 | #define HAVE_WCTYPE_H 1 | #define HAVE_SYS_PTEM_H 1 | #define HAVE_STRINGS_H 1 | #define TIME_WITH_SYS_TIME 1 | #define WORDS_BIGENDIAN 1 | #define HAVE_LIBTERMLIB 1 | #define TERMINFO 1 | #define TGETENT_ZERO_ERR 0 | #define OSPEED_EXTERN 1 | #define UP_BC_PC_EXTERN 1 | #define SYS_SELECT_WITH_SYS_TIME 1 | #define HAVE_SVR4_PTYS 1 | #define PTYRANGE0 pqr | #define PTYRANGE1 0123456789abcdef | #define RETSIGTYPE void | #define SIGRETURN return | #define HAVE_SIGCONTEXT 1 | #define HAVE_BCMP 1 | #define HAVE_FCHDIR 1 | #define HAVE_FCHOWN 1 | #define HAVE_FSYNC 1 | #define HAVE_GETCWD 1 | #define HAVE_GETPWNAM 1 | #define HAVE_GETPWUID 1 | #define HAVE_GETRLIMIT 1 | #define HAVE_GETTIMEOFDAY 1 | #define HAVE_GETWD 1 | #define HAVE_LSTAT 1 | #define HAVE_MEMCMP 1 | #define HAVE_MEMSET 1 | #define HAVE_OPENDIR 1 | #define HAVE_PUTENV 1 | #define HAVE_QSORT 1 | #define HAVE_READLINK 1 | #define HAVE_SELECT 1 | #define HAVE_SETENV 1 | #define HAVE_SETPGID 1 | #define HAVE_SETSID 1 | #define HAVE_SIGALTSTACK 1 | #define HAVE_SIGSTACK 1 | #define HAVE_SIGSET 1 | #define HAVE_SIGSETJMP 1 | #define HAVE_SIGACTION 1 | #define HAVE_STRCASECMP 1 | #define HAVE_STRERROR 1 | #define HAVE_STRFTIME 1 | #define HAVE_STRNCASECMP 1 | #define HAVE_STRPBRK 1 |
Re: vim 7.3 configure fails to detect missing libiconv on SunOS 5.10
On Thu, Feb 10, 2011 at 05:27:10PM -0600, john.wier...@thomsonreuters.com wrote:
This occurs in src/auto/configure: When /lib/libiconv.so* is not
present, the short program in configure which references iconv_open()
compiles and links successfully, but if run it aborts due to the missing
shared object:
ld.so.1: conftest: fatal: libiconv.so.2: open failed: No such file or
directory
[snip]
This kind of bug is easily reproducible by copying a no-op program into
conftest.c:
int main () { return 0; }
and compiling with:
$ cc -o conftest -g -I/usr/local/include -L/usr/local/lib conftest.c
-lm -ltermlib -lelf -lnsl -lsocket -liconv
conftest.c, line 192: warning: statement not reached
This sounds like a bug with the linker for not erroring out when it
can't link against the libraries it has been told to link with. I tried
that test locally (Linux system, so gcc) and the compile/link failed.
$ ./conftest
ld.so.1: conftest: fatal: libiconv.so.2: open failed: No such file or
directory
Killed
$ echo $?
137
It seems to me that the correct solution is to *not* include -liconv
unless libiconv.so is actually present (and working). I'm not sure how
to achieve that with autoconf-style programs. The function being used
in this case is ac_fn_c_try_link() which has the following comment:
One could change configure to try and run the program, but that's
generally to be avoided since it inhibits cross-compiling.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@jamessan.com
signature.asc
Description: Digital signature
Re: vim 7.3 configure fails to detect missing libiconv on SunOS 5.10
$ cc -o conftest -g -I/usr/local/include -L/usr/local/lib conftest.c -lm -ltermlib -lelf -lnsl -lsocket -liconv conftest.c, line 192: warning: statement not reached This sounds like a bug with the linker for not erroring out when it can't link against the libraries it has been told to link with. I tried that test locally (Linux system, so gcc) and the compile/link failed. Just on the offchance...is the problem that /usr/local/lib is given there with an -L option, so found while compiling/linking, but isn't in your LIBPATH, so isn't being searched by ld at runtime? It's a bit of a long shot, as I would expect a lot more to be broken if there are a bunch of libs in /usr/local/lib not being found, but it's worth checking. Or is there a libiconv.so somewhere else on your system being found at compile/link time, but not at runtime? Maybe that's more likely. Your error message included a full filename (not just 'iconv'), which suggests the linker found a file by that name at some stage. Where did it find it, and why can't it find it at runtime? It seems to me that the correct solution is to *not* include -liconv unless libiconv.so is actually present (and working). I'm not sure how to achieve that with autoconf-style programs. The function being used in this case is ac_fn_c_try_link() which has the following comment: One could change configure to try and run the program, but that's generally to be avoided since it inhibits cross-compiling. Shouldn't the configure test just test for iconv headers and not include the library if there are no headers? Whether cross compiling or not, your development environment should be such that headers for installed (on the target system) libraries are available, and headers for non-installed libraries are not. If you have a situation where libiconv is not installed, but you have headers floating around, you should trash the headers (or install the library!). Ben. -- 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
