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

Weird wrong calculated width #48

Open
ACEMerlin opened this issue Jan 9, 2019 · 10 comments
Open

Weird wrong calculated width #48

ACEMerlin opened this issue Jan 9, 2019 · 10 comments
Labels

Comments

@ACEMerlin
Copy link

ACEMerlin commented Jan 9, 2019

I only have writeroom-mode installed using use-package

(use-package writeroom-mode
  :init
  (setq writeroom-width 0.5)
  (global-set-key (kbd "C-c w") 'writeroom-mode))

Steps:

  1. open emacs (no frame-parameter whatsoever), press C-c w
  2. Weird width, so I change the code to this:
(defun writeroom--calculate-width ()
  "Calculate the width of the writing area."
  (if (floatp writeroom-width)
      (progn
	(message "%s" (window-total-width))
	(truncate (* (window-total-width) writeroom-width)))
    writeroom-width))
  1. goto step 1, and It prints out 96(the old width before fullscreen), which should be 192 when in fullscreen.
  2. but when I edebug this function and go step by step, it prints out 192 and show things correctly...
  3. if I fullscreen first then call writeroom-mode, it also works correctly.
  4. that's weird, you can see the screen capture below:

bug

@joostkremers
Copy link
Owner

Strange, and unfortunately I can't replicate it. What OS and Emacn version are you using?

The fact that window-total-width returns an incorrect value suggest that it's a problem between Emacs and full-screen on your system, though. Not sure if I can do much about it in that case.

What happens if you build a small pause into writeroom--calculate-width?

(defun writeroom--calculate-width ()
  "Calculate the width of the writing area."
  (if (floatp writeroom-width)
      (progn
	(sleep-for 2)
        (message "%s" (window-total-width))
	(truncate (* (window-total-width) writeroom-width)))
    writeroom-width))

Perhaps it takes a few moments for the UI to catch up...

@ACEMerlin
Copy link
Author

ACEMerlin commented Jan 10, 2019

yes, It works correctly with a tiny pause. After reading the document, I suggest the following code to fix this:

...
  (redisplay)
  (setq visual-fill-column-width (writeroom--calculate-width)
...

Of course, you can put (redisplay) anywhere you like

@joostkremers
Copy link
Owner

Honestly, I'm a little hesitant to add (redisplay), because I don't know if it's the right way to deal with this. I've asked on the Emacs mailing list and will let you know if and when I get an answer.

If people advise me against adding (redisplay), it'll still be fairly easy to solve your issue, though. You could simply write a custom fullscreen function that calls (redisplay) and use that instead of the default fullscreen option. I'd be happy to help with the details.

But let's first wait and see what the mailing list says.

@joostkremers
Copy link
Owner

I received some answers to my questions, but I haven't had time to go into them yet. My suggestion would be to add the (redisplay) to your local copy of writeroom-mode.el for the moment. Once I implement a permanent solution, I'll let you know.

@ACEMerlin
Copy link
Author

got it, thx

joostkremers added a commit that referenced this issue Feb 12, 2019
Enabling v-f-c-mode in `writeroom--enable` can cause a race condition between
the WM enabling fullscreen and `writeroom-mode` calculating the width of the
text area when `writeroom-mode-width` is set to a fractional value.

See Github issue #48.
@joostkremers
Copy link
Owner

I pushed a commit to the devel branch that hopefully fixes this. The cause of the problem is simply a race condition between the WM enabling full screen and Emacs. The fix involves calculating the width of the text area in the hook window-size-change-functions, which should run once full screen has been enabled. Apparently, however, there's no guarantee that this will indeed be the case...

Could you try the devel branch and see if it solves the issue for you?

@joostkremers
Copy link
Owner

I just found that my proposed solution causes an annoying bug if a user doesn't actually activate full screen, so I'm gonna have to try and think of something else...

@ntdef
Copy link

ntdef commented Mar 3, 2020

I seem to be experiencing this issue too now. Does the redisplay fix not work?

@joostkremers
Copy link
Owner

With redisplay, the chances of getting a correct result are better, but the underlying problem isn't solved, so I haven't adopted it. I've been meaning to look for a better solution but never got round to it.

@ntdef
Copy link

ntdef commented Mar 4, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants