GNU bug report logs - #25408
Remove Decorations Around Emacs Frame (Windows OS)

Previous Next

Package: emacs;

Reported by: Arthur Miller <arthur.miller.no1 <at> gmail.com>

Date: Mon, 9 Jan 2017 22:21:02 UTC

Severity: wishlist

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: arthur.miller.no1 <at> gmail.com, cpitclaudel <at> gmail.com, 25408 <at> debbugs.gnu.org
Subject: bug#25408: Remove Decorations Around Emacs Frame (Windows OS)
Date: Mon, 08 May 2017 08:48:12 +0200
> What happens when the line is full-width, i.e. the last character is
> flushed all the way to the right edge of the window?

Tested with normal continuation lines, truncated line and visual line
mode and all sorts of window widths.  No problems.

> What happens
> when you set wrap-prefix to some string value and then turn on
> visual-line-mode in a buffer with lines longer than the window width?

No special problems found but for one: If the window is narrower than
the wrap-prefix, Emacs may hang with all processor cycles it can get.
But this is easily reproducible here without setting the new parameter.

I use the following recipe: With emacs -Q I evaluate

(let ((frame (make-frame)))
  (find-file-noselect "dnd.el")
  (set-window-buffer (frame-root-window frame) "dnd.el")
  (with-current-buffer (window-buffer (frame-root-window frame))
    (setq wrap-prefix "-------------")
    (visual-line-mode 1)))

Then I make the new frame as narrow as possible by dragging one of its
borders with the mouse.  Now alternatively using (1) <down> to move the
cursor towards the end of the buffer _and_ (2) <wheel-down> to scroll
the buffer end out of view sooner or later hangs my Emacs 25.2 here.

>> Also, IIUC Clément has no intention to make such buffers scrollable,
>> editable or focusable.  So if necessary we can also forbid such actions.
>
> ??? This is a general-purpose feature, not something created for a
> single use case.  And I don't quite see how you can forbid cursor
> motion without also forbidding a lot of other useful features.

We could treat such frames like tooltip frames.  But I currently see no
need for such harsh measures.

martin





This bug report was last modified 7 years and 314 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.