lexical-binding is turned on in more use cases

lexical-binding is turned on in more use cases

[Eli Zaretskii]

Commit e08e0880f made lexical-binding be non-nil in more use cases,
but the NEWS entry doesn't say how to get back the old behavior.  Is
there a way of getting back the old behavior, say, for M-: or for
"--eval" options?

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/x-markdown; coding=UTF-8, Size: 424 bytes --]

> Commit e08e0880f made lexical-binding be non-nil in more use cases,
> but the NEWS entry doesn't say how to get back the old behavior.  Is
> there a way of getting back the old behavior, say, for M-: or for
> "--eval" options?

Not really, no.  You can do things like replacing `<foo>` with `(eval
'<foo>)` or adding a bunch of `(defvar <bar>)`, but there's no
config var to get back the old behavior.


        Stefan

Re: lexical-binding is turned on in more use cases

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sun, 08 Mar 2020 12:35:22 -0400
> 
> > Commit e08e0880f made lexical-binding be non-nil in more use cases,
> > but the NEWS entry doesn't say how to get back the old behavior.  Is
> > there a way of getting back the old behavior, say, for M-: or for
> > "--eval" options?
> 
> Not really, no.  You can do things like replacing `<foo>` with `(eval
> '<foo>)` or adding a bunch of `(defvar <bar>)`, but there's no
> config var to get back the old behavior.

And neither can one bind something in the form being evaluated,
AFAICS, right?  Isn't that a bit too harsh?

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/x-markdown; coding=UTF-8, Size: 1269 bytes --]

>> > Commit e08e0880f made lexical-binding be non-nil in more use cases,
>> > but the NEWS entry doesn't say how to get back the old behavior.  Is
>> > there a way of getting back the old behavior, say, for M-: or for
>> > "--eval" options?
>> Not really, no.  You can do things like replacing `<foo>` with `(eval
>> '<foo>)` or adding a bunch of `(defvar <bar>)`, but there's no
>> config var to get back the old behavior.
> And neither can one bind something in the form being evaluated,
> AFAICS, right?

You can wrap your code inside a `(eval '...)`, but not a `let`
binding, no.

> Isn't that a bit too harsh?

I don't see why: lexical-binding gives a strict superset of what can be
done without it, and the cases where existing dynamically-scoped code gives
a different results from its interpretation with lexical-binding are
rather uncommon, especially in small chunks of code such as those
typically used in `M-:` and `--eval`.

That doesn't mean that I expect it won't break anything in practice:
I do expect that some Makefile somewhere will be broken because of
a `--eval` that depends on dynamic binding.

But I think it'll be just as easy to fix with a `defvar` or an `eval` as
it would be by setting or let-binding some new variable.


        Stefan

Re: lexical-binding is turned on in more use cases

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sun, 08 Mar 2020 13:33:07 -0400
> 
> That doesn't mean that I expect it won't break anything in practice:
> I do expect that some Makefile somewhere will be broken because of
> a `--eval` that depends on dynamic binding.
> 
> But I think it'll be just as easy to fix with a `defvar` or an `eval` as
> it would be by setting or let-binding some new variable.

I'm looking for a couple of recipes to put in NEWS for those who might
need this.  I don't think I understand how could this be easily fixed,
since you just said that it's basically impossible.  I must be missing
something.  I'd appreciate some suggestions for what to say in NEWS.

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/x-markdown; coding=UTF-8, Size: 440 bytes --]

> I'm looking for a couple of recipes to put in NEWS for those who might
> need this.  I don't think I understand how could this be easily fixed,
> since you just said that it's basically impossible.  I must be missing
> something.  I'd appreciate some suggestions for what to say in NEWS.

We could say that to recover the original behavior, instead of

    --eval "<foo>"

the command could use

    --eval "(eval '<foo>)"


-- Stefan

Re: lexical-binding is turned on in more use cases

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 08 Mar 2020 14:20:05 -0400
> Cc: emacs-devel@gnu.org
> 
> We could say that to recover the original behavior, instead of
> 
>     --eval "<foo>"
> 
> the command could use
> 
>     --eval "(eval '<foo>)"

And the same for M-:?

Re: lexical-binding is turned on in more use cases

[Alan Mackenzie]

Hello, Eli and Stefan.

On Sun, Mar 08, 2020 at 20:34:10 +0200, Eli Zaretskii wrote:
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Date: Sun, 08 Mar 2020 14:20:05 -0400
> > Cc: emacs-devel@gnu.org

> > We could say that to recover the original behavior, instead of

> >     --eval "<foo>"

> > the command could use

> >     --eval "(eval '<foo>)"

> And the same for M-:?

As it happens, this issue bit me this afternoon.  I instrumented a
function for edebug and tried

    M-: (c-align-cpp-indent-to-body)

.  This complained about c-syntactic-context being unbound, so I
tried:

   M-: (let ((c-syntactic-context (c-guess-basic-syntax)))
   (c-align-cpp-indent-to-body))

, and was puzzled that c-syntactic-context was _still_ unbound.  So I
checked the spelling, and was more puzzled.  Eventually I used setq,
which worked, but caused me further problems later on in my Emacs
session.

Furthermore, c-syntactic-context is explicitly declared a dynamic
variable by a defvar form.  So why did a dynamic binding not work?

THIS IS A MAJOR BACKWARD STEP FOR EMACS!!!!

Looking at the git log, it appears this change was made nearly a year
ago.  I don't remember the discussion about it on emacs-devel, but I
would surely have argued against it if I knew it was being proposed.

