Well, the user might want to tweak it for some reason. > (define-key map (kbd "C-M-") 'darkroom-decrease-margins) > (define-key map (kbd "C-M-+") 'darkroom-increase-margins) You either weren't looking at the latest version, or I didn't push it. > (defun darkroom-decrease-margins (decrement) I could, but there's no big benefit and this also make the consness > (round (* (+ 1 increment) (cdr darkroom-buffer-margins))))
Writeroom mode auto wrap windows#
> You should test this when resizing windows and increasing fonts. Keep in mind I need to affect all windows that display that buffer. > Can't you use with-current-buffer? The walk-windows seems excessive. > (when (eq (window-buffer w) (current-buffer)) Particular structure, in which case I try to first separate byįunctionality, not programming construct. > I think these should all be at the top of the file. > "Buffer-local version of `darkroom-margins' defcustom. Here I'm concerned with the window geometry, not the current line's
> (- (line-end-position) (line-beginning-position)) > (ceiling (* (let ((edges (window-edges))) To please my mentor, I added a docstring :-) Leave them out, rather than risk them getting out of date, or hindering For internal functions, it might be a good idea to Should explain the "what" carefully avoiding the "how", so you canĬhange that later. Very much sympathise with your thoroughness in documentation, docstrings
Writeroom mode auto wrap code#
It's an internal function (what version of code were you lookingĪt). Ideas welcome, I didn't think much about the heuristic, this one worked > I think you can simplify this and you should not hardcode. > (let ((margin (round (/ (- window-width top-quartile-avg) 2)))) OK removed it and replaced with a message. > "Perhaps turn on visual-line-mode for a better darkroom?") > tested, check that it works out with the floats). > You do you need to add this to the top of your file? Yes, but I want to collect actual line widths here. > the end of the line, not the "visual" end of the line. How `darkroom-real-window-width' hacks it. The above won't work because I need to know about window I dealt with the FIXME with the ultra-horrible > `line-move' and `line-move-visual' (I don't know). > Note, for understanding this you might get some insights from studying > (progn (beginning-of-visual-line) (point)))) > (save-excursion (- (progn (end-of-visual-line) (point)) > Probably there's a more appropriate way of doing it. > You can estimate the realized width rolling over some lines and measure. > suitable default to put in `darkroom-margins', I guess. > 0, since window-width ignores text scaling. > FIXME: broken when darkroom-text-scale-increase is anything but > margins should center it on the window, otherwise, margins of > the buffer's paragraphs are mostly filled to `fill-column',
> apply a heuristic to figure out how wide to set the margins. > Collects some statistics about the buffer's line lengths, and I don't think Emacs uses that particular blank, but OK. > I think there should be a blank line here. > "Guess suitable margins for `darkroom-margins'. You found a bug, that second part of the docstring no longer applies. > specifying it manually? What takes priority? > So, there's both a function to calculate margins the possibility of > changing window or by calling `darkroom-set-margins'" > Value is effective when `darkroom-mode' is toggled, when > be default if you can sort out the FIXME > You might want to mention the function you wrote below. I wonder what else is not clear, but I have The opening tautology is necessary to diffentiate it from > This paragraph is not clear and potentially tautologous.
> There's usually a clause somewhere about whether it's part of Emacs.
0 kommentar(er)
