From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#22923: [PATCH] Support completion of attribute values in CSS mode Date: Sun, 20 Mar 2016 03:17:12 +0200 Message-ID: References: <1457272432.10399.0@smtp.gmail.com> <1457550112.3805.2@smtp.gmail.com> <0400ddb1-6995-eb93-2dde-c7d5a5a992b0@yandex.ru> <1458391338.13455.0@smtp.gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1458436704 18239 80.91.229.3 (20 Mar 2016 01:18:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Mar 2016 01:18:24 +0000 (UTC) Cc: 22923@debbugs.gnu.org, Stefan Monnier To: Simen =?UTF-8?Q?Heggest=C3=B8yl?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 20 02:18:13 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ahS0R-0007wy-F1 for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Mar 2016 02:18:11 +0100 Original-Received: from localhost ([::1]:51129 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahS0Q-0000bI-J9 for geb-bug-gnu-emacs@m.gmane.org; Sat, 19 Mar 2016 21:18:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41288) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahS0M-0000bA-Gp for bug-gnu-emacs@gnu.org; Sat, 19 Mar 2016 21:18:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ahS0I-0003V2-GB for bug-gnu-emacs@gnu.org; Sat, 19 Mar 2016 21:18:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56904) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ahS0I-0003Uy-Bp for bug-gnu-emacs@gnu.org; Sat, 19 Mar 2016 21:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ahS0H-0001JS-Kv for bug-gnu-emacs@gnu.org; Sat, 19 Mar 2016 21:18:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Mar 2016 01:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22923 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 22923-submit@debbugs.gnu.org id=B22923.14584366414997 (code B ref 22923); Sun, 20 Mar 2016 01:18:01 +0000 Original-Received: (at 22923) by debbugs.gnu.org; 20 Mar 2016 01:17:21 +0000 Original-Received: from localhost ([127.0.0.1]:54031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ahRzd-0001IX-DM for submit@debbugs.gnu.org; Sat, 19 Mar 2016 21:17:21 -0400 Original-Received: from mail-wm0-f43.google.com ([74.125.82.43]:38527) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ahRzb-0001IK-P9 for 22923@debbugs.gnu.org; Sat, 19 Mar 2016 21:17:20 -0400 Original-Received: by mail-wm0-f43.google.com with SMTP id l68so82378179wml.1 for <22923@debbugs.gnu.org>; Sat, 19 Mar 2016 18:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=AhDzcqntYPhwucB8FcbCsZmgQLt+cZIOJEFpfK1wPkQ=; b=ta62uVLubxROMFX+9dF30hzVeowVR87K2ZcxjpGsl8BG4vGXp6D9f+vt+HsohSXSt3 vuo0HLljSfRKHUgq/hHHXCcSec1FBw5VB0xU52A2CKBVgtzoDgr9qe3zZ7CDFvkLDHuE FnsZFHI9klZCMzCfa7WxaNGwR1sDHQvdO3592WjbZqYksbDtceWytmL1kkEppEK2z1/D LSIVubBeLJopvf+H//625xTAJihYepz6SA9R5ERxra2jUbU7gF79/WY8gen17RnGUWQk lwYIF04M7J2wetj7UKDaGUX7Ekkuwji9pPehgXIqZ7i+dn2jqRcU2hU3jjrgQ3mKvsC9 8rbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=AhDzcqntYPhwucB8FcbCsZmgQLt+cZIOJEFpfK1wPkQ=; b=VEV8x/aCBZFBEonGHtfwvNsY1Kf6YHC45S+1lE6bkD43V5Q4LE6w6X9KEN9EAjh+/i C62ioe4bOvCgwn16wRr2lXbJOxQgDqFIqyihklJu3SpONLz0jxbPNlIDTftclJnb3/h4 IBFdYrUhgZsE9u62BC811u+ztUsoFDWxWRhy3FTax0XNyp4F0p5OOWNF8oIC+m1rlbFa NZBpYUfeckDzLh9Le3v2zkAvaxvu/sPGT7gzZx+hVxO8y/wmCaVYMCm9XH8q76CClE+t q3n3U3p3p1RgRTbx6A2cCGtv5fXm31Kc/xRnq5QZy2/W/NWtpdv8Kduk2E5Lk38gxdC2 hlWQ== X-Gm-Message-State: AD7BkJJpEk/pMCmgKK+O8bJvCjt/qnuluv9nMwzmO0iLrAeOaBN/f1ztQo21dcRyfIwcqw== X-Received: by 10.28.128.83 with SMTP id b80mr6476446wmd.6.1458436634268; Sat, 19 Mar 2016 18:17:14 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id c144sm5757171wmd.12.2016.03.19.18.17.13 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 Mar 2016 18:17:13 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <1458391338.13455.0@smtp.gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:115108 Archived-At: Hi again, Simen, On 03/19/2016 02:42 PM, Simen Heggestøyl wrote: > Yes, it allows us to stay close to the CSS spec, which is my view is > very valuable when maintaining these lists. Sure, but by "current approach" I meant what Company does. Please clarify: > Here is a concrete example: the value class `image' is defined as > follows in the CSS Image Values spec [1]: > > = | | | > > Which translates naturally to: > > ("image" uri image-list element-reference gradient) > > It is not a CSS property, so it should go into the value class alist. It > is referenced by the `border-image-source' property as well as the > `bg-image' value class (which in turn is referenced by the > `background-image' property and `bg-layer' value class). If you were adding it to company-css, wouldn't you just add it to company-css-value-classes? And then refer to it in background-image value inside company-css-property-alist? What the limitation of that approach? Do value classes in the spec refer back to the actual properties sometimes? > My point is that even though it would be possible to eliminate the need > for this value class by expanding it where it is referenced, I think > that by keeping it, it'll be much easier to make updates to it when the > CSS spec changes. I think it is worth the added complexity. I'm not sure I follow. Expanding it in company-css-property-alist?