From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id qMl2IZHdHGBacQAA0tVLHw (envelope-from ) for ; Fri, 05 Feb 2021 05:54:25 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id wG9JHZHdHGChbQAA1q6Kng (envelope-from ) for ; Fri, 05 Feb 2021 05:54:25 +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 D24A1940485 for ; Fri, 5 Feb 2021 05:54:24 +0000 (UTC) Received: from localhost ([::1]:41928 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7u4V-0003fW-KJ for larch@yhetil.org; Fri, 05 Feb 2021 00:54:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53376) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7u42-0003dG-B4 for emacs-orgmode@gnu.org; Fri, 05 Feb 2021 00:53:54 -0500 Received: from mail-pg1-x533.google.com ([2607:f8b0:4864:20::533]:37470) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l7u40-00051k-J4 for emacs-orgmode@gnu.org; Fri, 05 Feb 2021 00:53:54 -0500 Received: by mail-pg1-x533.google.com with SMTP id z21so3794013pgj.4 for ; Thu, 04 Feb 2021 21:53:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:subject:date:in-reply-to:message-id :mime-version; bh=zBSMnQfjQ/FH3NpypNiXP4+ZY5Ul8lHBpp2XX7qjzbI=; b=pxOVHH3O3on3xhW2vO9OyTW3ULnLfVXnTb1ks7F9ZUaWBRMTM8lMZyI6jNStzeFVrD Pgar4OTaE0IeF+WiJbz8jzkUDjNPSIQdF9a7PveJXyqedQhxRAL2MYBHOMEcPoW84uk4 aoXI/41X8BK0RBaWeO2hbUvODDhmO1ZslSAfHDWPq45S0JC+vW2iIVEC2iHu+imFpRrO iR6m9/F7RFmqFTuk0yQfnMiKbjGb2Kgvhe3wRxlVGDGn1SdmVFBSEoeClyh67QzsloMO 88R7PR2ZOkPGQHrq5as6RdUAdAz9qQ8q6aAs+Tcx1HPz9iLN8OrM+u+vHk1y/yXAkKSn 1MrQ== 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:subject:date :in-reply-to:message-id:mime-version; bh=zBSMnQfjQ/FH3NpypNiXP4+ZY5Ul8lHBpp2XX7qjzbI=; b=CuWUquJ/ZO0HJ89ctNEDM4dT349ew3DT0fHG47qiPTIBsnoURt18wj5e1/gXl/+hVQ gQzC844/k33WYJWiGqcEH2jpxg4szV2enUADu6yffKVXaoKGXdq219q9fZ63ooi/+5SG e+TOPTWw6u01dvlnTQe/nNIYG8Qn1wOWy98truXda61dz5z5YYNvTgSouMwv1F2P2EpN FrSpUmOxNlqE5AhUwo/JfJ8nRYhC6wft/vwz85OUAEJukQrafTobXN49JH4T3Kax0UZB RAnfs643Xs+MRVk4F747PVPDzdx9pDR/bnoboZZ+Bn0a0i3Diicldltqd8wt6otZdeDh fH+A== X-Gm-Message-State: AOAM533D/dxWvf/ylU0BwpkvZzL3lRMq8uwIU+O1pAs+R3pUajrV+ygb R4Z2NhXj1ojpE6Qrjoz6sMltL/DIpJw= X-Google-Smtp-Source: ABdhPJy5D/Nq25hgpRrb4ognlddm/CleTaFQnqnJJ4pdq9BlMROVUnwHK0FtNrgz9l35xGyN4bK+0w== X-Received: by 2002:a63:7f09:: with SMTP id a9mr2672978pgd.63.1612504430551; Thu, 04 Feb 2021 21:53:50 -0800 (PST) Received: from tim-desktop (220-235-12-101.dyn.iinet.net.au. [220.235.12.101]) by smtp.gmail.com with ESMTPSA id b6sm7403364pgt.69.2021.02.04.21.53.49 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Feb 2021 21:53:50 -0800 (PST) References: <87im7k51u0.fsf@ericabrahamsen.net> <875z39y8ua.fsf@kyleam.com> <871rdv6upl.fsf@ericabrahamsen.net> User-agent: mu4e 1.5.8; emacs 27.1.91 From: Tim Cross To: emacs-orgmode@gnu.org Subject: Re: Free up C-c SPC/org-table-blank-field? Date: Fri, 05 Feb 2021 16:32:21 +1100 In-reply-to: <871rdv6upl.fsf@ericabrahamsen.net> Message-ID: <87im77njpx.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::533; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x533.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 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-Spam-Score: -2.05 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=pxOVHH3O; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: D24A1940485 X-Spam-Score: -2.05 X-Migadu-Scanner: scn1.migadu.com X-TUID: kU6TNd7rlFPd Eric Abrahamsen writes: >> Does it actually need a key binding? I've never used it and just use >> to move to the next field, leaving the field blank. > > I assume it's meant for blanking a field you've already typed something > into. But yes, I can't imagine it's a heavily-used command, and I > suspect the C-c binding is mostly mnemonic: "make this field > contain only blanks". > I guess that makes sense, but not convinced the use of a valuable key binding is justified given the need. Then again, others probably have vastly different use cases to mine. >>>> >>>> What do people think about making it a no-op when not on a table >>>> (letting it fall through to the global map), or putting it in a keymap >>>> text property on tables, or otherwise not hogging the binding? >>> >>> In my view, the first would be fine, and the second also unless someone >>> chimes in with a technical reason not to. For the last, perhaps `C-c >>> C-SPC' would be an okay replacement, though I'd assume that would break >>> some users' muscle memory in a surprising and unpleasant way. >> >> I'm not familiar with how this is all put together inside org mode. >> If it is possible to configure things so that it is only bound when >> inside a table and does not shadow other bindings for that sequence >> outside a table, I think that would be a positive change. However, I do >> also note that this is the type of change which tends to cause 'ripples' >> and may have unexpected impact in other areas, such as other packages, >> predefined or 'canned' emacs configurations etc. > > The way Org handles these situations now is to have a command that is > named for its actual keybinding (eg `org-shiftmetaleft'), which then > examines its context and dispatches to various other functions. That's a > bit odd and not really how it's done in Emacs -- but I am not proposing > we change this as it is pretty fundamental to how Org is set up and > would wreck a bunch of stuff if it were changed. > > I thought Emacs might have some easy way to let a key event "fall > through" to other keymaps, but I haven't been able to find anything > immediately obvious. Maybe I can ask on emacs.devel... > I don't believe there is one. I think the basic model is a hierarchy of key maps with bindings and the first match wins. I guess the only option is to add a more sophisticated context test and only perform the action if the context is inside a table cell. If not inside a table cell, either perform some function which makes sense. It could be that on loading, org checks to see if there is a binding and stores that as the default action outside of tables or if we have some action which would make sense, bind to that or keep it simple and have it defined as a user option which defaults to a noop and allow the user to define something if they want? Since switching to spacemacs and its 'evil' key binding model, I've become very aware of the dangers associated with modes that try to be too clever when it comes to key bindings. I think they are really quite a personal thing and best kept as simple as possible. In general, org has been reasonably successful with its rather 'advanced' approach, but there have been times I've found it frustrating. Smart key bindings are great when they do what you expect, but when they don't.... -- Tim Cross