From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gustavo Barros Newsgroups: gmane.emacs.devel Subject: Re: jinx Date: Wed, 19 Apr 2023 19:09:50 -0300 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15189"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , rms@gnu.org, m.eliachevitch@posteo.de, emacs-devel@gnu.org To: Arash Esbati Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 20 00:10:44 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 1ppG0h-0003lV-9O for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Apr 2023 00:10:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppG0B-0008RR-6q; Wed, 19 Apr 2023 18:10:11 -0400 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 1ppG0A-0008Pd-2k for emacs-devel@gnu.org; Wed, 19 Apr 2023 18:10:10 -0400 Original-Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ppG07-0002zQ-6v; Wed, 19 Apr 2023 18:10:09 -0400 Original-Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-63b5c48ea09so368696b3a.1; Wed, 19 Apr 2023 15:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681942202; x=1684534202; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=9liDGuuebkOZBS2mELgbsiLU9n5hMgZ1FRjrGzmyKwk=; b=qIVDx+R9DSPFpA28GWmQBeE91xeELjQZehnXNeC1fNaXW0yPW106dc91q48Xzo+yf3 bYAE1GoWMEw9DR9YzlYfZEIPNZL+gI4R04Kss8RyT9E0t9Q03JUQy2th1FccO3iEC1mu EjYtzMs0k3q+KiXg+sHpZfR5HckkiloqQReYNVhSOdYmk1IZ60X0C6jDn98WDiFC+rgS OxkcsIXkkL5VW2E8w0T9FaXidBOT9tQXaUKDviv7duHRtdBYAuocKt3rpZoGGB3pRGsT /FbU3AifRxdirPdzJFRTvaH7F351PDmdEn74hPXXjPWpOLWTutd+Q9ah8bdKB6zCnmRC 8aFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681942202; x=1684534202; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9liDGuuebkOZBS2mELgbsiLU9n5hMgZ1FRjrGzmyKwk=; b=Obaw0P/uS8yWxYcMBcvxPY60AfUiuf1ZOThh4IbWI2O0bedI4YtS8q0DmnpTkWhoio HaubrNuKbVaMtngdbpQKu83MwN6HT56++O9SxXqXB2ZsLOCBek1rPRo2oeqgx1JGAgh/ 2yFlAVVXOA1jn6uEWcgz0Z/2aWy2W7JAjKd+E3t7wuE2M8UD3hC0euLklrTnhelEcZru bxnT7+Ob0QjyEeGQ6H95BBhzjv70G/SD6bNrvO+37l1J95HzpPSSNbV4+iYaafk5/Kth 6/AkAcF+T3S+gAt2zC49e6hIWGWHDPMT8LJTUFEmNiTBy94ztfidgoRZGjSk2JXG50Bz 6aKg== X-Gm-Message-State: AAQBX9dtzRkI61mjIzhZ3F40948NYlmX6VGENv0eLVDvFQuMMJ0VZWnD OdauokcLUc8f7YAfTsxnTGJaxVxLu2fJzUErjfJw9fNzhpYF7w== X-Google-Smtp-Source: AKy350aXa9pz0LLOc5cXnUdiF7HuESwlRCZARGv09grAJpkf1+EcdrRYI1golxrma3MnGZQSHhHo0H5dqhjc3YCT1yI= X-Received: by 2002:a17:90a:9d85:b0:233:ee67:8eb3 with SMTP id k5-20020a17090a9d8500b00233ee678eb3mr4505067pjp.24.1681942202024; Wed, 19 Apr 2023 15:10:02 -0700 (PDT) Received-SPF: pass client-ip=2607:f8b0:4864:20::42c; envelope-from=gtvbrs@gmail.com; helo=mail-pf1-x42c.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, HK_RANDOM_ENVFROM=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-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:305469 Archived-At: Hi Arash, Hi All, Arash Esbati writes: > Somewhat off-topic, but it would be great if ispell and flyspell could > use the same logic for skipping portions of buffer text. Take for > example (La)TeX mode: ispell uses `ispell-tex-skip-alists' and flyspell > uses `flyspell-tex-command-regexp' (which is not very powerful) and then > a function added to `flyspell-generic-check-word-predicate' (AFAIU). I > once wrote an addition for AUCTeX (tex-ispell.el) which extends > `ispell-tex-skip-alists' for many LaTeX packages but had hard times > making it work with flyspell as well, skipping multi-line text portions > was something I couldn't solve for flyspell, e.g.: I've been trying pretty hard to make `jinx` work with AUCTeX this week, and perhaps I can chime in. And I also come from a background of heavily customizing `flyspell` for LaTeX. Jinx relies heavily on font-lock to be able to ignore certain parts of the buffer according to their faces. This is a powerful and fast approach, but comes with some challenges. I tried to summarize the main ones I found at an issue there (https://github.com/minad/jinx/issues/25#issuecomment-1512876646, see also https://github.com/minad/jinx/issues/40), and I shared there the following summary: ;; The way font-lock works in AUCTeX, as done by 'font-latex.el', poses some ;; challenges to the face based predicate for ignoring (or not) certain ;; parts of the buffer used by Jinx. ;; ;; 1. All optional arguments are fontified with a single face, ;; 'font-lock-variable-name-face', for all classes and all commands, and ;; that's hard-coded inside 'font-latex-match-command-with-arguments' with ;; no viable way to selectively control it. Even if arguably most optional ;; arguments are meant to be ignored, not all of them are, and there is no ;; way to distinguish the cases based on faces alone. ;; ;; 2. For each keyword class, and hence for every command in the class, a ;; single face is applied to all mandatory arguments. Therefore, if a macro ;; has one argument which should be spell checked and another that should ;; not, there is no way to distinguish them based on faces alone. ;; ;; 3. Since the keyword classes are populated with criteria other than spell ;; checking in mind it is not always easy to decide if a class of commands ;; should have its arguments ignored or not. Take the "reference" class, ;; for example, which includes most cross-referencing commands, whose ;; arguments are labels, but also "\footnote", "\footnotetext" and ;; "\marginpar". Besides, some keyword classes share the same face. ;; ;; 4. Given that (currently) the face predicate is called first by Jinx, at ;; the time the regexp predicate is called, point is already inside the ;; argument, meaning a regexp for the whole macro won't match, and which ;; macro that argument comes from can only be found out by expensive ;; backwards searching. ;; ;; To some extend, number 3 can be dealt with by tweaking font-lock with ;; regular tools ('font-latex-add-keywords' etc.), possibly requiring ;; personal style files in many cases. How much this is a meaningful way to ;; deal with the problem, I'm not sure. ;; ;; A reordering of the ignore predicates may help with 4, but it doesn't ;; fully solve the problem either. Because it is easy to use a regexp to ;; ignore a command which the faces predicate would not, but not the other ;; way around. So, if you have a command using a face which is part of ;; 'jinx-exclude-faces' but should be spell checked, the only way to deal ;; with it would be to remove the face altogether from 'jinx-exclude-faces', ;; and then handling all the other commands which use that face be ignored ;; by regexps. Not an appealing route. ;; ;; But numbers 1 and 2 remain impossible to tackle with current machinery ;; since there's no way to distinguish the parts of a regexp what should be ;; spell checked from those that shouldn't. It is quite possible though to complement font-lock to cover these gaps though. My attempt at it ran in the following lines: https://github.com/minad/jinx/issues/25#issuecomment-1511954696 By now I've generalized this a little, and can reach outstanding results solely based on font-locking, faces, plus some extra added command/argument specific properties. Better than what I had on a heavily customized `flyspell` for the same purpose. I don't add a single TeX specific regexp to my config. It must be said though that `flyspell` already supports custom predicates through `flyspell-generic-check-word-predicate`. So using the same approach with `flyspell` is a matter of "plugging it in" there. With faces (and some little extra properties to guide spell checking) in hand, the predicate itself is trivial. Best, Gustavo.