unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* delq string element in ido
@ 2009-12-26 10:49 Leo
  2009-12-26 11:15 ` Andreas Schwab
  0 siblings, 1 reply; 7+ messages in thread
From: Leo @ 2009-12-26 10:49 UTC (permalink / raw)
  To: emacs-devel

In function `ido-kill-buffer-at-head', there's this form

    (delq buf ido-cur-list)

where buf is a string and ido-cur-list is a list of strings. I get this
by stepping through this function and checking the values of buf and
ido-cur-list. But delq uses `eq' to compare. Any idea why this function
still succeeds?

Leo





^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: delq string element in ido
  2009-12-26 10:49 delq string element in ido Leo
@ 2009-12-26 11:15 ` Andreas Schwab
  2009-12-26 12:13   ` Leo
  0 siblings, 1 reply; 7+ messages in thread
From: Andreas Schwab @ 2009-12-26 11:15 UTC (permalink / raw)
  To: Leo; +Cc: emacs-devel

Leo <sdl.web@gmail.com> writes:

> In function `ido-kill-buffer-at-head', there's this form
>
>     (delq buf ido-cur-list)
>
> where buf is a string and ido-cur-list is a list of strings. I get this
> by stepping through this function and checking the values of buf and
> ido-cur-list. But delq uses `eq' to compare. Any idea why this function
> still succeeds?

Because `eq' returns t for identical Lisp objects.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: delq string element in ido
  2009-12-26 11:15 ` Andreas Schwab
@ 2009-12-26 12:13   ` Leo
  2009-12-26 12:34     ` Teemu Likonen
                       ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Leo @ 2009-12-26 12:13 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Leo, emacs-devel

2009/12/26 Andreas Schwab <schwab@linux-m68k.org>:
> Leo <sdl.web@gmail.com> writes:
>
>> In function `ido-kill-buffer-at-head', there's this form
>>
>>     (delq buf ido-cur-list)
>>
>> where buf is a string and ido-cur-list is a list of strings. I get this
>> by stepping through this function and checking the values of buf and
>> ido-cur-list. But delq uses `eq' to compare. Any idea why this function
>> still succeeds?
>
> Because `eq' returns t for identical Lisp objects.
>
> Andreas.

I don't quite get it.

If buf holds "str1" and ido-cur-list '("str1" "str2" "str3"), (delq
buf ido-cur-list) does not return '("str2" "str3"). But it does inside
ido-kill-buffer-at-head. That's where I am confused.

Could you explain a bit more? Thanks.

Leo




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: delq string element in ido
  2009-12-26 12:13   ` Leo
@ 2009-12-26 12:34     ` Teemu Likonen
  2009-12-26 12:37     ` Eli Zaretskii
  2009-12-26 13:05     ` Andreas Schwab
  2 siblings, 0 replies; 7+ messages in thread
From: Teemu Likonen @ 2009-12-26 12:34 UTC (permalink / raw)
  To: Leo; +Cc: Andreas Schwab, Leo, emacs-devel

On 2009-12-26 12:13 (UTC), Leo wrote:

> 2009/12/26 Andreas Schwab <schwab@linux-m68k.org>:
>> Because `eq' returns t for identical Lisp objects.

> I don't quite get it.
>
> If buf holds "str1" and ido-cur-list '("str1" "str2" "str3"), (delq
> buf ido-cur-list) does not return '("str2" "str3"). But it does inside
> ido-kill-buffer-at-head. That's where I am confused.

It's not actually "identical Lisp objects"; eq is about the _same_ Lisp
object. Let me demonstrate:

    (setq my-list (list "one" "two")
          my-one (car my-list))

Internally my-one and (car my-list) refer to the same Lisp object:

    (eq my-one (car my-list))
    => t

But in the following examples the string "one" creates new Lisp object
which is different from the one referenced by my-one or (car my-list).

    (eq "one" (car my-list))
    => nil

    (eq "one" my-one)
    => nil




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: delq string element in ido
  2009-12-26 12:13   ` Leo
  2009-12-26 12:34     ` Teemu Likonen
@ 2009-12-26 12:37     ` Eli Zaretskii
  2009-12-26 13:05     ` Andreas Schwab
  2 siblings, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2009-12-26 12:37 UTC (permalink / raw)
  To: Leo; +Cc: schwab, emacs-devel

> Date: Sat, 26 Dec 2009 12:13:22 +0000
> From: Leo <sdl.web@googlemail.com>
> Cc: Leo <sdl.web@gmail.com>, emacs-devel@gnu.org
> 
> If buf holds "str1" and ido-cur-list '("str1" "str2" "str3"), (delq
> buf ido-cur-list) does not return '("str2" "str3"). But it does inside
> ido-kill-buffer-at-head. That's where I am confused.

Probably because the value of buf comes from ido-cur-list, so it's the
same Lisp object as one of the strings in ido-cur-list.




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: delq string element in ido
  2009-12-26 12:13   ` Leo
  2009-12-26 12:34     ` Teemu Likonen
  2009-12-26 12:37     ` Eli Zaretskii
