i want to get the offset of
the current cursor position
the current selection range
in vim, beginning from the start of the file. I do this in python, so hints how to do it with vim's python scripting would be very helpful.
I have used vim.current.. before for doing scripting, but it uses lines and columns rather than a general offset.
Would i have to calculate the amount of all preceding line lengths + the current row, or is there a simpler method ?
If your vim is compiled with the +byte_offset option, then in a Python script after the usual import vim, you can use, e.g.:
vim.eval('line2byte(line("."))+col(".")')
to get the byte offset from start of file of the cursor position, and similarly for other marks. More generally, if you have a line/column pair this (assuming +byte_offset is how your vim was compiled with) is the way to get a byte offset (there's also a byte2line function to go the other way).
While the vim module does make a lot of functionality available directly to Python scripts in vim, I've found that vim.eval and vim.command are often the handiest (and sometimes the only;-) way to get in just as deep as needed;-). Oh, and I always try to have a vim compiled with +justabouteverything whenever I can;-).
You may also want to look at the statusline setting. This will add the bye offset to the statusline:
set statusline+=%o
See :h statusline
Just be careful because the default statusline is blank, and by appending the %o to it, you loose all the defaults.
Related
I want to compile and run a Python script using Gvim.
I have configured this in my _vimrc:
map <F5>:!D:\Python27\python.exe%
But when I complete the Python code and then enter :F5enter, I receive the error:
E448 Extra tail characters
How can I solve this?
Your first problem is that you do not normally compile python - you just run it.
Second I suspect that you need a space before the % in your configuration assuming that it gets replaced by the filename.
You're missing spaces, in two important areas:
First, there must be whitespace separating the {lhs} (<F5> in your case) from the {rhs} (to what the mapping is expanded.
Second, the % that Vim will expand to the filename must be separated from the Python executable path, or else you'll end up with something like python.exeFoo.py, which the operating system doesn't understand.
Additionally:
You should select the proper modes for your mapping; these usually aren't invoked by :F5Enter (for which you would need :cmap, and omit the :), but rather by just pressing F5 from normal mode (:nmap).
You should use :noremap; it makes the mapping immune to remapping and recursion.
:nnoremap <F5> :!D:\Python27\python.exe %<CR>
Whenever I append a : character in Vim in Python mode, it either:
indents the line
dedents the line
does nothing
What is it even trying to do, and how do I get rid of this behavior?
Certain keys, when pressed, will trigger Vim's indent feature, which will attempt to set the correct amount of indentation on the current line. (You can manually trigger this by typing == in normal mode.)
You can change which keys trigger this behavior, but first you need to know what indenting mode is being used.
First, execute :set indentexpr?. If it is nonempty (I would expect this for Python), then indentexpr mode is being used. In this case, executing :set indentkeys? gives you the list of trigger keys. To remove the colon, execute :setlocal indentkeys-=:.
If indentexpr is empty, then you are probably using cindent mode, and :set cindent? will tell you that cindent is set. In this case, do the same as before, but using cinkeys instead of indentkeys. (Note that indentexpr mode takes precedence over cindent mode.)
Nathan Grigg's answer set me on the right track. I had to make a few changes for my setup.
I had to use :setlocal indentkeys-=<:>, because in my case :set indentkeys? showed indentkeys=0{,0},!^F,o,O,e,<:>,=elif,=except.
Also, putting :setlocal indentkeys-=<:> in .vim/after/ftplugin/python.vim did not work to make the change permanent. I found that there is a built-in vim python indent file that runs AFTER this after-ftplugin file.
To diagnose, open a Python file for editing, and run :scriptnames. That will show you a list of all the vim scripts that have run, in order of precedence. The scripts at the bottom of that list have been applied most recently, and take precedence. See this question on SuperUser for more info.
When I did that, it showed me a built-in vim file at /my-install-path/vim/7.4.1830/share/vim/vim74/indent/python.vim. Sure enough, that was setting <:> as part of the indent keys.
To fix it, I set an autocommand in .vimrc, and that really gets the last word.
autocmd FileType python setlocal indentkeys-=<:>
Update
I had to add :setlocal indentkeys-=: after all. Here's what I have in my .vimrc now.
autocmd FileType python setlocal indentkeys-=<:>
autocmd FileType python setlocal indentkeys-=:
It is trying to be helpful. If you want to turn off all the auto-indenting for the current file,
:setlocal noautoindent
:setlocal nocindent
:setlocal nosmartindent
:setlocal indentexpr=
Or, you can add set in your vimrc file. You can do these per file type too. See here
TL;DR I disabled autoindentation by typing:
:set indentexpr=
then hitting the ENTER key.
It's a quick fix without needing to understand indentkeys ..
Thanks to Christian Long for the docs to indentkeys, where I noticed (my emphasis):
A list of keys that, when typed in Insert mode, cause reindenting of
the current line. Only happens if 'indentexpr' isn't empty.
Tip - you might want to save a copy of the existing value of indentexpr before you clear it out. To see that (and any other values that are set) just type:
:set
HTH
Some terminals will send ^? as backspace, some other terminals will send ^H.
Most of the terminals can be configured to change their behavior.
I do not want to deal with all the possible combinations but I would like to accept both ^? and ^H as a backspace from python.
doing this
os.system("stty erase '^?'")
I will accept the first option and with
os.system("stty erase '^H'")
I will accept the second one but the first will be no longer available.
I would like to use
raw_input("userinput>>")
to grab the input.
The only way I was able to figure out is implementing my own shell which works not on "raw based input" but on "char based input".
Any better (and quicker) idea?
The built-in function raw_input() (or input() in Python 3) will automatically use the readline library after importing it. This gives you a nice and full-feautured line editor, and it is probably your best bet on platforms where it is available, as long as you don't mind Readline having a contagious licence (GPL).
I don't know your question exactly. IMO, you need a method to read some line-based text(including some special character) from console to program.
No matter what method you use, if read this character have special mean in different console, you should confront a console(not only system-specific, but also console-specific) question, all text in console will be store in buffer first, and then show in screen, finally processed and send in to your program. Another way to surround this problem is to use a raw line-obtaining console environment.
You can add a special method(a decorator) to decorate the raw_input() or somewhat input method to process special word.
After solved that question
using this snippet can deal with input,:
def pre():
textline=raw_input()
# ^? should replace to the specific value.
textline.replace("^?","^H")
return textline
To be faster, maybe invoke some system function depend on OS is an idea. But in fact, IO in python is faster enough for common jobs.
To fix ^? on erase do stty erase ^H
Am I correct in thinking that that Python doesn't have a direct equivalent for Perl's __END__?
print "Perl...\n";
__END__
End of code. I can put anything I want here.
One thought that occurred to me was to use a triple-quoted string. Is there a better way to achieve this in Python?
print "Python..."
"""
End of code. I can put anything I want here.
"""
The __END__ block in perl dates from a time when programmers had to work with data from the outside world and liked to keep examples of it in the program itself.
Hard to imagine I know.
It was useful for example if you had a moving target like a hardware log file with mutating messages due to firmware updates where you wanted to compare old and new versions of the line or keep notes not strictly related to the programs operations ("Code seems slow on day x of month every month") or as mentioned above a reference set of data to run the program against. Telcos are an example of an industry where this was a frequent requirement.
Lastly Python's cult like restrictiveness seems to have a real and tiresome effect on the mindset of its advocates, if your only response to a question is "Why would you want to that when you could do X?" when X is not as useful please keep quiet++.
The triple-quote form you suggested will still create a python string, whereas Perl's parser simply ignores anything after __END__. You can't write:
"""
I can put anything in here...
Anything!
"""
import os
os.system("rm -rf /")
Comments are more suitable in my opinion.
#__END__
#Whatever I write here will be ignored
#Woohoo !
What you're asking for does not exist.
Proof: http://www.mail-archive.com/python-list#python.org/msg156396.html
A simple solution is to escape any " as \" and do a normal multi line string -- see official docs: http://docs.python.org/tutorial/introduction.html#strings
( Also, atexit doesn't work: http://www.mail-archive.com/python-list#python.org/msg156364.html )
Hm, what about sys.exit(0) ? (assuming you do import sys above it, of course)
As to why it would useful, sometimes I sit down to do a substantial rewrite of something and want to mark my "good up to this point" place.
By using sys.exit(0) in a temporary manner, I know nothing below that point will get executed, therefore if there's a problem (e.g., server error) I know it had to be above that point.
I like it slightly better than commenting out the rest of the file, just because there are more chances to make a mistake and uncomment something (stray key press at beginning of line), and also because it seems better to insert 1 line (which will later be removed), than to modify X-many lines which will then have to be un-modified later.
But yeah, this is splitting hairs; commenting works great too... assuming your editor supports easily commenting out a region, of course; if not, sys.exit(0) all the way!
I use __END__ all the time for multiples of the reasons given. I've been doing it for so long now that I put it (usually preceded by an exit('0');), along with BEGIN {} / END{} routines, in by force-of-habit. It is a shame that Python doesn't have an equivalent, but I just comment-out the lines at the bottom: extraneous, but that's about what you get with one way to rule them all languages.
Python does not have a direct equivalent to this.
Why do you want it? It doesn't sound like a really great thing to have when there are more consistent ways like putting the text at the end as comments (that's how we include arbitrary text in Python source files. Triple quoted strings are for making multi-line strings, not for non-code-related text.)
Your editor should be able to make using many lines of comments easy for you.
I am looking for any way to have Emacs format a Python buffer by hitting a few keys. By format, I mean:
Replace tabs with 4 spaces
Wrap all long lines correctly at 79 chars. This includes wrapping & concatenating long strings, wrapping long comments, wrapping lists, function headers, etc.
Unrelated, but when I hit enter, it'd be nice if the cursor was tabbed in automatically.
In general I'd like to just format everything according to PEP 8.
I've looked for a pretty printer / code beautifier / code formatter for Python to run the buffer through, but can't find an open source one.
My .emacs is here.
For those who are going to answer "You don't need a formatter for Python, it's beautiful by the nature of the language," I say to you that this is not correct. In real software systems, comments should be auto-wrapped for you, strings are going to be longer than 79 characters, tab levels run 3+ deep. Please just help me solve my issue directly without some philosophical discussion about the merits of formatting Python source.
To change tabs into spaces and fill comments at the same time, you can use this command:
(defun my-format-python-text ()
"untabify and wrap python comments"
(interactive)
(untabify (point-min) (point-max))
(goto-char (point-min))
(while (re-search-forward comment-start nil t)
(call-interactively 'fill-paragraph)
(forward-line 1)))
Which you can bind to the key of your choice, presumably like so:
(eval-after-load "python"
'(progn
(define-key python-mode-map (kbd "RET") 'newline-and-indent)
(define-key python-mode-map (kbd "<f4>") 'my-format-python-text)))
Note the setting of the RET key to automatically indent.
If you wanted to all tabs with spaces with just built-in commands, this is a possible sequence:
C-x h ;; mark-whole-buffer
M-x untabify ;; tabs->spaces
To get the fill column and tab width to be what you want, add to your .emacs:
(setq fill-column 79)
(setq-default tab-width 4)
Arguably, the tab-width should be set to 8, depending on how other folks have indented their code in your environment (8 being a default that some other editors have). If that's the case, you could just set it to 4 in the 'python-mode-hook. It kind of depends on your environment.
About your point 3:
Unrelated, but when I hit enter, it'd
be nice if the cursor was tabbed in
automatically.
My emacs Python mode does this by default, apparently. It's simply called python-mode...
Using Spacemacs' Python layer with default bindings:
The sequence , = will run yapfify-buffer to impose PEP8 formatting on the entire buffer.
You can set
(setq-default dotspacemacs-configuration-layers '(
(python :variables python-enable-yapf-format-on-save t)))
to enable automating reformatting on save.
The best way to avoid tab characters in your file is to not insert them at all. The following statement will always insert the correct number of spaces, rather than inserting tab characters
;; Turn off tab insertion in favor of space insertion
(setq-default indent-tabs-mode nil)
I see you have this in your .emacs file already
The autopep8 and the emacs wrapper for it should fulfill your desire.. https://github.com/paetzke/py-autopep8.el