This is broken.  Can we get it fixed, please (for some reasonable value
of "fixed")?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/x-markdown; coding=UTF-8, Size: 686 bytes --]

>> We could say that to recover the original behavior, instead of
>> 
>>     --eval "<foo>"
>>
>> the command could use
>>
>>     --eval "(eval '<foo>)"
>
> And the same for M-:?

Right.  These are not *good* solutions, but they're expedient.
A way to kick the can a bit further down (I hope the
non-lexical-binding mode will disappear before next century).

The right solution is to fix the code so it works correctly with
lexical-binding, which is usually a matter of adding a few `defvar`s or
`require`s, but it takes more effort and knowledge.

Of course, in the vast majority of cases the old code should work
identically with lexical-binding as it did before.


        Stefan

Re: lexical-binding is turned on in more use cases

[Eli Zaretskii]

> Date: Sun, 8 Mar 2020 19:30:48 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> > > We could say that to recover the original behavior, instead of
> 
> > >     --eval "<foo>"
> 
> > > the command could use
> 
> > >     --eval "(eval '<foo>)"
> 
> > And the same for M-:?
> 
> As it happens, this issue bit me this afternoon.  I instrumented a
> function for edebug and tried
> 
>     M-: (c-align-cpp-indent-to-body)
> 
> .  This complained about c-syntactic-context being unbound, so I
> tried:
> 
>    M-: (let ((c-syntactic-context (c-guess-basic-syntax)))
>    (c-align-cpp-indent-to-body))
> 
> , and was puzzled that c-syntactic-context was _still_ unbound.  So I
> checked the spelling, and was more puzzled.  Eventually I used setq,
> which worked, but caused me further problems later on in my Emacs
> session.

Does it help to say

  M-: (eval (c-align-cpp-indent-to-body))

instead?

Re: lexical-binding is turned on in more use cases

[Alan Mackenzie]

Hello, Eli.

On Sun, Mar 08, 2020 at 21:40:17 +0200, Eli Zaretskii wrote:
> > Date: Sun, 8 Mar 2020 19:30:48 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org

> > > > We could say that to recover the original behavior, instead of

> > > >     --eval "<foo>"

> > > > the command could use

> > > >     --eval "(eval '<foo>)"

> > > And the same for M-:?

> > As it happens, this issue bit me this afternoon.  I instrumented a
> > function for edebug and tried

> >     M-: (c-align-cpp-indent-to-body)

> > .  This complained about c-syntactic-context being unbound, so I
> > tried:

> >    M-: (let ((c-syntactic-context (c-guess-basic-syntax)))
> >    (c-align-cpp-indent-to-body))

> > , and was puzzled that c-syntactic-context was _still_ unbound.  So I
> > checked the spelling, and was more puzzled.  Eventually I used setq,
> > which worked, but caused me further problems later on in my Emacs
> > session.

> Does it help to say

>   M-: (eval (c-align-cpp-indent-to-body))

> instead?

Well, the essential thing was getting a binding of c-syntactic-context
for calling c-align-cpp-indent-to-body.  So, I tried:

    M-: (eval (let ((c-syntactic-context (...)))
    (c-align-cpp-indent-to-body)))

, but this didn't help at all.  This was while the current buffer's major
mode was C Mode, which has lexical-binding nil.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: lexical-binding is turned on in more use cases

[Eli Zaretskii]

> Date: Sun, 8 Mar 2020 19:56:20 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> > Does it help to say
> 
> >   M-: (eval (c-align-cpp-indent-to-body))
> 
> > instead?
> 
> Well, the essential thing was getting a binding of c-syntactic-context
> for calling c-align-cpp-indent-to-body.  So, I tried:
> 
>     M-: (eval (let ((c-syntactic-context (...)))
>     (c-align-cpp-indent-to-body)))
> 
> , but this didn't help at all.

And if you quote the form?

Re: lexical-binding is turned on in more use cases

[Alan Mackenzie]

Hello again, Eli.

On Sun, Mar 08, 2020 at 22:06:52 +0200, Eli Zaretskii wrote:
> > Date: Sun, 8 Mar 2020 19:56:20 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org

> > > Does it help to say

> > >   M-: (eval (c-align-cpp-indent-to-body))

> > > instead?

> > Well, the essential thing was getting a binding of c-syntactic-context
> > for calling c-align-cpp-indent-to-body.  So, I tried:

> >     M-: (eval (let ((c-syntactic-context (...)))
> >     (c-align-cpp-indent-to-body)))

> > , but this didn't help at all.

> And if you quote the form?

To be precise,

    M-: (eval '(let (...) (c-align-cpp-indent-to-body)))

runs correctly, but fails to stop in c-align-..-body, even though it is
instrumented for edebug.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/x-markdown; coding=UTF-8, Size: 1366 bytes --]

> .  This complained about c-syntactic-context being unbound, so I
> tried:
>
>    M-: (let ((c-syntactic-context (c-guess-basic-syntax)))
>    (c-align-cpp-indent-to-body))
>
> , and was puzzled that c-syntactic-context was _still_ unbound.  So I
> checked the spelling, and was more puzzled.  Eventually I used setq,
> which worked, but caused me further problems later on in my Emacs
> session.

Indeed `c-syntactic-context` is only declared as dynamically scoped in
some files but not globally, for some reason.

It's rather unusual.  The more common pattern is to write

    (defvar c-syntactic-context nil)

which would not make you bump into this problem.

> Furthermore, c-syntactic-context is explicitly declared a dynamic
> variable by a defvar form.

