From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Amos Bird Newsgroups: gmane.emacs.help Subject: Re: How can I force updating mini window's header line when mode line is updated? Date: Fri, 27 Apr 2018 10:52:55 +0800 Message-ID: <87r2n1743c.fsf@gmail.com> References: <5AE17A16.7060906@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-Trace: blaine.gmane.org 1524797488 15415 195.159.176.226 (27 Apr 2018 02:51:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 27 Apr 2018 02:51:28 +0000 (UTC) User-Agent: mu4e 1.0-alpha3; emacs 27.0.50 Cc: help-gnu-emacs@gnu.org To: martin rudalics Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Apr 27 04:51:24 2018 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fBtTn-0003tB-RR for geh-help-gnu-emacs@m.gmane.org; Fri, 27 Apr 2018 04:51:23 +0200 Original-Received: from localhost ([::1]:45509 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fBtVt-0007dm-2J for geh-help-gnu-emacs@m.gmane.org; Thu, 26 Apr 2018 22:53:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fBtVT-0007dg-BP for help-gnu-emacs@gnu.org; Thu, 26 Apr 2018 22:53:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fBtVP-0003M9-D0 for help-gnu-emacs@gnu.org; Thu, 26 Apr 2018 22:53:07 -0400 Original-Received: from mail-pg0-x230.google.com ([2607:f8b0:400e:c05::230]:44185) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fBtVP-0003LZ-6U for help-gnu-emacs@gnu.org; Thu, 26 Apr 2018 22:53:03 -0400 Original-Received: by mail-pg0-x230.google.com with SMTP id 82-v6so385128pge.11 for ; Thu, 26 Apr 2018 19:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=hNLtQrK7TtxokzRjkdaquvbrgx/in4BPUM11dSuhvHI=; b=QzbH0dJwrOMIO0DgeCQy6X/Zgb02N9VzE3m/o+CBpM0/14w1263vjwpiGXfaDALuUJ n/jZRBzdYJ1J8ZjHdPpds1Sf33GnlbLfOdh3bq49KAQAxdkzC55s9h8yB2OM6o14UkOT ikzxPXawmTkxjXPorsdMpc1JeQzu2Aq6rIaPH3bflyPRM5vkcqHrHQZJgCpLBWb7jzqW /I8AhvwvluVCJe0tDLnLsHxA4tDHF/fxQZIy1Dwh+VhXKSzcp7dG8Jn2Exe0BI/zUUWm I6pKhXhy5LWpYGBkdiiiGkbWnbX5ibOY1KnABYrUyf6LgsMUUeEjm66DNNuj1QYBjuOE 6RQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=hNLtQrK7TtxokzRjkdaquvbrgx/in4BPUM11dSuhvHI=; b=niuonLjXpvncMMU1fUWlo/M8k0z2WPKckzC2nPPNdBK3drIDje11HZKH3MJIz/4wFb TozW6pUFqP8VP0C1VZGF4kCXUodan5kT6viaQYiVVShzv+PTQ2BeNBQ0mYeV/PqeOm4T 3KP6qQfheD6msbCTvWpyvARWrLKhL/K3DNokaSfVYeRsWWRvj2bD3DChIlC4EOrB+OLd Uf0kSdBys/b8qop+f8nRevMZTMi83FjgRt6Hn5anzO6LnIjEaeGNay44Mw/us3+0Lbx5 KGakIf6q+yH8tgNZCysLj7UOXRXaw8z4b41m/v52f1K1MeoNagzCqEdzct6p5HW8B+XG nbTg== X-Gm-Message-State: ALQs6tDvELil8DjkD7pXn+wHsBfdiVDR7fKQjSaLk0ouPKeuRbey16xS BaVH8axAXlE1/evco8ohhuLTSw== X-Google-Smtp-Source: AB8JxZrjI6LQ7Ghj0hVy8XU4kPgwgoKcyvEsaIr6d9qbGU+tHFQJX6smruxEN7h+e7dsTot/R7sLbg== X-Received: by 10.98.73.22 with SMTP id w22mr562244pfa.96.1524797581889; Thu, 26 Apr 2018 19:53:01 -0700 (PDT) Original-Received: from localhost ([168.235.105.19]) by smtp.gmail.com with ESMTPSA id 81sm336104pfl.92.2018.04.26.19.52.59 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 26 Apr 2018 19:53:00 -0700 (PDT) In-reply-to: <5AE17A16.7060906@gmx.at> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400e:c05::230 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:116604 Archived-At: Yeah, I think using mini window's header line is indeed a nasty idea, but it somehow fits my need (both in GUI and terminal emacs). I've hacked some xdisp code and it works now. https://github.com/amosbird/emacs/tree/onemodeline Here is what I've done. 1. turn on the head line of mini window by tweaking window_wants_header_line. 2. change a bunch of functions that initialize mini-window size to 2 instead of 1. 3. hide normal window's mode line if it's at bottom 4. always use inactive mode line format and empty string content for normal window (used to build horizontal divider in terminal) 5. refresh mini window's header line on every window's redisplay action. 6. make sure mode line format uses previous-window if mini window is selected It seems to cover all the corner cases I can reach in both GUI and terminal. (minibuffer resizing, frame/window switching, frame creation/deletion...) Here is a demo screencast in terminal emacs. https://youtu.be/OSv5JCIlPZA regards, martin rudalics writes: >> Emacs code has deep assumption of mini window having only one >> line. > > This is not entirely correct. As long as other windows on the > same > frame fit, a minibuffer window can get quite large (see > 'max-mini-window-height'). But in some parts of the window and > redisplay code we assume that minibuffer windows behave like > pseudo > windows (those used for displaying the tool bar or the menu bar > on > some platforms) or internal windows - they can't have dividers, > a mode > or a header line because these are simply not counted when > displaying > the window or calculating its height. That's why you observe > that > >> After I turn on the header line, things become messy. > > For example, 'window_wants_header_line' in window.c cannot deal > with > that. > >> I'll try >> collecting all the hard-coded logic and see if this route >> indeed >> works. > > Good idea. Note that I'm currently changing a number of things > related to minibuffer windows which, among others, should allow > them > to appear anywhere on a frame or even not being displayed at > all. So > I do not think that displaying the mode line of a frame within > the > minibuffer window is a good idea in the first place. Even > presently, > people who use standalone minibuffer frames might not be very > enthralled by the idea that they have to look on their > minibuffer > frame for consulting the mode line contents. > > I think that if we want frame-local modelines which, IIUC should > display the mode line contents of the frame's selected window, > it > might be a better idea to add a new kind of pseudo window on top > or > bottom of a frame for that. > > martin -- Amos Bird amosbird@gmail.com