From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: [RFC] Change visibility for bracket links Date: Thu, 13 Oct 2016 23:05:51 +0100 Message-ID: <871szjj45c.fsf@gmail.com> References: <87bmyyold3.fsf@nicolasgoaziou.fr> <65e1130f-ec6f-1409-e135-01acca1d1f53@grinta.net> <87r37lonua.fsf@nicolasgoaziou.fr> <6054e2d8-ce7b-de83-f35a-ba5103325d29@grinta.net> <87h98g5u67.fsf@nicolasgoaziou.fr> <87oa2oph5h.fsf@gmail.com> <878tts5svn.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buo8X-0002b7-8i for emacs-orgmode@gnu.org; Thu, 13 Oct 2016 18:06:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buo8R-00019E-6I for emacs-orgmode@gnu.org; Thu, 13 Oct 2016 18:06:00 -0400 Received: from mail-lf0-x22e.google.com ([2a00:1450:4010:c07::22e]:35441) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buo8Q-000197-Ti for emacs-orgmode@gnu.org; Thu, 13 Oct 2016 18:05:55 -0400 Received: by mail-lf0-x22e.google.com with SMTP id l131so117921361lfl.2 for ; Thu, 13 Oct 2016 15:05:54 -0700 (PDT) In-Reply-To: <878tts5svn.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Nicolas Goaziou Cc: emacs-orgmode@gnu.org Hi Nicolas, 2016ko urriak 13an, Nicolas Goaziou-ek idatzi zuen: > > Hello, > > Aaron Ecay writes: > >> FWIW, I agree. On the other hand, many people object to the brackets. > > I don't mind adding a variable. I think that org in general has too many customization variables. Of course, for each of them there is some user(s) who regard it as very important to their workflow. So, we should think hard before introducing new ones about whether there is a way to accomplish what we want which does not need a variable. (Of course, sometimes this goal is not possible and a new defcustom is needed.) [...] >> WDYT? > > That would only partly solve the problem. Cursor's color would tell you > where you are, but the dance (e.g., C-a or backward-forward) is still > needed to effectively move to the other side. Yes: the point will always be in only one of the two positions indicated in my previous mail. And some command(s) will always be needed to move between the two. AFAICT this remains true under any scenario: the status quo, the proposal for visible brackets, or the one for distinctive cursor color. The question as I understood it is finding a display mechanism that communicates the information about which of the two positions point is in when it is relevant, without being obtrusive during other editing. You also pointed out the importance of making the commands needed as obvious as possible. I think the bracket proposal satisfies the goal of perspicuous commands, but not of presenting the information only when relevant. Changing point color satisfies the presentation criteria, but the movement commands would not be very obvious. The suggestion of hiding and showing markers based on point motion, raised in another subthread, is interesting. It might be the best of both worlds. I would like to try out a POC implementation. (I believe I can predict the effect of either the brackets or the cursor colors on my editing experience, but not necessarily the other.) -- Aaron Ecay