Is there a simple way to set margins face or, at least, background color?

It would be nice to have a screen shot to explain/show an example.

Currently no keymap means no binding anything to olivetti-shrink and olivetti-expand. Get on that.

It would be very nice to be able to always maintain a small left margin between the body text and the window divider, even when the window is very narrow.

One way to do this is to set olivetti-body-width to something like 0.9 and olivetti-minimum-body-width to something very small. However, when the window is large the body text is also too wide.

It would be nice if there was also a olivetti-maximum-body-width setting, or some other way to make sure there is always a bit of margin around the body text.

Setting olivetti-body-width to something other than an integer or a float between 0 and 1 (e.g. 70.3, 1.1, "foo") causes Emacs to continue to run window-configuration-change-hook with each attempt to change the window, but keep receiving an error.

The one from the screenshot in the readme

thanks

This is a recent issue, however I've found that when:

1. I open a buffer.
2. Enable olivetti-mode
3. Run olivetti-expand a bunch of times.
4. Run any other command

emacs starts spitting out set-transient-map PCH: (wrong-type-argument keymapp nil). This also has the affect of basically making emacs useless if toggle-debug-on-error is true.

Firstly, thank you for olivetti, it's fantastic!

• I've noticed that the default width of 80 characters actually seems to wrap at 78 for me, for some reason. This could be some interaction with the rest of my config. Even widths seem to be short by 2, odd ones by 3. Can you reproduce?

• Is there a preferred way to set a default width for olivetti in an init.el file (e.g. non-interactively)? Even if the width difference is peculiar to my config, I'd like change the default value so that it wraps at 80.

Thanks again for olivetti!

I'm afraid I've run into what sounds like a recurrence of the window too small for splitting bug referenced in #12, though only when using persp-mode. If the bug is better reported to the persp-mode maintainers, do let me know!

persp-mode is part of Spacemacs; it looks like someone else mentioned the same problem there.

Context

persp-mode manages 'perspectives'; groups of buffers and window configurations which can be switched between.

When using a perspective containing vertical splits, and with one or more buffers with olivetti-mode mode active, upon navigating away from, and then back to, the perspective, the window configuration is lost, with the error message:

