[Suggestion]: Use different colors to make :dig output more readable
I often use the :digraph command to find foreign language characters. But looking for a certain character sometines is like finding a needle in the haystack. Would it be possible to color-code the three colums of :dig's output? Axel -- 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: [Suggestion]: Use different colors to make :dig output more readable
Hi Axel! On Do, 26 Aug 2010, Axel wrote: I often use the :digraph command to find foreign language characters. But looking for a certain character sometines is like finding a needle in the haystack. Would it be possible to color-code the three colums of :dig's output? I have written a plugin, unicode.vim (http://www.vim.org/scripts/script.php?script_id=2822) that ought to make that easier by providing a completion function for digraphs and Unicode Glyphs. regards, Christian -- 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: [Suggestion]: Use different colors to make :dig output more readable
Axel wrote: I often use the :digraph command to find foreign language characters. But looking for a certain character sometines is like finding a needle in the haystack. Would it be possible to color-code the three colums of :dig's output? Finding a character is hard. I suppose some clever highlighting would help. I wondered about this and have come up with a script to show the :dig output in a scratch buffer. I got lazy and have not implemented a proper syntax highlighting scheme, but instead took the opportunity to experiment with the new 'colorcolumn' feature of Vim 7.3. Put the following in a file, for example, dig.vim. In Vim, enter this command to source the file: :so dig.vim Create a scratch buffer with :dig output, highlighted. function! s:Dig() set nomore redir = output silent dig redir END set more new setlocal buftype=nofile bufhidden=hide noswapfile setlocal colorcolumn=4,16,28,40,52,64,76 put =output g/^$/d endfunction command! Dig call s:Dig() When you want to see the :dig output, enter this command: :Dig A command like this can set the colours: :hi ColorColumn guifg=snow guibg=seagreen The column highlighting goes a little weird with some of the characters, but it seems reasonably ok. John -- 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: [Suggestion]: Use different colors to make :dig output more readable
I have written a plugin, unicode.vim (http://www.vim.org/scripts/script.php?script_id=2822) that ought to make that easier by providing a completion function for digraphs and Unicode Glyphs. Hi Christian. This sounds interesting but I still have not found how to work with your script. It seems, for me, that it takes last two characters before cursor and shows all lines from the list of unicode glyphs which contain this 2-char substring. With this, I don't see how to get 'a' with acute, cyrilic 'b' etc. Is there a trick I missed? Milan -- 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: Suggest ':TOhtml' to use 'fileencoding' rather than 'encoding' as default html charset
On Aug 25, 11:11 pm, JiaYanwei jia...@126.com wrote: I think this will be more reasonable than before. If the encoding of edited text file differ form the system/vim encoding, it's inconvenient to set default HTML charset to be 'encoding'. Thus, after ':TOhtml', we should modify the generated HTML file to make the file encoding the same as HTML charset. e.g. If the system/vim encoding is 'UTF-8', but a text file encoding is 'latin-1'. If the default HTML charset is 'encoding', after ':TOhtml', we should change the HTML charset to 'iso-8859-1', or save the generated HTML file by ':w ++enc=utf-8'. But if the default HTML charset is 'fileencoding', we should do nothing after ':TOhtml'. Thanks, I'll take a look. I don't yet have a good handle on 'encoding', 'fileencoding', and any other related options. It looks like I'm going to need to. From my understanding, 'fileencoding' is the encoding Vim is supposed to use to read/write the file. So, it does make sense that we should use this instead of just 'encoding' for the charset of the generated html. Does anyone know why TOhtml has used 'encoding' instead? I have not touched the charset detection code yet, other than to move it from the 2html.vim file into the autoload/tohtml.vim file. You say you need to do nothing to the TOhtml output if we set the charset to the file encoding. But, don't we also need to ensure that the file encoding of the new html file is the same as the file encoding of the source file? The file encoding could be different from file to file, whereas Vim's encoding is always the same. I can picture this causing problems, if the charset says one thing, but the file encoding is different. By the way, until this is fixed...you can use the g:html_use_encoding option to override the normal detection mechanisms, rather than manually editing the generated HTML file. -- 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: Suggest ':TOhtml' to use 'fileencoding' rather than 'encoding' as default html charset
On Aug 26, 9:40 am, Ben Fritz fritzophre...@gmail.com wrote: From my understanding, 'fileencoding' is the encoding Vim is supposed to use to read/write the file. So, it does make sense that we should use this instead of just 'encoding' for the charset of the generated html. Does anyone know why TOhtml has used 'encoding' instead? One problem with the supplied patch, is that Vim will use 'encoding' for a file's encoding, if 'fileencoding' is empty. In my setup, it looks like 'fileencoding' is nearly always empty. So, the script will need to fall back to 'encoding' if 'fileencoding' is empty. Probably it should also re-detect the charset using 'encoding' when 'fileencoding' is not blank but does not resolve to a valid charset. Any thoughts? Like I said, I've never needed to mess with 'encoding' or 'fileencoding' in my daily use of Vim. -- 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: : Use different colors to make :dig output more readable
Thanks for the answers so far! However, I'd like to see a functionality that can be used out of the box. This is due to the fact that I - quite often - just copy over gvim.exe to a newly installed box and work there for a while. I think it should be possible to have some small patch doing this. Btw. Though being a programmer, I'm not familiar with gvim's code structure... I just love to use it. Axel -- 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
[Possible bug] Vim Python interface - Unable to access contents of buffers which are not loaded in a window
Steps to reproduce: - Open any three 3 buffers. - :python import vim - :python for b in vim.buffers: print b.name+' '+b[0] Expected output: [Filename of buffer A] - [first line of buffer A] [Filename of buffer B] - [first line of buffer B] [Filename of buffer C] - [first line of buffer C] My output: The buffer names/file names are printed correctly, but the first line of the buffer will only be printed if the buffer is visible in a window. e.g. If I'm viewing B when I issue the command, the first line for A and C will be blank, but the first line of buffer B will be displayed. If I split windows and view B and C at once, A will not display the first line of the buffer, but B and C will. Is there some reason that I can only access the lines of buffers which are visible in a window? I tested this on Windows 7 with Vim 7.3 and XP with 7.2 (Python 2.6.5). Please let me know if I need to provide any information. Thanks! -- 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
A basic omni completion function form for simple lists?
Dear Vim-Dev, I wrote my first omni completion function today and I quickly noticed that the basic completion function of 20 lines has about 16 static lines that are usually reused in every basic completion function. In the most basic function, where provided matchings are shown in the list as well, only the source of matching candidates vary. That would mean that people copy 20-line function form and then edit minimal amount of lines in there. Vimscript doesn't support currying so I wonder if there ought to be a basic omni completion widget that would take a list of possible completions as argument, and handle the rest? The user only has to provide a list of candidates. The reasoning is that it would encourage users to write small and productive completion scripts to small one-file projects. The major shells support that kind of a bare completion system and it works okay for the simple tasks. --Mikael -- 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: [Possible bug] Vim Python interface - Unable to access contents of buffers which are not loaded in a window
On Thu, 26 Aug 2010, perrytrinier wrote: Is there some reason that I can only access the lines of buffers which are visible in a window? It may be that you can only access the lines in a buffer when the buffer is actually loaded, and by default it is not unless it's displayed in a window. What happens if you do :set hidden? (Note that you may still have to manually cause Vim to actually load the buffers to access their contents.) - Christian -- Christian J. Robinson hept...@gmail.com -- http://christianrobinson.name/ -- 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] Re: 7.3 unable to load ruby 1.9.2?
bump... any feedback from a core committer as to whether this patch is acceptable to be merged into default? -- 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: Vim Python interface - Unable to access contents of buffers which are not loaded in a window
Thanks for your reply, Christian. I tried :set hidden, but it behaved the same way. If it's only possible to access loaded buffers, there is no mention of that in the docs at http://vimdoc.sourceforge.net/htmldoc/if_pyth.html#python-vim . On Aug 26, 4:29 pm, Christian J. Robinson hept...@gmail.com wrote: On Thu, 26 Aug 2010, perrytrinier wrote: Is there some reason that I can only access the lines of buffers which are visible in a window? It may be that you can only access the lines in a buffer when the buffer is actually loaded, and by default it is not unless it's displayed in a window. What happens if you do :set hidden? (Note that you may still have to manually cause Vim to actually load the buffers to access their contents.) - Christian -- Christian J. Robinson hept...@gmail.com --http://christianrobinson.name/ -- 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: Vim Python interface - Unable to access contents of buffers which are not loaded in a window
On Thu, 26 Aug 2010, perrytrinier wrote:
Thanks for your reply, Christian. I tried :set hidden, but it
behaved the same way.
Did you make sure to explicitly load each buffer before running your
example code, but after you had turned 'hidden' on?
Using the Perl interface, I see the same behavior you do, until I do
:set hidden /and then/ manually cycle all of my buffers into a
window. My code:
:perl foreach my $b (VIM::Buffers()) {VIM::Msg($b-Name() . ' ' . $b-Get(1))}
Your sample code also works fine for me, after I've made sure Vim has
actually loaded the buffers, even if only one is currently displayed.
If it's only possible to access loaded buffers, there is no mention
of that in the docs at
http://vimdoc.sourceforge.net/htmldoc/if_pyth.html#python-vim
I do agree this is a somewhat obscure bit of knowledge. The if_perl
documentation doesn't mention it either.
About the only place I personally know of that gives the right hint is
:help windows-intro where it explains what an inactive buffer is.
- Christian
--
A bore is a man who deprives you of solitude without providing you with
company. -- Gian Vincenzo Gravina
Christian J. Robinson hept...@gmail.com http://christianrobinson.name/
--
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: Suggest ':TOhtml' to use 'fileencoding' rather than 'encoding' as default html charset
Oh, sorry, I forgeted that 'fileencoding' may be empty. This should be handled. I encountered the opposite that 'fileencoding' is often different from 'encoding' while editing existing files. Ben Fritz wrote: On Aug 26, 9:40 am, Ben Fritz fritzophre...@gmail.com wrote: From my understanding, 'fileencoding' is the encoding Vim is supposed to use to read/write the file. So, it does make sense that we should use this instead of just 'encoding' for the charset of the generated html. Does anyone know why TOhtml has used 'encoding' instead? One problem with the supplied patch, is that Vim will use 'encoding' for a file's encoding, if 'fileencoding' is empty. In my setup, it looks like 'fileencoding' is nearly always empty. So, the script will need to fall back to 'encoding' if 'fileencoding' is empty. Probably it should also re-detect the charset using 'encoding' when 'fileencoding' is not blank but does not resolve to a valid charset. Any thoughts? Like I said, I've never needed to mess with 'encoding' or 'fileencoding' in my daily use of Vim. -- 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
