From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aaron Jensen Newsgroups: gmane.emacs.bugs Subject: bug#60321: 29.0.60; ruby-mode indentation of hash or array as first arg in multiline method call Date: Sat, 31 Aug 2024 16:41:48 -0700 Message-ID: References: <4e44df18-207c-c7ca-0588-7285f3008dfb@yandex.ru> <358bbd65-9375-04c8-f0a2-24a4383f142e@yandex.ru> <2b4a91e1-bad1-382f-dd64-abf171efb404@yandex.ru> <60e207e0-7378-ad9f-3ef0-99df1c139939@yandex.ru> <902440c7-706a-20e1-55af-4e12e8cdda2c@yandex.ru> <1191195d-1528-dc2a-64e0-15426e4b5608@yandex.ru> <75342f40-d576-e1c6-3d63-692b80e78bfe@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="00000000000069c1cd06210340ae" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="810"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60321@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 01 01:43:20 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 1skXkV-000AdX-Nm for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Sep 2024 01:43:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1skXkJ-0004mm-Rz; Sat, 31 Aug 2024 19:43:07 -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 1skXkG-0004kZ-OV for bug-gnu-emacs@gnu.org; Sat, 31 Aug 2024 19:43:05 -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 1skXkF-0004rx-W8 for bug-gnu-emacs@gnu.org; Sat, 31 Aug 2024 19:43:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:In-Reply-To:From:References:Mime-Version:To:Subject; bh=BcC4oiYmPPfe0goa9pspdszbEUbn/dYCNG6KOVBSwsU=; b=bicSh2jmJZ3vw9vaOjffIJ/z0ju6UbXxW6gZ4Z4FTqC/CnqBRQS7cNfbt6McOZRS6k87fgBtrV+dpczkOl8qeWd8qeJwqiG3Z6dnaO9AX6LuCvtRYhw4tfwlMe9XvMHc5C5w0f+y6BPWEv3wI+Iv3usJiea+TqBTA4Cl4Tlz3s1JBXYuq+aTPYP6AZP/WzWvqKtZrd5M94yyTijYzzn6mV29btTsT+dXKOSIP5D7fYtfqUtegcOYQs285Pc/iVyFSN1SPnCtVeYceyKX94VyGaob8d2QmihJ9Q4IbNahU7yY7Uy/9EJSOc0+1xWtRAGBGGZzd9s8uq0jWEf6hHd9SQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1skXlC-0000lY-9m for bug-gnu-emacs@gnu.org; Sat, 31 Aug 2024 19:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Aaron Jensen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 31 Aug 2024 23:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60321 X-GNU-PR-Package: emacs Original-Received: via spool by 60321-submit@debbugs.gnu.org id=B60321.17251478382926 (code B ref 60321); Sat, 31 Aug 2024 23:44:02 +0000 Original-Received: (at 60321) by debbugs.gnu.org; 31 Aug 2024 23:43:58 +0000 Original-Received: from localhost ([127.0.0.1]:58537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skXl7-0000l8-I7 for submit@debbugs.gnu.org; Sat, 31 Aug 2024 19:43:58 -0400 Original-Received: from mail-lj1-f170.google.com ([209.85.208.170]:58826) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skXl4-0000kr-WF for 60321@debbugs.gnu.org; Sat, 31 Aug 2024 19:43:56 -0400 Original-Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-2f51e5f0656so33642351fa.1 for <60321@debbugs.gnu.org>; Sat, 31 Aug 2024 16:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725147710; x=1725752510; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:in-reply-to:from:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LRXfbmF2Y+KjUJdOxySgbgDXMZFFFzHu/8LgtbH80OY=; b=lG5q4krPMfaov2b3rgWtTw/q7ETdkiq5b1ZCtvib6ya+7fSCJfXRmdfv6aAmP5BKVq 4okuAUh/5YPwL8b5PKQxFiEmzTsTO4aulOZdBuzEIpw28sPRA3hFk9MLrdkkIVgrqu33 TMmOUoX3LYWSKKuv+aGPugphrvzzFL9vbLxVq1kclkfUpeayA58F+pGvfN+NXFzkXvni CEoN9K2D9V19cQOZqH6i+eGBDYYo5+iha4wZCgJqdGh76mvLn09FnkmI6k4HSfu0IRsc zCNqUUfCcpZVyaWLX0WDAHx0WxCN3QhaseThjrMOdWYrme+GV0IjYAE3D+96GNWOmYIo 88Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725147710; x=1725752510; h=cc:to:subject:message-id:date:in-reply-to:from:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LRXfbmF2Y+KjUJdOxySgbgDXMZFFFzHu/8LgtbH80OY=; b=WVA5Y1Wt+0nFCOugrmdwJ1kK05eNnAf70arCB/ecQav7/BV0eKBgI3FwT73pxY/SH4 D85ZcPY2BfhThlBPhDZqZtT5dhoTcJz0An0VNCFdJbUFo92SqCcLJvzoRo+Qq58SgnJf +KaOuS32H/6fhc8BujvqJkb6iOZcoIgMWy4qv8bq5oeHIK0BZGqEEZM9Si7olPGkCpU0 ixGFkDLCrY8Zwpgta3hay0CIPuPEv91fliB2tvbK1Q1kF9frYuVgLk71EhrPUP5/5O6W UiX7VVmnN+8X0uqhx0f0a+3cozF4LKaykT+93abEIu690j2tGdt1lUPS4mBB6/e7S9CO n9IQ== X-Gm-Message-State: AOJu0YydmDU0x17BfeW+hT7Vu3hc8l+a4ZiQKCW3N5MIWzpruboQkarH DD4wN54LHFj8IhU9nvmVYIsWeKkKrBtsQFtileS4U+RE9uU/GHYSr9NC4L/HMVymX+zYUXiOEeH 1QyVoGnDx3H+6zzl+4577A1vyDYs= X-Google-Smtp-Source: AGHT+IEiuN3thOkjS7l7sx3ex6uLWMTGLQ7R4Pt94oQOYBYnkxw+1vEARTCXyU5AyAYDNCvhc5pqM2sfFk8/21X6tzQ= X-Received: by 2002:a05:651c:548:b0:2f4:3de7:ac4c with SMTP id 38308e7fff4ca-2f6103908d3mr86652211fa.8.1725147709546; Sat, 31 Aug 2024 16:41:49 -0700 (PDT) Original-Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Sat, 31 Aug 2024 16:41:48 -0700 X-Superhuman-Draft-ID: draft00bfe6058908090e In-Reply-To: X-Mailer: Superhuman Desktop (2024-08-30T19:05:53Z) X-Superhuman-ID: m0ise23d.2227bb24-d7b0-4645-8a2f-8415e928ee9c 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:291035 Archived-At: --00000000000069c1cd06210340ae Content-Type: multipart/alternative; boundary="00000000000069c1cc06210340ac" --00000000000069c1cc06210340ac Content-Type: text/plain; charset="UTF-8" I made an attempt at this (attached). It introduces a new variable: ruby-bracketed-args-indent It is set to t by default and the behavior will be as it was before this patch. If it is something other than t, it will cause enable indentation like this: update({ key => value, other_key: }, { key => value, other_key: }) update([ 1, 2 ], [ 3, 4 ]) It does not handle cases such as: some_method({ key: :value }, other_argument) It will indent other_argument to be aligned with the (. This could be elaborated further, but I contend that if people are formatting their code this way that they likely have rather idiosyncratic formatting requirements and they would be best left to do what they want manually. Thanks, Aaron On Mon, Dec 26, 2022 at 8:38 PM, Aaron Jensen wrote: > On Mon, Dec 26, 2022 at 8:16 PM Dmitry Gutov wrote: > > Vim's choice looks saner to my eye. Probably comes down to the choice of > indentation algorithm, though. > > Agreed, though it's hard to pick which is more sane when all the options > start with insanity. > > If I had to type it as above, I would probably indent it like this: > > and_in_a_method_call({ > no: :difference > }, > foo, > bar) > > But I can't imagine that would be easy to implement at all, so I wouldn't > bother. > > The indentation logic itself might be not that difficult to write, but the > fact that the expression will have to be reindented as soon as the method > call grows a second argument (after the user types the comma?), makes it a > hard sell usability-wise. > > Right, I think that's just more of the same thing... We are looking at > ways of writing code that are out of the realm of reason. It's a challenge > to define behavior when the behavior could very well be undefined. But, if > we must define it, then what are our guiding principles? Not having to > reindent preceding lines when adding a new line may be a very reasonable > one. In that case, the only two options I could think of would be: > > and_in_a_method_call({ > no: :difference > }, > foo, > bar) > > or > > and_in_a_method_call({ > no: :difference > }, > foo, > bar) > > The difference being if we decide to dedent upon the last closing > indent-requiring-token or the first. > > I think a reasonable rule of thumb for a human might be: "If you open N > indents on one line, you must close N indents on one line". Any time you > stray away from this, behavior becomes... not ideal. > > Aaron > --00000000000069c1cc06210340ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I made an attempt a= t this (attached). It introduces a new variable:

