Describe the new feature or enhancement
I was investigating a small plotting behavior detail and traced figure-creation paths in mne/viz/_mpl_figure.py and mne/viz/evoked.py.
During that check, I noticed that evoked.plot() still creates a plain Matplotlib figure in its default path, even though the line-plot figure-class refactor direction in #7751 points toward consolidating these under MNELineFigure.
A small, isolated enhancement would be to:
- route
evoked.plot() through _line_figure / MNELineFigure when it creates its own figure
- keep
plot_white / plot_joint out of scope for now
- add a small regression test to lock this behavior
I can open a focused PR as a partial improvement linked to #7751, without claiming closure of #7751.
Describe your proposed implementation
I propose implementing this as a small enhancement to the existing evoked.plot() path in mne/viz/evoked.py:
- when
evoked.plot() creates its own figure (axes is None), route figure creation through mne.viz._mpl_figure._line_figure(...)
- this makes it instantiate
MNELineFigure instead of a plain matplotlib figure for the default path
- keep behavior unchanged when users pass explicit
axes
- keep
evoked.plot_white() and evoked.plot_joint() out of scope for this issue/PR
- add a regression test in
mne/viz/tests/test_evoked.py to assert the expected figure class for evoked.plot() in the default path
- add a small changelog (towncrier) entry
This keeps the change isolated and aligned with the 2D plotting figure-class refactor direction discussed in #7751.
Describe possible alternatives
Possible alternatives considered:
- Do nothing for now
- Pros: no immediate code churn
- Cons:
evoked.plot() remains inconsistent with the line-figure refactor direction
- Refactor
evoked.plot(), evoked.plot_white(), and evoked.plot_joint() together in one PR
- Pros: broader consistency in one go
- Cons: much larger risk/scope; harder review; more likely to regress behavior
- Add a new optional argument (e.g.,
figure_class="line") to evoked.plot()
- Pros: explicit opt-in
- Cons: adds API surface for what should be an internal consistency improvement
Chosen approach (small internal routing change for default evoked.plot()) is better because it is minimal, testable, and incremental, while still moving toward #7751.
Additional context
No response
Describe the new feature or enhancement
I was investigating a small plotting behavior detail and traced figure-creation paths in
mne/viz/_mpl_figure.pyandmne/viz/evoked.py.During that check, I noticed that
evoked.plot()still creates a plain Matplotlib figure in its default path, even though the line-plot figure-class refactor direction in #7751 points toward consolidating these underMNELineFigure.A small, isolated enhancement would be to:
evoked.plot()through_line_figure/MNELineFigurewhen it creates its own figureplot_white/plot_jointout of scope for nowI can open a focused PR as a partial improvement linked to #7751, without claiming closure of #7751.
Describe your proposed implementation
I propose implementing this as a small enhancement to the existing
evoked.plot()path inmne/viz/evoked.py:evoked.plot()creates its own figure (axes is None), route figure creation throughmne.viz._mpl_figure._line_figure(...)MNELineFigureinstead of a plain matplotlib figure for the default pathaxesevoked.plot_white()andevoked.plot_joint()out of scope for this issue/PRmne/viz/tests/test_evoked.pyto assert the expected figure class forevoked.plot()in the default pathThis keeps the change isolated and aligned with the 2D plotting figure-class refactor direction discussed in #7751.
Describe possible alternatives
Possible alternatives considered:
evoked.plot()remains inconsistent with the line-figure refactor directionevoked.plot(),evoked.plot_white(), andevoked.plot_joint()together in one PRfigure_class="line") toevoked.plot()Chosen approach (small internal routing change for default
evoked.plot()) is better because it is minimal, testable, and incremental, while still moving toward #7751.Additional context
No response