From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: bug#16026: Connection specific settings and proxies Date: Mon, 06 Feb 2017 10:22:21 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87k293ny36.fsf@flea> References: <86wqjnwa9u.fsf@somewhere.org> <871u1s38m3.fsf@flea.lifelogs.com> <877f5j2i67.fsf@gnus.org> <87a8a8paru.fsf@lifelogs.com> <87r33jnvn1.fsf@lifelogs.com> <87h94fqjq7.fsf@gmx.de> <87o9ykr6os.fsf@flea> <87mve3ffov.fsf__41803.1231420629$1486136780$gmane$org@gmx.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1486394564 9769 195.159.176.226 (6 Feb 2017 15:22:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Feb 2017 15:22:44 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: Lars Ingebrigtsen , 16026@debbugs.gnu.org, Stefan Monnier , Emacs developers To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 06 16:22:40 2017 Return-path: Envelope-to: ged-emacs-devel@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 1cal7n-0002Ly-IP for ged-emacs-devel@m.gmane.org; Mon, 06 Feb 2017 16:22:39 +0100 Original-Received: from localhost ([::1]:48998 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cal7t-0004Gz-6Q for ged-emacs-devel@m.gmane.org; Mon, 06 Feb 2017 10:22:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cal7c-0004A6-41 for emacs-devel@gnu.org; Mon, 06 Feb 2017 10:22:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cal7Y-0004pb-Tv for emacs-devel@gnu.org; Mon, 06 Feb 2017 10:22:28 -0500 Original-Received: from mail-qt0-x233.google.com ([2607:f8b0:400d:c0d::233]:35408) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cal7Y-0004pM-OB for emacs-devel@gnu.org; Mon, 06 Feb 2017 10:22:24 -0500 Original-Received: by mail-qt0-x233.google.com with SMTP id x49so107466708qtc.2 for ; Mon, 06 Feb 2017 07:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lifelogs.com; s=google; h=from:to:cc:subject:organization:references:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:user-agent :mime-version; bh=YjuDQYDc3GmNSgB0evkAnm5jaLHiA6w+hfrbLpMmUus=; b=QORghvZs+6C+Sp1oQuXIHAnYwRkwBfSEYwUQn/yCeaatfq18Z5pzdNEbog6cODJ14g hv8HxBh6Y/cHEUcL0og5bZVHcKtXQkItjeoS0jQFshc+C96Ug5xWCbej0q+lq7eYCSp+ 4rT2mMqA7IPvcfan8xCd3z/BkQcldChjJujA0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:organization:references :mail-copies-to:gmane-reply-to-list:date:in-reply-to:message-id :user-agent:mime-version; bh=YjuDQYDc3GmNSgB0evkAnm5jaLHiA6w+hfrbLpMmUus=; b=Y3FhKhOsDoL3NhvpF+Ofd1lwrYmNH+C9AbeM2QEw3BpWnhuBo4r9cDElleQmGQi6Np DuWEfAMt2ImqKGGjwe00UG47SKFMopEHGdRmQ8wkNTXZ672IB3Jja/ekAxQLyDMiXQ7l Hm9hVMfCdAtCyyO35/g6wNMZUhM4iOHfl+bp3zWR23U/u/4wri7hl5VTK+IEF1uOblL8 UmAZn+NK1ZGaeCwAC8Q7JMZ59pIdodAdXvYgGm1QSKheehGOwLTS8GXnqEKXwIvwgR2V e5U8GSe6641GluqhOUyQxzbhfqRQPxg+r8aM9qFMaBJxFVSgOgIsGfWb/ilmqI3tr8vi +TqQ== X-Gm-Message-State: AMke39nAHPDflMp+GhZZVf/v+4yYNXA5I7lr18bFXpfg3417MTjitoB5uxNF6Assl0xDnQ== X-Received: by 10.200.0.25 with SMTP id a25mr9724853qtg.191.1486394543840; Mon, 06 Feb 2017 07:22:23 -0800 (PST) Original-Received: from flea (c-98-229-60-157.hsd1.ma.comcast.net. [98.229.60.157]) by smtp.gmail.com with ESMTPSA id l53sm748246qtl.41.2017.02.06.07.22.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 06 Feb 2017 07:22:22 -0800 (PST) X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Gmane-Reply-To-List: yes In-Reply-To: <87mve3ffov.fsf__41803.1231420629$1486136780$gmane$org@gmx.de> (Michael Albinus's message of "Fri, 03 Feb 2017 16:37:52 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c0d::233 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:212033 Archived-At: On Fri, 03 Feb 2017 16:37:52 +0100 Michael Albinus wrote: MA> Ted Zlatanov writes: MA> Hi Ted, >> The way Michael set it up, you have connection profiles ("classes") that >> can be associated with any variables. (For passers-by, see >> `connection-local-set-class-variables', `connection-local-set-classes', >> and `with-connection-local-classes'). Profiles can be overlaid to >> augment each other. >> >> (Michael: maybe it's not too late to change "class" to "profile" >> because the former is so overloaded in our field?) MA> Well, I've stolen the "class" name from directory-local variables. The MA> concept of connection-local variables is closed to that of directory-local. MA> No problem to rename it, if it helps. And sometimes I'm even not sure MA> whether we need the class/profile concept; it might be even sufficient MA> to bind variables to connections directly, like variables can be bound MA> directly to buffers. I think from the user's side, it's necessary. We have to associate the data with a profile, which is then exposed as a configurable entity. Let's call them "connection profiles" to be very clear, since just "profile" can be ambiguous as well. >> I see. I think the classes should be associated with applications and >> protocols and login names, not just connections. Michael, what do you >> think? That would require changing the identification parameter to >> `connection-local-get-classes' to be an alist or a plist like >> :user U :application X :protocol Y :machine Z MA> Well, currently a class is bound to a connection via a regexp, which is MA> used for checking the result of `file-remote-p'. This is good for Tramp, MA> but it is less good for url-* functionality unless `url-handler-mode' is MA> enabled, and it does not work for other applications like imap-based MA> connections. MA> Your proposal looks OK to me. U, Y and Z shall be regexps, X a symbol MA> (or also a regexp?). All of them shall be optional. Wonderful. I propose that the application should be a defgroup symbol, and every connection profile should be required to have a defgroup. That would give us an implicit connection profile hierarchy and a place to hook connection profile customizations at the UI level. So defining connection profiles would be something like this: (add-connection-profiles :user U :defgroup X :protocol Y :machine Z :profile 'UXYZ :vars '(...)) (add-connection-profiles :profile 'general :vars '(...)) And then the application Gnus would do (note it's required that the defgroup 'gnus exists): (connection-profile-get-local-variables :defgroup 'gnus ...other criteria...) >From the user's side, they would say M-x customize-connection-profile UXYZ ; change criteria or settings M-x customize-connection-profile general ; change criteria or settings M-x create-connection-profile atwork ; specify desired settings M-x connection-profiles ; some kind of table/list UI Let me know what you think. Thanks Ted