Received: (at 67246) by debbugs.gnu.org; 25 Nov 2023 09:22:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 25 04:22:58 2023 Received: from localhost ([127.0.0.1]:37798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r6osM-0000uU-IT for submit <at> debbugs.gnu.org; Sat, 25 Nov 2023 04:22:58 -0500 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]:60810) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <andreyorst@HIDDEN>) id 1r6osJ-0000uF-2R for 67246 <at> debbugs.gnu.org; Sat, 25 Nov 2023 04:22:57 -0500 Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a0b65cbf096so41288966b.1 for <67246 <at> debbugs.gnu.org>; Sat, 25 Nov 2023 01:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700904164; x=1701508964; darn=debbugs.gnu.org; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=VTP4YXOpD6QhX8mn2so/e28QLHiH1Y+WV83WRyjupfE=; b=Ds14QYyFhv/uyCsjdtq6oAP5uch2SD7VnNiKWMMnGF1dRVlu8I0dQrhyWRVihrMyuB Mwsspi5UMExvXfqBJELZcnwJntmWJgur3eQwtTdzzCDpzL886KtPqXTf7NcUlXVVQ1nY Vz6eYJ8XEjHvljqMSiQvWdo498kL7vFwiORt768q8XtONnX+t+AOR22+Dtk4iQqoI1ef 34YiB3soYJ6nl0IA1VC8FRoHZTIto06Cv1z/aEDobh+JVs90L6NE65DaTKkU9Gr10NB/ fHlyOdxgitOQeHV/iOpudYrlsILBUqazQ9wfaSk0QwOSXbyJ3hWsr4jJQ9kZdq4NUryL poFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700904164; x=1701508964; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VTP4YXOpD6QhX8mn2so/e28QLHiH1Y+WV83WRyjupfE=; b=Rycoc5x0ytX+Da7Jh1JIPCYF+uBqrjYtuDQi/el+SC7v7VcBYX7oakUGTYuyAkH7Is tPxbqkobB6X/MxglTFBau53x9EDcSS77aXrNl4/yC+Q3sSGI5yn0QPJF8U5C7PyxzZtk Wvj+sGalrjqIJWMZTBm6tX59DIrdw7w5qFA9O1QaXC//XA2VKrR/TcEIZlCus+Cj6aR2 ojJ8/iPSZYgv1GSbdziM+/c4NAMW18LD+1GfiEWTHOhZ35DjnJ3Ob3Nvu433xzPhBFRD 2sTZX48X38Cby2xkBDZOhOeN0vIUZRZkM6hwgmHKL5DRsLPV6AN7WuoJMOChK0VWIsjU odmw== X-Gm-Message-State: AOJu0YzhdRDlVnCmjekgx+qYXDQ5fLZnUQnh3nLKdARJ9rnfiO7d2KZj oAeGf0nqdGwhxSdL+GoMdV4SQgfPmuI= X-Google-Smtp-Source: AGHT+IE1gzPlJMZGizS5MR9bbxyLp2XDPR98OAz/vUDLjY146Md9RCfpLmVn0TJt+UZJ38Zj38F5/Q== X-Received: by 2002:a17:906:e99:b0:a04:b801:66f7 with SMTP id p25-20020a1709060e9900b00a04b80166f7mr4548892ejf.23.1700904163881; Sat, 25 Nov 2023 01:22:43 -0800 (PST) Received: from toolbox.smtp.gmail.com (broadband-46-242-11-135.ip.moscow.rt.ru. [46.242.11.135]) by smtp.gmail.com with ESMTPSA id t24-20020a17090616d800b009ffb4af0505sm3194818ejd.104.2023.11.25.01.22.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Nov 2023 01:22:43 -0800 (PST) References: <87y1ewgnn7.fsf@HIDDEN> <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN> <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN> <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN> <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN> <9ae8eb33-fd8b-f8d6-dd7f-79f8d4464a51@HIDDEN> User-agent: mu4e 1.8.11; emacs 30.0.50 From: Andrey Listopadov <andreyorst@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently Date: Sat, 25 Nov 2023 11:33:38 +0300 In-reply-to: <9ae8eb33-fd8b-f8d6-dd7f-79f8d4464a51@HIDDEN> Message-ID: <87a5r2p4pq.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67246 Cc: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>, 67246 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dmitry@HIDDEN> writes: > The idea was to balance the new look between the "old" major modes and > the newer, shinier ones. So that the overall style still somewhat > appeals to the existing audience, just with added features and more > precision. Here's a Reddit recent thread about the same sentiment: > https://www.reddit.com/r/emacs/comments/18152qo/overcolorization_everything_is_purple/ > It discusses a post written by Andrey, BTW. Yes, I published this post after submitting the bug in order to raise awareness among the community. > One could basically say that a function call and a properly lookup are > easy to distinguish from glancing at the text, there's not much need > to highlight them. As opposed to e.g. implicit variable declaration or > function declaration. Yeah, as I said in my post, highlighting important parts of the code, like macro calls, or dynamic/global variables tells you that you're looking at something more intricate, that is otherwise syntactically indistinguishable from regular code. > And here's another aspect: the default built-in theme doesn't > distinguish many of the faces (and the same is true for many other > built-in themes). E.g. it doesn't distinguish variable-name-face from > variable-use-face or function-name-face from function-call-face. I'm wondering if font-lock.el needs a bit more generic faces, as packages often define their own faces, that aren't supported by themes in any way. Again, the example with elixir-mode isn't to bash the developers, but before 2019 elixir-mode (not elixir-ts-mode) defined a few faces with explicit colors. Here's a commit that fixed that https://github.com/elixir-editors/emacs-elixir/commit/f101c676cc9485aa22ec088a71d8afc72cda3d58 but before it, `elixir-atom-face' and `elixir-attribute-face' were `RoyalBlue4' and `MediumPurple4' no matter what theme you were using. IIRC the CIDER package also defines some faces like that, so it's somewhat common. I can't come up with missing faces, and most modes I use define extra faces in terms of inheritance to the inbuilt faces, but maybe font-lock-symbol-face is worth including, as some languages may want to distinguish these like elixir does right now with `elixir-ts-atom-face'.
bug-gnu-emacs@HIDDEN:bug#67246; Package emacs.
Full text available.Received: (at 67246) by debbugs.gnu.org; 25 Nov 2023 00:22:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 24 19:22:05 2023 Received: from localhost ([127.0.0.1]:37508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r6gQs-0002vk-9z for submit <at> debbugs.gnu.org; Fri, 24 Nov 2023 19:22:05 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:54529) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1r6gQn-0002vA-Ez for 67246 <at> debbugs.gnu.org; Fri, 24 Nov 2023 19:22:01 -0500 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id 34B6D5C01D3; Fri, 24 Nov 2023 19:21:47 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 24 Nov 2023 19:21:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1700871707; x=1700958107; bh=nxqFvC02tr1mCCN0+sGv/ax81i/1f2oaPq8 HkgpxZlY=; b=jacrR18WAek2/qwqRgciF+YT1e6FkKTAGIPZLk356cYCnqBZxpx vQvdRfkRfs9b71xt8aOYsinRSPBCPUrG7ls54ytxxWs1y01wd0xpF5zziIupHI/P Tn55t2qLjTID1Bqgq4hIHS1qdAYs+n3KNy3iJueEABfV40nZ+6Jemy8pXnjAxCo6 wE9OKwA1y2nvH6zglJsqaxUMJHROnm8+0pfT1q5cWo/3bpTx8dXtS+qGREcDYADD wZojEZURECpoQzZUz/IXNA2OXe4c5+OUMMmmfxYgqcPk47lEXBPX8L6nl1lkDQp1 e5o4nTZCMDku/rT4h2FS7uy3+1TYu+266Og== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700871707; x=1700958107; bh=nxqFvC02tr1mCCN0+sGv/ax81i/1f2oaPq8 HkgpxZlY=; b=2KNzSsQHwnRj4CUAfowgNT/ZDL3bA/iUCF/OLsN8O6VMP72+VFK GTx4Hh21Yy924bn5gOKx3fJBKo/VXED/1xOq+dxwMP0itzM+jm4GSkUUZ5PMhrr9 wEpaM8xaUPMOF8Vu/5QaKKlGgKBdAcs3d+q5UBnGAPGnaaqVbvqNQieRUL9rMKSl 47KlY09WkVyKbZZE18E7qse47d7esEg19uUI0bwIcO5zZny5C/rkrk6yJ2gmafFK UXyU+Ht3LyXR4MwY7kSTGsR4swWWw/kHv/WyuEhJlrCJevRBvL6BQIsCNNZu2kzd JOCZihH2VIIFoGLv+s0C4CaMLlw3S2iTL/Q== X-ME-Sender: <xms:Gj5hZR1CCeFMIH8UpdGHH2qgRwPV3xG3e8hLV5WEwvA5j79tLBt3Xw> <xme:Gj5hZYFQCYP71G8Z5yLJ0Ozl9Ixdc9yMJ3uuT1R55fpifWtkdcfq0cor1Mmjk8BWu OeTIk53yvCE3eFVprg> X-ME-Received: <xmr:Gj5hZR6FlzV2NnW9z4jZBRpANN31zMmGQQU4Itr--GYT053QvWCs6e76LB2iMqUBgmzFFQ> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehiedgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepjeejhfehvddukedvjedtgfeiveevgeeghfetkeehkeelieefffffgfekgfdu tddvnecuffhomhgrihhnpehgihhthhhusgdrtghomhdprhgvugguihhtrdgtohhmnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhih sehguhhtohhvrdguvghv X-ME-Proxy: <xmx:Gj5hZe0NqPNEfJ6hlzG0sX9NZZNk7D5MzcAH5jdOOqqSu75LqHOVJg> <xmx:Gj5hZUGg0FNlSnDn51tc1vYkoeLQBiAwTyOWN7XBtwr4CzDIpB9_mA> <xmx:Gj5hZf89obqx6HEjMbxvYzi71gv_Mydt9NHi1utaCye3UFyLS52aTA> <xmx:Gz5hZeMJ6BoyVfrMCOhl-dOZi0eVcrQ_kVvvf-IHGSh_5Q95Kih6-Q> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 24 Nov 2023 19:21:45 -0500 (EST) Message-ID: <9ae8eb33-fd8b-f8d6-dd7f-79f8d4464a51@HIDDEN> Date: Sat, 25 Nov 2023 02:21:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently Content-Language: en-US To: Wilhelm Kirschbaum <wkirschbaum@HIDDEN> References: <87y1ewgnn7.fsf@HIDDEN> <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN> <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN> <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN> <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 67246 Cc: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.9 (---) On 24/11/2023 21:47, Wilhelm Kirschbaum wrote: > I see that the latest work > (https://github.com/wkirschbaum/elixir-ts-mode/pull/36 > <https://github.com/wkirschbaum/elixir-ts-mode/pull/36>) anticipated at > least some of my comments. > > Remainder: > > 1) font-lock-variable-name-face is intended for declarations and > perhaps > initial assignments (where it's also an implicit declaration), but for > other variable references it's better to use > font-lock-variable-use-face. With my test file, I see examples to the > contrary, even though some attempt to use the latter face had been made > (inside the 'elixir-function-call' feature's query). > > > Thanks, this has been fixed. Sorry, is there a specific commit in the upstream repo I could look at? > 2) Moving highlighting of function calls and variable (and/or property) > references to the 4th feature level. Looking at your font-lock > rules, it > seems like the elixir-function-call matches is more targeted than the > elixir-variable one, but still the other built-in modes put both at 4, > so it would be good for uniformity. Function definitions (and variable > definitions/declarations, if they're highlighted separately) can remain > in the 'declaration' or 'definition' feature which is put in a lower > feature level (e.g. ruby/js/typescript modes have it on level 1). > > > Level 4 is strange to me, because the default is 3. I read the docs and > tried to > follow it with the new changes, but was hesitant to remove much from the > highlighting as not many people might discover there is a 4th level. > Then again, if there is a query it > is pretty easy just to communicate this. The idea was to balance the new look between the "old" major modes and the newer, shinier ones. So that the overall style still somewhat appeals to the existing audience, just with added features and more precision. Here's a Reddit recent thread about the same sentiment: https://www.reddit.com/r/emacs/comments/18152qo/overcolorization_everything_is_purple/ It discusses a post written by Andrey, BTW. One could basically say that a function call and a properly lookup are easy to distinguish from glancing at the text, there's not much need to highlight them. As opposed to e.g. implicit variable declaration or function declaration. And here's another aspect: the default built-in theme doesn't distinguish many of the faces (and the same is true for many other built-in themes). E.g. it doesn't distinguish variable-name-face from variable-use-face or function-name-face from function-call-face. So if the -use- and -call- are used freely, in the default setup they will get muddled with the function and variable declaration. OTOH, if the user installs a theme which has this more advanced support for the new faces (or customize the faces manually to be distinct), they might as well set treesit-font-lock-level to 4, that's very little extra effort. > Something else I would recommend: > > 3) Removing the '-face' suffix from the face names. This is the best > practice across most modes, and it's something the manual entry for > 'defface' recommends: > > You should not quote the symbol face, and it should not end in > ‘-face’ (that would be redundant). > > Face names inside font-lock.el are a historical exception (and we > followed it when adding new faces recently), but if you search for > 'defface' inside the Emacs codebase, such names are in the minority. > > > Okay thanks, I had a look and it makes sense. I see a new mode with the > same -face suffixes. > The defface docs does not mention this, so might be a good idea to add > it there? Probably. I rarely read the manual myself, and this is useful information. > I am not entirely sure what "you should not quote the symbol face" means > wrt to the changes, because > it does not look like I am quoting it. Indeed you're not, I only put that in the quote so that the sentence is not cut off from the beginning. Sorry if that was confusing. > I haven't done too much testing myself. Perhaps Andrey will take the > upstream version for a spin. Or we'll wait for the changes to be merged > here and continue. >
bug-gnu-emacs@HIDDEN:bug#67246; Package emacs.
Full text available.Received: (at 67246) by debbugs.gnu.org; 24 Nov 2023 19:48:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 24 14:48:00 2023 Received: from localhost ([127.0.0.1]:37318 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r6c9f-0003Fn-Nb for submit <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:48:00 -0500 Received: from mail-qt1-x82f.google.com ([2607:f8b0:4864:20::82f]:44441) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <wkirschbaum@HIDDEN>) id 1r6c9a-0003Ee-3v for 67246 <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:47:58 -0500 Received: by mail-qt1-x82f.google.com with SMTP id d75a77b69052e-41cd4cc515fso11839291cf.1 for <67246 <at> debbugs.gnu.org>; Fri, 24 Nov 2023 11:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700855264; x=1701460064; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=O+l4IrU5iMU3dqz73/u7FugvVULv8gX04lMRTXL8R4o=; b=FrlabXhlPLjuCt1j+BYkNdSTPFGB9q6HwpNivRgzIdNVhHDDs0fx/egMy2RIFfRRh7 SJZIybLgDvLSjfobaC10WSE7FzVWCQGa/ktFAj4El8R60x8VBuRF/+fnprLuHL5wrHHS kZTOhKV7avnLfqUiCvDy4hzy0mJPxIBdLcSfumnhfZDYE7Phu3yLLeIGhCEFdmrGLq0s dqLnMeAifzTVOJ3r9Izp/lhJhvrjpL9NtJm86TJA5OXbHnN5m/SxCwufave/YC5mI9W3 KBVOMkEiwHDpr+dpo0ZzDt1ZZ8lm2IZ5R65P+gXO1jjZXl5iJessksKGh78nhYrvznW5 F7ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700855264; x=1701460064; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=O+l4IrU5iMU3dqz73/u7FugvVULv8gX04lMRTXL8R4o=; b=g2e5AtAVNoRvsaxKebVlkFUtwgdgDamFCWMHa3hmL7Cgj7pwk8QAUWIaMrZXkRiGMz 3uoF1p1f0Vu2pP68qJ7qYZ1Kz6Tkxn4nDVevhzuI4rHN7FbKSDxt+nUMbzJ2q84Zil5s /BhitLsMoMIq9/lW1lbSvF11hK/g+mpNouiAhOyx9ZE6No2Ns8hQavZDcQpWqMNeH5+b Ha/K/BSE1jh73xge00PMKzhO2u8tkxUr7qwuGfDqCjWQHiSi27YCKnTM3XwZWLviSDnl 5eOc6OHVtPgQ8KqGqcn6xg6gNHUw+aWV7HXOGspgUMtS0naFGwSeiKjKtFPcK8/2vQU8 vmAQ== X-Gm-Message-State: AOJu0Yxil4d9ixeYmtBZsyD+X5mOIMA0qETeHXUMzrxFIvJQ6tzCIAga ViIcLJ5Ew50qnevsLaBkiROPVS35cicyC9O5cEQ= X-Google-Smtp-Source: AGHT+IHYGMlzbQTn0uSlzmla/Qi+5uNr7E+xPlvp+yueiTigMqfCX0JgrmZiTCaJ8zEyJlPF/0HdzX07tfDGACr8ig8= X-Received: by 2002:a05:622a:a13:b0:423:98be:e73e with SMTP id bv19-20020a05622a0a1300b0042398bee73emr4592630qtb.66.1700855263713; Fri, 24 Nov 2023 11:47:43 -0800 (PST) MIME-Version: 1.0 References: <87y1ewgnn7.fsf@HIDDEN> <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN> <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN> <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN> In-Reply-To: <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN> From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN> Date: Fri, 24 Nov 2023 21:47:32 +0200 Message-ID: <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN> Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000cee100060aeb39bc" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67246 Cc: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000cee100060aeb39bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 20, 2023 at 3:50=E2=80=AFAM Dmitry Gutov <dmitry@HIDDEN> wro= te: > On 18/11/2023 09:50, Wilhelm Kirschbaum wrote: > > > > On Sat, Nov 18, 2023 at 3:36=E2=80=AFAM Dmitry Gutov <dmitry@HIDDEN > > <mailto:dmitry@HIDDEN>> wrote: > > > > On 17/11/2023 21:50, Andrey Listopadov wrote: > > > > > > I've upgraded from elixir-mode to elixir-ts-mode and noticed tha= t > the > > > latter uses faces rather inconsistently. > > > > > > For example, the =3Dfont-lock-keyword-face=3D is used for both > > keywords and > > > method calls, as well as for parentheses. The > > > =3Dfont-lock-function-name-face=3D is used both for function > definitions, > > > parameter names, and calls. Some calls use the > > > =3Dfont-lock-keyword-face=3D, for example the call to `raise'. = The > > > =3Dfont-lock-type-face=3D is used both for types and =3D:symbols= =3D. > > > > > > All of that basically makes Elixir code mostly use 2 colors. > > > Additionally, it makes impossible selectively disabling > > highlighting, as > > > disabling the function call highlighting will disable the functi= on > > > definition highlighitng an so on. > > > > > > I believe, Emacs 29 introduced a lot of faces for all kinds of > > > situations possible in Tree-sitter generated AST, so perhaps the > > fix is > > > to use them more semantically, rather than for good looks. > > > > Thanks for the report. Wilhelm, could you look into this? If you > > have time. > > > > Speaking of new faces, we added font-lock-function-call-face that > > can be > > used for function calls, while font-lock-function-name-face stays > used > > on definitions. > > > > For parens, if one wanted to highlight them at all, > > font-lock-bracket-face could be used. Though it's probably better t= o > > leave them to the 4th feature level (see js-ts-mode as an example). > > elixir-ts-mode currently defines 3 levels. > > > > For levels, we've currently settled on the scheme that function cal= ls > > and property lookups go to the 4th level of highlighting, whereas t= he > > default is 3. This is all tweakable by the individual user, but I > think > > it's better to stay consistent between the modes. > > > > Finally, I see that font-lock-function-name-face ends up being used > for > > parameters (as Andrey mentioned) and local variables as well. That'= s > > not > > great; probably a query that ended up matching too widely. We prefe= r > to > > use font-lock-variable-name-face (for parameter declarations) or > > font-lock-variable-use-face for such identifiers. Though it can be > hard > > to reliably distinguish them in a dynamic language, so as far as I'= m > > concerned, they could stay non-highlighted (the uses, that is; the > > declarations are usually easy to find using queries). > > > > > > Thanks for the detailed explanation. It's unfortunate timing, because I > > published a rework of the faces on MELPA so long and a few people are > > trying it out. It is a total rework using the faces a bit better. I ca= n > > submit the patch later today and start the conversation from there? > > I guess I expected that if the mode has been added to the core then the > development is led here too. And modes maintained externally live more > easily in ELPA. Anyway, we are where we are. > > I see that the latest work > (https://github.com/wkirschbaum/elixir-ts-mode/pull/36) anticipated at > least some of my comments. > > Remainder: > > 1) font-lock-variable-name-face is intended for declarations and perhaps > initial assignments (where it's also an implicit declaration), but for > other variable references it's better to use > font-lock-variable-use-face. With my test file, I see examples to the > contrary, even though some attempt to use the latter face had been made > (inside the 'elixir-function-call' feature's query). > Thanks, this has been fixed. > > 2) Moving highlighting of function calls and variable (and/or property) > references to the 4th feature level. Looking at your font-lock rules, it > seems like the elixir-function-call matches is more targeted than the > elixir-variable one, but still the other built-in modes put both at 4, > so it would be good for uniformity. Function definitions (and variable > definitions/declarations, if they're highlighted separately) can remain > in the 'declaration' or 'definition' feature which is put in a lower > feature level (e.g. ruby/js/typescript modes have it on level 1). > Level 4 is strange to me, because the default is 3. I read the docs and tried to follow it with the new changes, but was hesitant to remove much from the highlighting as not many people might discover there is a 4th level. Then again, if there is a query it is pretty easy just to communicate this. > > Something else I would recommend: > > 3) Removing the '-face' suffix from the face names. This is the best > practice across most modes, and it's something the manual entry for > 'defface' recommends: > > You should not quote the symbol face, and it should not end in > =E2=80=98-face=E2=80=99 (that would be redundant). > > Face names inside font-lock.el are a historical exception (and we > followed it when adding new faces recently), but if you search for > 'defface' inside the Emacs codebase, such names are in the minority. > Okay thanks, I had a look and it makes sense. I see a new mode with the same -face suffixes. The defface docs does not mention this, so might be a good idea to add it there? I am not entirely sure what "you should not quote the symbol face" means wrt to the changes, because it does not look like I am quoting it. > > I haven't done too much testing myself. Perhaps Andrey will take the > upstream version for a spin. Or we'll wait for the changes to be merged > here and continue. > --000000000000cee100060aeb39bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Mon, Nov 20, 2023 at 3:50=E2=80=AF= AM Dmitry Gutov <<a href=3D"mailto:dmitry@HIDDEN">dmitry@HIDDEN</a= >> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px= 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On = 18/11/2023 09:50, Wilhelm Kirschbaum wrote:<br> > <br> > On Sat, Nov 18, 2023 at 3:36=E2=80=AFAM Dmitry Gutov <<a href=3D"ma= ilto:dmitry@HIDDEN" target=3D"_blank">dmitry@HIDDEN</a> <br> > <mailto:<a href=3D"mailto:dmitry@HIDDEN" target=3D"_blank">dmitr= y@HIDDEN</a>>> wrote:<br> > <br> >=C2=A0 =C2=A0 =C2=A0On 17/11/2023 21:50, Andrey Listopadov wrote:<br> >=C2=A0 =C2=A0 =C2=A0 ><br> >=C2=A0 =C2=A0 =C2=A0 > I've upgraded from elixir-mode to elixir-= ts-mode and noticed that the<br> >=C2=A0 =C2=A0 =C2=A0 > latter uses faces rather inconsistently.<br> >=C2=A0 =C2=A0 =C2=A0 ><br> >=C2=A0 =C2=A0 =C2=A0 > For example, the =3Dfont-lock-keyword-face=3D= is used for both<br> >=C2=A0 =C2=A0 =C2=A0keywords and<br> >=C2=A0 =C2=A0 =C2=A0 > method calls, as well as for parentheses.=C2= =A0 The<br> >=C2=A0 =C2=A0 =C2=A0 > =3Dfont-lock-function-name-face=3D is used bo= th for function definitions,<br> >=C2=A0 =C2=A0 =C2=A0 > parameter names, and calls.=C2=A0 Some calls = use the<br> >=C2=A0 =C2=A0 =C2=A0 > =3Dfont-lock-keyword-face=3D, for example the= call to `raise'.=C2=A0 The<br> >=C2=A0 =C2=A0 =C2=A0 > =3Dfont-lock-type-face=3D is used both for ty= pes and =3D:symbols=3D.<br> >=C2=A0 =C2=A0 =C2=A0 ><br> >=C2=A0 =C2=A0 =C2=A0 > All of that basically makes Elixir code mostl= y use 2 colors.<br> >=C2=A0 =C2=A0 =C2=A0 > Additionally, it makes impossible selectively= disabling<br> >=C2=A0 =C2=A0 =C2=A0highlighting, as<br> >=C2=A0 =C2=A0 =C2=A0 > disabling the function call highlighting will= disable the function<br> >=C2=A0 =C2=A0 =C2=A0 > definition highlighitng an so on.<br> >=C2=A0 =C2=A0 =C2=A0 ><br> >=C2=A0 =C2=A0 =C2=A0 > I believe, Emacs 29 introduced a lot of faces= for all kinds of<br> >=C2=A0 =C2=A0 =C2=A0 > situations possible in Tree-sitter generated = AST, so perhaps the<br> >=C2=A0 =C2=A0 =C2=A0fix is<br> >=C2=A0 =C2=A0 =C2=A0 > to use them more semantically, rather than fo= r good looks.<br> > <br> >=C2=A0 =C2=A0 =C2=A0Thanks for the report. Wilhelm, could you look into= this? If you<br> >=C2=A0 =C2=A0 =C2=A0have time.<br> > <br> >=C2=A0 =C2=A0 =C2=A0Speaking of new faces, we added font-lock-function-= call-face that<br> >=C2=A0 =C2=A0 =C2=A0can be<br> >=C2=A0 =C2=A0 =C2=A0used for function calls, while font-lock-function-n= ame-face stays used<br> >=C2=A0 =C2=A0 =C2=A0on definitions.<br> > <br> >=C2=A0 =C2=A0 =C2=A0For parens, if one wanted to highlight them at all,= <br> >=C2=A0 =C2=A0 =C2=A0font-lock-bracket-face could be used. Though it'= ;s probably better to<br> >=C2=A0 =C2=A0 =C2=A0leave them to the 4th feature level (see js-ts-mode= as an example).<br> >=C2=A0 =C2=A0 =C2=A0elixir-ts-mode currently defines 3 levels.<br> > <br> >=C2=A0 =C2=A0 =C2=A0For levels, we've currently settled on the sche= me that function calls<br> >=C2=A0 =C2=A0 =C2=A0and property lookups go to the 4th level of highlig= hting, whereas the<br> >=C2=A0 =C2=A0 =C2=A0default is 3. This is all tweakable by the individu= al user, but I think<br> >=C2=A0 =C2=A0 =C2=A0it's better to stay consistent between the mode= s.<br> > <br> >=C2=A0 =C2=A0 =C2=A0Finally, I see that font-lock-function-name-face en= ds up being used for<br> >=C2=A0 =C2=A0 =C2=A0parameters (as Andrey mentioned) and local variable= s as well. That's<br> >=C2=A0 =C2=A0 =C2=A0not<br> >=C2=A0 =C2=A0 =C2=A0great; probably a query that ended up matching too = widely. We prefer to<br> >=C2=A0 =C2=A0 =C2=A0use font-lock-variable-name-face (for parameter dec= larations) or<br> >=C2=A0 =C2=A0 =C2=A0font-lock-variable-use-face for such identifiers. T= hough it can be hard<br> >=C2=A0 =C2=A0 =C2=A0to reliably distinguish them in a dynamic language,= so as far as I'm<br> >=C2=A0 =C2=A0 =C2=A0concerned, they could stay non-highlighted (the use= s, that is; the<br> >=C2=A0 =C2=A0 =C2=A0declarations are usually easy to find using queries= ).<br> > <br> > <br> > Thanks for the detailed explanation. It's unfortunate timing, beca= use I <br> > published a rework of the faces on MELPA so long and a few people are = <br> > trying it out. It is a total rework using the faces a bit better.=C2= =A0 I can <br> > submit the patch later today and start the conversation from there?<br= > <br> I guess I expected that if the mode has been added to the core then the <br= > development is led here too. And modes maintained externally live more <br> easily in ELPA. Anyway, we are where we are.<br> <br> I see that the latest work <br> (<a href=3D"https://github.com/wkirschbaum/elixir-ts-mode/pull/36" rel=3D"n= oreferrer" target=3D"_blank">https://github.com/wkirschbaum/elixir-ts-mode/= pull/36</a>) anticipated at <br> least some of my comments.<br> <br> Remainder:<br> <br> 1) font-lock-variable-name-face is intended for declarations and perhaps <b= r> initial assignments (where it's also an implicit declaration), but for = <br> other variable references it's better to use <br> font-lock-variable-use-face. With my test file, I see examples to the <br> contrary, even though some attempt to use the latter face had been made <br= > (inside the 'elixir-function-call' feature's query).<br></block= quote><div><br></div><div>Thanks, this has been fixed. <br></div><div>=C2= =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= x;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> 2) Moving highlighting of function calls and variable (and/or property) <br= > references to the 4th feature level. Looking at your font-lock rules, it <b= r> seems like the elixir-function-call matches is more targeted than the <br> elixir-variable one, but still the other built-in modes put both at 4, <br> so it would be good for uniformity. Function definitions (and variable <br> definitions/declarations, if they're highlighted separately) can remain= <br> in the 'declaration' or 'definition' feature which is put i= n a lower <br> feature level (e.g. ruby/js/typescript modes have it on level 1).<br></bloc= kquote><div><br></div><div>Level 4 is strange to me, because the default is= 3.=C2=A0 I read the docs and tried to=C2=A0</div><div>follow it with the n= ew changes, but was hesitant to remove much from the=C2=A0</div><div>highli= ghting as not many people might discover there is a 4th level.=C2=A0 Then a= gain, if there is a query it</div><div>is pretty easy just to communicate t= his.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m= argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left= :1ex"> <br> Something else I would recommend:<br> <br> 3) Removing the '-face' suffix from the face names. This is the bes= t <br> practice across most modes, and it's something the manual entry for <br= > 'defface' recommends:<br> <br> =C2=A0 =C2=A0You should not quote the symbol face, and it should not end in= <br> =E2=80=98-face=E2=80=99 (that would be redundant).<br> <br> Face names inside font-lock.el are a historical exception (and we <br> followed it when adding new faces recently), but if you search for <br> 'defface' inside the Emacs codebase, such names are in the minority= .<br></blockquote><div><br></div><div>Okay thanks, I had a look and it make= s sense.=C2=A0 I see a new mode with the same -face suffixes.=C2=A0 <br></d= iv><div>The defface docs does not mention this, so might be a good idea to = add it there?=C2=A0=C2=A0</div><div>I am not entirely sure what "you s= hould not quote the symbol face" means wrt to the changes, because=C2= =A0</div><div>it does not look like I am quoting it. <br></div><div>=C2=A0<= /div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= rder-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> I haven't done too much testing myself. Perhaps Andrey will take the <b= r> upstream version for a spin. Or we'll wait for the changes to be merged= <br> here and continue.<br> </blockquote></div></div> --000000000000cee100060aeb39bc--
bug-gnu-emacs@HIDDEN:bug#67246; Package emacs.
Full text available.Received: (at 67246) by debbugs.gnu.org; 24 Nov 2023 19:30:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 24 14:30:34 2023 Received: from localhost ([127.0.0.1]:37314 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r6bsn-0002mS-R0 for submit <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:30:34 -0500 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:34663) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1r6bsl-0002mB-4M for 67246 <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:30:32 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 3B45A3200A76; Fri, 24 Nov 2023 14:30:20 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 24 Nov 2023 14:30:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1700854219; x=1700940619; bh=uHK+dz7f9R4cdAJhZrP6FCJpJ1/5dTbWXZ2 w0mSemmU=; b=neaG+KFJieYvMydmBouZww1YUO1p6EFzpksz/YgIWIQwswLRAmq 4xnHiyTpR3BdfSlLX9ToRNlz0CgrVjxGpeTWhSgj7QPcO7y96M0OwKNBDNbY5JTc erU+BIIPIJ3teQjw4BYWOAd7cfBRkv9ju6254D+Y1afLM11aYsw0eCcZxA26CE5/ CYCGW2b2PKqv4L2inQYJ4fpnQ5kDSL2ac8eRNHK0duYkVHZTnPCMwuc/bTWAlHFR 5iKCV4i2qQEwZYWBV6Folhhxq7hEnAgqyG1JklHhFym65dDa87nSd/wfTucSsETw mW8sJPuZYch9QKSgwvqYlzgIhh7z5tKaXDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700854219; x=1700940619; bh=uHK+dz7f9R4cdAJhZrP6FCJpJ1/5dTbWXZ2 w0mSemmU=; b=RMxzlu5ZAp8H8pyDBPsrkvcVym4kcM1F63+Zl2rHBVO+51d/xuB OyX43CUA1eeIAcRixWY81OtNM4YiaCcXQwaReCHUQ7g7D9BBm0gQ8vOuWD+xdEJ5 YGfethauqTFx0FxPeCT+Pzle6Z8Uuz8ukoooxEVwBseiAkeW0ObqN/BC3Foxchay M0JO3msvTQczGEleOxhJTaS42WGNgJObpoklLev74l+lE/RreD0y/Kr4g21O49Xi lc9MtTsl2O4f09+DdWf+NODAqWZwkDaB9hti9AH1aJscta2kLeDVg53DFqM0Oxd6 eT8balIe3j/lSstnAjEQDvnJ3BUIfZVCJfg== X-ME-Sender: <xms:y_lgZeWw8XUMPqj6KpQQKG1hpb-1FVOLS8mPJWTWKeKurC_R0iKzJw> <xme:y_lgZakr6E2aa_rsZrVHon3G80kXPKnIYcXrZ9vvxWcVEJZxQ702EvCd7b6E1cONw hKYnsLfJJ8czL81KCE> X-ME-Received: <xmr:y_lgZSbFQIhy1rY3Ksym8W3FtesX0lAvslrX_LlaPTa0p1hECButiV_ViaijWYeQG4FpFA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehhedguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffg feejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: <xmx:y_lgZVWBnyx2ILZizIjSzYxI53eDai-lmtvXXjjFmuUvAg3O2iDbZA> <xmx:y_lgZYkzvHpNULDqr0N2gh3Jxk-4zT55KprSBIPlmWDLZYSZFgMYmA> <xmx:y_lgZaejoSkEP_5ZYIj5RmkRlMTcqw2FWIV2HyTQwBzuyfKsS09ZUA> <xmx:y_lgZUuCg2k5NBeBQ5uyYHElK-_7KLDXZNs-g9m0EzcMW5lO18oRwg> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 24 Nov 2023 14:30:18 -0500 (EST) Message-ID: <cef11c60-03b1-3a67-2f9d-40839eb132be@HIDDEN> Date: Fri, 24 Nov 2023 21:30:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently Content-Language: en-US To: Wilhelm Kirschbaum <wkirschbaum@HIDDEN> References: <87y1ewgnn7.fsf@HIDDEN> <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN> <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN> <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN> <4f4e3d4c-e162-4007-a9b5-8210ea2f044b@HIDDEN> <CAOS0-359BvdqEWa0iJC3t0EELr=io-Vk8EFkhvKZGu6+HeCkaQ@HIDDEN> <62c76a1f-586a-751c-0565-baa11ca8a2ae@HIDDEN> <CAOS0-34JrbfFxpfAwzryh7qpcaVTtAcZqtCynia4ovhY8DqsAQ@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <CAOS0-34JrbfFxpfAwzryh7qpcaVTtAcZqtCynia4ovhY8DqsAQ@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 67246 Cc: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.9 (---) On 24/11/2023 21:23, Wilhelm Kirschbaum wrote: > > On Fri, Nov 24, 2023 at 9:06 PM Dmitry Gutov <dmitry@HIDDEN > <mailto:dmitry@HIDDEN>> wrote: > > On 24/11/2023 20:56, Wilhelm Kirschbaum wrote: > > On Mon, Nov 20, 2023 at 12:00 PM Andrey Listopadov > <andreyorst@HIDDEN <mailto:andreyorst@HIDDEN> > > <mailto:andreyorst@HIDDEN <mailto:andreyorst@HIDDEN>>> wrote: > > > > Nov 20, 2023 04:50:27 Dmitry Gutov <dmitry@HIDDEN > <mailto:dmitry@HIDDEN> > > <mailto:dmitry@HIDDEN <mailto:dmitry@HIDDEN>>>: > > > > > I guess I expected that if the mode has been added to the core > > then the > > > development is led here too. And modes maintained > externally live > > more > > > easily in ELPA. Anyway, we are where we are. > > > > > > I agree, but not sure how to deal with the users already using it on > > emacs 29.1 with the MELPA package. > > When I wanted to submit the package, I remember there being an email > > saying we should not add packages to ELPA yet, so now I am stuck > with > > the github repository and MELPA. > > Once 30 drops it should be easier to redirect conversations here, > not > > sure how this works. The packages are slightly different and I > regret > > my earlier decisions. > > OTOH, once Emacs 30 drops, there will be no good way to undo the > inclusion, if you became so inclined. > > > Which might be an option currently, since elixir-ts-mode hasn't been in > an Emacs release yet. > > > I am not sure what you mean? Which option? I meant I regret pushing it > to MELPA first. Ah. If you want it to stay in Emacs core (and not in ELPA), then it should be easy enough to pull it from MELPA at any later point. Simply asking should suffice.
bug-gnu-emacs@HIDDEN:bug#67246; Package emacs.
Full text available.Received: (at 67246) by debbugs.gnu.org; 24 Nov 2023 19:23:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 24 14:23:45 2023 Received: from localhost ([127.0.0.1]:37308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r6bmC-0002Zl-QQ for submit <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:23:45 -0500 Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]:58864) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <wkirschbaum@HIDDEN>) id 1r6bm9-0002ZR-6o for 67246 <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:23:43 -0500 Received: by mail-qt1-x835.google.com with SMTP id d75a77b69052e-4239f2204acso3011551cf.1 for <67246 <at> debbugs.gnu.org>; Fri, 24 Nov 2023 11:23:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700853811; x=1701458611; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hBBDlnZ9dzJ+jXSru49tlUj+VAfgj18wAaDNgJYHoxc=; b=HFQ023Btspf1MINHQVWmhSW5zBxpvPbhA8JpfA34W3aWhihj4R7btBa74gXTCbfCVu PoGNPNMXHRQO4+a018KArKpM1o3EzGSSesauCASxj+Mn0SRosY1VdVNYy3XO0SxFc8gV jNA+fOR9EA5dM2P4vLl8GeYjPVduWkk+EsLhEtgL3Lvf/bQklEUFS/Ry7wcz0wE8FHmk lZi0beRnBjjO9TyyX35/AQAQ9I0khsPUsWzVkgMZ9eVQ6kLO6JFGD9blpEKapR0DVqjg 28Mu2JMx6uc0LKo55VvzPe5+RB6UfnlyfhQVONgiRj9VcGEJr9COm+FUJMoPBPLLSGcD ks3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700853811; x=1701458611; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hBBDlnZ9dzJ+jXSru49tlUj+VAfgj18wAaDNgJYHoxc=; b=tZuRZlrcF4jpfEwTyVlPp2rLn5EFL+UL1XsKYQf0lrelz4OYxguchvy6F8pMGgD1ud v+WPg4tAUCkEdjpe3pbZpxXdeBO5gYT3OeuVcon+eqFcohrFdphdT1ae2qEGYClavMmc kfpT2Lzq1XRuOt4bSU+RVoI3b7Wtzc5mKH839LJAx9D9UVkHS0qAutvu29PaNQIGjx4e eRrRCcemCRTvQp1RxnF+8wA3zHcydvDAGh5LNia+IV/J4RWLUM8Nv7Jffvkp+zc321SD CBK7JUPfMlCL2oxjNKnOd0i7KrXVTFcLXhbpMdbqDGmP2ID1y91Df99cNGynUqk/t8ol 2d3g== X-Gm-Message-State: AOJu0YwyLl7C3McDyn7KkoyS+dQGu9WWk3vqW8erVyPbxOUwIQb7B/9J Fdh0aOTKyTs9mE8fbM5mdu1p6RPmfPTHxK85Ypo= X-Google-Smtp-Source: AGHT+IHjJiRQibyoZT+3QPSwBM4CIZquZaY9G8D6Abm1flMK3FG7nxpcLFFof6mCR5TX3EiP8SRXZWO+WdJ8kYIr7xg= X-Received: by 2002:a05:622a:2c5:b0:417:f85b:5a5a with SMTP id a5-20020a05622a02c500b00417f85b5a5amr5142768qtx.5.1700853810899; Fri, 24 Nov 2023 11:23:30 -0800 (PST) MIME-Version: 1.0 References: <87y1ewgnn7.fsf@HIDDEN> <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN> <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN> <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN> <4f4e3d4c-e162-4007-a9b5-8210ea2f044b@HIDDEN> <CAOS0-359BvdqEWa0iJC3t0EELr=io-Vk8EFkhvKZGu6+HeCkaQ@HIDDEN> <62c76a1f-586a-751c-0565-baa11ca8a2ae@HIDDEN> In-Reply-To: <62c76a1f-586a-751c-0565-baa11ca8a2ae@HIDDEN> From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN> Date: Fri, 24 Nov 2023 21:23:19 +0200 Message-ID: <CAOS0-34JrbfFxpfAwzryh7qpcaVTtAcZqtCynia4ovhY8DqsAQ@HIDDEN> Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: multipart/alternative; boundary="00000000000036af13060aeae340" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 67246 Cc: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --00000000000036af13060aeae340 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 24, 2023 at 9:06=E2=80=AFPM Dmitry Gutov <dmitry@HIDDEN> wro= te: > On 24/11/2023 20:56, Wilhelm Kirschbaum wrote: > > On Mon, Nov 20, 2023 at 12:00=E2=80=AFPM Andrey Listopadov <andreyorst@= gmail.com > > <mailto:andreyorst@HIDDEN>> wrote: > > > > Nov 20, 2023 04:50:27 Dmitry Gutov <dmitry@HIDDEN > > <mailto:dmitry@HIDDEN>>: > > > > > I guess I expected that if the mode has been added to the core > > then the > > > development is led here too. And modes maintained externally liv= e > > more > > > easily in ELPA. Anyway, we are where we are. > > > > > > I agree, but not sure how to deal with the users already using it on > > emacs 29.1 with the MELPA package. > > When I wanted to submit the package, I remember there being an email > > saying we should not add packages to ELPA yet, so now I am stuck with > > the github repository and MELPA. > > Once 30 drops it should be easier to redirect conversations here, not > > sure how this works. The packages are slightly different and I regret > > my earlier decisions. > > OTOH, once Emacs 30 drops, there will be no good way to undo the > inclusion, if you became so inclined. > > Which might be an option currently, since elixir-ts-mode hasn't been in > an Emacs release yet. > I am not sure what you mean? Which option? I meant I regret pushing it to MELPA first. --00000000000036af13060aeae340 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><div= dir=3D"ltr" class=3D"gmail_attr">On Fri, Nov 24, 2023 at 9:06=E2=80=AFPM D= mitry Gutov <<a href=3D"mailto:dmitry@HIDDEN">dmitry@HIDDEN</a>>= ; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px= 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 24/1= 1/2023 20:56, Wilhelm Kirschbaum wrote:<br> > On Mon, Nov 20, 2023 at 12:00=E2=80=AFPM Andrey Listopadov <<a href= =3D"mailto:andreyorst@HIDDEN" target=3D"_blank">andreyorst@HIDDEN</a>= <br> > <mailto:<a href=3D"mailto:andreyorst@HIDDEN" target=3D"_blank">a= ndreyorst@HIDDEN</a>>> wrote:<br> > <br> >=C2=A0 =C2=A0 =C2=A0Nov 20, 2023 04:50:27 Dmitry Gutov <<a href=3D"m= ailto:dmitry@HIDDEN" target=3D"_blank">dmitry@HIDDEN</a><br> >=C2=A0 =C2=A0 =C2=A0<mailto:<a href=3D"mailto:dmitry@HIDDEN" targ= et=3D"_blank">dmitry@HIDDEN</a>>>:<br> > <br> >=C2=A0 =C2=A0 =C2=A0 > I guess I expected that if the mode has been = added to the core<br> >=C2=A0 =C2=A0 =C2=A0then the<br> >=C2=A0 =C2=A0 =C2=A0 > development is led here too. And modes mainta= ined externally live<br> >=C2=A0 =C2=A0 =C2=A0more<br> >=C2=A0 =C2=A0 =C2=A0 > easily in ELPA. Anyway, we are where we are.<= br> > <br> > <br> > I agree, but not sure how to deal with the users already using it on <= br> > emacs 29.1 with the MELPA package.<br> > When I wanted to submit the package, I remember there being an email <= br> > saying we should not add packages to ELPA yet, so now I am stuck with = <br> > the github repository and MELPA.<br> > Once 30 drops it should be easier to redirect conversations here, not = <br> > sure how this works.=C2=A0 The packages are slightly different and I r= egret <br> > my earlier decisions.<br> <br> OTOH, once Emacs 30 drops, there will be no good way to undo the <br> inclusion, if you became so inclined. <br></blockquote><blockquote class=3D= "gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2= 04,204,204);padding-left:1ex"> <br> Which might be an option currently, since elixir-ts-mode hasn't been in= <br> an Emacs release yet.<br></blockquote><div><br></div><div>I am not sure wha= t you mean? Which option? I meant I regret pushing it to MELPA first. <br><= /div></div></div> --00000000000036af13060aeae340--
bug-gnu-emacs@HIDDEN:bug#67246; Package emacs.
Full text available.Received: (at 67246) by debbugs.gnu.org; 24 Nov 2023 19:06:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 24 14:06:13 2023 Received: from localhost ([127.0.0.1]:37304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r6bVF-00026K-0Y for submit <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:06:13 -0500 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:35867) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1r6bVC-000262-Sz for 67246 <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:06:12 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2E3A93200A5A; Fri, 24 Nov 2023 14:05:59 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 24 Nov 2023 14:05:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1700852758; x=1700939158; bh=ol5FOW5H2W/vg3TVWVVkazFSkKWWsOn1QYh e6DsRseM=; b=mQiWhOMkpH7dE/g41kfnBZ0m8piMyaJUpR3Ia+K7uCeq+GBWyXS ommOeASy+E5BTmWl/Ih1MTXskSMWUqgKlPpvpDMIsBuutAL7nNx4AY2JGX1shiND dg5AlBM9hnvZwI4Qas8KyCwNvbWjPMbJQi3a8+nuXGjE5vqUwkrSDw0dzS3M2p9x BtoqbQZVfshR7DqkOr+1sfVhFO9RKMVL7SyFS/OkQZzoUmV+2I9rUP+CrIfwZbj9 J8wDYVJb1wqeoIvy1VPEZf/vQbYzwpzBH3K/t2S0hgfk7VRFxeeb9p6uFsAHNhGX iebRAkCoy8r1TadMCherYDRl0UFKM0pEEfg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700852758; x=1700939158; bh=ol5FOW5H2W/vg3TVWVVkazFSkKWWsOn1QYh e6DsRseM=; b=jNfQ0d+Q10nnchnYD6HVqpgYiqVpaRXDexcaDxWMllz0kNyQYmk rCSpyqKcoAvBSS6DHaYg/99yiP1Jpo7fosaPCsjRiKlSo3s0koDilhtmcfNa7IF9 27FW9VDPQaVEf+Vt+fzhykZybs0HX14ip1Qch5lALzcELaLy8la/kczkSpYOM87W AxCgiosEWup7+drT1okfSSjatrjNAqGWVeqkxpoKKjOg9BjDieLpxusGRsdcgMPO ZRIn6yL2KLfmUJMaBa6sRNSi25DYYWghqW+h3dHbpPAbs5ehFVUt9nslsCSWBSvB ftCkEXY2bQLtfPEsHLpHOEXcC1VkRNMaavQ== X-ME-Sender: <xms:FvRgZUqdNmPdykibR0hyu4KFIPTkOKHV0xVhVdKPEbREViQd8gMkaw> <xme:FvRgZaqQv8PoVJr6xrXHuyYCRj9VG3vdw_dd0-lqA5R09PWuALXU5su_TRlGF0Ems a4fO8C4jKcz7VrQbg0> X-ME-Received: <xmr:FvRgZZOsoTQ9VaDladqNRK4Pnn9HsKna0IJjq7dECUuCuODHbAKaMwqFaVNYtcfHqHKZsg> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehhedguddvtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffg feejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: <xmx:FvRgZb74SYABKUFbYIuatGiMSImk5kQB_QrdBC_pGiGJXN0XCj_bag> <xmx:FvRgZT5hZWQ3XKMq1Rv0X2nCKTTNnNsgZjNz8tPpelqXiNZAzMx6Tg> <xmx:FvRgZbi3lr7zmp3fxUPob3fvge0vc9ulC6O5oafjj9L6DhZW2H1FWQ> <xmx:FvRgZdQd1Is2Qht96j1RBqrVyG0svV8F_cVfDgQIxI6XVI2CPPhTRw> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 24 Nov 2023 14:05:57 -0500 (EST) Message-ID: <62c76a1f-586a-751c-0565-baa11ca8a2ae@HIDDEN> Date: Fri, 24 Nov 2023 21:05:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently Content-Language: en-US To: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>, Andrey Listopadov <andreyorst@HIDDEN> References: <87y1ewgnn7.fsf@HIDDEN> <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN> <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN> <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN> <4f4e3d4c-e162-4007-a9b5-8210ea2f044b@HIDDEN> <CAOS0-359BvdqEWa0iJC3t0EELr=io-Vk8EFkhvKZGu6+HeCkaQ@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <CAOS0-359BvdqEWa0iJC3t0EELr=io-Vk8EFkhvKZGu6+HeCkaQ@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 67246 Cc: 67246 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.9 (---) On 24/11/2023 20:56, Wilhelm Kirschbaum wrote: > On Mon, Nov 20, 2023 at 12:00 PM Andrey Listopadov <andreyorst@HIDDEN > <mailto:andreyorst@HIDDEN>> wrote: > > Nov 20, 2023 04:50:27 Dmitry Gutov <dmitry@HIDDEN > <mailto:dmitry@HIDDEN>>: > > > I guess I expected that if the mode has been added to the core > then the > > development is led here too. And modes maintained externally live > more > > easily in ELPA. Anyway, we are where we are. > > > I agree, but not sure how to deal with the users already using it on > emacs 29.1 with the MELPA package. > When I wanted to submit the package, I remember there being an email > saying we should not add packages to ELPA yet, so now I am stuck with > the github repository and MELPA. > Once 30 drops it should be easier to redirect conversations here, not > sure how this works. The packages are slightly different and I regret > my earlier decisions. OTOH, once Emacs 30 drops, there will be no good way to undo the inclusion, if you became so inclined. Which might be an option currently, since elixir-ts-mode hasn't been in an Emacs release yet.
bug-gnu-emacs@HIDDEN:bug#67246; Package emacs.
Full text available.Received: (at 67246) by debbugs.gnu.org; 24 Nov 2023 18:57:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 24 13:57:05 2023 Received: from localhost ([127.0.0.1]:37289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r6bMO-0007gC-Rb for submit <at> debbugs.gnu.org; Fri, 24 Nov 2023 13:57:05 -0500 Received: from mail-oa1-x35.google.com ([2001:4860:4864:20::35]:49256) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <wkirschbaum@HIDDEN>) id 1r6bMM-0007fa-Po for 67246 <at> debbugs.gnu.org; Fri, 24 Nov 2023 13:57:03 -0500 Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-1ef36a04931so1337625fac.2 for <67246 <at> debbugs.gnu.org>; Fri, 24 Nov 2023 10:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700852212; x=1701457012; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CIyPNZZhHbrnqroR7MjOJAiTi/cUGN6B2z7KXQdiUXU=; b=iuiPDrlNrtqQzKm+bjLGlF4ZwIIimdKD8IvIfHJNz0XbliG5gMpnW3DpNXnehtfz6G +sJBvPLVZu9iYmaR5eeIrVVy6PyoMArLUCF76DVC+NkWe7Z2G7lR7+ulWWdsaOQjxkZB ehjKPL5T9E5AWYZlrCJ6/6juYC7KWI3FK7EUeHwjB7NeLCxRS470uQccoDWainJNz5z/ Na2Gnm9ljlT/4dY5TYoHTaQEUOnSIhAYwBc4fpEVMUzMikqZsxemXxy/99CCLXZieOIU DYjLH3njrzXkMmgy1Oa4qecJOYp5pfmZjk0y57UC1tXP9vYdGbWir+4DLN6TZM6MmF2p upTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700852212; x=1701457012; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CIyPNZZhHbrnqroR7MjOJAiTi/cUGN6B2z7KXQdiUXU=; b=KFp4lHh0ixuUbS06NPoI14h6k38yQyEp/wikdYHzfkDhgZy9uJxh96WN0oU7rJCmAC eKwv6a27rNC3XZPhg+tAa8hodrTbM5XaKLZarcy6RLl27PuEVCe/ll1TxMwDiXDQlxSA e3TX1yNuV8/LfooqFQgwRz/t+vmiQHQ3SWde+OX1abfs6hGLNWdU+ii8YfylG32XELNn GZqrz99e8XEmKPLpTxsSLy5IVYWY9dBsEpLk9aeowQKI86Ihqsfbr8upWpqxoAtcK8Nc KFJPU3Hei1sFFnbgTUyFJ30IWeb2M3GzLKjWF3JSJvGWWLmPH+MsYkZZs9b6wZId7gjG CSNA== X-Gm-Message-State: AOJu0YwhOZnmqBpIf2nbiKxo03yV/3d8Zmvsu86Z+sPaUD0QcGbnr/E8 cZykZE13rjgzbFKSvucmOXdyXgyBZ9IprHR7SM8= X-Google-Smtp-Source: AGHT+IENlX7v6Gmc/Gy4H0g/cRtmiFnThRx4l4xmKw0ThJymP/t1BIHdY6obNuUkIAGIIB2UMubK8G7iyF57uNygWoY= X-Received: by 2002:a05:6870:b10:b0:1eb:4805:30d9 with SMTP id lh16-20020a0568700b1000b001eb480530d9mr4676943oab.49.1700852212221; Fri, 24 Nov 2023 10:56:52 -0800 (PST) MIME-Version: 1.0 References: <87y1ewgnn7.fsf@HIDDEN> <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN> <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN> <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN> <4f4e3d4c-e162-4007-a9b5-8210ea2f044b@HIDDEN> In-Reply-To: <4f4e3d4c-e162-4007-a9b5-8210ea2f044b@HIDDEN> From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN> Date: Fri, 24 Nov 2023 20:56:41 +0200 Message-ID: <CAOS0-359BvdqEWa0iJC3t0EELr=io-Vk8EFkhvKZGu6+HeCkaQ@HIDDEN> Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently To: Andrey Listopadov <andreyorst@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000eccd34060aea8380" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67246 Cc: 67246 <at> debbugs.gnu.org, Dmitry Gutov <dmitry@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000eccd34060aea8380 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry for the late response. On Mon, Nov 20, 2023 at 12:00=E2=80=AFPM Andrey Listopadov <andreyorst@gmai= l.com> wrote: > Nov 20, 2023 04:50:27 Dmitry Gutov <dmitry@HIDDEN>: > > > I guess I expected that if the mode has been added to the core then the > > development is led here too. And modes maintained externally live more > > easily in ELPA. Anyway, we are where we are. > I agree, but not sure how to deal with the users already using it on emacs 29.1 with the MELPA package. When I wanted to submit the package, I remember there being an email saying we should not add packages to ELPA yet, so now I am stuck with the github repository and MELPA. Once 30 drops it should be easier to redirect conversations here, not sure how this works. The packages are slightly different and I regret my earlier decisions. > > I thought the same thing. I wonder if there are other modes that continue > development on melpa first, and what is the proper way to set up the > override in my init.el. I'll have to look into that, I guess. > There is no need to set an override if you use a conventional method of loading the package as far as I know. > > > I haven't done too much testing myself. Perhaps Andrey will take the > > upstream version for a spin. Or we'll wait for the changes to be merged > > here and continue. > > I have pulled the melpa package, and at level 2 the font locking now > seems to be correct (I grew to expect syntax highlights to highlight > important parts of the code, so level 2 seems the most appropriate to me > personally). Thanks for the changes! However, I don't know how exactly > tree sitter mode should be organizedm so I can't give a proper review on > the changes - if there's a guide or a manual for that, I'd like to read > it. > Thanks for checking. Any feedback will be very helpful, I will prep the patch in the next day or two. Wilhelm --000000000000eccd34060aea8380 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Sorry for the late response. <br></div><div dir=3D"lt= r"><br></div><div dir=3D"ltr">On Mon, Nov 20, 2023 at 12:00=E2=80=AFPM Andr= ey Listopadov <<a href=3D"mailto:andreyorst@HIDDEN">andreyorst@gmail.= com</a>> wrote:</div><div class=3D"gmail_quote"><blockquote class=3D"gma= il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2= 04,204);padding-left:1ex">Nov 20, 2023 04:50:27 Dmitry Gutov <<a href=3D= "mailto:dmitry@HIDDEN" target=3D"_blank">dmitry@HIDDEN</a>>:<br> <br> > I guess I expected that if the mode has been added to the core then th= e <br> > development is led here too. And modes maintained externally live more= <br> > easily in ELPA. Anyway, we are where we are.<br></blockquote><div><br>= </div><div><div>I agree, but not sure how to deal with the users already us= ing it on emacs 29.1 with the MELPA package.=C2=A0=C2=A0</div><div>When I wanted to submit the package, I remember there being an email saying=20 we should not add packages to ELPA yet, so now I am stuck with the=20 github repository and MELPA. <br></div><div>Once 30 drops it should be easi= er to redirect conversations here, not sure how this works.=C2=A0 The packa= ges are slightly different and I regret my earlier decisions. <br></div></d= iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0= px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> I thought the same thing. I wonder if there are other modes that continue <= br> development on melpa first, and what is the proper way to set up the <br> override in my init.el. I'll have to look into that, I guess.<br></bloc= kquote><div><br></div><div>There is no need to set an override if you use a= conventional method of loading the package as far as I know. <br></div><di= v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px= 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> > I haven't done too much testing myself. Perhaps Andrey will take t= he <br> > upstream version for a spin. Or we'll wait for the changes to be m= erged <br> > here and continue.<br> <br> I have pulled the melpa package, and at level 2 the font locking now <br> seems to be correct (I grew to expect syntax highlights to highlight <br> important parts of the code, so level 2 seems the most appropriate to me <b= r> personally).=C2=A0 Thanks for the changes!=C2=A0 However, I don't know = how exactly <br> tree sitter mode should be organizedm so I can't give a proper review o= n <br> the changes - if there's a guide or a manual for that, I'd like to = read <br> it.<br></blockquote><div><br></div><div>Thanks for checking.=C2=A0 Any feed= back will be very helpful, I will prep the patch in the next day or two.</d= iv><div><br></div><div>Wilhelm<br></div></div></div> --000000000000eccd34060aea8380--
bug-gnu-emacs@HIDDEN:bug#67246; Package emacs.
Full text available.Received: (at 67246) by debbugs.gnu.org; 20 Nov 2023 10:00:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 20 05:00:15 2023 Received: from localhost ([127.0.0.1]:52487 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r514h-0004XO-Kw for submit <at> debbugs.gnu.org; Mon, 20 Nov 2023 05:00:15 -0500 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]:52363) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <andreyorst@HIDDEN>) id 1r514e-0004W2-Ss for 67246 <at> debbugs.gnu.org; Mon, 20 Nov 2023 05:00:13 -0500 Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5480edd7026so5202493a12.0 for <67246 <at> debbugs.gnu.org>; Mon, 20 Nov 2023 02:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700474404; x=1701079204; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=hpoaZ4zIqEcP1b65vNGGWMlQtvdIWNZtRyWnRkige38=; b=RUqPzN/e1JefzVhhTRlNz7uIC8hWlfIp5GkJU/3oyXvZhvc8xkD0dMN1N8QrwedvMF dhtmYNVOvs6v6uk3uZvufB1ay6uBZCSJBxyD6eR/O/HzVfmP7pWeY/ufOBI7Ut/6V1P2 lG1hOUp8QogA11HtBvUpVm6/l/eYB9s3IFkx6bgircmkOHW6XImbrwNwue4Gr4qDykua nyeMr2BdGLqv9ZPKUx9lECoirxkLtT/mVER2r6YsBkPmTJAEMpnpRVLruFZeukSP1/OI jHNzMGG0BI54IzLXJBfzCZBEr7hSDBAMzeQCFq7QsDvxIs7LS9hRxKjQGky2LQ0JA7nj dkjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700474404; x=1701079204; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=hpoaZ4zIqEcP1b65vNGGWMlQtvdIWNZtRyWnRkige38=; b=lwSHUxvzwfHpJMVLfmuONyWzn6WMOy9EO2g0SHEoChvbq/SYUh3uVshc/CuoKGtq7S /2p5ETSLrrNa2oUNJEc0r4Z01ezml7YIP/Xb8hWfjX0TXt03SNlfvVCl9Zil1coWRbft M9D0XCFTcpiifNZ9Ez1CItcq1sDNmvxBwz+PfGUoDu8l4ya3oMLuCj+1R4JtnPJKige3 F+HKCQNHHi9w85I0TrPJo1tkEsX3MEfW1If4DbTxnaCfZpBYmJpc3Q9y7Vao+uz82UbH a0Jz/8mN3Q+bYJ1xwyyCNqPAIt5rVD3LBRGBmVU9XOQ83XOHDrG4rk/y1q1xzMU0ogG+ dXRw== X-Gm-Message-State: AOJu0Yy6HvHHJIJofaymVIE4SlSQXvCDTHtqoBr0R7J2FWG9wTTQFDnP 8ufXjzT3DqmQt46pmprTreE= X-Google-Smtp-Source: AGHT+IHEAyJArw0w9RDquL7S2bEBskfS42+ZKOFnpSTzF/CmXkl75V4FI9oZeeJZdzO130nBv9XceA== X-Received: by 2002:a17:906:2212:b0:a00:773c:3f09 with SMTP id s18-20020a170906221200b00a00773c3f09mr185603ejs.17.1700474403650; Mon, 20 Nov 2023 02:00:03 -0800 (PST) Received: from [127.0.0.1] ([176.59.43.116]) by smtp.gmail.com with ESMTPSA id cd17-20020a170906b35100b009b2ba067b37sm3686181ejb.202.2023.11.20.02.00.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Nov 2023 02:00:03 -0800 (PST) Date: Mon, 20 Nov 2023 13:00:01 +0300 (GMT+03:00) From: Andrey Listopadov <andreyorst@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> Message-ID: <4f4e3d4c-e162-4007-a9b5-8210ea2f044b@HIDDEN> In-Reply-To: <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN> References: <87y1ewgnn7.fsf@HIDDEN> <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN> <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN> <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN> Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Correlation-ID: <4f4e3d4c-e162-4007-a9b5-8210ea2f044b@HIDDEN> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67246 Cc: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>, 67246 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Nov 20, 2023 04:50:27 Dmitry Gutov <dmitry@HIDDEN>: > I guess I expected that if the mode has been added to the core then the= =20 > development is led here too. And modes maintained externally live more=20 > easily in ELPA. Anyway, we are where we are. I thought the same thing. I wonder if there are other modes that continue= =20 development on melpa first, and what is the proper way to set up the=20 override in my init.el. I'll have to look into that, I guess. > I haven't done too much testing myself. Perhaps Andrey will take the=20 > upstream version for a spin. Or we'll wait for the changes to be merged= =20 > here and continue. I have pulled the melpa package, and at level 2 the font locking now=20 seems to be correct (I grew to expect syntax highlights to highlight=20 important parts of the code, so level 2 seems the most appropriate to me=20 personally).=C2=A0 Thanks for the changes!=C2=A0 However, I don't know how = exactly=20 tree sitter mode should be organizedm so I can't give a proper review on=20 the changes - if there's a guide or a manual for that, I'd like to read=20 it. I guess when the patch for the core package will arive, someone who knows= =20 how font-locking is organized should give a proper review.
bug-gnu-emacs@HIDDEN:bug#67246; Package emacs.
Full text available.Received: (at 67246) by debbugs.gnu.org; 20 Nov 2023 01:50:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Nov 19 20:50:39 2023 Received: from localhost ([127.0.0.1]:52299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r4tQt-0005yY-5a for submit <at> debbugs.gnu.org; Sun, 19 Nov 2023 20:50:39 -0500 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:50433) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1r4tQo-0005yB-KU for 67246 <at> debbugs.gnu.org; Sun, 19 Nov 2023 20:50:37 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 81D82320097C; Sun, 19 Nov 2023 20:50:26 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sun, 19 Nov 2023 20:50:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1700445026; x=1700531426; bh=nwRset3vFCoXIdjxZC0Exh53C+bfgYz25BD d/NWqp48=; b=F1fIChMF4sTT7TtVSyoJTwjdRs5BCriFAf4SGrMRfBxVnQAU/UZ p1wRadyEsFi/dYcCUtVK3ZIYq3jHM3R9E5xOLBVQUX3ouaKw0e4O2/l+FjT47Oaa oRUSCq+CH2ezCZQyboBW9X+urBKIsUh+UDR45SNZrbfW1UQbAT8Hh9ILxA4pWkVk KJGqveQhfSqVCT2BU4r2fMTfCMaOcVDm9z3hWMnxLntIPw3UGOTNNLB/lZtLHJt4 4mniAAulAQ7/sespmZVYEJBjHUF1hkPUYOaySO1Zlt0kI2M9hblO1DeZFQMkKIZa M1wmyCHG4/7SW4ENmHi8q4PPTlOegz3uJ/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1700445026; x=1700531426; bh=nwRset3vFCoXIdjxZC0Exh53C+bfgYz25BD d/NWqp48=; b=wTzrqJjZy7LmZCX7lHad4/pcofhYAmJdYLy9OecpU9uGblRVJyn fQGVPNhkLqSRgWbVk77KtzS1oXTedIno2Uv4aqFKr/KK7TdmkdLucdYBqewa5/ti RsFUZoukEnwnP0vliUSHjEb/7qtYkaIN9qnrWYnA60R40RG48LjOW0T5JFYrX6XH QInfa8+mWUeOPNgv4sJ/9wpo0TN7pfMzjP/nbCVXeOMUAutKmXn+H9w3mx2lMNnl ZPsjsgkUWQaiozMWh5eV3HmbRd7+IwKs22V/r/Rzv2OWP8kee6FkujytoMHfQVHr WFZN+7ZXnXL6u307G25UBwkZ+gczN3sxnrA== X-ME-Sender: <xms:YbtaZV4oCb2wVQ37wxKddjIR4m2btXqsGepD73XZ_zlnS6RkX1IIdw> <xme:YbtaZS7AyLkkYzkkB1prPl0YZ3bVlBw6Bx38P_c5xW4jgZq2RhHVzlMOwleMcgczs 1t2WpVAuMgUEcRunaQ> X-ME-Received: <xmr:YbtaZcd_63waAcXB8dFzkuJgM6wZsKQTcTP1vTa26A6YdqIY2oUg9FBhdtB67Ldsg-bsrg> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeghedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepueffveeiffeugffgveejvdegteeuhfdugfehleelfeejtdelteethfdtieeg vddunecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: <xmx:YbtaZeKdaWcNot5w_pjGhePQlyUzcyrdc6Mnu3t3bQ1ZL7bdvr-itQ> <xmx:YbtaZZIJbbBeTnCyOy9l3X0PsdAsl_meTD4n0a7HLS3-M55lxJb7nA> <xmx:YbtaZXzbhARHhvwRECZsQtno9mEj4QgSdjnsCzuliQFDBmFFhK-flA> <xmx:YrtaZXjDrTikI6-7LhjldIS36aEjhsgq8z7Zc1Yfam8iSmWtVD-JYQ> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 19 Nov 2023 20:50:24 -0500 (EST) Message-ID: <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN> Date: Mon, 20 Nov 2023 03:50:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently Content-Language: en-US To: Wilhelm Kirschbaum <wkirschbaum@HIDDEN> References: <87y1ewgnn7.fsf@HIDDEN> <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN> <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 67246 Cc: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.9 (---) On 18/11/2023 09:50, Wilhelm Kirschbaum wrote: > > On Sat, Nov 18, 2023 at 3:36 AM Dmitry Gutov <dmitry@HIDDEN > <mailto:dmitry@HIDDEN>> wrote: > > On 17/11/2023 21:50, Andrey Listopadov wrote: > > > > I've upgraded from elixir-mode to elixir-ts-mode and noticed that the > > latter uses faces rather inconsistently. > > > > For example, the =font-lock-keyword-face= is used for both > keywords and > > method calls, as well as for parentheses. The > > =font-lock-function-name-face= is used both for function definitions, > > parameter names, and calls. Some calls use the > > =font-lock-keyword-face=, for example the call to `raise'. The > > =font-lock-type-face= is used both for types and =:symbols=. > > > > All of that basically makes Elixir code mostly use 2 colors. > > Additionally, it makes impossible selectively disabling > highlighting, as > > disabling the function call highlighting will disable the function > > definition highlighitng an so on. > > > > I believe, Emacs 29 introduced a lot of faces for all kinds of > > situations possible in Tree-sitter generated AST, so perhaps the > fix is > > to use them more semantically, rather than for good looks. > > Thanks for the report. Wilhelm, could you look into this? If you > have time. > > Speaking of new faces, we added font-lock-function-call-face that > can be > used for function calls, while font-lock-function-name-face stays used > on definitions. > > For parens, if one wanted to highlight them at all, > font-lock-bracket-face could be used. Though it's probably better to > leave them to the 4th feature level (see js-ts-mode as an example). > elixir-ts-mode currently defines 3 levels. > > For levels, we've currently settled on the scheme that function calls > and property lookups go to the 4th level of highlighting, whereas the > default is 3. This is all tweakable by the individual user, but I think > it's better to stay consistent between the modes. > > Finally, I see that font-lock-function-name-face ends up being used for > parameters (as Andrey mentioned) and local variables as well. That's > not > great; probably a query that ended up matching too widely. We prefer to > use font-lock-variable-name-face (for parameter declarations) or > font-lock-variable-use-face for such identifiers. Though it can be hard > to reliably distinguish them in a dynamic language, so as far as I'm > concerned, they could stay non-highlighted (the uses, that is; the > declarations are usually easy to find using queries). > > > Thanks for the detailed explanation. It's unfortunate timing, because I > published a rework of the faces on MELPA so long and a few people are > trying it out. It is a total rework using the faces a bit better. I can > submit the patch later today and start the conversation from there? I guess I expected that if the mode has been added to the core then the development is led here too. And modes maintained externally live more easily in ELPA. Anyway, we are where we are. I see that the latest work (https://github.com/wkirschbaum/elixir-ts-mode/pull/36) anticipated at least some of my comments. Remainder: 1) font-lock-variable-name-face is intended for declarations and perhaps initial assignments (where it's also an implicit declaration), but for other variable references it's better to use font-lock-variable-use-face. With my test file, I see examples to the contrary, even though some attempt to use the latter face had been made (inside the 'elixir-function-call' feature's query). 2) Moving highlighting of function calls and variable (and/or property) references to the 4th feature level. Looking at your font-lock rules, it seems like the elixir-function-call matches is more targeted than the elixir-variable one, but still the other built-in modes put both at 4, so it would be good for uniformity. Function definitions (and variable definitions/declarations, if they're highlighted separately) can remain in the 'declaration' or 'definition' feature which is put in a lower feature level (e.g. ruby/js/typescript modes have it on level 1). Something else I would recommend: 3) Removing the '-face' suffix from the face names. This is the best practice across most modes, and it's something the manual entry for 'defface' recommends: You should not quote the symbol face, and it should not end in ‘-face’ (that would be redundant). Face names inside font-lock.el are a historical exception (and we followed it when adding new faces recently), but if you search for 'defface' inside the Emacs codebase, such names are in the minority. I haven't done too much testing myself. Perhaps Andrey will take the upstream version for a spin. Or we'll wait for the changes to be merged here and continue.
bug-gnu-emacs@HIDDEN:bug#67246; Package emacs.
Full text available.Received: (at 67246) by debbugs.gnu.org; 18 Nov 2023 07:51:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 18 02:51:09 2023 Received: from localhost ([127.0.0.1]:47724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r4G6f-0005Fj-3Y for submit <at> debbugs.gnu.org; Sat, 18 Nov 2023 02:51:09 -0500 Received: from mail-qt1-x82b.google.com ([2607:f8b0:4864:20::82b]:53536) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <wkirschbaum@HIDDEN>) id 1r4G6c-0005FC-CA for 67246 <at> debbugs.gnu.org; Sat, 18 Nov 2023 02:51:07 -0500 Received: by mail-qt1-x82b.google.com with SMTP id d75a77b69052e-4219f89ee21so15788581cf.3 for <67246 <at> debbugs.gnu.org>; Fri, 17 Nov 2023 23:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700293860; x=1700898660; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gXfKJUvt2xtRZroc0krKOGG9/O2RAZc1/g/oJD1a9nY=; b=Mwx7zjDAVMGyP/trTo5cfcfokUnIOOLQ7c7ZmQWzFuLsOh0pBxZhIhfDKymiR5Q7eG dHbBqqgOT0zfNsgpMOBo+FZvtYaBXvnSqNIMYOY9JLTEiiTs9aZ6JSk5Q/nf7S8lBCYI lky2snEEb4/F/GVAGink5QEu43ZISx2t+HyfIpSdOoU1q8jQX58rh4KtyzSdK0VBuV47 tlOroYMTem9OYe29UzP0PW9U6qPybQxzRFJQZ+zViQlEJFHXe7P+BDZfdbJ33hWj8XLa 1SBDl29NGp7BOhjspQwFPq/qH95vAZ1mdfj0BkVlSLnoEHlKAXKeYcUiMn9p8F4d3Ehc G81Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700293860; x=1700898660; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gXfKJUvt2xtRZroc0krKOGG9/O2RAZc1/g/oJD1a9nY=; b=IBKJft+/ikN4PezAM44btl6ADSXc8oERFDnsStqE0fLuLg88Gm/KHxc/jEs2Sh7miI d4sWRyUV++YRQFIiUndJkmhjDtN+NjJiaWPEi6VL+g57mYMUizlOOXpB7SRojNGiOYFT Rsa3oUx7y0sIRt+PB7TcRw2FC/e34wnNKv7QNumhfnFzjH9hf5+g4yqYf9zx1jR5Zqlz d6gEwXLA+Zzn11GDzC7g9tlWEEo4LBncAf6+FzJzSvvDYk226DJvkHA7M3LdtbC5tRbR sEmPncUuBspAkBAaEYQb1QF799JJafu5FAMt+7wXb/wYx7nvBLTJk6xLNHO4Vw9Jvuwa vo+Q== X-Gm-Message-State: AOJu0YyvV5tkRYHzqayeAanWfSzYYU6EigImlCnpK59P5YrnegwXJKwB 8PnygJtFOSFLWuUnDRQJl2Zd8GkPyQpqM/opTfc= X-Google-Smtp-Source: AGHT+IEd2R4wRsTpI7yDqT78kvBBn8RlSZmic9Q9/YcvsN4jtXSnt7c+88cHxa9bi7s+l62081FVAL8W4O7l0gGea88= X-Received: by 2002:ac8:5dd4:0:b0:41c:e92a:c604 with SMTP id e20-20020ac85dd4000000b0041ce92ac604mr2333715qtx.59.1700293859836; Fri, 17 Nov 2023 23:50:59 -0800 (PST) MIME-Version: 1.0 References: <87y1ewgnn7.fsf@HIDDEN> <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN> In-Reply-To: <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN> From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN> Date: Sat, 18 Nov 2023 09:50:48 +0200 Message-ID: <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN> Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: multipart/alternative; boundary="00000000000087879f060a688381" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67246 Cc: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --00000000000087879f060a688381 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 18, 2023 at 3:36=E2=80=AFAM Dmitry Gutov <dmitry@HIDDEN> wro= te: > On 17/11/2023 21:50, Andrey Listopadov wrote: > > > > I've upgraded from elixir-mode to elixir-ts-mode and noticed that the > > latter uses faces rather inconsistently. > > > > For example, the =3Dfont-lock-keyword-face=3D is used for both keywords= and > > method calls, as well as for parentheses. The > > =3Dfont-lock-function-name-face=3D is used both for function definition= s, > > parameter names, and calls. Some calls use the > > =3Dfont-lock-keyword-face=3D, for example the call to `raise'. The > > =3Dfont-lock-type-face=3D is used both for types and =3D:symbols=3D. > > > > All of that basically makes Elixir code mostly use 2 colors. > > Additionally, it makes impossible selectively disabling highlighting, a= s > > disabling the function call highlighting will disable the function > > definition highlighitng an so on. > > > > I believe, Emacs 29 introduced a lot of faces for all kinds of > > situations possible in Tree-sitter generated AST, so perhaps the fix is > > to use them more semantically, rather than for good looks. > > Thanks for the report. Wilhelm, could you look into this? If you have tim= e. > > Speaking of new faces, we added font-lock-function-call-face that can be > used for function calls, while font-lock-function-name-face stays used > on definitions. > > For parens, if one wanted to highlight them at all, > font-lock-bracket-face could be used. Though it's probably better to > leave them to the 4th feature level (see js-ts-mode as an example). > elixir-ts-mode currently defines 3 levels. > > For levels, we've currently settled on the scheme that function calls > and property lookups go to the 4th level of highlighting, whereas the > default is 3. This is all tweakable by the individual user, but I think > it's better to stay consistent between the modes. > > Finally, I see that font-lock-function-name-face ends up being used for > parameters (as Andrey mentioned) and local variables as well. That's not > great; probably a query that ended up matching too widely. We prefer to > use font-lock-variable-name-face (for parameter declarations) or > font-lock-variable-use-face for such identifiers. Though it can be hard > to reliably distinguish them in a dynamic language, so as far as I'm > concerned, they could stay non-highlighted (the uses, that is; the > declarations are usually easy to find using queries). > Thanks for the detailed explanation. It's unfortunate timing, because I published a rework of the faces on MELPA so long and a few people are trying it out. It is a total rework using the faces a bit better. I can submit the patch later today and start the conversation from there? Wilhelm --00000000000087879f060a688381 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div>On Sat, Nov 18, 2023 at 3:36=E2= =80=AFAM Dmitry Gutov <<a href=3D"mailto:dmitry@HIDDEN">dmitry@gutov.= dev</a>> wrote:<div class=3D"gmail_quote"><blockquote class=3D"gmail_quo= te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= );padding-left:1ex">On 17/11/2023 21:50, Andrey Listopadov wrote:<br> > <br> > I've upgraded from elixir-mode to elixir-ts-mode and noticed that = the<br> > latter uses faces rather inconsistently.<br> > <br> > For example, the =3Dfont-lock-keyword-face=3D is used for both keyword= s and<br> > method calls, as well as for parentheses.=C2=A0 The<br> > =3Dfont-lock-function-name-face=3D is used both for function definitio= ns,<br> > parameter names, and calls.=C2=A0 Some calls use the<br> > =3Dfont-lock-keyword-face=3D, for example the call to `raise'.=C2= =A0 The<br> > =3Dfont-lock-type-face=3D is used both for types and =3D:symbols=3D.<b= r> > <br> > All of that basically makes Elixir code mostly use 2 colors.<br> > Additionally, it makes impossible selectively disabling highlighting, = as<br> > disabling the function call highlighting will disable the function<br> > definition highlighitng an so on.<br> > <br> > I believe, Emacs 29 introduced a lot of faces for all kinds of<br> > situations possible in Tree-sitter generated AST, so perhaps the fix i= s<br> > to use them more semantically, rather than for good looks.<br> <br> Thanks for the report. Wilhelm, could you look into this? If you have time.= <br> <br> Speaking of new faces, we added font-lock-function-call-face that can be <b= r> used for function calls, while font-lock-function-name-face stays used <br> on definitions.<br> <br> For parens, if one wanted to highlight them at all, <br> font-lock-bracket-face could be used. Though it's probably better to <b= r> leave them to the 4th feature level (see js-ts-mode as an example). <br> elixir-ts-mode currently defines 3 levels.<br> <br> For levels, we've currently settled on the scheme that function calls <= br> and property lookups go to the 4th level of highlighting, whereas the <br> default is 3. This is all tweakable by the individual user, but I think <br= > it's better to stay consistent between the modes.<br> <br> Finally, I see that font-lock-function-name-face ends up being used for <br= > parameters (as Andrey mentioned) and local variables as well. That's no= t <br> great; probably a query that ended up matching too widely. We prefer to <br= > use font-lock-variable-name-face (for parameter declarations) or <br> font-lock-variable-use-face for such identifiers. Though it can be hard <br= > to reliably distinguish them in a dynamic language, so as far as I'm <b= r> concerned, they could stay non-highlighted (the uses, that is; the <br> declarations are usually easy to find using queries).<br></blockquote><div>= <br></div><div>Thanks for the detailed explanation. It's unfortunate ti= ming, because I published a rework of the faces on MELPA so long and a few = people are trying it out. It is a total rework using the faces a bit better= .=C2=A0 I can submit the patch later today and start the conversation from = there? <br></div><div><br></div><div>Wilhelm<br></div></div></div> --00000000000087879f060a688381--
bug-gnu-emacs@HIDDEN:bug#67246; Package emacs.
Full text available.Received: (at 67246) by debbugs.gnu.org; 18 Nov 2023 01:36:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 17 20:36:42 2023 Received: from localhost ([127.0.0.1]:47334 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r4AGH-0003jr-Lh for submit <at> debbugs.gnu.org; Fri, 17 Nov 2023 20:36:41 -0500 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:50785) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1r4AGE-0003jd-CY for 67246 <at> debbugs.gnu.org; Fri, 17 Nov 2023 20:36:40 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 3718D320090D; Fri, 17 Nov 2023 20:36:31 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 17 Nov 2023 20:36:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1700271390; x=1700357790; bh=DNx1f2UYiIMnch9k/F9UcoXPdZUrB+Oj+cl 4u6ICPdw=; b=rtbMOQQ5vu++oA6TYe13Bgwc7nrYGkdIgMicnNylh28mee2iZ3/ EDbMk6Z4wu5ONFx85x4nx1OkrumloXzLqv3oX0FpXHtUgbpBFk5d2a7Dd+8jr4MW osrFIOpdjG3jgwnOYqMEfh+ApFcDQRyPBXRCLNhQbNb3PxWkP9iGyTMpnchjR0jZ BrtrLg+01UMLW42wOGoo/UxR3MsmoZYVoTpjzM6TqADDNcM8vW7xFtbkpkeL7DFI P7uHoGnO+hZZ3XAfPiDNOnY8w6LQUoGwmBVHXoW2fixVJSANEBvflJSzIZVYYqSq 9DgzNq3ePQcH9UEikS+v9CqDr8O9YO0zxbQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1700271390; x= 1700357790; bh=DNx1f2UYiIMnch9k/F9UcoXPdZUrB+Oj+cl4u6ICPdw=; b=1 SSOtxtsuOW8pskT8v7GIOBQnB3Ka2sczboyWl76ULbl2iGMYl69skylGReIvRMqZ s6uN6eLCpFKCsZhxY6oMDE+AAKBj/WWd344HRxFT3vAztVT7eOSKE46CkeBhgPZP 4gzYXFIrILwweCEGrU8Q2AwNYJKQJ4Y6ypLoNiaPrCCobussQpZBu0B12/qo1cPN fqyYFtasdMxaHkgzlgX0ioGJgBpxPPKS3/dJBQ2gvO7JQ/Ixlch+voboyiJnhYdt R1oZkYew4sHdWZ27zVZHxx9eXLZgMOceqmCdQn5BqKEM0tVuUZtbCBPIucwreCvo KQjyA8dG6eSTpL4tNmE/w== X-ME-Sender: <xms:HhVYZd_sd9XqZEXR25luvGlrEwrdBzAqDz3s-K5ZfW_15yEi6cObiw> <xme:HhVYZRtRaqpEwToffwOhFlYSLwOxcGXSFZbTmjfH9xlbk-OxpKpuZEI91eSi5bBIM GFAKE1ntRXbx21lFPM> X-ME-Received: <xmr:HhVYZbAiZzpIwH7n5DplT4p9w2HXwyeRPAbsvM61ERTrdd3S8Nq-UfVx3uXQ3zyVRpAXoA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeguddgfeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeghedthedujeeiteeutddtjeekheejteeukeehffdutdejuedvfeevueeviedu udenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: <xmx:HhVYZRdRN2aGl56q6ULISFyTefebtjYbOQw0Pud4wKk9NSN-Wn1Wsw> <xmx:HhVYZSP13yfe-2WG1nbslYwBPHf6_2309vHTIBbFEP7_loYTbS60hw> <xmx:HhVYZTluwwf-NclCy2Wau7yA0Gwlmnk6qP6RcGzg548CyRTiA9_dtA> <xmx:HhVYZU3IKKUgeluO0ut0wXIasvICCaLYHjZ5AjYUDPftZeadOKOjPg> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 17 Nov 2023 20:36:29 -0500 (EST) Message-ID: <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN> Date: Sat, 18 Nov 2023 03:36:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently Content-Language: en-US To: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org, Wilhelm H Kirschbaum <wkirschbaum@HIDDEN> References: <87y1ewgnn7.fsf@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <87y1ewgnn7.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 67246 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.9 (---) On 17/11/2023 21:50, Andrey Listopadov wrote: > > I've upgraded from elixir-mode to elixir-ts-mode and noticed that the > latter uses faces rather inconsistently. > > For example, the =font-lock-keyword-face= is used for both keywords and > method calls, as well as for parentheses. The > =font-lock-function-name-face= is used both for function definitions, > parameter names, and calls. Some calls use the > =font-lock-keyword-face=, for example the call to `raise'. The > =font-lock-type-face= is used both for types and =:symbols=. > > All of that basically makes Elixir code mostly use 2 colors. > Additionally, it makes impossible selectively disabling highlighting, as > disabling the function call highlighting will disable the function > definition highlighitng an so on. > > I believe, Emacs 29 introduced a lot of faces for all kinds of > situations possible in Tree-sitter generated AST, so perhaps the fix is > to use them more semantically, rather than for good looks. Thanks for the report. Wilhelm, could you look into this? If you have time. Speaking of new faces, we added font-lock-function-call-face that can be used for function calls, while font-lock-function-name-face stays used on definitions. For parens, if one wanted to highlight them at all, font-lock-bracket-face could be used. Though it's probably better to leave them to the 4th feature level (see js-ts-mode as an example). elixir-ts-mode currently defines 3 levels. For levels, we've currently settled on the scheme that function calls and property lookups go to the 4th level of highlighting, whereas the default is 3. This is all tweakable by the individual user, but I think it's better to stay consistent between the modes. Finally, I see that font-lock-function-name-face ends up being used for parameters (as Andrey mentioned) and local variables as well. That's not great; probably a query that ended up matching too widely. We prefer to use font-lock-variable-name-face (for parameter declarations) or font-lock-variable-use-face for such identifiers. Though it can be hard to reliably distinguish them in a dynamic language, so as far as I'm concerned, they could stay non-highlighted (the uses, that is; the declarations are usually easy to find using queries).
bug-gnu-emacs@HIDDEN:bug#67246; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 17 Nov 2023 19:56:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 17 14:56:13 2023 Received: from localhost ([127.0.0.1]:47180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1r44wm-0003EX-Gk for submit <at> debbugs.gnu.org; Fri, 17 Nov 2023 14:56:13 -0500 Received: from lists.gnu.org ([2001:470:142::17]:34626) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <andreyorst@HIDDEN>) id 1r44wj-0003EH-9x for submit <at> debbugs.gnu.org; Fri, 17 Nov 2023 14:56:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <andreyorst@HIDDEN>) id 1r44wd-000115-7o for bug-gnu-emacs@HIDDEN; Fri, 17 Nov 2023 14:56:03 -0500 Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <andreyorst@HIDDEN>) id 1r44wa-0004Rd-Un for bug-gnu-emacs@HIDDEN; Fri, 17 Nov 2023 14:56:02 -0500 Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2c5056059e0so33311521fa.3 for <bug-gnu-emacs@HIDDEN>; Fri, 17 Nov 2023 11:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700250959; x=1700855759; darn=gnu.org; h=mime-version:message-id:date:subject:to:from:user-agent:from:to:cc :subject:date:message-id:reply-to; bh=l7zqwFLp5CSz0ssZEkwK4m/b6nDdyZe5D+66jsVoILo=; b=kAfN8p/7k//Pd9EXEj6/ctFOofYJi58p8+20y0gFK+1lSLGDEfi6ruxiH5V1iT9tIY wWjOz+QCc7r6B3n/hn3y56RhdJl6zJF6kz8Qd8l6a88xrVh0LKjlXfqFA+6xNGyS0pew LoKJwAUuCqSwpcWmvjiOGVh6ZVqJ8evNXiBJpaaAuKpSu3rx9hmkRMx+N6n6ttqScH4E 4NH/6Z/XimwrMg+iDbqhzG5EU4lDOeJR0ZXR4eCdjsRvMJcMjEWb+D2XvK89QnAwjPFq nlGxXn27cU2aHZW+Gu/YYdck96RjKgVgUzqvJl8ATdy4dl/aulYFBUFb9PzylKDIZGGm craA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700250959; x=1700855759; h=mime-version:message-id:date:subject:to:from:user-agent :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=l7zqwFLp5CSz0ssZEkwK4m/b6nDdyZe5D+66jsVoILo=; b=Ak6xZ7+pvNVsRX6bbrCVPTtVLoKmW3BA3QeZLvqIWQDaMTjGk3s73AGogeuimPODod +EaBAwvZZzJhb9KKr8bofPHJp3MJIm0gqXg432Q+ct7Rqu8LKkts0OFMOLvoR0zyvlPB FgNpW3MwoyZuNvoIc70R3XQO56JcC8cZkV+zOLbiyh4Lr9llEGiXJa1VSZWOhGBr660u wMnbrkIHtUMERAMVJpPKmFduCnJhdTsAfX9laVeV7eP+i8cVDRwOb59Si6Y4vW3bSInJ Gv3EFKD0+FSTrIkktMedTJswUMu+ZRX16otxH2hHK31KpOkVTNPM5QBHApM4/9Xw97xF ihQQ== X-Gm-Message-State: AOJu0YzNcNBNTQZVHQPq4CsI4AFK6znX9k5D6NAlxprjzPxIY7d9eyk0 BRncar0VwPQhPB1vlrdNjCajQMa7SPW3tA== X-Google-Smtp-Source: AGHT+IGGFHGjTsQ2Aub17BD7XOaoSEIxyEF8njUA+RzVNRyHQv2l41zyedXNkTQYxqntxwVZ7oY6BA== X-Received: by 2002:a2e:a0d2:0:b0:2c5:a21:8388 with SMTP id f18-20020a2ea0d2000000b002c50a218388mr458197ljm.29.1700250958700; Fri, 17 Nov 2023 11:55:58 -0800 (PST) Received: from toolbox.smtp.gmail.com (broadband-90-154-71-4.ip.moscow.rt.ru. [90.154.71.4]) by smtp.gmail.com with ESMTPSA id r7-20020a170906280700b009cc1e8ed7c5sm1102670ejc.133.2023.11.17.11.55.57 for <bug-gnu-emacs@HIDDEN> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Nov 2023 11:55:58 -0800 (PST) User-agent: mu4e 1.8.11; emacs 30.0.50 From: Andrey Listopadov <andreyorst@HIDDEN> To: bug-gnu-emacs@HIDDEN Subject: 30.0.50; elixir-ts-mode uses faces inconsistently Date: Fri, 17 Nov 2023 22:50:58 +0300 Message-ID: <87y1ewgnn7.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::231; envelope-from=andreyorst@HIDDEN; helo=mail-lj1-x231.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.0 (/) I've upgraded from elixir-mode to elixir-ts-mode and noticed that the latter uses faces rather inconsistently. For example, the =font-lock-keyword-face= is used for both keywords and method calls, as well as for parentheses. The =font-lock-function-name-face= is used both for function definitions, parameter names, and calls. Some calls use the =font-lock-keyword-face=, for example the call to `raise'. The =font-lock-type-face= is used both for types and =:symbols=. All of that basically makes Elixir code mostly use 2 colors. Additionally, it makes impossible selectively disabling highlighting, as disabling the function call highlighting will disable the function definition highlighitng an so on. I believe, Emacs 29 introduced a lot of faces for all kinds of situations possible in Tree-sitter generated AST, so perhaps the fix is to use them more semantically, rather than for good looks. In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.8) of 2023-11-08 built on toolbox Repository revision: bf9cbc2354124a1e9eb3327007468ba384ba2945 Repository branch: master System Description: Fedora Linux 38 (Container Image) Configured using: 'configure --without-compress-install --with-native-compilation=aot --with-pgtk --with-mailutils --with-xwidgets --prefix=/var/home/alist/.local' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER XIM XWIDGETS GTK3 ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: mu4e:main Minor modes in effect: global-git-commit-mode: t magit-auto-revert-mode: t mu4e-search-minor-mode: t mu4e-update-minor-mode: t mu4e-context-minor-mode: t electric-pair-mode: t savehist-mode: t delete-selection-mode: t pixel-scroll-precision-mode: t global-auto-revert-mode: t repeat-mode: t vertico-mode: t marginalia-mode: t corfu-popupinfo-mode: t global-corfu-mode: t global-region-bindings-mode: t recentf-mode: t gcmh-mode: t override-global-mode: t tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t context-menu-mode: t global-font-lock-mode: t blink-cursor-mode: t minibuffer-regexp-mode: t buffer-read-only: t column-number-mode: t line-number-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t overwrite-mode: overwrite-mode-binary Load-path shadows: /var/home/alist/.config/emacs/elpa/transient-20231103.2312/transient hides /var/home/alist/.local/share/emacs/30.0.50/lisp/transient /var/home/alist/.config/emacs/elpa/modus-themes-20231031.716/theme-loaddefs hides /var/home/alist/.local/share/emacs/30.0.50/lisp/theme-loaddefs Features: (shadow face-remap emacsbug mu4e mu4e-org ob-fennel fennel-proto-repl fennel-mode inf-lisp xref magit-bookmark magit-submodule magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff smerge-mode diff diff-mode git-commit log-edit pcvs-util add-log magit-core magit-autorevert magit-margin magit-transient magit-process with-editor magit-mode transient magit-git magit-base magit-section cursor-sensor crm project ob-lua ob-shell shell org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint org-pcomplete pcomplete org-list org-footnote org-faces org-entities ob-emacs-lisp ob-core ob-eval org-cycle org-table org-keys oc org-loaddefs find-func mu4e-main mu4e-view gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail mail-source utf7 nnoo parse-time iso8601 gnus-spec gnus-int gnus-range gnus-win gnus nnheader range cal-menu calendar cal-loaddefs mu4e-headers mu4e-compose mu4e-draft mu4e-actions smtpmail mu4e-search mu4e-lists mu4e-bookmarks mu4e-mark mu4e-message shr pixel-fill kinsoku url-file svg dom flow-fill hl-line mu4e-contacts mu4e-update mu4e-folders mu4e-server mu4e-context mu4e-vars mu4e-helpers mu4e-config bookmark ido message sendmail yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa epg rfc6068 epg-config gnus-util time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader vertico-directory mule-util highlight-defined advice noutline outline elec-pair isayt disp-table hideshow hl-todo savehist delsel pixel-scroll cua-base autorevert filenotify repeat vertico marginalia corfu-popupinfo cape corfu compat region-bindings recentf tree-widget gcmh init proxy gsettings s gvariant parsec dash zig-compilation-mode fennel-compilation-mode clojure-compilation-mode derived compile text-property-search server ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init ediff-util sql-indent sql view thingatpt comint ansi-osc ring zig-mode reformatter ansi-color ol org-fold org-fold-core org-compat org-version org-macs format-spec blog use-package-delight formfeed modus-vivendi-theme modus-themes dbus xml common-lisp-modes novice cus-edit pp cus-load wid-edit font mode-line messages defaults edmacro kmacro functions use-package-bind-key bind-key local-config delight comp comp-cstr warnings icons rx use-package-ensure cl-extra help-mode use-package-core early-init finder-inf blog-autoloads cape-autoloads clj-decompiler-autoloads clj-refactor-autoloads cider-autoloads clojure-mode-autoloads common-lisp-modes-autoloads consult-autoloads corfu-terminal-autoloads corfu-autoloads csv-mode-autoloads delight-autoloads dumb-jump-autoloads eat-autoloads elfeed-autoloads expand-region-autoloads fennel-mode-autoloads gcmh-autoloads geiser-guile-autoloads geiser-autoloads gnugo-autoloads ascii-art-to-unicode-autoloads gsettings-autoloads gvariant-autoloads highlight-defined-autoloads hl-todo-autoloads inflections-autoloads isayt-autoloads jdecomp-autoloads lsp-java-autoloads lsp-metals-autoloads dap-mode-autoloads lsp-docker-autoloads bui-autoloads lsp-treemacs-autoloads lsp-mode-autoloads f-autoloads lua-mode-autoloads marginalia-autoloads markdown-mode-autoloads message-view-patch-autoloads magit-autoloads pcase magit-section-autoloads git-commit-autoloads modus-themes-autoloads mu4e-alert-autoloads alert-autoloads log4e-autoloads gntp-autoloads multiple-cursors-autoloads orderless-autoloads org-modern-autoloads org-tree-slide-autoloads ox-hugo-autoloads package-lint-flymake-autoloads package-lint-autoloads paredit-autoloads parsec-autoloads parseedn-autoloads parseclj-autoloads phi-search-autoloads popon-autoloads popup-autoloads puni-autoloads easy-mmode racket-mode-autoloads region-bindings-autoloads request-autoloads scala-mode-autoloads separedit-autoloads edit-indirect-autoloads sesman-autoloads sly-autoloads spinner-autoloads sql-indent-autoloads tomelr-autoloads transient-autoloads treemacs-autoloads cfrs-autoloads posframe-autoloads ht-autoloads hydra-autoloads lv-autoloads pfuture-autoloads ace-window-autoloads avy-autoloads s-autoloads dash-autoloads vertico-autoloads vundo-autoloads with-editor-autoloads info compat-autoloads xpm-autoloads queue-autoloads yaml-autoloads yaml-mode-autoloads yasnippet-autoloads zig-mode-autoloads reformatter-autoloads package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win pgtk-dnd touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads xwidget-internal dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo gtk pgtk lcms2 multi-tty move-toolbar make-network-process native-compile emacs) Memory information: ((conses 16 672577 585595) (symbols 48 39874 485) (strings 32 183934 60222) (string-bytes 1 5724204) (vectors 16 69084) (vector-slots 8 1236810 764574) (floats 8 489 1785) (intervals 56 649 178) (buffers 992 11)) -- Andrey Listopadov
Andrey Listopadov <andreyorst@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#67246; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.