From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers Date: Tue, 7 May 2024 14:15:33 +0100 Message-ID: References: <1de34060-e93b-0a42-fff5-20e283abe0dc@yandex.ru> <87o7vq0zir.fsf@gnus.org> <8735d20yvd.fsf@gnus.org> <2c5c8afa-b57e-3156-d21c-5523cacb4d87@yandex.ru> <831qf1mgjl.fsf@gnu.org> <87cyyj9rpp.fsf@gnu.org> <65793.1694843596@localhost> Reply-To: David Fussner Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="000000000000a3763c0617dcfada" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13943"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53749@debbugs.gnu.org, Ikumi Keita , Tassilo Horn , Arash Esbati , stefankangas@gmail.com, Dmitry Gutov , Eli Zaretskii To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 07 15:16:05 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1s4Kft-0003Rr-CA for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 May 2024 15:16:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s4Kff-0007Cv-TS; Tue, 07 May 2024 09:15:52 -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 1s4KfU-00079W-8j for bug-gnu-emacs@gnu.org; Tue, 07 May 2024 09:15:41 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s4KfS-0005fP-EZ for bug-gnu-emacs@gnu.org; Tue, 07 May 2024 09:15:38 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s4Kfp-0004UV-Rf for bug-gnu-emacs@gnu.org; Tue, 07 May 2024 09:16:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David Fussner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 May 2024 13:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53749 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: pending patch Original-Received: via spool by 53749-submit@debbugs.gnu.org id=B53749.171508776117257 (code B ref 53749); Tue, 07 May 2024 13:16:01 +0000 Original-Received: (at 53749) by debbugs.gnu.org; 7 May 2024 13:16:01 +0000 Original-Received: from localhost ([127.0.0.1]:42652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4Kfn-0004UH-Tr for submit@debbugs.gnu.org; Tue, 07 May 2024 09:16:00 -0400 Original-Received: from mail-pl1-x631.google.com ([2607:f8b0:4864:20::631]:59613) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s4Kfk-0004U9-GJ for 53749@debbugs.gnu.org; Tue, 07 May 2024 09:15:57 -0400 Original-Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1ecddf96313so26750015ad.2 for <53749@debbugs.gnu.org>; Tue, 07 May 2024 06:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20230601; t=1715087726; x=1715692526; 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=Gh5YrPgBnl8LygP/+wg28snfCrtXdUCs4LqxlcUXS1o=; b=dPcoqpOapFz/6HIb6omWIw86nyXD2qC7bOpALmPtB0Oqq78/Ra2Kuu+JJ4tWUDYjRr DNzkU1GyWgpVSFdALOgsT5/F6hs8qo80DNgZF9hmf2zRkQPSG30BzH3KuKi/heKhzpXH BIJPcwrK4HSh4GMVdr6/lsdjEC+Sca/9dC2QBQRE7RRMKqRsgz1IUGbzwdfN2nMtlEUJ 1i87dETHMU+cjwFfxz3QJ0PPTiJ8UoMsphD2cA0U6cuMnftsixT/HMxxzV4p5a+vFq/p ZAnV3jdXS65g8T/aFN0ehP1lnIB/RwfF90ZmbWsjwWE2E35a5lX/eZdloUe3p89Ljrbt BLZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715087726; x=1715692526; 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=Gh5YrPgBnl8LygP/+wg28snfCrtXdUCs4LqxlcUXS1o=; b=WYmwF645d0COEGalxhj7/72dlOk3kUr61vBNamcWewH6sKR/LGd2r7zm4XdllDVxHG +ODcONckl2nSiMtEBBOFHR6mb9Bc7VkF2jnOy4LZtzKus1Lgs3ijgwXfZ62QMzLXTB7r koLvOlsnzKDLH7eNDForEQI92t6J2BFrBSzQwfoZkb7FO10JZdkNHgzUfQRmHUbJJ2Qo QGgY+aIyQat3t06Wa+A1BTnrk+DUyyuzfHgFCxkfnZ3rId7baknJNdExIAZbPgk6W4xp qG2m3flDDmU5e/suYd9qvXG8jwBE75VNwItWQoNDS+3SwdPcxFLkTQhlv4WTpcjzIpAj Ogvw== X-Forwarded-Encrypted: i=1; AJvYcCWDxJs13fEl+Ij1uaDeVszRf/cF6KfVg6nmOk4D0m0n+UI35udpbuYXhdkgxSHJ3lQRO0bmUgDQGmhv6/3PO+usbgX0Djk= X-Gm-Message-State: AOJu0Yz2KSH9r63KGL97Rut66pKEEe7cVZlCuI94segK3EYEwdBYBMgF UV3JG9uUar+RxzaqN+jas9KzTYvHV2TY/n9aP3k4m3828kSfAIxBB+jry0QnltvARgE9TO17CjW jsCk7sTADc1NVQ8HHF0bTq3fX+LwO+I9M8yQ= X-Google-Smtp-Source: AGHT+IGYe4ERX3/pMPSnOxc+wtxOX82121gR3afT85/lMqxfvUSyibjxOrq3Ca+5CnrFp17xYAtOrzxB29wZROhq75k= X-Received: by 2002:a17:90b:684:b0:2b4:329e:e373 with SMTP id m4-20020a17090b068400b002b4329ee373mr13854095pjz.6.1715087725517; Tue, 07 May 2024 06:15:25 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:284639 Archived-At: --000000000000a3763c0617dcfada Content-Type: text/plain; charset="UTF-8" Hi Stefan, I apologize in advance if my reply gets lengthy. > Also I don't clearly see how the above regexp distinguishes expl3 code > from "normal" LaTeX code, so the comment should say something about it. You are quite right that the regexp can (and does) match "normal" LaTeX code, and I can see that this isn't acceptable as it stands. The only way to be sure about ":" and "_" is to determine whether they're inside a matched pair of \ExplSyntaxOn \ExplSyntaxOff macros (or in a file which does something like \ProvidesExpl[File|Class]). The file case can, I think, be sorted by modifying the syntax table as part of setting up the relevant major modes. The temporary toggling of ExplSyntax is trickier, but I have some proof-of-concept code that adds a function to the `syntax-propertize-extend-region-functions' hook that creates a list (`tex-expl-region-list`) of the start and end of all such regions in a buffer and updates it whenever `syntax-propertize` runs. In the `syntax-propertize-function` we test whether hits are inside one of these regions and only change the syntax when they are. (A very lightly-tested and incomplete patch on top of my earlier patch is attached. It only applies to the "_" now, but would need extending to the other sub-matches, too.) > Currently we "skip" inappropriate underscores via > `tex-font-lock-match-suscript` and/or by adding a particular `face` text > property rather than via `syntax-table/propertize`. > > For algorithmic reasons, it's better to minimize the work done in > `syntax-propertize-function` as much as possible (font-lock is more lazy > than `syntax-propertize`), so I recommend you try and moving the above > to font-lock rules. The reason I've been using `syntax-propertize` rather than `font-lock` is because the former may confer advantages when using `xref-find-references`, but that in turn depends on how we decide to define that function in the `tex-etags` backend. Please see below. In any case, I think I can easily use `tex-expl-region-list` in a test for how to fontify "_", so if you don't object to the addition of `tex-expl-region-set` to the `syntax-propertize-extend-region-functions' hook then we should be able to get pretty close to a rigorous demarcation between "normal" LaTeX and expl3 code in this context. > > + (setq-local syntax-propertize-function > > + (eval > > + `(tex-xref-syntax-function > > + ,identifier ,beg ,end))) > > Why do we need to change `syntax-propertize-function` and why do we need > `eval`? > > > + (setq syntax-propertize--done 0) > > This is not sufficient. You want to `syntax-ppss-flush-cache`. We only need `eval` because I'm confused about the handling of macros -- I have some code in progress to fix this. As for why we need to change `syntax-propertize-function`, that's the core of the issue with `xref-find-references`. In the current patch, the wrapper for the standard `xref-backend-references` gathers file extensions and also tests whether the search string begins and/or ends with a non-word, non-symbol character. In `xref-references-in-directory` the only hits offered to the user match (format "\\_<%s\\_>" ...), so I create a bespoke `syntax-propertize-function` to ensure that the search string matches that format. (Actually, I would need to improve that to cope with searches for "\command" in code that looks like "\let\command\othercommand" -- even when the "\" has the right syntax the search fails because the "t" in "let" doesn't.) My mental model for `syntax-propertize` was/is insufficient, as you point out, so your improvement ensures that buffers return to the status quo ante after the search is complete, but it's still an open question whether we want to do this at all. I see at least 3 options: 1. The maximalist approach, which tries to ensure that any TeX symbol may be searched for successfully, even if the syntax of its components is inconvenient. My patch is a (faulty) attempt at this. 2. The minimalist approach, providing no bespoke `syntax-propertize-function`, and accepting failure when searching some strings, especially strings which aren't offered up by default. (In the above example, "command" would be the default offered up, so manual intervention is needed to search for "\command".) In this case I'd be very keen to have the expl3 "_" and ":" code actually in `syntax-propertize`, because then searches for expl3 constructs (without the "\") would work. (I'd also be very keen on having something similar in AUCTeX, though their current method works fine in most files.) 3. The non-standard approach, the `tex-etags` backend calling a variant of `project-find-regexp` instead of `xref-backend-references` when someone presses M-?. We could supply file extensions to search, as now, and allow the choice of projects and/or directories, as now, but the output will always be very non-standard, more like `xref-backend-apropos` than `xref-backend-references`. The syntax of the search string won't matter, and the problem will be "too many hits" rather than "too few or none". If you have any thoughts on the matter I'd be all ears. > > +(add-to-list 'auto-mode-alist '("\\.[tT]e[xX]\\'" . latex-mode) t) > > Maybe I have not followed the whole discussion closely enough, but at > least to me the above "soon" is very unclear. > I'll assume that this code will be removed before we install the patch. > If not, please explain in the comment why this specific hack is needed > and how it works. As soon as AUCTeX has "*.[tT]e[xX]" in its contributions to `semantic-symref-filepattern-alist` this will be redundant. As it stands, not searching *.tex files for symbols in LaTeX-mode buffers is kind of terrible. > > +;; Setup AUCTeX modes (for testing purposes only). > > + > > +(add-hook 'TeX-mode-hook #'tex-set-auctex-xref-backend) > > + > > +(defun tex-set-auctex-xref-backend () > > + (add-hook 'xref-backend-functions #'tex--xref-backend nil t)) > > I assume this will be sent to AUCTeX and is not meant to be in > `tex-mode.el`, right? Yes. Please assume I agree with all of your other corrections and clarifications, and that I'll modify the patch accordingly. Once again, thank you for the careful review, and my apologies for occupying too much of your time. Best, David. On Fri, 3 May 2024 at 15:11, Stefan Monnier wrote: > > Hi, > > Apparently I'm the `tex-mode.el` guy, so I tried to take a look. > > > diff --git a/lisp/textmodes/tex-mode.el b/lisp/textmodes/tex-mode.el > > index 97c950267c6..d990a2dbfa9 100644 > > --- a/lisp/textmodes/tex-mode.el > > +++ b/lisp/textmodes/tex-mode.el > > @@ -695,7 +696,25 @@ tex-verbatim-environments > > ("\\\\\\(?:end\\|begin\\) *\\({[^\n{}]*}\\)" > > (1 (ignore > > (tex-env-mark (match-beginning 0) > > - (match-beginning 1) (match-end 1)))))))) > > + (match-beginning 1) (match-end 1))))) > > + ;; The next two rules change the syntax of `:' and `_' in expl3 > > + ;; constructs, so that `tex-font-lock-suscript' can fontify them > > + ;; more accurately. > > + ((concat "\\(\\(?:[\\\\[:space:]{]_\\|" > > + "[\\\\{[:space:]][^][_[:space:][:cntrl:][:digit:]\\\\{}()/=]+\\)" > > + "\\(?:_+\\(?:[^][[:space:][:cntrl:][:digit:]:\\\\{}()/#_=]+\\|" > > + "#+[1-9]\\)\\)+\\)\\([:_]?\\)") > > Can you add in the comment some URL pointing to some relevant expl3 > documentation which "explains" why the above regexp makes sense? > Also I don't clearly see how the above regexp distinguishes expl3 code > from "normal" LaTeX code, so the comment should say something about it. > > Side note: I'd avoid [:space:] whose exact meaning is rarely quite what > we need. > Side note: backslash doesn't need to be backslashed in [...]. > > > + (1 (ignore > > + (let* ((expr (buffer-substring-no-properties (match-beginning 1) > > + (match-end 1))) > > + (list (seq-positions expr ?_))) > > + (dolist (pos list) > > + (put-text-property (+ pos (match-beginning 1)) > > + (1+ (+ pos (match-beginning 1))) > > + 'syntax-table (string-to-syntax "_")))))) > > + (2 "_")) > > + ("\\\\[[:alpha:]]+\\(:\\)[[:alpha:][:space:]\n]" > > + (1 "_"))))) > > Currently we "skip" inappropriate underscores via > `tex-font-lock-match-suscript` and/or by adding a particular `face` text > property rather than via `syntax-table/propertize`. > > For algorithmic reasons, it's better to minimize the work done in > `syntax-propertize-function` as much as possible (font-lock is more lazy > than `syntax-propertize`), so I recommend you try and moving the above > to font-lock rules. > > > +(defvar tex-esc-and-group-chars '(?\\ ?{ ?}) > > + "The current TeX escape and grouping characters. > > I recommend you backslash escape the { and } above (although it's not > indispensable, `emacs-lisp-mode` will parse the code better). > More importantly, the docstring doesn't explain what this list > means/does. E.g. does the order matter? Can it be longer than 3 elements? > > From the current docstring I can't guess what would be the consequence > of adding/removing elements to/from this list. > > > +;; Populate `semantic-symref-filepattern-alist' for the in-tree modes; > > +;; AUCTeX is doing the same for its modes. > > +(defvar semantic-symref-filepattern-alist) > > +(with-eval-after-load 'semantic/symref/grep > > + (push '(latex-mode "*.[tT]e[xX]" "*.ltx" "*.sty" "*.cl[so]" > > + "*.bbl" "*.drv" "*.hva") > > + semantic-symref-filepattern-alist) > > + (push '(plain-tex-mode "*.[tT]e[xX]" "*.ins") > > + semantic-symref-filepattern-alist) > > + (push '(doctex-mode "*.dtx") semantic-symref-filepattern-alist)) > > We know `semantic-symref-filepattern-alist` will exist when > `semantic/symref/grep` is loaded, but not before, so I'd put the > `defvar` inside the `with-eval-after-load`. > > > +;; Setup AUCTeX modes (for testing purposes only). > > + > > +(add-hook 'TeX-mode-hook #'tex-set-auctex-xref-backend) > > + > > +(defun tex-set-auctex-xref-backend () > > + (add-hook 'xref-backend-functions #'tex--xref-backend nil t)) > > I assume this will be sent to AUCTeX and is not meant to be in > `tex-mode.el`, right? > > > +;; `xref-find-references' currently may need this when called from a > > +;; latex-mode buffer in order to search files or buffers with a .tex > > +;; suffix (including the buffer from which it has been called). We > > +;; append it to `auto-mode-alist' so as not to interfere with the usual > > +;; mode-setting apparatus. Changes here and in AUCTeX should soon > > +;; render it unnecessary. > > +(add-to-list 'auto-mode-alist '("\\.[tT]e[xX]\\'" . latex-mode) t) > > Maybe I have not followed the whole discussion closely enough, but at > least to me the above "soon" is very unclear. > I'll assume that this code will be removed before we install the patch. > If not, please explain in the comment why this specific hack is needed > and how it works. > > > +(cl-defmethod xref-backend-references ((_backend (eql 'tex-etags)) identifier) > > + "Find references of IDENTIFIER in TeX buffers and files." > > + (require 'semantic/symref/grep) > > + (let (bufs texbufs > > + (mode major-mode)) > > + (dolist (buf (buffer-list)) > > + (if (eq (buffer-local-value 'major-mode buf) mode) > > + (push buf bufs) > > + (when (string-match-p ".*\\.[tT]e[xX]" (buffer-name buf)) > > + (push buf texbufs)))) > > + (unless (seq-set-equal-p tex--buffers-list bufs) > > + (let* ((amalist (tex--collect-file-extensions)) > > + (extlist (alist-get mode semantic-symref-filepattern-alist)) > > + (extlist-new (seq-uniq > > + (seq-union amalist extlist #'string-match-p)))) > > After sinking the `defvar` above, you'll need to add a new `defvar` for > `semantic-symref-filepattern-alist` just after the `require`. > > > + (setq-local syntax-propertize-function > > + (eval > > + `(tex-xref-syntax-function > > + ,identifier ,beg ,end))) > > Why do we need to change `syntax-propertize-function` and why do we need > `eval`? > > > + (setq syntax-propertize--done 0) > > This is not sufficient. You want to `syntax-ppss-flush-cache`. > > > Stefan > --000000000000a3763c0617dcfada Content-Type: text/x-patch; charset="US-ASCII"; name="0001-expl-region.patch" Content-Disposition: attachment; filename="0001-expl-region.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lvwecdhu0 ZGlmZiAtLWdpdCBhL2xpc3AvdGV4dG1vZGVzL3RleC1tb2RlLmVsIGIvbGlzcC90ZXh0bW9kZXMv dGV4LW1vZGUuZWwKaW5kZXggZDk5MGEyZGJmYTkuLmIyYTY0MTZmMzc5IDEwMDY0NAotLS0gYS9s aXNwL3RleHRtb2Rlcy90ZXgtbW9kZS5lbAorKysgYi9saXNwL3RleHRtb2Rlcy90ZXgtbW9kZS5l bApAQCAtNzA1LDE3ICs3MDUsMzYgQEAgdGV4LXZlcmJhdGltLWVudmlyb25tZW50cwogICAgICAg ICAgICAgICAiXFwoPzpfK1xcKD86W15dW1s6c3BhY2U6XVs6Y250cmw6XVs6ZGlnaXQ6XTpcXFxc e30oKS8jXz1dK1xcfCIKICAgICAgICAgICAgICAgIiMrWzEtOV1cXClcXCkrXFwpXFwoWzpfXT9c XCkiKQogICAgICAgKDEgKGlnbm9yZQotICAgICAgICAgIChsZXQqICgoZXhwciAoYnVmZmVyLXN1 YnN0cmluZy1uby1wcm9wZXJ0aWVzIChtYXRjaC1iZWdpbm5pbmcgMSkKLSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobWF0Y2gtZW5kIDEpKSkK LSAgICAgICAgICAgICAgICAgKGxpc3QgKHNlcS1wb3NpdGlvbnMgZXhwciA/XykpKQotICAgICAg ICAgICAgKGRvbGlzdCAocG9zIGxpc3QpCi0gICAgICAgICAgICAgIChwdXQtdGV4dC1wcm9wZXJ0 eSAoKyBwb3MgKG1hdGNoLWJlZ2lubmluZyAxKSkKLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICgxKyAoKyBwb3MgKG1hdGNoLWJlZ2lubmluZyAxKSkpCi0gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAnc3ludGF4LXRhYmxlIChzdHJpbmctdG8tc3ludGF4ICJfIikpKSkp KQorICAgICAgICAgICh3aGVuIHRleC1leHBsLXJlZ2lvbi1saXN0CisgICAgICAgICAgICAobGV0 ICgobWF0Y2ggKG1hdGNoLWJlZ2lubmluZyAxKSkpCisgICAgICAgICAgICAgIChjYXRjaCAncmVz dWx0CisJICAgICAgICAoZG9saXN0IChyYW5nZSB0ZXgtZXhwbC1yZWdpb24tbGlzdCkKKwkgICAg ICAgICAgKGFuZCAoPiBtYXRjaCAoY2FyIHJhbmdlKSkKKwkgICAgICAgICAgICAgICAoPCBtYXRj aCAoY2RyIHJhbmdlKSkKKyAgICAgICAgICAgICAgICAgICAgICAgKGxldCogKChleHByIChidWZm ZXItc3Vic3RyaW5nLW5vLXByb3BlcnRpZXMKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAobWF0Y2gtYmVnaW5uaW5nIDEpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKG1hdGNoLWVuZCAxKSkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAo bGlzdCAoc2VxLXBvc2l0aW9ucyBleHByID9fKSkpCisgICAgICAgICAgICAgICAgICAgICAgICAg KGRvbGlzdCAocG9zIGxpc3QpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAocHV0LXRleHQt cHJvcGVydHkgKCsgcG9zIChtYXRjaC1iZWdpbm5pbmcgMSkpCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKDErICgrIHBvcyAobWF0Y2gtYmVnaW5uaW5nIDEp KSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnc3ludGF4 LXRhYmxlCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHN0 cmluZy10by1zeW50YXggIl8iKSkpKQorICAgICAgICAgICAgICAgICAgICAgICAodGhyb3cgJ3Jl c3VsdCB0KSkpKSkpKSkKICAgICAgICgyICJfIikpCiAgICAgICgiXFxcXFtbOmFscGhhOl1dK1xc KDpcXClbWzphbHBoYTpdWzpzcGFjZTpdXG5dIgogICAgICAgKDEgIl8iKSkpKSkKIAorKGRlZnZh ci1sb2NhbCB0ZXgtZXhwbC1yZWdpb24tbGlzdCBuaWwpCisKKyhkZWZ1biB0ZXgtZXhwbC1yZWdp b24tc2V0IChfYmVnIF9lbmQpCisgIChzZXRxIHRleC1leHBsLXJlZ2lvbi1saXN0IG5pbCkKKyAg KGdvdG8tY2hhciAocG9pbnQtbWluKSkKKyAgKHdoaWxlIChyZS1zZWFyY2gtZm9yd2FyZCAiXFxF eHBsU3ludGF4T24iIG5pbCB0KQorICAgIChsZXQgKChuZXctYmVnIChwb2ludCkpCisgICAgICAg ICAgKG5ldy1lbmQgKHJlLXNlYXJjaC1mb3J3YXJkICJcXEV4cGxTeW50YXhPZmYiIG5pbCB0KSkp CisgICAgICAoYWRkLXRvLWxpc3QgJ3RleC1leHBsLXJlZ2lvbi1saXN0IChjb25zIG5ldy1iZWcg bmV3LWVuZCkgdCkpKSkKKwogKGRlZnVuIHRleC1lbnYtbWFyayAoY21kIHN0YXJ0IGVuZCkKICAg KHdoZW4gKD0gY21kIChsaW5lLWJlZ2lubmluZy1wb3NpdGlvbikpCiAgICAgKGxldCAoKGFyZyAo YnVmZmVyLXN1YnN0cmluZy1uby1wcm9wZXJ0aWVzICgxKyBzdGFydCkgKDEtIGVuZCkpKSkKQEAg LTEzMDgsNiArMTMyNyw4IEBAIHRleC1jb21tb24taW5pdGlhbGl6YXRpb24KICAgICAgICAgICAg ICAgICAjJ3RleC0tcHJldHRpZnktc3ltYm9scy1jb21wb3NlLXApCiAgIChzZXRxLWxvY2FsIHN5 bnRheC1wcm9wZXJ0aXplLWZ1bmN0aW9uCiAJICAgICAgKHN5bnRheC1wcm9wZXJ0aXplLXJ1bGVz IGxhdGV4LXN5bnRheC1wcm9wZXJ0aXplLXJ1bGVzKSkKKyAgKGFkZC1ob29rICdzeW50YXgtcHJv cGVydGl6ZS1leHRlbmQtcmVnaW9uLWZ1bmN0aW9ucworICAgICAgICAgICAgICAgICAgIyd0ZXgt ZXhwbC1yZWdpb24tc2V0IG5pbCB0KQogICA7OyBUQUJzIGluIHZlcmJhdGltIGVudmlyb25tZW50 cyBkb24ndCBkbyB3aGF0IHlvdSB0aGluay4KICAgKHNldHEtbG9jYWwgaW5kZW50LXRhYnMtbW9k ZSBuaWwpCiAgIDs7IFNldCB1cCB4cmVmIGJhY2tlbmQgaW4gVGVYIGJ1ZmZlcnMuCg== --000000000000a3763c0617dcfada--