@ 2009-12-26 13:05     ` Andreas Schwab
  2009-12-26 15:24       ` Leo
  2 siblings, 1 reply; 7+ messages in thread
From: Andreas Schwab @ 2009-12-26 13:05 UTC (permalink / raw)
  To: Leo; +Cc: Leo, emacs-devel

Leo <sdl.web@googlemail.com> writes:

> If buf holds "str1" and ido-cur-list '("str1" "str2" "str3"), (delq
> buf ido-cur-list) does not return '("str2" "str3"). But it does inside
> ido-kill-buffer-at-head. That's where I am confused.

(setq buf (car ido-cur-list))
(eq (delq buf ido-cur-list) (cdr ido-cur-list))

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: delq string element in ido
  2009-12-26 13:05     ` Andreas Schwab
@ 2009-12-26 15:24       ` Leo
  0 siblings, 0 replies; 7+ messages in thread
From: Leo @ 2009-12-26 15:24 UTC (permalink / raw)
  To: emacs-devel

On 2009-12-26 13:05 +0000, Andreas Schwab wrote:
> Leo <sdl.web@googlemail.com> writes:
>
>> If buf holds "str1" and ido-cur-list '("str1" "str2" "str3"), (delq
>> buf ido-cur-list) does not return '("str2" "str3"). But it does inside
>> ido-kill-buffer-at-head. That's where I am confused.
>
> (setq buf (car ido-cur-list))
> (eq (delq buf ido-cur-list) (cdr ido-cur-list))
>
> Andreas.

Thank you. Now I get it.

On 2009-12-26 12:37 +0000, Eli Zaretskii wrote:
>> Date: Sat, 26 Dec 2009 12:13:22 +0000
>> From: Leo <sdl.web@googlemail.com>
>> Cc: Leo <sdl.web@gmail.com>, emacs-devel@gnu.org
>> 
>> If buf holds "str1" and ido-cur-list '("str1" "str2" "str3"), (delq
>> buf ido-cur-list) does not return '("str2" "str3"). But it does inside
>> ido-kill-buffer-at-head. That's where I am confused.
>
> Probably because the value of buf comes from ido-cur-list, so it's the
> same Lisp object as one of the strings in ido-cur-list.

Indeed, it is due to ido-name.

On 2009-12-26 12:34 +0000, Teemu Likonen wrote:
[...]
>
> It's not actually "identical Lisp objects"; eq is about the _same_ Lisp
> object. Let me demonstrate:
>
>     (setq my-list (list "one" "two")
>           my-one (car my-list))
>
> Internally my-one and (car my-list) refer to the same Lisp object:
>
>     (eq my-one (car my-list))
>     => t
>
> But in the following examples the string "one" creates new Lisp object
> which is different from the one referenced by my-one or (car my-list).
>
>     (eq "one" (car my-list))
>     => nil
>
>     (eq "one" my-one)
>     => nil

Many thanks for the detailed explanation.

Leo





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2009-12-26 15:24 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-26 10:49 delq string element in ido Leo
2009-12-26 11:15 ` Andreas Schwab
2009-12-26 12:13   ` Leo
2009-12-26 12:34     ` Teemu Likonen
2009-12-26 12:37     ` Eli Zaretskii
2009-12-26 13:05     ` Andreas Schwab
2009-12-26 15:24       ` Leo

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).