[persp-mode] Warning: Can not restore the window configuration, because of the error -- (error Window #<window 3 on  *temp*> too small for splitting)

I've tried turning other modes on and off, and this does seem peculiar to olivetti-mode.

The problem is slightly different via the GUI and terminal. With the latter, perspectives behave as expected and without error during the session, but a similar error message appears when persp-mode attempts to recover the configurations when starting up in a new session.

I'm on GNU Emacs 25.2 on Ubuntu 16.04, using the latest versions of persp-mode and olivetti from MELPA (20170509.829 and 20160912.1758, respectively).

Hello,

I’ve run into a bad interaction between olivetti and org-mode when the variable org-special-ctrl-a/e is set to t.

Here’s the docstring for the variable:

Non-nil means ‘C-a’ and ‘C-e’ behave specially in headlines and items.

When t, ‘C-a’ will bring back the cursor to the beginning of the
headline text, i.e. after the stars and after a possible TODO
keyword.  In an item, this will be the position after bullet and
check-box, if any.  When the cursor is already at that position,
another ‘C-a’ will bring it to the beginning of the line.

‘C-e’ will jump to the end of the headline, ignoring the presence
of tags in the headline.  A second ‘C-e’ will then jump to the
true end of the line, after any tags.  This also means that, when
this variable is non-nil, ‘C-e’ also will never jump beyond the
end of the heading of a folded section, i.e. not after the
ellipses.

When set to the symbol ‘reversed’, the first ‘C-a’ or ‘C-e’ works
normally, going to the true line boundary first.  Only a directly
following, identical keypress will bring the cursor to the
special positions.

This may also be a cons cell where the behavior for ‘C-a’ and
‘C-e’ is set separately.

When it’s set to t, enabling olivetti in an org-mode suppresses the special behaviours and reverts them to their defaults (i.e. move-end-of-line & move-beginning-of-line(-dwim)).

I had little time to investigate, but I expect the problem to come from some keymap-inheritance from a major-mode. However, I’ve inspected olivetti-mode-map, and there doesn’t seem to be anything out of the ordinary.

HTH.

Hi!

I'm wondering if it would be better not to have visual-line-mode enabled by default? To me, this seems like a preference thing, more than a vital part of the mode.

I prefer setting truncate-lines to t, so that lines that go outside the window just "disappear" with only a slight indication that the line does continue. This workes well with Olivetti and visual-line-mode disabled. visual-line-mode overrides this behavior, so I need to explicitly disable it for Olivetti.

This isn't to argue that truncating lines is better in any way, but that visual-line-mode seems more like an opt-in feature to me. My suggestion would be to add a note in the README that Olivetti plays nice with visual-line-mode, and with the appropriate lisp-code to enable it together with Olivetti. Alternatively, it can be added as an option.

Feel free to close this issue with no changes if you prefer to keep visual-line-mode enabled by default 👍

There seems to be some conflicts with visual-fill-column-mode. For example, if both modes are on, the fringes will not move to center as they should do, but remain in edges of the window. Moreover, when using counsel-M-x, the visual effect of olivetti mode disappears all the margin setting are restored to the default. It looks that we should turn off the visual-fill-column-mode when entering olivetti mode and restore it when exiting olivetti mode.

Without visual-fill-column-mode

With visual-fill-column-mode

When called from Lisp, can (olivetti-set-width) not post a message in the echo area? I have a function to automatically set a different Olivetti width in my Dired buffers, and it’s annoying to get the “text width has been set” message every time I move directories.

I think there are ways to suppress messages to the echo area, but I’m reporting this as an issue because I don’t think any message should be sent if body width is changed non-interactively.

First of, I really love Olivetti! It helps me concentrate on my work in Org-mode and also keeps the width of the text to a very comfortable readability.
However, I've noticed that when I scroll up and down (particularly with my trackpad) the words would disappear as a whole and leave only my background color for some split second.

p.s. I am using brew-built Emacs 27.0.50 on macOS Mojave

It seems there are two possible candidate hooks for enabling olivetti-mode on the minibuffer when executing isearch.
minibuffer-setup-hook or isearch-mode-hook

minibuffer-setup-hook

It looks like isearch is activating minibuffer but it's not. We can see that by observing minibuffer-setup-hook
isn't triggered by isearch-forwarduntil we explicitly focus on the minibuffer.

isearch-mode-hook

Since isearch commands won't change focus to minibuffer, olivetti-mode won't be activated on minibuffer.
So, we have to get the minibuffer object and activate olivetti-mode with it.

(defun olivetti-isearch-mode-setup ()
  (let* ((win (minibuffer-window))
         (buf (window-buffer win)))
    (with-current-buffer buf
      (olivetti-mode 1))))

(add-hook 'isearch-mode-hook 'olivetti-isearch-mode-setup)

This should work but it won't. My guess is that the hooks olivetti-mode relies on isn't firing.

A hack to go around this issue is calling olivetti-set-window explicitly after enabling olivetti-mode on minibuffer.

(defun olivetti-isearch-mode-setup ()
  (let* ((win (minibuffer-window))
         (buf (window-buffer win)))
    (with-current-buffer buf
      (olivetti-mode 1)
      (olivetti-set-window win))))

(add-hook 'isearch-mode-hook 'olivetti-isearch-mode-setup)

The Readme says:

A simple Emacs minor mode for a nice writing environment.

Anyhow it is unclear what this means and what the mode actually does. Please be more verbose in the Readme and explain what this means.

Hi! This config used to work a few commits ago:

(eval-and-compile
  (defvar bootstrap-version)
  (let ((bootstrap-file
	 (expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
	(bootstrap-version 5))
    (unless (file-exists-p bootstrap-file)
      (with-current-buffer
	  (url-retrieve-synchronously
	   "https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el"
	   'silent 'inhibit-cookies)
	(goto-char (point-max))
	(eval-print-last-sexp)))
    (load bootstrap-file nil 'nomessage)))

(straight-use-package 'diff-hl)
(global-diff-hl-mode)

(straight-use-package 'olivetti)
(define-globalized-minor-mode global-olivetti-mode
  nil (lambda ()
	(pcase major-mode
	  ('minibuffer-inactive-mode)
	  ('exwm-mode)
	  ('mu4e-headers-mode)
	  ('pdf-view-mode)
	  ('image-mode)
	  (_ (olivetti-mode 1)))))
(global-olivetti-mode 1)

(load it with emacs -Q -l NAME-OF-CONFIG.el)
but now if you run it, open a file under git version control, make a change and then save, olivetti stops working until you change the window size among other things. Maybe there is a better way to make olivetti-mode global that doesn't introduce this bug? Thanks for making this package!

Hi!

Right off the bat, I love this piece of Elisp-goodness!

I would like to use this along with text-scale-mode, and thought it would be cool to make the window grow dynamically with it. I think it won't be so hard to implement, and I can't see how it would interfere with people who don't use text-scale-mode.

I'll fork the repo, and see if I can make it work, and if so, send a pull request. Just thought I'd suggest it here first, in case you have some opinion on the matter!

First of all, thanks for olivetti mode. It makes writing text in emacs feel much more natural.

I have noticed that olivetti mode does not take into account fringe-mode.

Steps to reproduce:

1. Start emacs -q
2. Install olivetti mode
3. (fringe-mode 16)
4. (olivetti-mode)

Expected result: 80 columns of characters
Actual result: about 75 columns

See the attached screenshot:

Hi @rnkn,

I think I understand why you made the change from C-c [ to C-c { (eg: consistency with upstream bindings in f72920f), but I find them horrible on an ANSI keyboard. + c, then + [ ...slow and awkward. In Debian we also like to avoid disrupting the workflow of existing users, if at all possible, so I was originally thinking about reverting this change in our package.

A new team member helpfully suggested checking if anything else uses the C-c [ keybinding among the modes users are likely to combine with Olivetti-mode, and it seems none do, thus I plan to enable legacy bindings in the Emacs package. Would you also like to provide them to your MELPA and run-from-git-repo users? If so, I'll file a PR rather than making a Debian-specific change :-)

Best,
Nicholas

When I enable olivetti-mode in a text scratch buffer it centers the text fine. However in an org buffer it errors and does nothing:
Error during redisplay: (olivetti-set-window #<window 15 on 20220109T003018-electronics.org>) signaled (wrong-type-argument number-or-marker-p unspecified)

Backtrace:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p unspecified)
  olivetti-scale-width(648)
  olivetti-normalize-width(72 #<window 15 on 20220109T003018-electronics.org>)
  olivetti-set-window(#<window 15 on 20220109T003018-electronics.org>)
  olivetti-set-buffer-windows()
  olivetti-mode(toggle)
  funcall-interactively(olivetti-mode toggle)
  command-execute(olivetti-mode record)
  execute-extended-command(nil "olivetti-mode" nil)
  funcall-interactively(execute-extended-command nil "olivetti-mode" nil)
  command-execute(execute-extended-command)

Hello,

First of all, thanks for this great package. I've been facing a weird issue where if I open e.g. an org-mode file, where there is a olivetti-mode hook for org-mode, after I close that buffer, the buffer that is displayed after is itself narrowed as well. Is there any solution? My relevant config is the following:

(use-package olivetti
  :elpaca t
  :hook
  (org-mode . olivetti-mode)
  (markdown-mode . olivetti-mode)
  (Info-mode . olivetti-mode)
  (elpher-mode . olivetti-mode)
  (eww-mode . olivetti-mode)
  (TeX-mode . olivetti-mode)
  (tex-mode . olivetti-mode)
  (LaTeX-mode . olivetti-mode)
  (latex-mode . olivetti-mode))

(add-hook 'olivetti-mode-on-hook (lambda () (olivetti-set-width 130)))

Thanks in advance.

If you pad the windows with fringes like https://github.com/anler/centered-window-mode, will it fix the incompatibility with linum and display-line-numbers-mode?

I installed Olivetti via MELPA in Aquamacs. I enabled it on a fountain buffer with M-x olivetti-mode and I get the following error:

Wrong type argument: listp, fountain-mode-default 

Any help would be greatly appreciated. Thanks!

If I have guide-key mode enabled and set to either the right or left position, and I trigger it in olivetti mode, the new guide-key window inherits some of the window padding from the olivetti window, and then I have to close it manually. Sometimes attempting this locks up emacs.

When doing middle-click on top of the margins I get

<left-margin> <mouse-2> is undefined

Originally, middle click anywhere on the screen should paste the contents of the clipboard on the cursor position.

1. How do I enable olivetti mode globally in emacs for all buffers
2. How do I enable olivetti mode locally in emacs for some buffers (e.g. for w3m and eww)

Thx a lot

Since upgrading to Emacs 25, I'm no longer able to split windows horizontally, even when I set split-width-threshold to a low value (e.g. 5). When I run split-window-horizontally or split-window-right, I get this:

Debugger entered--Lisp error: (error "Window #<window 7 on warm.org> too small for splitting (2)")
  signal(error ("Window #<window 7 on warm.org> too small for splitting (2)"))
  error("Window %s too small for splitting (2)" #<window 7 on warm.org>)
  split-window(nil nil t)
  split-window-horizontally(nil)
  funcall-interactively(split-window-horizontally nil)
  call-interactively(split-window-horizontally nil nil)
  command-execute(split-window-horizontally)

When I disable olivetti-mode for the current buffer, I am then able to do split-window-horizontally. Any suggestions?

emacs: 28.0.50
olivetti version:

;; Package-Version: 20200702.601
;; Version: 1.11.1

Given text like this and a configuration where olivetti wraps the line:

complete after this: wo_ <---- cursor here, then trigger completion window
* This is a very very very long line that is longer than my olivetti mode keeps on one line and wraps to the second

That second line will shift to the left and it's very visually distracting lately, though I could easily ignore it at first.

Related:

company-mode/company-mode#272
zk-phi/sublimity#21

Hi!

It seems like commit 8332154 breaks scaling the width along with text-scale-mode.

It's is almost certainly due to removing olivetti-set-margins from post-command-hook. Luckily, there is a text-scale-mode-hook, so the fix should be simple.

I'll send a PR!

While it appears that olivetti crosses all its T's and dots all its I's when it comes to minor mode conventions, visual-line-mode, which is integral to the functioning of the minor mode, still doesn't behave correctly when switching olivetti off.

If visual-line-mode is enabled prior to enabling olivetti-mode then when olivetti is turned off, then turning off visual-line-mode will have no effect.

1. new buffer in text-mode with enough text to wrap window
2. enable visual-line-mode
3. enable olivetti-mode
4. disable olivetti-mode
5. disable visual-line-mode

Text will still wrap to window, necessitating (visual-line-mode 0) or M-x text-mode

I don't know if this is due to some interaction effects with something else, and I'm not entirely sure how to check for that either, but my CPU profiler reported a lot of time being spent garbage collecting, and my memory profiler could confirm that

From having tried to written a similar mode to Olivetti before, I understand refreshing this after each command is a convenient option to ensure no edge case is missed, but with the input latency I get, I don't think it's worth it – regardless of how pretty my windows become with Olivetti turned on!

• Is there a quick way to check whether whatever processing we're about to do on the current window actually would change anything? And if not, just decline to do it?

• Would it perhaps be a solution to reset the environment in an idle timer instead?

• Or at least not run the processing if this-command is one of a predefined list of input commands, among others '(self-insert-char backward-char forward-char delete-char delete-backward-char) etc?

The help suggests for expensive post-command-hook functions to wrap the code in (while-no-input (redisplay) CODE) but that will terminate Olivetti processing midway through and leave buffers in invalid states.

Hi! I recently very bothered about Emacs performance moving cursor around and I couldn't identify where the problem was.

Started profiling and turning things on/off until I realized when Olivetti was turned on it made things laggier.

I couldn't yet identify if it's a GNU Emacs problem or what so I started again isolating stuff around.

I've measured performance simply but using:

(setq-default left-margin-width 70 right-margin-width 70) ; Define new widths.

And it alone makes everything 25% slower.

When testing Olivetti alone it makes 100% slower.

I was wondering if you could help me understand better where exactly the problem is, so I can report it properly to the GNU Emacs bug tracker.

Hello,

First off I'd like to say thank you for writing this minor mode, it's really visually pleasing.

Is it possible to set the background colour of the space that Olivetti creates on either side of the document? I looked at the code and didn't see any easy way to add colour, but I'm very much a Lisp novice.

Looking at the image attached to this issue, I'd like to set the colour of the areas surrounded by the red boxes.

If it's not possible without some major work, please delete this. I don't want to cause any hassle!

Summary

There is a strange bug happening when I try to use window-toggle-side-windows inside a side window when the other window has olivetti-mode enabled. At first, it works just fine, side window being hidden. But when I try to show it back, something strange happens and the main window becomes a side window (it can't be split), and the previous side window buffer opens in the main window instead of on the side. I am not sure how to debug it but i managed to find a reproducible way to cause this bug

Steps to reproduce

Minimal configuration

;; bootstrap straight
(defvar bootstrap-version)
(let ((bootstrap-file
       (expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
      (bootstrap-version 5))
  (unless (file-exists-p bootstrap-file)
    (with-current-buffer
        (url-retrieve-synchronously
         "https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el"
         'silent 'inhibit-cookies)
      (goto-char (point-max))
      (eval-print-last-sexp)))
  (load bootstrap-file nil 'nomessage))

;; install olivetti
(straight-use-package 'olivetti)

;; display help buffers in side window
(setq display-buffer-alist
      '(("\\*Help.*"
         (display-buffer-in-side-window))))

Inside emacs

M-x olivetti-mode RET Enable olivetti mode
C-h f + RET Open any help buffer
C-x o Switch to it
M-x window-toggle-side-windows Toggle side window
M-x window-toggle-side-windows Toggle it back

Now window-toggle-side-windows doesn't work at all and emacs' behaviour of displaying buffers is broken until olivetti-mode is turned off

System

• Emacs 29.0.50
• PGTK
• Native comp

Hi ! Great mode !
Use it everyday so thanks you :)

Just a little suggestion. I was thinking : would it be possible to get visual justification like this ?

There is a serious regression in Emacs 27.0 that will cause console Emacs to crash.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38757

I use Olivetti with use-package and straight.el on Emacs 29.1 RC1. My Olivetti config is simple.

(use-package olivetti
  :hook
  ((text-mode-hook prog-mode-hook) . olivetti-mode) 
  :custom (olivetti-body-width 108)
  :diminish)

However, I often get the following error on Emacs start.

Eager macro-expansion failure: (error "Eager macro-expansion skipped due to cycle:
  … => (load \"olivetti.el\") => (macroexpand-all …) => (macroexpand (eval-when-compile …)) => (load \"olivetti.el\")")

I can reproduce this error consistently with the following MWE with Emacs 29.1 RC1 and emacs -nw -q. I have also got this error quite a few times across different Emacs versions, 27.1 and 28.2.

(setq straight-build-dir (format "build/%d%s%d"
                                 emacs-major-version
                                 version-separator
                                 emacs-minor-version)
      straight-use-package-by-default t)

(let ((bootstrap-file
       (expand-file-name "straight/repos/straight.el/bootstrap.el" user-emacs-directory))
      (bootstrap-version 6))
  (unless (file-exists-p bootstrap-file)
    (with-current-buffer
        (url-retrieve-synchronously
         "https://raw.githubusercontent.com/raxod502/straight.el/develop/install.el"
         'silent 'inhibit-cookies)
      (goto-char (point-max))
      (eval-print-last-sexp)))
  (load bootstrap-file nil 'nomessage))

(setq use-package-hook-name-suffix nil)
(straight-use-package 'use-package)

(use-package olivetti
  :hook
  ((text-mode-hook prog-mode-hook) . olivetti-mode) ; `emacs-startup-hook' does not work
  :custom (olivetti-body-width 108)
  :diminish)

I use emacs snapshot on ubuntu 18.04 via https://launchpad.net/~ubuntu-elisp/+archive/ubuntu/ppa

ii  emacs-snapshot                                        20190505:96967-64f95e4~ubuntu18 amd64                           GNU Emacs editor (with GTK+ user interface)

GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2019-05-05

Recently, the olivetti mode margin has started jumping around.

emacs -nw -Q
C-x C-f olivetti.el
M-x eval-buffer
C-x b new-buffer
M-x olivetti-mode

Whenever I type, the margin jumps around from the very edges to the standard olivetti margins.

Edit

Update:

In Emacs27.1 git-gutter is not conflicting with olivetti on my computer! You may not need to take care, either!

In short

Olivetti uses margins and it often conflicts with git-gutter. git-gutter-fringe works well in GUI and for terminal I made a hack (gist).

Summary

It happens if git-gutter is loaded. It may be related to #42.

When changes are saved, current window with buffer in olivetti-mode loses distraction-free looking:

The left window lost distraction-free looking while it's in olivetti-mode

Steps to reproduce

1. Start Emacs with git-gutter and olivetti-mode. Also I opened init.el.
2. M-x olivetti-mode RET
3. Change the buffer and save it

init.el for reproduction

Enable use-package:

(progn
    (require 'package)
    (package-initialize)
    (setq package-enable-at-startup nil)
    (setq package-archives
          '(("gnu"   . "http://elpa.gnu.org/packages/")
            ("melpa" . "http://melpa.org/packages/")
            ("org"   . "http://orgmode.org/elpa/"))))

;; Install and enable use-package
(eval-when-compile
    (unless (package-installed-p 'use-package)
        (package-refresh-contents)
        (package-install 'use-package))
    (require 'use-package))

And then the packages:

(use-package olivetti :ensure t)

(use-package git-gutter
    :ensure t
    :config (global-git-gutter-mode +1))

;; I didn't use it, but if you like
;; (use-package evil
;;     :ensure t
;;     :config (evil-mode))

Actions to solve the issue

If it can't be fixed

• I think this is an important problem that worth noting in README.
• I'd like to find some hack to re-enable the distractin-free looking automatically after it's lost. (If I can.. but I'm not sure since I'm not yet faimlar with Emacs)

My attampt to find the hack

I could do one of the follows to re-enable the distraction-free looking:

1. M-: (run-hooks 'write-file-functions) RET
2. Type ESC (or some key) to show which-key in minibuffer

For which-key, I used the following configuration:

(use-package which-key
  :ensure t
  :config
  ;; Show hints immediately
  (setq which-key-idle-delay 0.01)
  (setq which-key-idle-secondary-delay 0.01)
  (setq which-key-popup-type 'minibuffer)
  (which-key-mode))

Thank you

edit: typo and indentations

it would be great if olivetti could turn off menu bars and turn on full screen. i tried to suggest (and implement) this in darkroom, a similar mode, but failed to both implement it properly and get the concept accepted: joaotavora/darkroom#2 i'd be curious to see if there would be more interest here.

Hi,

FYI, the new keymap appears to still conflict with (or shadow) org-mode's, specifically some of the table-related commands: https://orgmode.org/orgcard.pdf

I'm starting to wonder if it's better to defend against org-mode rather than accommodate it, because org-mode grabs all the good C-c bindings--bindings that are supposed to be reserved for user customisations. Were I to combine the two I would 1) draft the document.org with stubs 2) disable olivetti mode to access more advanced org-mode functionality 3) or just M-x what I wanted to do.

Add the moment I'm debating overriding the new keymap by-default in the Debian package, rather than forcing users to adapt their habits and configs to a new one that still has issues. My rationale is that users of org-mode are better equipped to figure this out for themselves than non-users of org-mode, and thus that it's better for Emacs adoption rates to accommodate a new generation of users with [edit: easier] bindings. For example, what about the following:

C-x C-- and C-x C-= reduce or increase text size. Would it be more consistent to have olivetti shrink and expand use C-c C-- and C-c C-=? These do not conflict with or shadow any bindings in org-mode's keymap.

What do you think?

Regards,
Nicholas

In some cases, when the Emacs frame is resized, a window where olivetti-mode is enabled is not updated. Evaluating (olivetti-set-margins) does not help, so it seems the problem is not with the hook but with the function itself.

I've noticed this in the following situations:

• with the i3 tiling window manager, opening an application next to the Emacs frame, so that the space is split in two (this is my own use case);
• in both Gnome and i3, calling toggle-frame-fullscreen (bound to F11 by default) twice.

The problem seems to impact Emacs beyond olivetti: for instance elements put on the right of the modeline generated by doom-modeline are hidden after such a resizing. But this also happens with emacs -Q, e.g. the scrollbar on the right is hidden.

(My OS is Ubuntu 18.04. Emacs version (emacs-version): GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2019-09-16. Olivetti 1.9.3 (20200320.1154 from Melpa))

https://lists.gnu.org/archive/html/emacs-devel/2019-05/msg00803.html

OK. Then I'm afraid you have to do the following: Whenever olivetti
mode is active in at least one live window on a frame you have to
use 'olivetti-split-window' on all internal windows of that frame
too. You can use 'walk-window-tree' for setting and resetting this
parameter and the margins of all olivetti mode windows. It should not
be too much of a hassle (and tell me immediately when you encounter
any problems).

The reason is that 'split-window' may be called for internal windows
too. For example, if you want to make a new window on the left or
right side of a frame, Emacs may want to split the root window of that
frame. In this case it will check the sizes of all live subwindows of
the root window and if any of these windows has too large margins, the
split may fail because of insufficient space for the new window.

@larstvei I’m taking a break from Emacs, could you please test the below patch on console and GUI and merge if it’s good?

From dc35104e9f2dfc0e2d8f0cc437581cf8fa0673b7 Mon Sep 17 00:00:00 2001
From: "Paul W. Rankin" <[email protected]>
Date: Sun, 29 Jan 2023 09:07:07 +0000
Subject: [PATCH] Quote mouse-wheel events

---
 olivetti.el | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/olivetti.el b/olivetti.el
index f440088..7df6453 100644
--- a/olivetti.el
+++ b/olivetti.el
@@ -428,10 +428,10 @@ If prefixed with ARG, incrementally increase."
     (define-key map [right-fringe mouse-1] #'mouse-set-point)
     ;; This code is taken from https://github.com/joostkremers/visual-fill-column
     (when (bound-and-true-p mouse-wheel-mode)
-      (define-key map (vector 'left-margin mouse-wheel-down-event) 'mwheel-scroll)
-      (define-key map (vector 'left-margin mouse-wheel-up-event) 'mwheel-scroll)
-      (define-key map (vector 'right-margin mouse-wheel-down-event) 'mwheel-scroll)
-      (define-key map (vector 'right-margin mouse-wheel-up-event) 'mwheel-scroll))
+      (define-key map (vector 'left-margin 'mouse-wheel-down-event) 'mwheel-scroll)
+      (define-key map (vector 'left-margin 'mouse-wheel-up-event) 'mwheel-scroll)
+      (define-key map (vector 'right-margin 'mouse-wheel-down-event) 'mwheel-scroll)
+      (define-key map (vector 'right-margin 'mouse-wheel-up-event) 'mwheel-scroll))
     map)
   "Mode map for `olivetti-mode'.")
 
-- 
2.38.2

It would be nice to have something like this in the docs for new users:

;; this will hide the fringe on a per-frame basis, but will not
;; reenable the fringe if olivetti-mode is disabled.
(add-hook 'olivetti-mode-hook (lambda () (set-fringe-style 0)))

Of course ideally a call to "fringe-query-style", would be added, storing the value in a buffer-local
variable, which is then restored if olivetti-mode is disabled for a buffer...but that's more work.

[edit: Why? Because some themes set up the fringe using a contrasting colour, and this is distracting.]

Runtime Environment

• Manjaro i3 Stable
• GNU Emacs 27.0.50
• olivetti-20190330.1633
• ~/.emacs.d
• use-package declaration:

(use-package olivetti
  :defer t
  :ensure t
  :config
  (setq-default olivetti-body-width 100)
  (setq olivetti-body-width 100))

Issue

Whenever I focus out of Emacs, this appears in the Messages buffer:

Error during redisplay: (olivetti-set-environment #<window 96 on notes.org>) signaled (wrong-type-argument framep #<window 96 on notes.org>) [4 times]

Hi,

I think Olivetti mode's documentation can be enhanced by adding a code snippet for configuring a custom function that

1. goes full-screen using the newish multiplatform method built into GNU Emacs
2. activating olivetti-mode
3. starting emacs with "emacs -f name-of-this-function"

Such a function can then be trivially bound to a shortcut key such as F11. An alternate method would be to hook into the fullscreen function, but this has the disadvantage of activating Olivetti when what you're trying to do is work in a full-screen multiwindow Emacs session.

I've been using something like this for many years:

#!/bin/sh
# jot down an idea
# This program is GPL-2+
# (C) Nicholas D Steeves 2008

/usr/bin/emacs -f custom-jot-function ~/Desktop/Notebook/`date +%y-%m-%d_%R`.txt

Bug report

I got this picture. The buffer in the up window is in Olivetti mode (as the mode line suggests), but it lost discraction-free looking (I mean, the width is more than 70):

Steps to reproduce

First we set Olivetti up opening two files in two windows:

1. emacs -nw -Q 1.txt 2.txt
2. M-: (load "/path/to/olivetti.el")

We let the two windows, say, A and B, be in olivetti-mode:

3. M-x olivetti-mode // window A
4. C-x o (other-window)
5. M-x olivetti-mode // window B

Then toggle olivetti-mode:

6. M-x olivetti-mode // window B

Now window A lost distraction-free looking while it's in olivetti-mode.

Expected behavior

Window A is in olivetti-mode and it keeps distraction-free looking.

Thank you

I'm really liking Olivetti!

edited: fixed some typos