From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 2C0XLg2RkmFf2AAAgWs5BA (envelope-from ) for ; Mon, 15 Nov 2021 17:55:41 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id yILHKQ2RkmG9KQAAB5/wlQ (envelope-from ) for ; Mon, 15 Nov 2021 16:55:41 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 67F41EA51 for ; Mon, 15 Nov 2021 17:55:41 +0100 (CET) Received: from localhost ([::1]:53632 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mmfGe-0000he-II for larch@yhetil.org; Mon, 15 Nov 2021 11:55:40 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58022) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mmfFV-0000at-6u for emacs-orgmode@gnu.org; Mon, 15 Nov 2021 11:54:29 -0500 Received: from ciao.gmane.io ([116.202.254.214]:56406) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mmfFT-0007U2-Rm for emacs-orgmode@gnu.org; Mon, 15 Nov 2021 11:54:28 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mmfFS-00067d-6W for emacs-orgmode@gnu.org; Mon, 15 Nov 2021 17:54:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: org-capture windows Date: Mon, 15 Nov 2021 23:54:18 +0700 Message-ID: References: <87a6ic5u1c.fsf@dumper.i-did-not-set--mail-host-address--so-tickle-me> <8735o4mhvd.fsf@localhost> <87ilwwvu1g.fsf@onenetbeyond.org> <87pmr3mfq3.fsf@localhost> <877ddaqr0e.fsf@onenetbeyond.org> <87fsrxeo6d.fsf@ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: <87fsrxeo6d.fsf@ucl.ac.uk> Content-Language: en-US Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1636995341; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=9cWnU8N5mXD4O4RWYSrb+Luo+VD6qfZq/QpeBXT5QaY=; b=bCRFVTsk0nS9N+PpHI88lqmBDqd8zW+P3qFP4UA0onxOr2RcMZvyb3tdDu+rGOHc3G++Pn 84fgZ3xXOq/EfOZSp9fiEhin9jZQhGcYqItXRp36qlcdOiPcDjCjibTl0Zowfq8iOw9fA8 U/4lHLtQpIE4CkaAdv47YpKCvlVmvd7nJUiwdocuDafeRKPScjy0sGwOqp2pNLhEMZEp+a 8LtMpcieTEU01ZlVTkHWyc6Wj2kEOmJQSJWbgh8lJz4vPwrN2PhWp4cZenyrutLbIFCeo+ o2Ob2utaZkgA64ekRCwBxGgSIjMGZruzzwB5UcaZGXIcQVCofjoQdXRWcRraNA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1636995341; a=rsa-sha256; cv=none; b=E72gpXVPlZMXouq2QzNsvc5JRzXkzSthaoExzvId0y9UI7fMvZRHx626tOLR8CsZFe6EsO Yvt/JLAVnMpo/7T+CrAlxZOscI7Y6jAcBmtvT3dAAbeTYylN58VJBg2B7GeiCAKqCM/r5N FUb1YtQTcHQuHH8Qetb+3z6l1aZJctnBHwBV1j4yXdTUkZqMnEsG65rtVuxVjjXxWS8YU0 svJrhJjwddSnwJ95BrkPnJLG3ri9ksnK2x2rFfkTds0RgngHTRVQAujvES4bbIFJE0IV1U VOCem2cNR8lu7f/cmbDG6aobX+WvvDxyAKVMOIodWIx3/xvzmKNkIevMr2l6FQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -2.34 Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 67F41EA51 X-Spam-Score: -2.34 X-Migadu-Scanner: scn0.migadu.com X-TUID: NP1TNVSEy00v On 15/11/2021 16:57, Eric S Fraga wrote: > > I agree completely. One of my bug-bears is org-capture which I often > use during meetings to take notes or create TODO items. Typically, the > org capture window covers my Teams buffer (I use exwm as my window > manager...) which is rather annoying. It seems, your workflow is inconsistent with original org-capture idea. It was created at the time when screens were smaller and video meetings were not usual activity. It is only my guess however. Some event requiring capture interrupts current activity. It should be postponed till capture completion, so all other windows are removed to not distract you. As soon as capture finished you can resume the earlier activity, so previous window layout and positions in buffers are restored. It is not bad approach per se but it is designed for frames with one or two buffers and incompatible with Emacs as window manager approach. I do not mind that such behavior should not be mandatory. I have another example when current behavior is confusing. Browser and an Emacs frame are placed side by side. A group of related pages should be captured. Initial buffer and position is arbitrary. During capture of first page I jump to particular heading to cross-reference new note with some older topic. It is necessary to add a bit more to the same topic for a next web page but on capture completion buffer position is reset to previous value despite I was going to continue capture process. Another problem is capture started through org-protocol without explicit template when template selection for previous capture was already active. Such kind of multi-tasking should not be a problem but it is since template key should be typed into minibuffer. I do not know what can be a proper solution. Maybe it can be a special mode with custom keymap for *Org Select* windows, so several such buffers may co-exist with no conflict due to minibuffer. > I did play with display-buffer-alist but it seemed to not be able to > take control of some of org's windows. Everything else I do in Emacs is > nicely managed through that alist. A couple of months ago `display-buffer-alist' was overridden by `org-no-popups'. Currently you can put "\\*Org Select\\*\\|CAPTURE-.*\.org" buffers to e.g. side window. Unfortunately other windows are still wiped till capture completion.