But a `defvar` with no 2nd arg (i.e. no default value), which means it
only affects the current file (not sure if this is part of the reason
why you have `(defvar c-syntactic-context)` both `cc-cmds.el` and in
`cc-vars.el`, but it would explain it tho the `(cc-bytecomp-defvar
c-syntactic-context)` in `cc-vars.el` makes the whole situation much
more murky).

> THIS IS A MAJOR BACKWARD STEP FOR EMACS!!!!

;-)

> Looking at the git log, it appears this change was made nearly a year ago.

Indeed, it's a wonder you managed to survive with such a majorly broken
Emacs for so long ;-)


        Stefan

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/x-markdown; coding=UTF-8, Size: 828 bytes --]

> Does it help to say
>
>   M-: (eval (c-align-cpp-indent-to-body))
             ^
             '

The quote is of the essence, otherwise you're asking to evaluate the
return value of the expression.

And since the above expression was wrong (it lacked the let binding),
what he should do is either

    M-: (eval '(let ((c-syntactic-context (c-guess-basic-syntax))))
                 (c-align-cpp-indent-to-body)) RET

or use `(defvar c-syntactic-context nil)` somewhere, or

    M-: (progn (defvar c-syntactic-context)
               (let ((c-syntactic-context (c-guess-basic-syntax))))
                 (c-align-cpp-indent-to-body)) RET

or write the `(let ((c-syntactic-context (c-guess-basic-syntax))))
(c-align-cpp-indent-to-body))` inside `cc-cmds.el` or `cc-vars.el`
and use `C-x C-e` there.

or ...


        Stefan

Re: lexical-binding is turned on in more use cases

[John Wiegley]

>>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> THIS IS A MAJOR BACKWARD STEP FOR EMACS!!!!

SM> ;-)

>> Looking at the git log, it appears this change was made nearly a year ago.

SM> Indeed, it's a wonder you managed to survive with such a majorly broken
SM> Emacs for so long ;-)

I do hope we're taking Alan's concern seriously here, all joking aside. This
change pretty harshly violates the "principle of least surprise", and working
with lexical-scope still isn't the norm for most old school Emacs Lispers. I'm
not sure I wuold have ever discovered the solution to such a problem in my own
debugging, had I not chanced on this discussion thread.

What are we gaining, again, at the cost of this potential confusion?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: lexical-binding is turned on in more use cases

[Alan Mackenzie]

Hello, Stefan.

On Sun, Mar 08, 2020 at 19:41:44 -0400, Stefan Monnier wrote:
> > .  This complained about c-syntactic-context being unbound, so I
> > tried:

> >    M-: (let ((c-syntactic-context (c-guess-basic-syntax)))
> >    (c-align-cpp-indent-to-body))

> > , and was puzzled that c-syntactic-context was _still_ unbound.  So I
> > checked the spelling, and was more puzzled.  Eventually I used setq,
> > which worked, but caused me further problems later on in my Emacs
> > session.

> Indeed `c-syntactic-context` is only declared as dynamically scoped in
> some files but not globally, for some reason.

That reason appearing to be a misfeature of defvar.  Why is (defvar foo)
a no-op?  Why does it not set the declared_special bit inside the symbol?
This would be sensible and consistent (even if unacceptable for Emacs
27).

> It's rather unusual.

Even if that's the case, it doesn't make it unimportant.  Let binding
from the minibuffer should work consistently, its effect not varying
chaotically between dynamic and lexical binding.

[ .... ]

> > Furthermore, c-syntactic-context is explicitly declared a dynamic
> > variable by a defvar form.

> But a `defvar` with no 2nd arg (i.e. no default value), which means it
> only affects the current file (not sure if this is part of the reason
> why you have `(defvar c-syntactic-context)` both `cc-cmds.el` and in
> `cc-vars.el`, but it would explain it tho the `(cc-bytecomp-defvar
> c-syntactic-context)` in `cc-vars.el` makes the whole situation much
> more murky).

See above.  defvar should not be a no-op.  It shouldn't be necessary to
write (defvar foo) in more than one file.

> > THIS IS A MAJOR BACKWARD STEP FOR EMACS!!!!

> ;-)

> > Looking at the git log, it appears this change was made nearly a year ago.

> Indeed, it's a wonder you managed to survive with such a majorly broken
> Emacs for so long ;-)

Why did you not initiate a discussion on emacs-devel before committing
this patch?  Also the title of the patch is highly misleading, since the
patch has nothing to do with defaults, only with forced lexical binding,
whether wanted or not.

How about making this lexical binding optional, controlled by a
customisable variable?  It would not be difficult.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

> I do hope we're taking Alan's concern seriously here, all joking aside. This
> change pretty harshly violates the "principle of least surprise", and working
> with lexical-scope still isn't the norm for most old school Emacs Lispers. I'm
> not sure I wuold have ever discovered the solution to such a problem in my own
> debugging, had I not chanced on this discussion thread.
> What are we gaining, again, at the cost of this potential confusion?

The problem is real.  I don't think we can solve it without pain.

Basically, M-: doesn't easily know whether to use lexical-binding or not
because it's only connected to the buffer where the code will be
run but not to some source buffer where the "related" code might reside
(and which we could try and use to guess which mode to use).

