]> git.eshelyaron.com Git - emacs.git/commitdiff
Comment
authorGerd Möllmann <gerd@gnu.org>
Mon, 21 Oct 2024 13:40:15 +0000 (15:40 +0200)
committerEshel Yaron <me@eshelyaron.com>
Mon, 23 Dec 2024 14:50:40 +0000 (15:50 +0100)
(cherry picked from commit 4a3ba42e6f86fa85b457bdeba9e08ccb4219107d)

src/frame.c

index 3634cea2bece5ea14d7d922c4175fdf3ea8351ca..49e86a577179537383227360af06b51afceb8b88 100644 (file)
@@ -1563,14 +1563,11 @@ affects all frames on the same terminal device.  */)
       if (CONSP (undecorated) && !NILP (XCDR (undecorated)))
        f->undecorated = true;
 
-      /* FIXME/tty: The only way to get borders on a tty is
-        to allow decorations for now. */
+      /* Unused at present. */
       Lisp_Object no_focus = Fassq (Qno_accept_focus, parms);
       if (CONSP (no_focus) && !NILP (XCDR (no_focus)))
        f->no_accept_focus = true;
 
-      /* FIXME/tty: The only way to get borders on a tty is
-        to allow decorations for now. */
       Lisp_Object no_split = Fassq (Qunsplittable, parms);
       if (CONSP (no_split) && !NILP (XCDR (no_split)))
        f->no_split = true;
@@ -1793,25 +1790,32 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor
      with your typing being interpreted in the new frame instead of
      the one you're actually typing in.  */
 
-  /* FIXME/tty: I don't understand this. Setting the last event
-     frame to nil leads to switch-frame events being generated even
-     if they normally wouldn't because the frame in question equals
-     selected-frame. This leads to problems at least on ttys.
-
-     Imagine that we have functions on post-command-hook that use
-     with-selected-window (which is the case with Vertico-Posframe),
-     Secondly, let these functions select/restore windows on different
-     frames, so there will be select-frame calls with different frames
-     during the execution of post-command-hook. Setting
-     internal_last_event_frame to nil makes these select-frame calls
-     potentially generate switch-frame events (but only in one direction
-     (frame_ancestor_p), which I also don't understand).
-
-     These switch-frame events form an endless loop in command_loop_1 by
-     running post-command-hook, which generates switch-frame events,
-     which command_loop_1 finds (bound to '#ignore) and executes, which
-     again runs post-command-hook etc. ad infinitum. */
+  /* FIXME/tty: I don't understand this. (The comment aove is from
+     Jim BLandy 1993 BTW.)
+
+     Setting the last event frame to nil leads to switch-frame events
+     being generated even if they normally wouldn't be because the frame
+     in question equals selected-frame. See the places in keyboard.c
+     where make_lispy_switch_frame is called.
+
+     This leads to problems at least on ttys.
+
+     Imagine that we have functions in post-command-hook that use
+     select-frame in some way (e.g. with-selected-window). Let these
+     functions select different frames during the execution of
+     post-command-hook in command_loop_1. Setting
+     internal_last_event_frame to nil here makes these select-frame
+     calls (potentially, and reality) generate switch-frame events. (But
+     only in one direction (frame_ancestor_p), which I also don't
+     understand).
+
+     These switch-frame events form an endless loop in
+     command_loop_1. It runs post-command-hook, which generates
+     switch-frame events, which command_loop_1 finds (bound to '#ignore)
+     and executes, which again runs post-command-hook etc. ad
+     infinitum.
 
+     Let's not do that for now on ttys. */
   if (!is_tty_frame (f))
     if (!frame_ancestor_p (f, sf))
       internal_last_event_frame = Qnil;