From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexander Adolf Newsgroups: gmane.emacs.devel Subject: Re: A proposal for a friendlier Emacs Date: Tue, 29 Sep 2020 19:08:14 +0200 Message-ID: <0e3f9f50238be8a62b481f78c1d26c83@condition-alpha.com> References: <4be18b5f-dc07-2703-a2de-1ed08916ebdf@gmail.com> <1e340d941b6fd0b21a477f39fc935468@condition-alpha.com> <62ff80b8ff943b698ef8c46849b8bc50@condition-alpha.com> <83y2l0vas0.fsf@gnu.org> <83lfgyrn57.fsf@gnu.org> <83h7rlsxpw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17189"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: rms@gnu.org, Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 29 19:09:43 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 1kNJ8J-0004Mv-3A for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Sep 2020 19:09:43 +0200 Original-Received: from localhost ([::1]:53748 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kNJ8I-000412-5W for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Sep 2020 13:09:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42554) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kNJ7A-0002pk-Rk for emacs-devel@gnu.org; Tue, 29 Sep 2020 13:08:32 -0400 Original-Received: from smtprelay07.ispgateway.de ([134.119.228.97]:16917) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kNJ73-0001U6-NI; Tue, 29 Sep 2020 13:08:32 -0400 Original-Received: from [46.244.196.23] (helo=condition-alpha.com) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1kNJ4c-0005mB-SQ; Tue, 29 Sep 2020 19:05:54 +0200 In-Reply-To: X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=134.119.228.97; envelope-from=alexander.adolf@condition-alpha.com; helo=smtprelay07.ispgateway.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/29 13:08:22 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -24 X-Spam_score: -2.5 X-Spam_bar: -- X-Spam_report: (-2.5 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.614, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham 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:256723 Archived-At: --=-=-= Content-Type: text/plain Richard Stallman writes: > [...] > > Why does it matter whether we call it "category" or "tags". The > > important part is what the user thinks about a package. And a single > > package can satisfy several different needs. > > > So I think the idea of categorization that assumes a single category > > per package is basically unworkable, because it's too restrictive, and > > won't stand the test of time. > > I agree. > > In any case, the implementation of this doesn't need to make an assumption > about how many categorizations a package can have. > [...] It seems I was talking about possible technical solutions instead of semantics, which appears to have gotten us into confusion. My intent was to attach one new concept to any given package in the repository. This concept would define the "init configuration topic" of the package, so as to allow Custom code to auto-generate an init file for that topic, and collect the config for all packages of that topic in this init file. In this thread, Eli has suggested a second concept to be attached to a package, which is a (virtually) unbounded list of words and terms, which would be matched against search terms users employ to find a package for their needs. I would hence view these as two distinct concepts, serving distinct purposes. The "init configuration topic" concept is chiefly technical information to partition init code into smaller units. The "unbounded word list" concept is chiefly UX information as it is used to improve search results' relevance. Note that I have deliberately shied away from choosing any labels for either of the concepts, under which they would be used in a vocabulary or user interface (such as for instance "tag" or "category"). While I see Eli's suggestion as a worthwhile addition (as we appear to be debating the metadata data model of the package repository), my intent was to use the concept I described to enable a new approach to Custom handling init files. So I don't see the two concepts as mutually exclusive, competing, or otherwise in conflict. The could very nicely coexist, or be adopted independently of each other. Just let's not mix them up; that's all. Many thanks and looking forward to your thoughts, --alexander --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJYBAEBCABCFiEENzc6rodAL9+d3HXC7QG0ORS7zjkFAl9zaf4kHGFsZXhhbmRl ci5hZG9sZkBjb25kaXRpb24tYWxwaGEuY29tAAoJEO0BtDkUu845qFsP/32CriDO TNoQFf0mODMrxJggp4vLmxSGZk88xTKL7N7AT941IyRPlZny9DWlQyhW+WoE+WzR 8UtZAamN/sNCbU3/St2j6bBMLGXbV7nrEVTuTNoBZ2xaDXYZYgttB0QkEbndTjbz PKihG79z0G9f6ZxGH9JEB+U4r7EoYqZ8s8qlIWqBxmYTOPZkGUZEOc+Ho1/lKIHs s2H0p7F2ntS18A2+gVSAU7Sh9QLO68+O2k0ZGqkrv18IJB5XxpZGIKQQLKJ4UDOZ I3w1obWqIMILHJqksXYd+1tWLw3RYoxy+mt6vuaugbzbkvY5T2H0SgH3S7xSu/xV QP6Db5+QtdFuZ0q3hrRH23boiA/dHO3kF25LCbMHxe6UbQfnqvQHrdbkRHeg4qUR HU+2aw9JjLpAXToF9iWkeLsNWtWdTZmbswO7j5v7kRXbPXw02olxCrag2njTy4uk JJOy9kbQM4d8MJYNcqz518ni/4IXntFdgrsW83Ddpi/bU6q7GeJkGl4t4loDbK2n WwMnpNl1RGdujcvQo076u+2yuD6CK/4xW4FFpnlcQOBG2YuFD0e+LyOqxyHCJWNn TuhlzvARRzwWhjjNKF+qxMyZgHq47ov4HxJznAZtLUPjChvlQNqzsvlQIcj69Bxs iNx7ckUstStwlEizkATfrq409gjzeQu1C/3B =Tpyg -----END PGP SIGNATURE----- --=-=-=--