ruby-bracketed-args-indent

It is set to t b= y default and the behavior will be as it was before this patch.

If it is something other than t, it will cause enable ind= entation like this:

update({
=C2= =A0 key =3D> value,
=C2=A0 other_key:
}, {
=C2=A0 key =3D> value,
=C2=A0 other_key:
<= /div>
})

update([
=C2=A0 1,<= br>
=C2=A0 2
], [
=C2=A0 3,
=
=C2=A0 4
])

It d= oes not handle cases such as:

some_method({
=C2=A0 key: :valu= e
},
other_argument= )

It will i= ndent other_argument to be aligned with=C2=A0the (. This could be elaborate= d further, but I contend that if people are formatting their code this way = that they likely have rather idiosyncratic formatting=C2=A0requirements and= they would be best left to do what they want manually.

Thanks,=C2=A0


Aaron

=
On Mon, Dec 26, 2022 at 8:38 PM, Aaron = Jensen <aaronjensen@gmail.com> wrote:

On Mon, Dec 26, 202= 2 at 8:16 PM Dmitry Gutov <dguto= v@yandex.ru> wrote:

Vim's choice looks saner to my eye. Probably comes down to the choice o= f indentation algorithm, though.

Agreed, though it's hard to pick which is more sane when all the options start with insanity.

If I had to type it as above, I would probably indent it like this:

and_in_a_method_call({
no: :difference
},
foo,
bar)

But I can't imagine that would be easy to implement at all, so I wouldn't bother.

The indentation logic itself might be not that difficult to write, but the fact that the expression will have to be reindented as soon as the method call grows a second argument (after the user types the comma?), makes it a hard sell usability-wise.

Right, I think that's just more of the same thing... We are looking at ways of writing code that are out of the realm of reason. It's a challenge to define behavior when the behavior could very well be undefined. But, if we must define it, then what are our guiding principles? Not having to reindent preceding lines when adding a new line may be a very reasonable one. In that case, the only two options I could think of would be:

and_in_a_method_call({
no: :difference
},
foo,
bar)

or

and_in_a_method_call({
no: :difference
},
foo,
bar)

The difference being if we decide to dedent upon the last closing indent-requiring-token or the first.

I think a reasonable rule of thumb for a human might be: "If you open N indents on one line, you must close N indents on one line". Any time you stray away from this, behavior becomes... not ideal.

Aaron


--00000000000069c1cc06210340ac-- --00000000000069c1cd06210340ae Content-Type: application/octet-stream; name="0001-Add-ruby-bracketed-argument-indentation-option.patch" Content-Disposition: attachment; filename="0001-Add-ruby-bracketed-argument-indentation-option.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: ffad75926378cb99_0.1 RnJvbSAzMmIxY2UyODE3ODNiOThhZDY0YjFkOTlhZTE0NmEyMzc1M2E1YTgwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBYXJvbiBKZW5zZW4gPGFhcm9uamVuc2VuQGdtYWlsLmNvbT4K RGF0ZTogU2F0LCAzMSBBdWcgMjAyNCAxOTozMToyMCAtMDQwMApTdWJqZWN0OiBbUEFUQ0hdIEFk ZCBydWJ5IGJyYWNrZXRlZCBhcmd1bWVudCBpbmRlbnRhdGlvbiBvcHRpb24KCiogbGlzcC9wcm9n bW9kZXMvcnVieS1tb2RlLmVsIChydWJ5LWJyYWNrZXRlZC1hcmdzLWluZGVudCksCihydWJ5LXNt aWUtcnVsZXMpOiBOZXcgb3B0aW9uCiogdGVzdC9saXNwL3Byb2dtb2Rlcy9ydWJ5LW1vZGUtcmVz b3VyY2VzL3J1YnktYnJhY2tldGVkLWFyZ3MtaW5kZW50LnJiOgoqIHRlc3QvbGlzcC9wcm9nbW9k ZXMvcnVieS1tb2RlLXRlc3RzLmVsCiAgKCJydWJ5LXBhcmVubGVzcy1jYWxsLWFyZ3VtZW50cy1p bmRlbnQucmIiKTogTmV3IHRlc3QgY2FzZQotLS0KIGxpc3AvcHJvZ21vZGVzL3J1YnktbW9kZS5l bCAgICAgICAgICAgICAgICAgICB8IDIzICsrKysrKysrKysrKysKIC4uLi9ydWJ5LWJyYWNrZXRl ZC1hcmdzLWluZGVudC5yYiAgICAgICAgICAgICB8IDMzICsrKysrKysrKysrKysrKysrKysKIHRl c3QvbGlzcC9wcm9nbW9kZXMvcnVieS1tb2RlLXRlc3RzLmVsICAgICAgICB8ICAxICsKIDMgZmls ZXMgY2hhbmdlZCwgNTcgaW5zZXJ0aW9ucygrKQogY3JlYXRlIG1vZGUgMTAwNjQ0IHRlc3QvbGlz cC9wcm9nbW9kZXMvcnVieS1tb2RlLXJlc291cmNlcy9ydWJ5LWJyYWNrZXRlZC1hcmdzLWluZGVu dC5yYgoKZGlmZiAtLWdpdCBhL2xpc3AvcHJvZ21vZGVzL3J1YnktbW9kZS5lbCBiL2xpc3AvcHJv Z21vZGVzL3J1YnktbW9kZS5lbAppbmRleCAzYmNmYTllZTdkZi4uODVjZGNlMzk5MzcgMTAwNjQ0 Ci0tLSBhL2xpc3AvcHJvZ21vZGVzL3J1YnktbW9kZS5lbAorKysgYi9saXNwL3Byb2dtb2Rlcy9y dWJ5LW1vZGUuZWwKQEAgLTQ3Miw2ICs0NzIsMjYgQEAgcnVieS1wYXJlbmxlc3MtY2FsbC1hcmd1 bWVudHMtaW5kZW50CiAgIDpzYWZlICdib29sZWFucAogICA6dmVyc2lvbiAiMjkuMSIpCiAKKyhk ZWZjdXN0b20gcnVieS1icmFja2V0ZWQtYXJncy1pbmRlbnQgdAorICAiTm9uLW5pbCB0byBhbGln biB0aGUgY29udGVudHMgb2YgYnJhY2tldGVkIGFyZ3VtZW50cyB3aXRoIHRoZSBicmFja2V0cy4K KworRXhhbXBsZToKKworICBxdXgoeworICAgICAgIGZvbyA9PiBiYXIKKyAgICAgfSkKKworU2V0 IGl0IHRvIG5pbCB0byBhbGlnbiB0byB0aGUgYmVnaW5uaW5nIG9mIHRoZSBzdGF0ZW1lbnQ6CisK KyAgcXV4KHsKKyAgICBmb28gPT4gYmFyCisgIH0pCisKK09ubHkgaGFzIGVmZmVjdCB3aGVuIGBy dWJ5LXVzZS1zbWllJyBpcyB0LiIKKyAgOnR5cGUgJ2Jvb2xlYW4KKyAgOnNhZmUgJ2Jvb2xlYW5w CisgIDp2ZXJzaW9uICIzMS4xIikKKwogKGRlZmN1c3RvbSBydWJ5LWRlZXAtYXJnbGlzdCB0CiAg ICJEZWVwIGluZGVudCBsaXN0cyBpbiBwYXJlbnRoZXNpcyB3aGVuIG5vbi1uaWwuCiBBbHNvIGln bm9yZXMgc3BhY2VzIGFmdGVyIHBhcmVudGhlc2lzIHdoZW4gYHNwYWNlJy4KQEAgLTgyNiw2ICs4 NDYsOSBAQCBydWJ5LXNtaWUtcnVsZXMKICAgICAgICkpCiAgICAgKGAoOmJlZm9yZSAuICwob3Ig IigiICJbIiAieyIpKQogICAgICAoY29uZAorICAgICAgKChhbmQgKG5vdCAoZXEgcnVieS1icmFj a2V0ZWQtYXJncy1pbmRlbnQgdCkpCisgICAgICAgICAgICAoc21pZS1ydWxlLXByZXYtcCAiLCIg IigiICJbIikpCisgICAgICAgKGNvbnMgJ2NvbHVtbiAoY3VycmVudC1pbmRlbnRhdGlvbikpKQog ICAgICAgKChhbmQgKGVxdWFsIHRva2VuICJ7IikKICAgICAgICAgICAgIChub3QgKHNtaWUtcnVs ZS1wcmV2LXAgIigiICJ7IiAiWyIgIiwiICI9PiIgIj0iICJyZXR1cm4iICI7IiAiZG8iKSkKICAg ICAgICAgICAgIChzYXZlLWV4Y3Vyc2lvbgpkaWZmIC0tZ2l0IGEvdGVzdC9saXNwL3Byb2dtb2Rl cy9ydWJ5LW1vZGUtcmVzb3VyY2VzL3J1YnktYnJhY2tldGVkLWFyZ3MtaW5kZW50LnJiIGIvdGVz dC9saXNwL3Byb2dtb2Rlcy9ydWJ5LW1vZGUtcmVzb3VyY2VzL3J1YnktYnJhY2tldGVkLWFyZ3Mt aW5kZW50LnJiCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAwMDAwLi43ZDNkZjM0 NjNmZgotLS0gL2Rldi9udWxsCisrKyBiL3Rlc3QvbGlzcC9wcm9nbW9kZXMvcnVieS1tb2RlLXJl c291cmNlcy9ydWJ5LWJyYWNrZXRlZC1hcmdzLWluZGVudC5yYgpAQCAtMCwwICsxLDMzIEBACit1 cGRhdGUoeworICBrZXkgPT4gdmFsdWUsCisgIG90aGVyX2tleToKK30sIHsKKyAga2V5ID0+IHZh bHVlLAorICBvdGhlcl9rZXk6Cit9KQorCit1cGRhdGUoWworICAxLAorICAyCitdLCBbCisgIDMs CisgIDQKK10pCisKK3VwZGF0ZShbeworICBrZXk6ICJ2YWx1ZSIKK30sIHsKKyAga2V5OiAidmFs dWUiCit9XSkKKwordXBkYXRlKGFyZzEsIHsKKyAgZm9vOiAiYmFyIgorfSwgWworICAxLAorICAy CitdLCBhcmcyKQorCisjIExvY2FsIFZhcmlhYmxlczoKKyMgcnVieS1icmFja2V0ZWQtYXJncy1p bmRlbnQ6IG5pbAorIyBydWJ5LW1ldGhvZC1wYXJhbXMtaW5kZW50OiBuaWwKKyMgRW5kOgpkaWZm IC0tZ2l0IGEvdGVzdC9saXNwL3Byb2dtb2Rlcy9ydWJ5LW1vZGUtdGVzdHMuZWwgYi90ZXN0L2xp c3AvcHJvZ21vZGVzL3J1YnktbW9kZS10ZXN0cy5lbAppbmRleCAyYjg1MDZhN2FkYy4uYzljZGU3 OTFiYWEgMTAwNjQ0Ci0tLSBhL3Rlc3QvbGlzcC9wcm9nbW9kZXMvcnVieS1tb2RlLXRlc3RzLmVs CisrKyBiL3Rlc3QvbGlzcC9wcm9nbW9kZXMvcnVieS1tb2RlLXRlc3RzLmVsCkBAIC05OTIsNiAr OTkyLDcgQEAgInJ1YnktYmxvY2staW5kZW50LnJiIgogKHJ1YnktZGVmdGVzdC1pbmRlbnQgInJ1 YnktbWV0aG9kLWNhbGwtaW5kZW50LnJiIikKIChydWJ5LWRlZnRlc3QtaW5kZW50ICJydWJ5LW1l dGhvZC1wYXJhbXMtaW5kZW50LnJiIikKIChydWJ5LWRlZnRlc3QtaW5kZW50ICJydWJ5LXBhcmVu bGVzcy1jYWxsLWFyZ3VtZW50cy1pbmRlbnQucmIiKQorKHJ1YnktZGVmdGVzdC1pbmRlbnQgInJ1 YnktYnJhY2tldGVkLWFyZ3MtaW5kZW50LnJiIikKIAogKGVydC1kZWZ0ZXN0IHJ1YnktLXRlc3Qt Y2hhaW5lZC1pbmRlbnRhdGlvbiAoKQogICAod2l0aC10ZW1wLWJ1ZmZlcgotLSAKMi40Mi4xCgo= --00000000000069c1cd06210340ae--