autopep8 exclude files by extensions - autopep8

I try to use command autopep8 the such way
autopep8 --in-place --exclude='*.js,*.jade,*.styl'
autopep8 --in-place --exclude='*.styl'
autopep8 --in-place --exclude=*.js,*.jade,*.styl
autopep8 --in-place --exclude=*.styl
all these methods do not work for me, the ignore does not apply. Where am I wrong? How can I ignore files by mask when formatting?
autopep8 version is 1.2.1

This style to avoid specific files works for me (using either single or double quotes):
autopep8 --diff --recursive --exclude="*.styl" .
This also works:
autopep8 --diff --exclude="*.styl" *.py
However this does not exclude .styl files:
autopep8 --diff --exclude="*.styl" *
In my opinion, it appears you've identified a bug in autopep8.
However, perhaps it's not a bug, but rather an opinionated decision that star inclusion should take precedence over star exclusion.
In other words, is running this command intended to process (a) all files, or (b) no files?
autopep8 --diff --exclude="*" *
Update: I've opened an issue on their repo for this.
https://github.com/hhatto/autopep8/issues/246

Related

How to change the EOL for all files from CRLF to LF

In Visual Studio Code, I have changed the default EOL (end-of-line token) from CRLF to LF, but this only applies to new files.
I would like to know how to change the EOL for all files at once as I have more than a hundred files and it will be hard to do it manually.
Run these. It works for me. Customize it with your requirements
git config core.autocrlf false
git rm --cached -r .
git reset --hard
To solve the problem in my project I used a Visual Studio Code extension called "Change All End Of Line Sequence", follow the process of the extension and then save all your files.
And that's it, hope it helps somebody still looking for a quick fix.
If you have a Node.js development environment and prettier installed, one way of replacing all CRLF for LF is by running prettier --end-of-line lf --write in the command line.
Another way is to set the endOfLine option to lf in the .prettierrc configuration file and place a script in your package.json like so:
...
"scripts": {
...
"format": "prettier --write"
...
}
...
Then, you just need to execute npm run format in your terminal and all files targeted by prettier in your project will be automatically changed and saved.

How do I get eshell working correctly in emacs?

For some reason, when I type in commands I'm used to on linux, it works perfectly, as it does in bash... But in eshell, it doesn't work.
I've narrowed the problem to a trivial and small sample, as follows:
$ du
c:/Program: command not found
$ which bash
c:/Program Files (x86)/Git/bin/bash.exe
How do I get this working? (du is whatever it is by default... It's implemented in elisp, I haven't made any unusual changes there, that is, it's a compiled lisp function in `em-unix.el')
I would've expected something along the lines of "You have used 1.3 GiB of disk space", rather than that command not found error.
It doesn't use bash.exe, but it can use du.exe, when present.
On my system:
c: gutov $ which bash.exe
which: no bash.exe in ...
c: gutov $ which du.exe
h:/Apps/System/gnuwin32/bin/du.exe
From your error message I can tell that it calls some command and fails because it doesn't properly quote the path to executable (which contains spaces). Maybe you should do M-x report-emacs-bug.
Overall, I recommend:
1) Uninstall Git and reinstall it selecting the second option when asked about your PATH environment ("Run Git from the Windows Command Prompt"). This will remove the unix tools packaged with it from PATH.
2) Install in some directory without spaces and add to PATH unix tools from GnuWin32 project, or from Eli Zaretski's ports. The latter contains fewer packages overall, but it has a much faster find, for example. You can mix them.
Alternatively, maybe you can get away with just reinstalling Git into directory without spaces.

configuration for msysgit bash inside emacs on windows

What do you add to your .emacs file to use msysgit bash inside emacs ?
I just modified the cygwin instructions for msysgit replace cygwin with msysgit everywhere in these .
The only thing i can't do is run ssh or vim inside the bash...
directory completions work with windows style drive names prepended at the beginning.
Add this to your "_emacs.el" - it works for me:
;; When running in Windows, we want to use an alternate shell so we
;; can be more unixy.
(setq shell-file-name "C:/Program Files/msysgit/bin/bash")
(setq explicit-shell-file-name shell-file-name)
Update May 2018: Git 2.18 (Q2 2018) has now removed the contrib/emacs/ content.
Users of the git.el mode are now much better off using either Magit or the Git backend for Emacs's own VC mode.
See "Emacs Lisp error at init" for more.
Original answer 2011:
Not tested, but the idea was (2008) to copy in your Git installation directory at least:
contrib\emacs\git.el
contrib\emacs\git-mswin.el
With git-mswin.el being "Windows/msysgit specific modifications for git.el".

Putting .vimrc in vimfiles directory

