Skip to content

Autocompletion on rcParams: long-overdue restructuring of rcParams #2249

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dpsanders opened this issue Jul 24, 2013 · 2 comments
Closed

Autocompletion on rcParams: long-overdue restructuring of rcParams #2249

dpsanders opened this issue Jul 24, 2013 · 2 comments

Comments

@dpsanders
Copy link

It would be great to have autocompletion on rcParams (or settings) in IPython, so you could do

settings["fon<TAB>"]

and get a list of all keys containing the string "fon".
This would be another tool to get people modifying settings.

Currently there is no completion on dictionary keys in IPython -- I am hoping to implement this this week.

However, a nicer solution, in my opinion, is attribute access, so you could do e.g.

settings.xtick.color = 'b'

This is easy to implement by hand. But it turns out that it is already implemented in IPython! Even if in a slightly obscure (but super-general so nothing done by hand) way:

from matplotlib import rcParams
from IPython.config import Config

settings = Config(rcParams)

You can now automatically use the settings.xtick.color syntax and completion!:

settings.xtic<TAB>

gives a list of all the settings starting with xtic. (See below for more completion magic).

However, there is a problem with the names of the rcParams keys using . as a separator, namely that doing

settings.xtick.<TAB>

no longer completes anything. This is because it is treating settings.xtick as a subdictionary or subclass.

There are 2 possible solutions:

  1. Change the names of the settings keys, e.g. to xtick_minor_pad. Yuck.
  2. An excellent solution -- not just for this autocompletion problem -- is the following:

Really turn the sequence of names including .s in the string in the attribute-access pattern into real sub-dictionaries of rcParams.

Of course, this makes the dictionary key syntax horrible, but there would be no longer be any need for it -- we would just switch over wholesale to the . attribute syntax.

Of course, this breaks some backward compatibility, but it gives a much more logical structure to rcParams as a whole.
[And, thinking about it, it should be possible to rewrite the dictionary access functions so that the old key accesses still work!]

Of course, the magic going on in the IPython.config module is easily extractable straight in to rcParams, in case somebody is worried that this depends on IPython.

------- [Comments on future IPython command completion possibilities below]

In fact, I have a mod for IPython's command completion which completes any word containing the letters that you type in a certain order. Here is the output for

settings.fon<TAB>:
settings.figure.frameon           settings.legend.fontsize
settings.figure.max_open_warning  settings.legend.frameon
settings.font.cursive             settings.mathtext.fontset
settings.font.family              settings.pdf.compression
settings.font.fantasy             settings.pdf.fonttype
settings.font.monospace           settings.pdf.use14corefonts
settings.font.sans-serif          settings.pgf.rcfonts
settings.font.serif               settings.ps.fonttype
settings.font.size                settings.savefig.extension
settings.font.stretch             settings.savefig.frameon
settings.font.style               settings.savefig.orientation
settings.font.variant             settings.svg.fonttype
settings.font.weight              

It includes things that don't start with fon but contain the sequence of characters f, o, n in that order.

An alternative is to just search for the word fon, without splitting up the characters.
I hope to submit an IPython pull request soon. It will be possible to change between these different types of completion mechanism with a standard IPython configuration method.

@tacaswell
Copy link
Member

should make this play nice with #2637

@pelson
Copy link
Member

pelson commented Jan 17, 2014

I don't think we would want to add anything specific here - autocompletion on dictionaries is very cool, as would autocomplete on properties / getters, but it is my aspiration that that should just fall out from a sensible setup in the first place.

@pelson pelson closed this as completed Jan 17, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants