From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Martin Marshall Newsgroups: gmane.emacs.devel Subject: Code snippets/template consolidation and potential improvements Date: Wed, 17 Jan 2024 16:48:52 -0500 Message-ID: <877ck7r5q3.fsf@martinmarshall.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9078"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 18 06:24:05 2024 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 1rQKsm-00027W-VD for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Jan 2024 06:24:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rQKs8-0004UC-HO; Thu, 18 Jan 2024 00:23:24 -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 1rQDmL-0004UZ-Tm for emacs-devel@gnu.org; Wed, 17 Jan 2024 16:48:57 -0500 Original-Received: from mail-yw1-x1130.google.com ([2607:f8b0:4864:20::1130]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rQDmJ-0004S3-Os for emacs-devel@gnu.org; Wed, 17 Jan 2024 16:48:57 -0500 Original-Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-5ff821b9acfso3077727b3.1 for ; Wed, 17 Jan 2024 13:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=martinmarshall-com.20230601.gappssmtp.com; s=20230601; t=1705528134; x=1706132934; darn=gnu.org; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=c0+6VPDDR5uFCM2wGD2widlfykdCEtpY8cJe03f8SL8=; b=1p9cybr8twCOIvG/1tPPvTsJ9H78LfDBpyU8/XZBIxMtVaeukTYI02VRPrTsr8Du6C DTSJKQNpOLRksT8yETD6i8xUwrEpuA24GBvz60RJhQUfrDdR55S2IM8+9LqdyrWPuBbs ay/kHDAE75EjL1SYiODtb7pjyPSyWk8ZbaiunutHK2Ejq8XIawO1jIcPqwbivIOLeI1z W8k+13yxr6hX7flliYAaziXhXolOhazW2WfzQlBig4xw3FJaTOtUg9EgFFUCaoJYHI3h ASrBGIdebsDaS+8ySRBzIbzuvPRJZiZwT8NHu97FA9FDYbkMg85jA70pBrCoHlDrW4Tl kjew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705528134; x=1706132934; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=c0+6VPDDR5uFCM2wGD2widlfykdCEtpY8cJe03f8SL8=; b=BmYP6BoqMWS4YC0pRht1ApEaNm64zEjJMsmDUblk7poltE4CXAh0h2ra0PnXyFurth 3ieuv0tinKiHkQl3vTGnRkQmwFzgu7T0hU6h9DsJ5wAwWzMd3sllO/GZYOgX7unlbh9l WSQUxN1/6SRii0AdLzG2T3fmgseKden49iEyM3eCnemD1XOJKP3wcVJv1VGtywYzNDc5 mYDS/bxdrN76OuSwzTuhTDz7SoNZN9X0W4DdX+iLXJhHNJUkBdBu0jOVZtT1n/LXRWEa eBDA92ZZXAHoQvx5kfxCVJhj+sQFGx0mZ4BTAhDKcZaCIFfcfOVks7m9OvxKJlG5AdRx aVDg== X-Gm-Message-State: AOJu0YwEZIxrYjPG3/sCFLffH48mAQ9JuS7L8ZkhxmWRHwU0D4kIeZ25 Fr5WdRBomhoN4QXZRqOYbhyKToMw8j+tKQn+h+AqdDVJEbJZ X-Google-Smtp-Source: AGHT+IGJmZFOlF3j1eOz6yHN8bz00qmPXRnkt1k9gbf7py88okXCUlNcsfYW9ZLrrx95GXhAkihR+A== X-Received: by 2002:a81:f006:0:b0:5ff:3120:e947 with SMTP id p6-20020a81f006000000b005ff3120e947mr3989740ywm.10.1705528133961; Wed, 17 Jan 2024 13:48:53 -0800 (PST) Original-Received: from vader (68-252-220-225.lightspeed.tukrga.sbcglobal.net. [68.252.220.225]) by smtp.gmail.com with ESMTPSA id h184-20020a816cc1000000b005ff6aa8e404sm805248ywc.6.2024.01.17.13.48.53 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jan 2024 13:48:53 -0800 (PST) Received-SPF: none client-ip=2607:f8b0:4864:20::1130; envelope-from=law@martinmarshall.com; helo=mail-yw1-x1130.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 18 Jan 2024 00:23:23 -0500 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:315068 Archived-At: (Please accept my apologies in advance for the long message. I've tried to organize it to make it easier to digest or piece through, at the reader's option.) Hello, there's an item in the TODO file regarding Emacs's template systems[1], but I'm not sure if I understand it the way it's intended. What is meant by "consolidate", and what specific improvements should be prioritized? I've been looking through the templating packages for a while, thinking about ways to improve them and writing some code. I hope to start a discussion, obtain guidance on improvements to submit, and coordinate with anyone else who has the time and desire to work on this. Here are a few ideas I have, along with some background information: - Make the same location-jumping commands usable without regard to which template package was used.[2] + Current situation: expand.el provides commands[3] for jumping within its templates. Skeleton templates can use the same commands to a limited extent.[4] Observation: Only one template at a time can use the expand.el commands. When a new template expands, it clears the markers stored by the last template. On the other hand, this makes it possible for expand.el abbreviations to set markers in a non-linear order (since they don't need to be sorted with other templates' markers). + Current situation: tempo.el includes its own commands for jumping to locations within tempo templates.[5] Observation: Unlike the expand.el commands, the markers that tempo.el stores when expanding a template will persist between template expansions and the locations are sorted automatically. This allows you to nest a template inside of a surrounding template without losing the location-markers of the surrounding template. Would it be desirable to have one or both packages' jumping commands made usable for all 3 template systems? It seems they have different benefits and drawbacks. - Improve the expand.el package. Expand.el makes an excellent simplified templating system, but it's unknown to most users and its out-of-the-box method for defining templates isn't convenient. It improves upon traditional abbrevs by adding a single very useful feature, the ability to jump to specified locations within the expanded text. + Current situation: Defining an expand.el abbrev involves calling 'expand-add-abbrev' (or 'expand-add-abbrevs') and providing a manually-calculated list of location indices for use by expand.el's location-jumping commands. Some ideas to improve the method of defining expand.el abbrevs: * Provide an interactive method of defining expand.el templates. Since this is the simplest of the template systems, it should have the simplest method for defining templates. This works much like the traditional interactive method of defining an abbrev. You select the expansion text and call a command to define the abbrev. But then a buffer pops up containing the expansion text, and you can designate the jump-locations on the text in this buffer. This would allow creation of templates without any specialized syntax, not even Elisp. * Provide a function for defining an expand.el abbrev that allows designating jump-locations by a special character in the expansion string. By default, this would use the "@" character, because that's what skeletons use. But unlike a skeleton definition, this is a text character within the expansion string, not a symbol. In case "@" is to be part of the expanded text, a different character can be specified by passing an optional argument to the function call. + Current situation: Expand.el doesn't come with prompting of any kind. It would be more useful if there were some way to remind oneself what text to insert at a specific point, or provide some default text that could be easily replaced. I think expand.el's strength is its simplicity, but I also think it can be improved without making it overly complex. Idea: * Extend expand.el templates so that a jump-location can be either a single location or a region which becomes activated upon reaching it with one of the jumping commands. Once activated, the region can be left as-is, overwritten by newly typed text, or deleted by simply pressing "DEL". This is a feature included in many more modern template systems (e.g.\nosentn{} yasnippets, temp= el templates). Caveat: Adding this feature might complicate consolidation of the location-jumping commands. A potential way to alleviate that would be to add this to skeleton.el's and tempo.el's templates. + Expand.el isn't documented. Idea: * After adding new features and consolidating expand.el with the other template systems, document it in the Autotyping manual and/or the Emacs manual. There's almost no mention of expand.el online, but I find the simplicity of its templates quite attractive. You expand an abbrev and can jump to locations within the expanded text. I imagine this covers the requirements of 80-90% of templates. Most of the time you just need some pre-written text with an easy way to change specific parts of it. - Consolidation in general How should these template systems be consolidated? + Should there be a single function/macro for creating any type of template? + Should the definition syntax itself be consolidated? (I would think not, but the meaning of "consolidate" might encompass that.) >From my perspective, Emacs's existing template options each fill a role, because each comes with different levels of versatility, which correlates to the learning curve of a user getting started with one of them. If you have read this far (or even if you just jumped to this location), I thank you for your attention! Footnotes: [1] It reads, "** Improve the 'code snippets' support=20 Consolidate skeleton.el, tempo.el, and expand.el (any other?) and then advertise/use/improve it." [2] This was the subject of a patch I submitted a couple of days ago, but that may have been premature. [3] They are 'expand-jump-to-next-slot' and 'expand-jump-to-previous-slot', bound by default to "C-x=C2=A0a=C2=A0n" and "C-x=C2=A0a=C2=A0p" respectively. [4] The locations are specified in the skeleton using '@' symbols. The skeleton must be added to an abbrev-table using 'expand-add-abbrev', and the commands will only work when the skeleton has been expanded by the abbrev. They will not work when the skeleton was expanded by calling its command (unless you've applied my patch to expand.el and skeleton.el). [5] The tempo.el commands are 'tempo-forward-mark' and 'tempo-backward-mark'. They have no default keybindings. --=20 Best regards, Martin Marshall