I want to keep my Vim and Emacs configurations under version control, but I don't want my entire home folder there (or rather, I do, but there should be 3 separate repositories). With Emacs it's easy; if ~/.emacs doesn't exist, then ~/.emacs.d/init.el is used as the init file. So I can have a separate Git repo in ~/.emacs.d/. With Vim, it seems .vimrc can only exist in home folder and not in ~/vimfiles (the equivalent to ~/.emacs.d). Is this the best way to put .vimrc under version control?
Just put a dummy .vimrc in ~ with just a single line:
source ~/path/to/real/vimrc
Works like a charm
Perhaps moving your .vimrc to ~/.vim/ and symlinking to home will do?
Other, much more modular approach is to move your startup script to ~/.vim/plugins/, perhaps create a subdirectory there, and single or multiple init scripts: Vim will do a :runtime! plugin/**/*.vim when starting.
As #Progo suggests in their answer, ~/.vimrc settings can be moved into a "plugin" script within a file like ~/.vim/plugin/00rc.vim.
There are a couple of things to keep in mind when going down this road:
Users and plugins alike expect that the settings in ~/.vimrc have been loaded before plugins are as described in :help startup. ~/.vim is usually first in 'runtimepath', but if the user has other plugins in ~/.vim/plugin, the .vimrc replacement must be lexicographically first to ensure it is loaded first, perhaps ~/.vim/plugin/00rc.vim.
When the vim startup process moves from step 3 'Execute Ex commands' (where .vimrc would have been read; again, see :help startup) to step 4 'Load the plugin scripts', it runs :runtime! plugin/**/*.vim. This command looks through 'runtimepath' for matching files to source and then starts sourcing them. This means that if something in ~/.vim/plugin/00rc.vim modifies 'runtimepath' then it will have been too late to affect which plugins are run. This occurs most commonly with pathogen and in that case it can be worked around by adding the following lines to the end of ~/.vim/plugin/00rc.vim:
" Since this "vimrc" is really run as a plugin, vim has already compiled the
" list of paths/plugins that it wil execute at startup.
" As a result, the pathogen plugins must be run manually.
runtime! bundle/*/plugin/**/*.vim
runtime! bundle/*/after/plugin/**/*.vim
Finally, (again as explained in :help startup), if a ~/.vimrc file isn't present, vim will search for other files like ~/.exrc so it may be necessary to remove them if their contents are unwanted.
Adds a step to the process, but I just have a bash script deploy.sh in my vim settings.
#!/bin/bash
if [ -f ~/.vimrc ] && [ ! -L ~/.vimrc ]
then
echo "Backing up existing ~/.vimrc to ~/.vimrc.bak"
mv ~/.vimrc ~/.vimrc.bak
fi
if [ -L ~/.vimrc ]
then
echo "Already have ~/.vimrc symlink, we're good"
else
echo "Creating symlink ~/.vimrc, which points to ~/.vim/vimrc"
ln -s ~/.vim/vimrc ~/.vimrc
fi
git submodule init
git submodule update
You could just keep a backup in version control and deploy it (i.e. move it) to your home directory when you need it. You could write an easy script to manage all this handling so at least transparently it won't seem like a lot of annoying work to move it back and forth.

Eclipse CDT created makefile cannot "clean" on Windows

I have a makefile project with makefiles generated by Eclipse CDT (Helios, MinGW). The "clean" command does not work because the "del" command is executed with arguments like ./src/myfile.o, but on Windows this doesn't work (should be .\src\myfile.o).
How can I either tell Eclipse to use the Windows Path Separator or otherwise maybe replace the command "del" by something different (I could easily write a batch script which replaces the forward-slashes by backslashes)?
Thanks for any hints!
There is simple solution, create a makefile.defs file in your project's main directory with the following content:
RM := rm -rf
Basically this file lets you override variables from auto-generated makefile and RM is wrapper for remove command.
The best option is to download and install GnuUtils http://sourceforge.net/projects/gnuwin32/files/coreutils/5.3.0/coreutils-5.3.0.exe/download
and add the installed directory (C:\ProgramFile???\GnuWin32\bin)to your windows path and restart eclipse.Eclipse should execute rm-rf now...if it still doesnt ...restart windows and check your path again to see if it has \GnuWin32\bin ...then restart eclipse...
in your msys bin directory (C:\msys\1.0\bin on my machine) create a copy of rm.exe and rename it del.exe.
this is a hack. i am not familiar with the differences between the rm and del arguments. the base functionality is there. (delete file1 file2 filen)
in windows there is no del.exe, the delete functionality is built into CMD.exe. eclipse runs the commands in the msys shell which does not have the del functionality. this prevents you from adding a path to eclipse in which to search for del.exe.
i tried many different things to get the managed make to put "RM := rm" in the makefile but failed.
Edit the makefiles to use the mingw rm command instead?
Before you rename rm.exe to del.exe, check the path in Eclipse. The path has to have Unix path separators (forward slash, /) and not the Windows path separator (backslash, \).
This has fixed the problem on my side.