Proposal: Add a way to configure window placement

[lduktus]

I think the overall user experience could improve:

1. when certain type of windows spawn in fixed position.
2. the modeline could be disabled for certain window types.

Especially point 1 would be nice as certain type of information, dialogs, etc. could be displayed on a certain area of the frame or in some cases even spawn a new frame. There are some packages which add this kind of functionality e.g.: https://github.com/emacsorphanage/popwin I don't now how doable it is.It seems that most solutions I stumbled upon have some tradeoffs.

On point 2: I may be oppionated about this, but in a lot of cases the modeline does not seem necessary to me, e.g. when opening help commands, spell checking or using org-capture.

[rougier]

Thansk for the suggestion. On point 1, the problem is that it woul introduce a dependency and I try to stick to vanilla emacs. At some point I played a bit with miniframe (still a ependency) and I may try again in the near future.

As for point 2, are you talking about the modeline or the headerline ? Because the modeline is rather small and unobstrusive moot of the time. Would you have a specific screenshot to show the problem?

[lduktus]

Thank you for your response. I guess I was not precise enough, I am sorry for that. Concerning point 2: I was talking about the headerline, I you wish I can provide some screenshots; I think the screenshots in the ispell issue (https://github.com/rougier/nano-emacs/issues/38) illustrate it quite well. At least imo the information provided by the headerline are not really relevant for the suggestions.

On point 1.: I don't wanted to suggest to add popwin as a dependency, as I really like the fact that you try to stick with vanilla emacs as much as possible. I just wanted to mention it as an example of a package that deals with the aspect of window placement. As far as I understand this project tries to streamline UX/UI aspects of emacs by providing some minimal defaults. I also read your paper about text editors. So my suggestion was that spawning windows in predictable and fixed areas of a frame would be quite helpful. However I don't know how doable and maintable this is or if it is better to use external packages or write your own functions. At least from what I read there are certain tradeoffs and hacks, due to the way how emacs deals with splits.

Imo the combination of both functionalities could help to create a more consistent style and workflow, e.g. spawn ispell choices always on the bottom without a headerline, etc.

[rougier]

Oh I got it now! So yes, we could get rid of the headline in some specific cases but one difficulty is to identify them. There is already one case for mu4e mail when you open an email, the two buffers are separated by "-----..."

[lduktus]

I didn't knew that mu4e has a different headerline. I only skimmed through nano-modeline.el and I am not sure if this can somehow be generalized? If I understood it properly mu4e provides a hook, which may not be true for every scenario. If I am right the only way would be to identify a given buffer by name? However most buffers for which such a behaviour would be desirable should have fixed names (e.g. ispell, reftex). I have to check if they provide some specific hooks. A more generic approach could maybe run a function on a standard hook. However I don't know if it is possible to define a function that sets the headerline or even disables it for just one buffer by a given name. From the standard hooks one candiate would be buffer-list-update-hook; however this could impact performance I guess. I will definetly try to read through some documentation when I have some time.

[rougier]

It is based on a hook when entering a specific mode:

(defun nano-modeline-mu4e-view-mode-p ()
  (derived-mode-p 'mu4e-view-mode))

(defun nano-modeline-mu4e-view-mode ()
  (let* ((msg     (mu4e-message-at-point))
         (subject (mu4e-message-field msg :subject))
         (from    (mu4e~headers-contact-str (mu4e-message-field msg :from)))
         (date     (mu4e-message-field msg :date)))
    (nano-modeline-compose (nano-modeline-status)
                           (s-truncate 40 subject "…")
                           ""
                           from)))

(add-hook 'mu4e-view-mode-hook
          (lambda () (setq header-line-format "%-")
            (face-remap-add-relative 'header-line
                                     '(:background "#ffffff"
                                       :underline nil
                                       :box nil
                                       :height 1.0))))

I could offer a list of buffers (or predicate) such that people can insert what they want.

[lduktus]

Thank you, some way of buffer-list may be helpful, however I am not sure if I understand how you want to implement it. My current and dirty modification is to just disable the header-line for some modes providing additional hooks:

;; define an empty header-line
(defun nano-empty-header-line ()
  "Sets an alternative header-line-format"
  (setq header-line-format ""))
(setq reftex-select-bib-mode-hook 'nano-empty-header-line)
(setq reftex-toc-mode-hook 'nano-empty-header-line)

I think a way to customize the header-line for certain modes would be nice. However with ispell I had no luck until now.

edit: format

[rougier]

For these two modes, we can merge them in the regular nano-modeline structure. I think there may be not too many mode where such empty header line make sense. By the way, for hthe hook, I think you may need to use relative face like in the code above.

[lduktus]

Thanks for your support, I am sorry for answering that late, currently I paused my switch to Emacs as it costed me to much time, which I can't afford right now. I will close the issue if you agree. You are absolutely right I don't think most people may have often the need for a completly empty header. As there are so much modes for Emacs I am not sure if it makes sense merging more modes into nano, maybe an easy acessible header function that could be hooked into any mode hook could the job?