You're probably right that "lexical-scope still isn't the norm for most
old school Emacs Lispers", so this change will irk those.  But my
impression is that the majority of *new* Elisp packages is using
lexical-binding nowadays, and the majority of Elisp snippets I see
quoted in StackExchange either work both ways or presume
lexical-binding (and then come with additional comments along the lines
of "I tried it and it didn't work ... indeed, you need to enable
lexical-binding by ... ah yes now it works").

It does remind me, tho, that we likely should introduce a `dlet` macro
to make it easy to do a dynamically scoped let-binding.  It'd be a much
cleaner solution than `(eval '...)` or `(progn (defvar ...) ...)`.
We already have it defined as `calendar-dlet*` and `mh-dlet*`.


        Stefan

RE: lexical-binding is turned on in more use cases

[Drew Adams]

We seem to be drifting farther from Common Lisp's
approach to cohabitation of lexical & dynamic.

Or is that a mistaken impression?

Would it make sense to move closer to, not farther
from, CL's approach to handling special variables?

I haven't developed using CL for a _long_ time,
but I really don't recall jumping through hoops to
accommodate both lexical & dynamic, either in files
or interactively.  (But granted, my interactive use
of Elisp is greater.  Emacs is a really interactive
environment.)

Does some of the complication maybe come from our
trying to repurpose `defvar'?  (No idea, just a
wild guess.)

Maybe you could run down clearly the reasons why
Emacs Lisp should be different from Common Lisp
wrt lexical & dynamic?  Such a rundown might even
be useful more generally, i.e., for all Emacs users.

No obligation; just thinking it might help.  (It
would help me, at least.)

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

> Or is that a mistaken impression?

I believe so, yes.


        Stefan

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

> Why is (defvar foo) a no-op?

Because that's what it has been since its introduction many many years
ago (Emacs-21? 20? 19? 18?).

In Emacs-24, a decision had to made about how to deal with it.
Given the many packages that did (and many still do) things like

   (defvar date)

making such defvars have global impacts means that any code using `date`
as a lexical variable would break whenever that other package with the
`(defvar date)` happened to be loaded.

This is still true if that other package does

    (defvar date nil)

but such definition of variables with no namespace prefix has been
widely understood as a bug since "for ever", so they're vanishingly rare
(contrary to the (defvar <VAR>) where <VAR> doesn't have a namespace
prefix, which I also consider as bugs but are still very widespread).

So the Emacs-24 design of lexical-binding make (defvar <VAR>) be
a declaration which only affects "the current scope".

I don't claim it is a perfect design, but it's what we have (introduced
in Emacs-24) and in retrospect it has worked fairly well, striking
a pretty good balance between the desire to minimize the amount of
changes needed when converting a file from dynamic to lexical scoping,
the need to work alongside the many pre-existing files which won't be
changed, the need to provide reasonably sane semantics which aren't too
badly affected by "unrelated" packages, ...

> Why does it not set the declared_special bit inside the symbol?

As explained, this would make lots of existing packages break other
unrelated packages.  In any case, this boat has sailed many years ago.

>> It's rather unusual.
> Even if that's the case, it doesn't make it unimportant.  Let binding
> from the minibuffer should work consistently, its effect not varying
> chaotically between dynamic and lexical binding.

let-binding is the thing that is different between dynamic and lexical
binding, so it is affected, by definition.  As for "chaotically", it's
a matter of judgment.  You're clearly not familiar with the behavior
of lexical-binding, so it's no surprise you find it chaotic.

> See above.  defvar should not be a no-op.

It was designed as a no-op from the very beginning, long before
`lexical-binding` was introduced.  `lexical-binding` is what made it less
of a no-op, so it seems you're arguing on favor of
`lexical-binding` unwittingly.

> It shouldn't be necessary to write (defvar foo) in more than one file.

Then write (defvar foo nil).

> Why did you not initiate a discussion on emacs-devel before committing
> this patch?

It was discussed somewhere for a while.  Lesseee....  Oh, I found it:

    https://debbugs.gnu.org/30078


-- Stefan

Re: lexical-binding is turned on in more use cases

[John Wiegley]

>>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

SM> It does remind me, tho, that we likely should introduce a `dlet` macro to
SM> make it easy to do a dynamically scoped let-binding. It'd be a much
SM> cleaner solution than `(eval '...)` or `(progn (defvar ...) ...)`. We
SM> already have it defined as `calendar-dlet*` and `mh-dlet*`.

Yes, such facilities would at the very least be an improvement.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: lexical-binding is turned on in more use cases

[Alan Mackenzie]

Hello, Stefan.

On Mon, Mar 09, 2020 at 18:05:12 -0400, Stefan Monnier wrote:

[ .... ]

> > Why did you not initiate a discussion on emacs-devel before
> > committing this patch?

> It was discussed somewhere for a while.  Lesseee....  Oh, I found it:

>     https://debbugs.gnu.org/30078

You haven't answered the question.  Why did you not initiate a discussion
on emacs-devel before committing this patch?  emacs-devel is where
proposals that might or will break things get discussed; not a thread on
bug-gnu-emacs, where most affected people won't see it.

> -- Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

> You haven't answered the question.  Why did you not initiate a discussion
> on emacs-devel before committing this patch?  emacs-devel is where
> proposals that might or will break things get discussed; not a thread on
> bug-gnu-emacs, where most affected people won't see it.

It doesn't break any*thing*, AFAICT: the `--eval` change might break
some Makefile somewhere, but the `M-:` change shouldn't break any
existing code.

It only change the user-visible behavior.

AFAIK the breakage is unavoidable and inevitable in the long run,
because living with both variants of Elisp is a drag.  So the only
question is *when* and based on my observation that the majority of new
packages are nowadays written in the lexical dialect of Elisp, I think
now is a good time because it serves the needs of a majority of our
current Elisp coders.

The anecdotal evidence (this is the first complaint about this change
even tho it's been made about a year ago on `master`, compared to the
number of implicit "complaints" on stackexchange of sample code that
doesn't work because the sample assumes lexical scoping) seems to agree
that the tipping point between "majority dynamic" and "majority lexical"
has been reached.


        Stefan

Re: lexical-binding is turned on in more use cases

[Alan Mackenzie]

Hello, Stefan.

On Mon, Mar 09, 2020 at 17:18:12 -0400, Stefan Monnier wrote:
> > I do hope we're taking Alan's concern seriously here, all joking
> > aside. This change pretty harshly violates the "principle of least
> > surprise", and working with lexical-scope still isn't the norm for
> > most old school Emacs Lispers. I'm not sure I wuold have ever
> > discovered the solution to such a problem in my own debugging, had I
> > not chanced on this discussion thread.  What are we gaining, again,
> > at the cost of this potential confusion?

> The problem is real.  I don't think we can solve it without pain.

You haven't answered the question.  Let me put it to you in a slightly
different way:  What specific real problem does forcing M-: to use
lexical binding solve?

> Basically, M-: doesn't easily know whether to use lexical-binding or
> not because it's only connected to the buffer where the code will be
> run but not to some source buffer where the "related" code might
> reside (and which we could try and use to guess which mode to use).

Lexical binding in M-: simply isn't very useful.  For any real needs,
dynamic binding works better.

> You're probably right that "lexical-scope still isn't the norm for most
> old school Emacs Lispers", so this change will irk those.  But my
> impression is that the majority of *new* Elisp packages is using
> lexical-binding nowadays, and the majority of Elisp snippets I see
> quoted in StackExchange either work both ways or presume
> lexical-binding (and then come with additional comments along the lines
> of "I tried it and it didn't work ... indeed, you need to enable
> lexical-binding by ... ah yes now it works").

The above paragraph is sophistry.  Lexical binding in M-: simply isn't
very useful, even when calling functions compiled with lexical binding.

What specific real problem does forcing M-: to use lexical binding
solve?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: lexical-binding is turned on in more use cases

[Alan Mackenzie]

Hello, Stefan.

On Tue, Mar 10, 2020 at 15:05:36 -0400, Stefan Monnier wrote:
> > You haven't answered the question.  Why did you not initiate a discussion
> > on emacs-devel before committing this patch?  emacs-devel is where
> > proposals that might or will break things get discussed; not a thread on
> > bug-gnu-emacs, where most affected people won't see it.

> It doesn't break any*thing*, AFAICT:

For crying out loud!  My very first post in this thread documented a
breakage which actually happened.  Please read it.

And you STILL havn't answered the question: why did you not initiate a
discussion on emacs-devel before committing this patch?  It has broken
long-standing behaviour, and from its very nature was always likely to
do so.

[ .... ]

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: lexical-binding is turned on in more use cases

[Andrea Corallo]

Alan Mackenzie <acm@muc.de> writes:

> What specific real problem does forcing M-: to use lexical binding
> solve?

My 2 cents are that it solves the problem of consistency if we assume
lexical binding is going to be the default for the future.  Indeed to
become default it has to start somewhere.

Regards

  Andrea

-- 
akrl@sdf.org

Re: lexical-binding is turned on in more use cases

[Alan Mackenzie]

Hello, Andrea.

On Tue, Mar 10, 2020 at 19:49:55 +0000, Andrea Corallo wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > What specific real problem does forcing M-: to use lexical binding
> > solve?

> My 2 cents are that it solves the problem of consistency if we assume
> lexical binding is going to be the default for the future.

What problem of consistency?

> Indeed to become default it has to start somewhere.

So, you would presumably agree with me, you know of no specific problem
that lexical binding in M-: will solve.  It causes breakage.  But you
think it's a good idea, anyway?

I believe people who say lexical binding is a good idea, even though I
can't see any benefit myself.  But there are places where lexical
binding is not a good thing, and M-: is one of these, in my view.

> Regards

>   Andrea

> -- 
> akrl@sdf.org

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

>> > You haven't answered the question.  Why did you not initiate a discussion
>> > on emacs-devel before committing this patch?  emacs-devel is where
>> > proposals that might or will break things get discussed; not a thread on
>> > bug-gnu-emacs, where most affected people won't see it.
>> It doesn't break any*thing*, AFAICT:
> For crying out loud!  My very first post in this thread documented a
> breakage which actually happened.  Please read it.

Your first post showed that it changed the behavior you got when you use
`M-:` but it did not break any existing code.

Usually we qualify this as "change" and not as "breakage".

IOW it's maybe incompatible with your fingers (or your brain/memory) but
not with existing code.


        Stefan

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

> What specific real problem does forcing M-: to use lexical binding solve?

Make it behave the way coders who use lexical-binding (which I believe
are now the majority) expect.

You likely won't write code that relies on lexical scoping since you're
used to writing dynamically scoped code, but many coders nowadays never
touch dynamically scoped code and hence very much expect the lexical
binding rules, which is mostly the ability to use closures (which is
sometimes present only implicitly via macros like `gv-ref` (itself used
in other macros like `add-function`), thunk.el and generator.el macros,
...).


        Stefan

Re: lexical-binding is turned on in more use cases

[Alan Mackenzie]

Hello, Stefan.

On Tue, Mar 10, 2020 at 16:26:38 -0400, Stefan Monnier wrote:
> >> > You haven't answered the question.  Why did you not initiate a discussion
> >> > on emacs-devel before committing this patch?  emacs-devel is where
> >> > proposals that might or will break things get discussed; not a thread on
> >> > bug-gnu-emacs, where most affected people won't see it.
> >> It doesn't break any*thing*, AFAICT:
> > For crying out loud!  My very first post in this thread documented a
> > breakage which actually happened.  Please read it.

> Your first post showed that it changed the behavior you got when you use
> `M-:` but it did not break any existing code.

IT BROKE SOMETHING.  In particular, it broke my ability to test
something.  Please stop your sophistry.

> Usually we qualify this as "change" and not as "breakage".

You might, personally.  The rest of us call it breakage when something
which used to work no longer works.

> IOW it's maybe incompatible with your fingers (or your brain/memory) but
> not with existing code.

And you still, for the fourth time of asking, haven't answered the
question of why you failed to discuss this change on emacs-devel.  Were
you trying to prevent people like me expressing a view about it?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: lexical-binding is turned on in more use cases

[Andrea Corallo]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Andrea.
>
> On Tue, Mar 10, 2020 at 19:49:55 +0000, Andrea Corallo wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > What specific real problem does forcing M-: to use lexical binding
>> > solve?
>
>> My 2 cents are that it solves the problem of consistency if we assume
>> lexical binding is going to be the default for the future.
>
> What problem of consistency?
>
>> Indeed to become default it has to start somewhere.
>
> So, you would presumably agree with me, you know of no specific problem
> that lexical binding in M-: will solve.  It causes breakage.  But you
> think it's a good idea, anyway?
>
> I believe people who say lexical binding is a good idea, even though I
> can't see any benefit myself.  But there are places where lexical
> binding is not a good thing, and M-: is one of these, in my view.

Hi Alan,

Is just that I like the idea of having *scratch* buffer and M-: behaving
as the code I (and most of us) write (lexical).  I understand that,
being dynamic a super set of lexical, someone very much experienced can
still prefer the first, but is not my case at least :)

Regards

  Andrea

-- 
akrl@sdf.org

Re: lexical-binding is turned on in more use cases

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Make it behave the way coders who use lexical-binding (which I believe
> are now the majority) expect.

Exactly that.  It's a relief that M-: uses lexical-binding now.  I hated
it when I had to test something with emacs -Q and always had to be
careful how to eval stuff there.

Michael.

Re: lexical-binding is turned on in more use cases

[Alan Mackenzie]

Hello, Stefan.

On Tue, Mar 10, 2020 at 16:41:43 -0400, Stefan Monnier wrote:
> > What specific real problem does forcing M-: to use lexical binding solve?

> Make it behave the way coders who use lexical-binding (which I believe
> are now the majority) expect.

So, you admit there is no specific problem solved by forcing lexical
binding in M-:?

Lexical binding is useless for M-:.  It can't do anything useful.
Unless (contrived example) somebody is going to type in the code for
creating a closure into the minibuffer.  Or something like that.  Is
this really why you want to force lexical-binding in M-:?

I would think that ALL emacs coders, whether working with
lexical-binding nil or t, would expect to be able to bind a dynamic
variable, any dynamic variable, in a let form in M-:

> You likely won't write code that relies on lexical scoping since you're
> used to writing dynamically scoped code, but many coders nowadays never
> touch dynamically scoped code and hence very much expect the lexical
> binding rules, which is mostly the ability to use closures (which is
> sometimes present only implicitly via macros like `gv-ref` (itself used
> in other macros like `add-function`), thunk.el and generator.el macros,
> ...).

So, what we need here is a customisation variable, so that people who
want lexical binding in M-: can have it, and those who want dynamic
binding can also have that.  Agreed?

I'll code it up.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: lexical-binding is turned on in more use cases

[Michael Heerdegen]

Alan Mackenzie <acm@muc.de> writes:

> > You're probably right that "lexical-scope still isn't the norm for most
> > old school Emacs Lispers", so this change will irk those.  But my
> > impression is that the majority of *new* Elisp packages is using
> > lexical-binding nowadays, and the majority of Elisp snippets I see
> > quoted in StackExchange either work both ways or presume
> > lexical-binding (and then come with additional comments along the lines
> > of "I tried it and it didn't work ... indeed, you need to enable
> > lexical-binding by ... ah yes now it works").
>
> The above paragraph is sophistry.  Lexical binding in M-: simply isn't
> very useful, even when calling functions compiled with lexical binding.

It's not ok if it's "broken" for you, but it's ok for you if it's
"broken" for all the people who use lexical binding for their code?

Michael.

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

> And you still, for the fourth time of asking, haven't answered the
> question of why you failed to discuss this change on emacs-devel.
> Were you trying to prevent people like me expressing a view about it?

You can keep asking, but I will not dignify these insinuations with any answer.


        Stefan

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

> So, what we need here is a customisation variable, so that people who
> want lexical binding in M-: can have it, and those who want dynamic
> binding can also have that.  Agreed?

Fine by me, as long as the default is lexical (unless you can show that
my assessment of where the majority of coders stands).


        Stefan

Re: lexical-binding is turned on in more use cases

[Alan Mackenzie]

Hello, Michael.

On Tue, Mar 10, 2020 at 22:14:28 +0100, Michael Heerdegen wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > > You're probably right that "lexical-scope still isn't the norm for most
> > > old school Emacs Lispers", so this change will irk those.  But my
> > > impression is that the majority of *new* Elisp packages is using
> > > lexical-binding nowadays, and the majority of Elisp snippets I see
> > > quoted in StackExchange either work both ways or presume
> > > lexical-binding (and then come with additional comments along the lines
> > > of "I tried it and it didn't work ... indeed, you need to enable
> > > lexical-binding by ... ah yes now it works").

> > The above paragraph is sophistry.  Lexical binding in M-: simply isn't
> > very useful, even when calling functions compiled with lexical binding.

> It's not ok if it's "broken" for you, but it's ok for you if it's
> "broken" for all the people who use lexical binding for their code?

No, it's not.

I've asked several times (possibly even many times) here for somebody to
give an example of code which might be typed into M-: which requires
lexical-binding to work.  Up until very recently, if even that, there
was no answer.

Would you perhaps like to give me such an example?

And I'm angry that such a far reaching change was pushed through without
open discussion beforehand on emacs-devel.  This seems to happen far too
often in Emacs development.

I have recently proposed that the lexicality of bindings created in M-:
(etc.) should be determined by a customisation variable, and have
offered to code it up.  Would you find this a good solution?

Thanks!

> Michael.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: lexical-binding is turned on in more use cases

[Michael Heerdegen]

Alan Mackenzie <acm@muc.de> writes:

> Would you perhaps like to give me such an example?

Well - anything that relies on lexical-binding.  You can use any
playground example, like

(defun my-make-counter ()
  (let ((counter 0))
    (lambda () (setq counter (1+ counter)))))

(setq mc (my-make-counter))

(funcall mc) => 1
(funcall mc) => 2 ; etc.

If you eval (my-make-counter) with lexical-binding off, the result is
not functional.  If the expression to eval defines/binds something
important, this will error or even break a package.

> And I'm angry that such a far reaching change was pushed through without
> open discussion beforehand on emacs-devel.  This seems to happen far too
> often in Emacs development.

Were does M-: break for you with the change?

> I have recently proposed that the lexicality of bindings created in M-:
> (etc.) should be determined by a customisation variable, and have
> offered to code it up.  Would you find this a good solution?

I guess not.

AFAIU scratch has lexical binding on now, I think this is good.  M-:
used to use the lexical binding mode from the buffer it had been called.
Dunno if an alternative would be to turn on lexical binding in more
buffers instead.

But my guess is that you will also not get lucky if you start to get in
touch with code that relies on lexical binding (it gets more) and
customize the new option to turn lexical binding off for evaluation.


Michael.

Re: lexical-binding is turned on in more use cases

[Noam Postavsky]

On Tue, 10 Mar 2020 at 19:42, Michael Heerdegen
<michael_heerdegen@web.de> wrote:

> (defun my-make-counter ()
>   (let ((counter 0))
>     (lambda () (setq counter (1+ counter)))))
>
> (setq mc (my-make-counter))

> If you eval (my-make-counter) with lexical-binding off, the result is
> not functional.

Actually, it only fails if you evaluate the (defun my-make-counter
...) with lexical-binding off.

> Were does M-: break for you with the change?

Please, let's not go in circles. An example was already given
upthread: https://lists.gnu.org/r/emacs-devel/2020-03/msg00219.html

Essentially some cc-mode variables are only declared dynamic locally
within individual files. Without lexical binding the only difference
this causes is that they are unbound at top level; but with
lexical-binding, outside of the declaring files (e.g., in M-:
expressions), let-binding those variables doesn't bind the value
dynamically.

Re: lexical-binding is turned on in more use cases

[Michael Heerdegen]

Noam Postavsky <npostavs@gmail.com> writes:

> Actually, it only fails if you evaluate the (defun my-make-counter
> ...) with lexical-binding off.

That's what I expected, too, but I tested it quickly and it was as I
said...sorry, it's late here.  Maybe byte compiling the source also
makes a difference?

> > Were does M-: break for you with the change?
>
> Please, let's not go in circles. An example was already given
> upthread: https://lists.gnu.org/r/emacs-devel/2020-03/msg00219.html
>
> Essentially some cc-mode variables are only declared dynamic locally
> within individual files. Without lexical binding the only difference
> this causes is that they are unbound at top level; but with
> lexical-binding, outside of the declaring files (e.g., in M-:
> expressions), let-binding those variables doesn't bind the value
> dynamically.

I meant "real" examples (that are not actually coding errors).  I
guess, like let-binding a variable that is not (yet) declared around an
expression whose evaluation will autoload the declaration but it's too
late for that binding and you get something unexpected.

Michael.

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/x-markdown; coding=UTF-8, Size: 807 bytes --]

> And I'm angry that such a far reaching change was pushed through without
> open discussion beforehand on emacs-devel.

Alan, I understand you're angry.  But this change only affects `M-:`.
Nothing else.  With such a confined impact, it can't qualify for "far
reaching", really.

So please get back on earth and discuss this without that drama which
undermines your arguments.

BTW, your example use of `M-:` also fails in Emacs-26 if you happen to
use it from a buffer where `lexical-binding` was set to t.  Now, this is
rather unlikely to happen in CC-mode buffers, but for code which is
used in Elisp-mode buffers, this current-buffer-dependent behavior was
sometimes surprising as well.

> offered to code it up.  Would you find this a good solution?

I already answered this part.


        Stefan

Re: lexical-binding is turned on in more use cases

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >     M-: (eval '(let (...) (c-align-cpp-indent-to-body)))

  > runs correctly, but fails to stop in c-align-..-body, even though it is
  > instrumented for edebug.

This leads me to suspect there is a bug in edebug
in its handling of dynamic and lexical bindings.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: lexical-binding is turned on in more use cases

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Usually we qualify this as "change" and not as "breakage".

  > You might, personally.  The rest of us call it breakage when something
  > which used to work no longer works.

This discussion is becoming unkind.  Please, everyone, make an effort
to respect the views that you are disagreeing with.

  > And you still, for the fourth time of asking, haven't answered the
  > question of why you failed to discuss this change on emacs-devel.  Were
  > you trying to prevent people like me expressing a view about it?

Please don't post conjectures that ascribe unworthy motives to the
other participants.  We have all made bad decisions with the best of
intentions.

Please reread https://gnu.org/philosophy/kind-communication.html
and think about it a bit.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: lexical-binding is turned on in more use cases

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > (defun my-make-counter ()
  >   (let ((counter 0))
  >     (lambda () (setq counter (1+ counter)))))

  > (setq mc (my-make-counter))

  > (funcall mc) => 1
  > (funcall mc) => 2 ; etc.

  > If you eval (my-make-counter) with lexical-binding off, the result is
  > not functional.

It is clear that my-make-counter needs to be run with lexical binding.
The closure it returns also needs to be run with lexical binding.

However, it seems like a bug that the lexical-dynamic mode in effect
around the _call_ to my-make-counter has any effect on how it runs.
It seems to me that if the definition of my-make-counter comes from a
file that specifies lexical, it should run with lexical bindings
regardless of where it is called from.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: lexical-binding is turned on in more use cases

[Eli Zaretskii]

> Date: Tue, 10 Mar 2020 21:02:11 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> So, what we need here is a customisation variable, so that people who
> want lexical binding in M-: can have it, and those who want dynamic
> binding can also have that.  Agreed?

No, I don't agree.  We had such a variable, and the change whose
effects we are discussing here effectively removed it.  We are not
going back, sorry.

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/x-markdown; coding=UTF-8, Size: 528 bytes --]

> To be precise,
>
>     M-: (eval '(let (...) (c-align-cpp-indent-to-body)))
>
> runs correctly, but fails to stop in c-align-..-body, even though it is
> instrumented for edebug.

That would be a bug.  I can't reproduce it here.  I did:

    % src/emacs -Q src/emacs-module.c lisp/progmodes/cc-cmds.el
    C-s cpp-indent RET
    C-u C-M-x
    C-x o
    M-: (eval '(let ((c-syntactic-context nil)) (c-align-cpp-indent-to-body))) RET

and it landed me in edebugging the body of `c-align-cpp-indent-to-body`.


        Stefan

Re: lexical-binding is turned on in more use cases

[Stefan Monnier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/x-markdown; coding=UTF-8, Size: 267 bytes --]

> However, it seems like a bug that the lexical-dynamic mode in effect
> around the _call_ to my-make-counter has any effect on how it runs.

It would be a bug, indeed.  I suspect it was a pilot error somewhere,
tho, because I can't reproduce it.


        Stefan

Re: lexical-binding is turned on in more use cases

[John Wiegley]

>>>>> "AM" == Alan Mackenzie <acm@muc.de> writes:

AM> And I'm angry that such a far reaching change was pushed through without
AM> open discussion beforehand on emacs-devel. This seems to happen far too
AM> often in Emacs development.

While it may indeed be time to rip the band-aid and just accept M-: as
lexical, you make a good meta-point, Alan. This forum exists for us to discuss
such matters, and the fact that you were surprised is a sign that we haven't
done the best job of communicating with each other on this issue.

I don't want to question past motives here, simply to encourage Stefan and
everyone else to do what you can to keep your fellow developers in the loop,
and feeling like a part of the close-knit community that we are. I doubt any
malfeasance was intended, but since the pot has evidently become stirred,
let's do our best to avoid it happening too often.

You are both extremely valued members of this development team. I'd rather
have you on good terms than to have a thousand lexically bound minibuffers.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: lexical-binding is turned on in more use cases

[Noam Postavsky]

On Tue, 10 Mar 2020 at 22:02, Michael Heerdegen
<michael_heerdegen@web.de> wrote:

> > Essentially some cc-mode variables are only declared dynamic locally
> > within individual files. Without lexical binding the only difference
> > this causes is that they are unbound at top level; but with
> > lexical-binding, outside of the declaring files (e.g., in M-:
> > expressions), let-binding those variables doesn't bind the value
> > dynamically.
>
> I meant "real" examples (that are not actually coding errors).

Whether or not there is a coding error in the above is a somewhat
philosophical question.

> like let-binding a variable that is not (yet) declared around an
> expression whose evaluation will autoload the declaration but it's too
> late for that binding and you get something unexpected.

But I just realized Bug#39823 is an example of exactly this.

https://debbugs.gnu.org/39823 "update-directory-autoloads regression
from Emacs 26 to Emacs 27"

Re: lexical-binding is turned on in more use cases

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > However, it seems like a bug that the lexical-dynamic mode in effect
> > around the _call_ to my-make-counter has any effect on how it runs.
>
> It would be a bug, indeed.  I suspect it was a pilot error somewhere,
> tho, because I can't reproduce it.

Indeed, the pilot was just too tired, sorry for the false alarm.

The case I originally intended to describe was where you reevaluate the
my-make-counter defun with M-:.  This is the pitfall I often faced when
testing stuff I think.

Michael.

Re: lexical-binding is turned on in more use cases

[Bruno Félix Rezende Ribeiro]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

Hi Andrea,

Andrea Corallo <akrl@sdf.org> writes:

> I understand that, being dynamic a super set of lexical, someone very
> much experienced can still prefer the first, but is not my case at
> least :)

Quoting what Stefan said earlier in this thread:

  I don't see why: lexical-binding gives a strict superset of what can be
  done without it[...]

So I guess it’s the other way around.


-- 
Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
<http://oitofelix.freeshell.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]