From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Complex SPEC for variables/customization like font-lock-keywords/org-capture-templates/etc (was: Instead of pcase) Date: Fri, 17 Nov 2023 08:54:31 +0000 Message-ID: <877cmgdak8.fsf@localhost> References: <87fs169mjj.fsf@posteo.net> <877cmhlhjp.fsf@web.de> <878r6xef86.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31627"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Michael Heerdegen , emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 17 09:52:59 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r3uaw-00083C-PF for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Nov 2023 09:52:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3uaD-0006Ia-4M; Fri, 17 Nov 2023 03:52:13 -0500 Original-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 ) id 1r3uaB-0006IO-98 for emacs-devel@gnu.org; Fri, 17 Nov 2023 03:52:12 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r3ua7-0002Pc-NF for emacs-devel@gnu.org; Fri, 17 Nov 2023 03:52:11 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 1770E240027 for ; Fri, 17 Nov 2023 09:52:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1700211124; bh=uabbmXRS9aM75e787OrdRnId44zrYquyAaZJbNuF/v8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=r7mpzkIHl1wJCqRlR5SMWYkkIuk3ygWv+hFro4sEi2mzqvZ9hGA44h2tNV91mr1eU JbHlk4uLbNU63OlHlyuqDHwoZJcT4tdTOJFQ4rQcTHeBhW+mn0JWByG058u9UFQDpS J9Ge/9x3Py2prgqrbFEreoTakIHHvSWKLYhX/EgrMA221rLczhU73bCcjhbFtX6AJT autWa4nOgE6ldfr3ZllfER+rIgV8xACdxtTn1aQFzE3CKVBun4ju4lv0XVwyD0qGmT vEkXnKm/V4NBnG6L+BYzxG1/di+/qEoWJgNjVW/E4YRsQxADFHygscODDjGDjyMbBj 5AIx9unlsou5A== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4SWrHk6VdHz6tvm; Fri, 17 Nov 2023 09:52:02 +0100 (CET) In-Reply-To: <878r6xef86.fsf@posteo.net> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312861 Archived-At: Philip Kaludercic writes: > Michael Heerdegen writes: > > ... If one has to talk about difficult to understand/remember > domain specific languages, then `font-lock-defaults' would be a much > more pressing candidate. Or font-lock-keywords... Last time I were seriously developing new keywords, I had to do it by trial-and-error and even examine font-lock sources. We also have similar issues with complex specifications in Org mode - org-capture-templates, org-agenda-custom-commands, etc. I believe that it is a general problem relevant various non-trivial variables/customization we have across Emacs and Emacs packages - developers, or, more frequently, Emacs users have significant difficulties understanding the obscure ad-hoc languages we have to invent for font-locking, templates, etc. The most common confusions are related to: 1. Quoting deeply nested lists 2. Keeping track of what each of the list elements refers to. For example, font-lock-keywords may contain something like (lisp--match-hidden-arg (0 '(face font-lock-warning-face help-echo "Easy to misread; consider moving the element to the next line") prepend)) It is hard to parse without constantly examining the docstring. Customize interface somewhat helps with (2), but many users avoid it and instead prefer to write init.el manually. Also, developers cannot even use customize interface (for example when developing font-lock-keywords). (1) is also a rather common problem, especially when both quoted and unquoted version of a list element are technically valid (for example, consider 'face-name vs. face-name in font-lock-keywords - a rather common confusion for me). I do not know a good solution to the above, and thus would like to discuss this problem. Some possible ideas: 1. Provide some universal mechanism for type-validation of variables. Something similar to :type spec in defcustom, but for Elisp variables. This will at least catch invalid values. 2. Provide custom warning mechanism catching common mistakes in the variables SPEC. For example, 'face-name vs. face-name for font-lock-keywords in the above example. 3. Enhance eldoc to show a tip about variable value structure, similar to what is done for function arguments. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at