Re: h j k l -- keys
On Mon, Dec 19, 2011 at 07:40, Marty Fried ma...@leftcoast-usa.com wrote: One thing to keep in mind is that the ASCII codes were not really meant to be something that the user typed in, they were *control codes* for controlling printing and display. But some of them were used by users sometimes, and most users knew things like backspace, XON, XOFF, EOF, etc. But I think they were just chosen by what was available, with no regard for mnemonics, or anything. Ctrl-G was bell, Ctrl-M was carriage return, Ctrl-J was linefeed; none of these are related to anything. It does seem to be a happy coincidence that the the linefeed character just happened to be on the strongest finger. Not impossible, but rather convenient. -- Dotan Cohen http://gibberish.co.il http://what-is-what.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 vs. ebooks
On Sunday, December 18, 2011 2:40:10 PM UTC+2, MarcWeber wrote: Think about the *why* you're asking for Vim - and then write again. We may find other workarounds for you. because I'm a bit tired reading w/ 'less'. on a more serious note I may only say that since vim has incredible opportunities for manipulating text it seems only logical for me to reformat ebooks w/ vim for easier reading (i.e., make shorter lines, highlight bold text, quotes, etc, etc). and if already using vim for preparing text, I see absolutely no reason to go for another tool for reading (I personally have vim running all the time in screen, and definitely has more than one buffer open -- so why not to dedicate one for a book?). -- ds -- 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: wqall! and closing buffers without a filename
On Monday, 19 December, 2011 at 05:27:02 GMT, Chris Lott wrote: I know I can do :wqall to close all buffers and quit if all have filenames, but how can I close all buffers and quit and *discard* buffers without filenames? :qa! will quit everything regardless of anything, but beware you'll lose any unsaved work (if you don't have persistent undo enabled). -- . -- 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
modifying marks
hi, how to alter the path of a mark. old-mark: /root/one/two/var/file.c i have a requirement where var will be changing often, without resetting the marks every time, how can i simply change the value of var to what i need. are there any functions like setmark() getmark(). cheers -- 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: sh (bash) syntax for here-document strings: embedding other languages
Pe 12/18/2011 11:04 AM, Andy Spencer a scris:
[...]
Yikes, start with something even simpler than that until you get it
working and then build it up from there. I wouldn't even try to script
it yet. I have the following (and only the following) in my
~/.vim/after/sh.vim
unlet b:current_syntax
syn include @phpSyntax syntax/php.vim
syn region shPhp matchgroup=shRedir contains=@phpSyntax
\ start=+\z(.*\)\ze\n.*vim: ft=php+ end=+\z1+
And it highlights the following sh/php fragment correctly.
phpEOF
?php # vim: ft=php?
?php echo hi there; ?
EOF
Is it possible vim has a bug with regular expressions ?
From :help \@=
The part of the pattern after \@= and \@! are checked for a
match first, thus things like \1 don't work to reference \(\) inside
the preceding atom. It does work the other way around:
Oh, yes, indeed, you are correct.
Unfortunately I kind of need the match-within-previous-string feature, \@=
The sh syntax allows for different forms of the here-document delimiter,
and the syntax/sh.vim file distributed with vim provides for the following:
- delimiter may be prefixed with the '-' character, as a flag to
trim leading tabs from the here-document lines and the
following delimiter line
- delimiter may be quoted, with single or double quotes, to
prevent backslash-escapes, parameter expansion, command
substitution and arithmetic expansion in the here-document.
- delimiter my be preceded or followed by \ followed by a
newline
To express all these forms, the author wrote 13 different regular
expressions, all matching some possible form for introducing the
here-document delimiter on a command line.
If I want to include some language or languages in the here-document,
than I would need to repeat the 13 region definitions for each and every
language. And I would like to include quite a few languages in my syntax
file (sh, awk, sed, bc, vim, php, python, perl, ..) ...
For this reason I tried to define a *contained* syn region, within the
predefined shHereDoc group (that happens to extend onto the entire
containing shHereDoc), so that I do not have to write (n * 13) regions
and regular expressions ...
Even with a simple :syn region (which, by the way, was the first thing I
tried), like this:
:syntax list sh_php_heredoc
--- Syntax items ---
sh_php_heredoc xxx start=/-\z(\S\+\)\n/ end=/^\z1$/ contained
keepend excludenl contains=@PHP containedin=shHereDoc
I still do not get any match. I do not know why but I guess it is
because the search starts within the containing region (shHereDoc),
after the -delimiter line. So I guess I need to search before
(within-previous-string), which does find the region start ...
However the \z( ... \) notation in vim regular expressions for syntax
does not work even with regions, for which the start and end regular
expressions are different, and as the documentation says the end one is
not even required ...
Even with re search-backwards feature \@= that I used, I still think
the external reference strings in REs, \z(...) and \z1, should work:
:syntax list @PHP sh_php_heredoc
--- Syntax items ---
PHP
cluster=htmlError,htmlSpecialChar,htmlEndTag,htmlCssDefinition,htmlTag,htmlComment,htmlPreProc,htmlLink,javaScript,htmlBold,htmlUnderline,html
Italic,htmlH1,htmlH2,htmlH3,htmlH4,htmlH5,htmlH6,htmlTitle,cssStyle,htmlHead,phpRegion,phpRegionSc,phpSpecialFunction,phpClasses,phpInterfaces,phpAssignByRef
,phpRegionSync
sh_php_heredoc xxx start=/\%(-\z(\S\+\)\n\)\@=/ end=/^\z1$/
contained keepend excludenl contains=@PHP containedin=shHereDoc
Press ENTER or type command to continue
However the above does not find the end match even if the RE is quite
simple ...
I find this everything-everyore-must-be-a-simple-RE design (for vim
syntax highlighting) insufficient to describe the syntax of a language.
More high-level features like followed-by, containing and contained
regions should be present, but with the ability to add alternatives for
the following and previous regions, to search only in a region as one
would search in a file, to add names to any regions in order to search
or extract data from it later or in other places, or to be used in some
kind of group_exists('name') macro, and some other high-level
conditionals, using defines or flags declared when matching regions of
text like defining them from within the REs used for a match.
Thank you,
Timothy Madden
--
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 vs. ebooks
Hi, Am Sonntag, 18. Dezember 2011 10:15:56 UTC+1 schrieb ds: has anybody seen any good and / or interesting workaround for reading ebooks (HTML, EPUB, FB2, [RTF]) in vim? You can convert the file at the FileReadCmd event to text (or to html and then to text) -- you should set the buffer to readonly and maybe buftype=nowrite/nofile? You should be aware though that most markup will be lost during conversion which is why I personally don't consider this such a good idea. Regards, Tom -- 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: sh (bash) syntax for here-document strings: embedding other languages
Related, I've started work on a TODO manager implemented partially in vim, and part of it is syntax highlighting raoups for nested code. My work so far is at http://github.com/richoH/vim-todo -- 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: modifying marks
Am 19.12.2011 12:11, schrieb sinbad:
hi,
how to alter the path of a mark.
old-mark: /root/one/two/var/file.c
i have a requirement wherevar will be
changing often, without resetting the marks
every time, how can i simply change the value
ofvar to what i need. are there any functions
like setmark() getmark().
cheers
You are talking about uppercase marks, right?
There is
:h getpos()
:h setpos()
E.g.
:call setpos('A, [2, 543, 67, 0])
Set mark 'A in buffer 2 at line 543, column 67.
Get the buffer number for given filename:
:h bufnr()
If the file is not yet in buffer list:
:h :badd
--
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: wqall! and closing buffers without a filename
On 12/18/11 23:27, Chris Lott wrote: I know I can do :wqall to close all buffers and quit if all have filenames, but how can I close all buffers and quit and *discard* buffers without filenames? I think you'd have to write all that have names and then force-quit on the rest, something like :sil! wa | qa! :sil! wa! | qa! The second one will force writes even for read-only files, for new named-files that would overwrite an existing file, etc. Alternatively, you could jockey the 'buftype'=nofile and 'bufhidden'=delete settings for your non-named files so that they get ignored (mentioned at :help new-buftype) either via an autocmd or a manual :bufdo command. -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 vs. ebooks
On Sunday, December 18, 2011 2:40:10 PM UTC+2, MarcWeber wrote: Think about the *why* you're asking for Vim - and then write again. We may find other workarounds for you. on a more serious note I may only say that since vim has incredible opportunities for manipulating text it seems only logical for me to reformat ebooks w/ vim for easier reading (i.e., make shorter lines, highlight bold text, quotes, etc, etc). and if already using vim for preparing text, I see absolutely no reason to go for another tool for reading I use vim to edit epubs -- saw the tip here from the creator of Calibre: http://www.mobileread.com/forums/showthread.php?t=103114 Quote: I just discovered that vim can open and edit files inside a zip file automatically, which of course means it can do the same for epub. Add the following to your .vimrc: Code: au BufReadCmd *.epub call zip#Browse(expand(amatch)) Maybe this will be useful. -- 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: sh (bash) syntax for here-document strings: embedding other languages
On 2011-12-19 14:00, Timothy Madden wrote:
I find this everything-everyore-must-be-a-simple-RE design (for vim
syntax highlighting) insufficient to describe the syntax of a language.
More high-level features like followed-by, containing and contained
regions should be present, but with the ability to add alternatives for
the following and previous regions, to search only in a region as one
would search in a file, to add names to any regions in order to search
or extract data from it later or in other places, or to be used in some
kind of group_exists('name') macro, and some other high-level
conditionals, using defines or flags declared when matching regions of
text like defining them from within the REs used for a match.
For followed-by, containing, and contained, is that that just nextgroup
and contained/contains/containedin?
You can use nextgroup to do some of the stuff you want, but it's a bit of a
hack (the keepend part of the hdBody line is important):
unlet! b:current_syntax | syn include @awkSyntax syntax/awk.vim
unlet! b:current_syntax | syn include @phpSyntax syntax/php.vim
syn region hdBody matchgroup=shRedir contains=hdStart keepend
\ start=-\?[']\?\z(.*\)[']\? end=\z1
syn match hdStart \%(.*\n\)\@= contained nextgroup=@hdLang
syn cluster hdLang contains=hdAwk,hdPhp
syn region hdAwk start=\%(.*\n\)\{0,4}.*ft=awk end=\#$ contained
contains=@awksyntax
syn region hdPhp start=\%(.*\n\)\{0,4}.*ft=php end=\#$ contained
contains=@phpSyntax
From :help syntax, Lexical highlighting might be a better name, but
since everybody calls it syntax highlighting we'll stick with that.
Lexical highlighting kind of defines the scope to simple regexes ;)
There are also some advantages to keeping it in this scope, you might
not always want a match to fail just because it's not technically
valid.. syn-region is a good example of this, it's nice to have it
highlight a string as a string even if you haven't typed the end quote
yet. With a stricter parser you might get a syntax error and not have
it match at all.
That being said, I've wanted some higher-level features for the syntax
matching too, and even more so for helping with indent expressions and
omnicompleteion. I started writing a BNF like parser for vim a while
back, but didn't get very far :(
pgpovhf2lmwbe.pgp
Description: PGP signature
