| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
PEP 8 (Style Guide for Python Code) suggests the use of 4 spaces:
http://www.python.org/dev/peps/pep-0008/#indentation
If you need to use tools like "git blame", you can use the -w option to
ignore this commit entirely. Patches will continue to work if you
substitute tabs with 4 spaces everywhere except in the Makefile.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When you deleted a directory and created a file with the same name, it
was treated like a directory, with ranger trying to preview it and
throwing lots of errors. This was because it tried to look for the path
of the currently selected file in fm.directories - a directory cache -
and if a file with the same name existed as a directory once, it would
have found it there.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
It works, but is rather hackish.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
To reproduce the bug that this patch fixes, do:
1. start in a place where the second item is a directory that contains
at least two files (the usual $HOME with sort_directories_first=True
will likely do)
2. open (and enter) a new tab with ^N
3. move down and right, entering the directory. The cursor is now on
file 1
4. switch to tab 1, then back to tab 2
5. now the cursor is on file 2 instead of file 1.
|
| |
|
|
|
|
|
| |
fm.source(custom_conf) could execute a "set colorscheme = ..." which
would lead to a "allow_access_to_confdir(..., False)" and that would
result in ranger not being able to find plugins since the confdir is not
in os.path anymore.
|
| |
|
|
|
| |
if you use ":tab_open 1 /path" while being in tab 1, the path should
change to /path, but it doesn't.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Without this, if you enter another tab, the cursor of the directory may
change and get_selection() will not return the actual selected file of
the tab anymore (unless they have been marked, in which case
everything's fine).
|
| | |
|
| | |
|
| |
|
|
|
| |
SettingObject can store settings local to a directory. Then LocalSettingObject
choses the right settings according to context.
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, you could change settings in both rc.conf and options.py.
With this commit, options.py is deprecated and you are encouraged to use
rc.conf to change settings. I chose to do this because it is more
elegant to use a simple list of ranger commands for configuration
rather than a python file with lots of magic around it and potential
syntax errors for inexperienced users.
The existing "set" command doesn't evaluate python objects anymore,
instead it always takes strings and converts to the proper type
automatically. This means that the old set command will not work
anymore and you have to update your commands.py if it still uses the old
definition of the "set" command.
This is how to convert your options.py:
old way, in options.py | new way, in rc.conf
---------------------------+------------------------
show_hidden = False | set show_hidden false
sort = 'basename' | set sort basename
column_ratios = (1, 5, 3) | set column_ratios 1,5,3
For backward compatibility, you still can use options.py, but you get a
warning when you start ranger. You can pipe stderr to /dev/null to
silence the warning, or just move your stuff from options.py to rc.conf
and plugins and delete the options.py.
Finally, to extend ranger, which you previously could do through
monkey-patching in options.py, you should now use the plugin system.
This was an experimental, undocumented feature of ranger for some time,
but this and the following commits will imrpove and document it.
You can simply move all the monkey-patching code from options.py to a
*.py file in ~/.config/ranger/plugins/.
|
| |
|
|
|
|
| |
before, in the search_next method, item.mimetype could be None,
resulting in an exception in lst.sort(key=fnc) when
order == 'mimetype'.
|
| | |
|
| |
|
|
|
|
| |
This reverts commit d6c78470ba0e3a9923d5cc13a5babaca4d52aecf.
It makes ... little sense atm to remove this.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code implements the functionality of cp and mv coreutils in python
and was removed as of v1.4.0 for efficiency and simplicity reasons.
I moved it back in for several reasons:
1. I plan to enhance shutil_g to report on its copying status so I can
display a progress bar
2. With no need for external cp/mv programs, distribution-specific
differences (like broken backup option on MacOS/BSD?) become irrelevant
3. You can still copy in ranger if you accidently delete /bin/cp
4. It gets rid of the occasional bug that the cp process keeps running
when ranger is terminated while copying
The possible downside is reduced efficiency in copying and ranger might
get stuck if the copying function is blocked. Let's see if it works
out.
|
| | |
|
| |
|
|
|
|
|
|
| |
instead of 's', you can append &>/dev/null
instead of 'p', you can append |less
instead of 'w', you can append ;read
If there is demand, I'll add the flags back in.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| | |
Conflicts:
doc/ranger.1
ranger/defaults/apps.py
|
| | |
| |
| |
| |
| |
| | |
This fixes the bug that some programs are killed even if they were run
with the "d" flag, if ranger is killed by closing its terminal with the
window manager instead of closed with :quit.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
in python2, weak references are not equal to the original object when
tested with "==", and this breaks Tab._set_thisfile_from_signal and
Tab._on_tab_change in python2 if weak=True is used in signal bindings
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
this was requested here: https://github.com/hut/ranger/issues/36
adam8157:
Why non-text files' default opener is editor now? It invoked open_with
before.
I think the old way is better. We can't describe all types in
rifle.conf, so many types are defined as unknown non-text types, it's
not appropriate to open them all with editor.
|
| | | |
|
| | | |
|
| | | |
|