Skip to content
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

DistractionFreeWindow not preserved on opening new file/tab #26

Open
telarmago opened this issue Jan 31, 2018 · 8 comments
Open

DistractionFreeWindow not preserved on opening new file/tab #26

telarmago opened this issue Jan 31, 2018 · 8 comments

Comments

@telarmago
Copy link

telarmago commented Jan 31, 2018

DistractionFreeWindow not preserved on opening new file/tab

Summary

While in 'DistractionFreeWindow mode', if I open a new file/tab, the status bar is hidden but no other elements are hidden.

Expected behavior

I would expect a new file/tab to open in 'DistractionFreeWindow mode' as well, with all settings preserved. For example, if I have the ruler hidden then I shouldn't see the ruler in a new file/tab.

Actual behavior

The file opens with only some DistractionFreeWindow settings applied. I have not tested this exhaustively, but settings that are not properly applied include:

  • hide rulers ("dfw_hide_rulers")
  • line numbers off ("dfw_hide_line_numbers")
  • gutter off ("dfw_hide_gutter")
  • draw centered ("dfw_draw_centered")

I have these settings set to "true" in my user preferences for DistractionFreeWindow. Only hiding the tab bar and the status bar appear to work properly when I open a new file/tab.

Steps to reproduce

  1. Open a file, then hit super+f11 (I'm on macOS so I hit fn+cmd+f11) to enter 'DistractionFreeWindow mode'
  2. Open a second file
  3. Observe how the second file has a ruler, line numbers, a gutter, and is not centered
  4. If you ctrl-tab back to the first file, it is still in the correct 'DistractionFreeWindow mode', with no ruler, no line numbers, etc.

See the .gif below for reference (also at https://imgur.com/a/gm2ZI)
out
In it, I start with a file open and I hit fn+cmd+f11 to enter 'DistractionFreeWindow mode'. Then, I open a second file. I ctrl-tab back and forth a few times to show the difference. Lastly, I hit fn+cmd+f11 to exit 'DistractionFreeWindow mode'.

Environment

DistractionFreeWindow:
    release:        0.6.8

Sublime Text:
    channel:        stable
    version:        Build 3143
    platform:       OSX (macOS)
@telarmago
Copy link
Author

telarmago commented Jan 31, 2018

After some more digging, it seems like this issue arises from how we alter the settings related to rulers, line numbers, gutters, and centered text. I examined the source code of this addon and also tried recreating this addon's functionality using key bindings/macros. It works, but has the same issue as described above. The settings that "stick" when opening a new file/tab are the ones that have "native" commands written into Sublime:

  • toggle_tabs
  • toggle_status_bar
  • toggle_minimap

For the other commands that need to be set with toggle_setting or set_setting (e.g., set(gutters, false)), it seems like the setting only sticks for the local window. This is why, I'm assuming, you created the all_views_in_window_setting_set function to act on all open window/tabs.

By the way - thank you for writing this addon, I love it! I was looking for something like goyo.vim for Sublime and this is as close as it gets. Pending a fix for this issue, I'm just double-tapping the hotkey for DFW mode (remapped to an easier-to-reach cmd-ctrl-w) every time I open a new file. With tabs, status bar, and minimap hidden by default, it's not too visually-jarring. Thanks again aziz!

@jrappen
Copy link
Collaborator

jrappen commented Feb 2, 2018

@telarmago Does the minimal setup code posted in #22 work for you? If so I’ll go ahead and work on the suggested changes there and see if I can fix it for ST2 too.

@telarmago
Copy link
Author

@jrappen Thank you for the response and suggestion! I tried your minimal setup code for distraction_free_window.py, but the same issue persists. I believe it arises due to the way we set values for this section of the code:

for v in w.views():
    v.settings().set('draw_centered', distraction_free.get('draw_centered', True))
    v.settings().set('draw_indent_guides', distraction_free.get('draw_indent_guides', True))
    v.settings().set('draw_white_space', distraction_free.get('draw_white_space', 'selection'))
    v.settings().set('fold_buttons', distraction_free.get('fold_buttons', True))
    v.settings().set('gutter', distraction_free.get('gutter', False))
    v.settings().set('line_numbers', distraction_free.get('line_numbers', False))
    v.settings().set('rulers', distraction_free.get('rulers', []))
    v.settings().set('scroll_past_end', distraction_free.get('scroll_past_end', True))
    v.settings().set('word_wrap', distraction_free.get('word_wrap', True))
    v.settings().set('wrap_width', distraction_free.get('wrap_width', 80))

This loops through all the open windows and applies settings. However, if we open a new file/tab/window, these specific settings shown above in the code snippet are not applied. That is, only this section:

w.set_sidebar_visible(False)
w.set_tabs_visible(False)
w.set_minimap_visible(False)
# w.set_status_bar_visible(False)

is applied "universally" across all tabs and windows, present and future.

Ideal behavior:

  1. I open a file.
  2. I hit a keyboard shortcut to turn on DistractionFreeWindow mode.
  3. I open a second file, and it opens up in DistractionFreeWindow mode with all settings applied correctly. This is how the native Distraction Free mode works (but in fullscreen).

Currently, step 3 only applies the settings in the second code block. I have to hit the keyboard shortcut twice (turn off and then turn on DistractionFreeWindow mode) to get my second file to enter DistractionFreeWindow mode. This is because the function looped through the open windows at the time the keybind was pressed, at which point only the first file was open.

@jrappen
Copy link
Collaborator

jrappen commented May 14, 2018

I'll take a stab at this tonight after work. Thanks for the detailed input.

@jrappen
Copy link
Collaborator

jrappen commented Jun 12, 2018

Sorry for the delay, got a call to take care of a friend in hospital that day... then forgot this pending issue. Anyhow, I'll take a look at the core code now to see how Jon did it there.

@telarmago
Copy link
Author

No problem! I hope all is well. I appreciate you looking into this.

@jrappen
Copy link
Collaborator

jrappen commented Jul 3, 2018

Core code for distraction free mode is not in the readable python files.

Pasting some links for future reference:

@jrappen
Copy link
Collaborator

jrappen commented Feb 21, 2019

It seems whether a window is in normal mode or distraction-free mode is stored in the session file. Maybe we can work with that?

MoritzBrueckner added a commit to MoritzBrueckner/DistractionFreeWindow that referenced this issue Mar 9, 2019
Now the distraction free mode gets saved between sessions, between projects and even after switching windows. Should fix issue aziz#26.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants