From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Corwin Brust Newsgroups: gmane.emacs.devel Subject: Re: Context menus and mouse-3 [was: Changes for emacs 28] Date: Tue, 15 Sep 2020 19:29:49 -0500 Message-ID: References: <87k0wwsrj4.fsf@gkayaalp.com> <87h7ryet7n.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40725"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, Richard Stallman , Juri Linkov , Gregory Heytings , Arthur Miller , Dmitry Gutov , =?UTF-8?B?R8O2a3R1xJ8gS2F5YWFscA==?= , Emacs developers , Drew Adams To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 16 02:32:00 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kILMe-000AQu-Cc for ged-emacs-devel@m.gmane-mx.org; Wed, 16 Sep 2020 02:32:00 +0200 Original-Received: from localhost ([::1]:53090 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kILMd-0003DP-6h for ged-emacs-devel@m.gmane-mx.org; Tue, 15 Sep 2020 20:31:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51796) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kILKp-0002Vs-Vj for emacs-devel@gnu.org; Tue, 15 Sep 2020 20:30:08 -0400 Original-Received: from mail-ej1-f67.google.com ([209.85.218.67]:37295) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kILKk-0007UK-F2; Tue, 15 Sep 2020 20:30:04 -0400 Original-Received: by mail-ej1-f67.google.com with SMTP id nw23so7816181ejb.4; Tue, 15 Sep 2020 17:30:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3hK+714ycqKjMKkSFTAgcfCkyEyV2FOLIqE4iWSBmaU=; b=cvTxT9/6bQJsEUh2+TfnmambYsgiQ0M+p/iTizoP2rsj3AzVKbA1QoMuufm512MhI8 BXc2gsEu1lwS3xMdgVE4LbOeapRgyosFdOP+W6zBETSLkhZBmQmmbDcd/AyPVA+hsPk4 3RwlTzBNcm83dsrGlTtu9l/Vsp/eNnza85wibJlxJ+1e6uZvnLDA9X7xxFunBJCXflEe QvcQ+gdNlXFOcWZsutGr+q9FdnXbJ7k1uKS685PteVaofks9ZnMybUwzFonKwWbBQqsU NnEcE8QgaWgjHy8jaddVjSr99sbmmTs3/alGCh+QCS2PrfFqF1fhYGFY2L3UYd8WscCm Bikw== X-Gm-Message-State: AOAM533abMCgc+jCEvqYqBPJPZdMYiA5NyliSkeAu0h7ZL6zunWMp/AY 0M/soK5PO1dh9IEjZXTl2M3Rnkep1jmAp3fN7eI= X-Google-Smtp-Source: ABdhPJwiofwXL1aBBfnroYvySGXxvfkkbmeV3DWXGyJUe/6NMQSzGG04EKgOakO+Z4ebQWe4mt5ibiQXIq0qrJfqz04= X-Received: by 2002:a05:6402:17fc:: with SMTP id t28mr25082370edy.244.1600216200427; Tue, 15 Sep 2020 17:30:00 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=209.85.218.67; envelope-from=mplscorwin@gmail.com; helo=mail-ej1-f67.google.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/15 20:30:00 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:255809 Archived-At: Hi. On Tue, Sep 15, 2020 at 6:06 PM Ergus via Emacs development discussions. wrote: > On September 15, 2020 10:33:51 PM GMT+02:00, Drew Adams wrote: > >> > read `Mouse Commands' if you haven't > >> > already, and give it a try. > >> > >> Mouse support is poor in Emacs, this is the reason > >> why I don't use the mouse in Emacs. > > > >I disagree that mouse support is poor in Emacs. > > > So you are the only one I know so far with that opinion. > > >I use a mouse in several other applications much > >of the workday, and Emacs mouse support is superior > >in every respect I'm aware of. But I'm no expert > >on the use of mice. And perhaps the mouse support > >in the apps I use is not a reference. > > > This is the same problem than undo-redo. Maybe the features are actually = better technically speaking or to whom knows all the tricks and trains hims= elf for years; but it worth nothing if the users feel uncomfortable or don'= t values some of the details that justify complexity in others. (Like hidin= g the context panel with a control or not having a redo button or not delet= ing the selection) Or just don't need them. Technically better is a pretty big deal. Especially when the specific technical advancement is massive-overkill levels of user-facing configuration and even more when the subject at hand is how best to get said technology to users. (And, to wit, those users' needs are varied so as to drive us to this type of sophistication/complexity.) > There are some "standards" in mouse interaction determined/imposed by mos= t of the gui programing interfaces from visual studio or java to qt5 and gt= k. The developers of all the aplications have been following them for years= and most of the user are used to them. This isn't really different from veteran coders who have troubled to become familiar with lots of Emacs bindings, or really any system expert. I acknowledge the utility of having Emacs' default bindings be simple and obvious to new users. I think that should be weighed carefully when pitted directly thoughtful existing practice/behaviours/defaults. Echoing what Drew said, above: What we already have may be superior to other more common practices. > So this is the "dilema". Or we change a bit (1 binding) to ease the user = experience and learning curve OR we expect that all the potential users cha= nge their expectations, trainings and don't go to any other editor but use = emacs because we pretend we offer a better functionality that they are not = aware of and most probably don't need or never learn/use because is complex= to remember. I think the "learning curve" is core to the value proposition of Emacs: if we invest the time, we are told, Emacs will overall reduce the efforts associated to our labors. There is a balance to be struck here: new users need to under enough of the machine to begin configuring it. Meanwhile, complexities hidden for ease of newcomers need to remain accessible to users who may be Emacs veterans but not elisp coders. Neither new nor old Emacs users will thank us for saving them a learning curve that costs efficiencies in our work-flows and I think most of us will learn (and relearn) as needed when the carrot is general efficiencies when writing, etc. I think it's the "trainings" you mention that are the biggest opportunity. > >> > Double-click (`mouse-1') on a word, then click > >> > `mouse-3' on another word. The selection picks up > >> > whole words, from the first through the last you > >> > clicked. > >> > >> In other apps, the same is achieved by double-click > >> (`mouse-1') on a word, then double-click the same > >> (`mouse-1') on another word while holding down the Shift key. > > > >And that's better why? Having to use both the > >keyboard and the mouse? > > > Usually the other hand is already in the keyboard and close to a shift. C= omparing, our approach of moving the mouse to the toolbar to copy after the= selection is probably less efficient than anything else or the fact that M= -w and C-y dont share any key like C-c/C-v or that we need the two hand to = undo instead of C-z. All these are less efficient too but we are used to th= em. I've been thinking about this. Those who play lots of computer games may know of an alternate position for the left hand (Ring finger slides left onto "A", pinky slides down over the "modern" location of Control, etc.) For those who know this position, our left-hands are pretty comfortable sliding around while we're mousing. It's almost another sort of touch-typing - I can stretch over and without looking hit the Eight key on the number-row with my left index finger pretty consistently. In any case, my point is that the diversity of use-cases continues to multiply however the value proposition Emacs is only strengthened: An editor I can configure, based on my own ever more unique behaviors, to access functionality representing decades of programers' workflows. > >> > Triple-click a line, then click `mouse-3' on > >> > another line. The selection picks up whole lines. > >> > >> In other apps, triple-click a line, then again triple-click > >> on another line while holding down the Shift key. > > > >Both keyboard and mouse again. Better? Not IMO. > > > But just the same button-1 so yes, probably simpler to remember and intui= tive for any office (or other modern editor) user. > Simple is better than complex. > Complex is better than complicated. I think I don't understand: I would say a simple solution I can remember beats a better solution I've forgotten because it is too unfamiliar or complex. But only until I understand how to get "on the fly help". The better solution is better for me given only that I understand and actually do use it. > The emacs approach with mouse is indeed complicated. Then it needs better training! A seperate tutorial? RMS mentioned a key-binding memorization game awhile back- maybe a "mouse-trainer" something like? In any case, thank you (all) for the work you are doing to help make Emacs more accessible to new users. I turn a lot of people on to Emacs and I'm looking forward to the help I expect this will be for them. > >We could provide a keyboard + mouse combination > >for such use cases if that were a common need. > > > >> Also in other apps Shift+F10 opens the context menu, > >> but why not in Emacs? > > > >That's orthogonal. Nothing prevents also having > >a keyboard key sequence to open a context menu. > >(Presumably the "location" it refers to would > >be point.) > > > There is the key which many applications use to show the panel fr= om keyboard too. There is also (right of the "right-Flag" key, for me). In OS context this opens a context window considering the active selection if any. According to ~~C-h k~~ it is unbound: | user-error: No command is bound to I think people come to Emacs expecting (bracing themselves) to learn. We need to do a better job of capitalizing on that by welcoming people with accessible bite-sized introductory material at least as much as we need to make the "factory defaults" for Emacs sufficient for people to make it though such materials. (I'm referencing on-going topics such as the first-run configuration wizard, minor-mode/theme, etc. discussed on other threads. Apart from the "mouse trainer" I not sure what else to suggest, specifically.) > >The impetus for this discussion was expectations > >of new users to get a context menu on `mouse-3'. > >(But newbies are not the only reason for such a > >feature.) > > > >> > [I'd like to see the double-clicking extended, so > >> > that if you double-click a paren in Lisp it picks > >> > up the full sexp, and if you then `mouse-3' another > >> > sexp it picks up full sexps in the interval. But > >> > this is a bit trickier.] > >> > >> It would be easier to use this as: double-click a paren to select > >> a sexp, then double-click another paren to select another sexp > >> while holding down the Shift key. > > > >Another keyboard + mouse mix. > > > >[What I described already works for simple cases, BTW. > >E.g. double-click a paren in Lisp (open or close), > >then `mouse-3' another paren, to select up the lists > >and intervening sexps.] The first message in this thread (Mouse Commands, plugging the manual, etc.) has meaningfully changed my workflow. In fact, I was playing with the feature described above last night. Double click the closing paren of a defun. Now Mouse-3 after the following defun. Finally, mouse-3 a second time in the same place (that is, right after the second defun). *Yoink* This seems great for refactoring, ie. making little ones out of big ones. Took me very little getting used to. > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > PS, can we rename "yank" to "yoink"? No? Okay. Regards, Corwin