unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* (copy-marker nil)
@ 2018-05-07  8:19 Andreas Röhler
  2018-05-07 13:39 ` John Mastro
  2018-05-07 13:55 ` Noam Postavsky
  0 siblings, 2 replies; 10+ messages in thread
From: Andreas Röhler @ 2018-05-07  8:19 UTC (permalink / raw)
  To: Help Gnu Emacs mailing list

Hi,

being surprised WRT behavior of copy-marker:

(setq a (copy-marker nil)) -> #<marker in no buffer>
(markerp a) -> t
a -> #<marker in no buffer>

Is taking nil by copy-marker reasonable?

Wanted to check for a valid buffer position, which doesn't seem possible 
that way. While without copy-marker, the variable a would be set to nil, 
now the result evaluates to  #<marker in no buffer>, which is a kind of t.


Cheers,

Andreas



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

* Re: (copy-marker nil)
  2018-05-07  8:19 (copy-marker nil) Andreas Röhler
@ 2018-05-07 13:39 ` John Mastro
  2018-05-07 14:23   ` Andreas Röhler
  2018-05-07 13:55 ` Noam Postavsky
  1 sibling, 1 reply; 10+ messages in thread
From: John Mastro @ 2018-05-07 13:39 UTC (permalink / raw)
  To: Help Gnu Emacs mailing list

Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:
> being surprised WRT behavior of copy-marker:
>
> (setq a (copy-marker nil)) -> #<marker in no buffer>
> (markerp a) -> t
> a -> #<marker in no buffer>
>
> Is taking nil by copy-marker reasonable?
>
> Wanted to check for a valid buffer position, which doesn't seem
> possible that way. While without copy-marker, the variable a would be
> set to nil, now the result evaluates to #<marker in no buffer>, which
> is a kind of t.

There are other ways to get a marker to no buffer, such as

(let ((a (point-marker)))
  (set-marker a nil))

So if you don't control the creation of the marker, it's probably a
scenario you need to take care for either way.

Explicitly testing the marker's buffer should work:

(let ((a (copy-marker nil)))
  (and (markerp a)
       (buffer-live-p (marker-buffer a))))

-- 
John



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

* Re: (copy-marker nil)
  2018-05-07  8:19 (copy-marker nil) Andreas Röhler
  2018-05-07 13:39 ` John Mastro
@ 2018-05-07 13:55 ` Noam Postavsky
  2018-05-07 14:20   ` Andreas Röhler
  1 sibling, 1 reply; 10+ messages in thread
From: Noam Postavsky @ 2018-05-07 13:55 UTC (permalink / raw)
  To: Andreas Röhler; +Cc: Help Gnu Emacs mailing list

On 7 May 2018 at 04:19, Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:

> being surprised WRT behavior of copy-marker:
>
> (setq a (copy-marker nil)) -> #<marker in no buffer>
> (markerp a) -> t
> a -> #<marker in no buffer>
>
> Is taking nil by copy-marker reasonable?

For most functions, passing nil for an &optional parameter is the same
as omitting it.

(copy-marker &optional MARKER TYPE)
[...]
If MARKER is not specified, the new marker does not point anywhere.



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

* Re: (copy-marker nil)
  2018-05-07 13:55 ` Noam Postavsky
@ 2018-05-07 14:20   ` Andreas Röhler
  2018-05-07 14:26     ` Drew Adams
  0 siblings, 1 reply; 10+ messages in thread
From: Andreas Röhler @ 2018-05-07 14:20 UTC (permalink / raw)
  To: Help Gnu Emacs mailing list

On 07.05.2018 15:55, Noam Postavsky wrote:
> On 7 May 2018 at 04:19, Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:
> 
>> being surprised WRT behavior of copy-marker:
>>
>> (setq a (copy-marker nil)) -> #<marker in no buffer>
>> (markerp a) -> t
>> a -> #<marker in no buffer>
>>
>> Is taking nil by copy-marker reasonable?
> 
> For most functions, passing nil for an &optional parameter is the same
> as omitting it.
> 
> (copy-marker &optional MARKER TYPE)
> [...]
> If MARKER is not specified, the new marker does not point anywhere.
> 

It's about the return value.

A marker pointing nowhere, might it be considered valid?
Expected such returning nil.

The use-case is the end-position of some object at point. Which will not 
exist, if there exists no one there. A useful info maybe.

Without marker, the end-position will be nil. However (setq end-position 
(copy-marker an-end-maybe)) makes it being something at any case.



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

* Re: (copy-marker nil)
  2018-05-07 13:39 ` John Mastro
@ 2018-05-07 14:23   ` Andreas Röhler
  0 siblings, 0 replies; 10+ messages in thread
From: Andreas Röhler @ 2018-05-07 14:23 UTC (permalink / raw)
  To: John Mastro, Help Gnu Emacs mailing list

On 07.05.2018 15:39, John Mastro wrote:
> Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:
>> being surprised WRT behavior of copy-marker:
>>
>> (setq a (copy-marker nil)) -> #<marker in no buffer>
>> (markerp a) -> t
>> a -> #<marker in no buffer>
>>
>> Is taking nil by copy-marker reasonable?
>>
>> Wanted to check for a valid buffer position, which doesn't seem
>> possible that way. While without copy-marker, the variable a would be
>> set to nil, now the result evaluates to #<marker in no buffer>, which
>> is a kind of t.
> 
> There are other ways to get a marker to no buffer, such as
> 
> (let ((a (point-marker)))
>    (set-marker a nil))
> 
> So if you don't control the creation of the marker, it's probably a
> scenario you need to take care for either way.
> 
> Explicitly testing the marker's buffer should work:
> 
> (let ((a (copy-marker nil)))
>    (and (markerp a)
>         (buffer-live-p (marker-buffer a))))
> 

Thanks. A way to deal with ;)





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

* RE: (copy-marker nil)
  2018-05-07 14:20   ` Andreas Röhler
@ 2018-05-07 14:26     ` Drew Adams
  2018-05-07 17:16       ` Andreas Röhler
  0 siblings, 1 reply; 10+ messages in thread
From: Drew Adams @ 2018-05-07 14:26 UTC (permalink / raw)
  To: Andreas Röhler, Help Gnu Emacs mailing list

> > For most functions, passing nil for an &optional parameter is the same
> > as omitting it.
> > If MARKER is not specified, the new marker does not point anywhere.
> 
> It's about the return value.
> A marker pointing nowhere, might it be considered valid?

What do you mean by "valid"?  Yes, it's a marker.  No, it
doesn't have a buffer or position.  The same is true of
other Emacs-Lisp objects, such as overlays: they can exist
without having non-nil values for certain of their properties.

> Expected such returning nil.

Why?  The doc string is pretty clear that it returns a
marker.  And it is clear what happens if arg MARKER is
nil: "the new marker does not point anywhere".



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

* Re: (copy-marker nil)
  2018-05-07 14:26     ` Drew Adams
@ 2018-05-07 17:16       ` Andreas Röhler
  2018-05-08  1:46         ` Stefan Monnier
  0 siblings, 1 reply; 10+ messages in thread
From: Andreas Röhler @ 2018-05-07 17:16 UTC (permalink / raw)
  To: Drew Adams, Help Gnu Emacs mailing list

On 07.05.2018 16:26, Drew Adams wrote:
>>> For most functions, passing nil for an &optional parameter is the same
>>> as omitting it.
>>> If MARKER is not specified, the new marker does not point anywhere.
>>
>> It's about the return value.
>> A marker pointing nowhere, might it be considered valid?
> 
> What do you mean by "valid"?  Yes, it's a marker.  No, it
> doesn't have a buffer or position.  The same is true of
> other Emacs-Lisp objects, such as overlays: they can exist
> without having non-nil values for certain of their properties.
> 
>> Expected such returning nil.
> 
> Why?  The doc string is pretty clear that it returns a
> marker.  And it is clear what happens if arg MARKER is
> nil: "the new marker does not point anywhere".
> 


Is there a use-case for a marker pointing nowhere?
 From my point of view refusing to create such a marker makes sense.



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

* Re: (copy-marker nil)
  2018-05-07 17:16       ` Andreas Röhler
@ 2018-05-08  1:46         ` Stefan Monnier
  2018-05-08  8:44           ` Andreas Röhler
  0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2018-05-08  1:46 UTC (permalink / raw)
  To: help-gnu-emacs

> Is there a use-case for a marker pointing nowhere?

Yes.

> From my point of view refusing to create such a marker makes sense.

It would break existing code.  BTW "check for a valid buffer position"
won't work with copy-marker for other reasons (e.g. (copy-marker 0)
returns a marker pointing to (point-min), even though 0 is not a valid
position).

I have no idea why you think copy-marker might be a good way to solve
your problem, but the evidence seems to suggest you should try
something else.


        Stefan




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

* Re: (copy-marker nil)
  2018-05-08  1:46         ` Stefan Monnier
@ 2018-05-08  8:44           ` Andreas Röhler
  2018-05-12 22:06             ` Stefan Monnier
  0 siblings, 1 reply; 10+ messages in thread
From: Andreas Röhler @ 2018-05-08  8:44 UTC (permalink / raw)
  To: help-gnu-emacs

On 08.05.2018 03:46, Stefan Monnier wrote:
>> Is there a use-case for a marker pointing nowhere?
> 
> Yes.
> 
>>  From my point of view refusing to create such a marker makes sense.
> 
> It would break existing code. 


Thats a concern. It would surprise me though. Do you have an example.


  BTW "check for a valid buffer position"
> won't work with copy-marker for other reasons (e.g. (copy-marker 0)
> returns a marker pointing to (point-min), even though 0 is not a valid
> position).
> 

Well, zero here is a special case. But copying a marker out of nil seems 
not logically. Resp. thats how the universe started? ;)






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

* Re: (copy-marker nil)
  2018-05-08  8:44           ` Andreas Röhler
@ 2018-05-12 22:06             ` Stefan Monnier
  0 siblings, 0 replies; 10+ messages in thread
From: Stefan Monnier @ 2018-05-12 22:06 UTC (permalink / raw)
  To: help-gnu-emacs

> Well, zero here is a special case.

No.  You can try it with many other "out of bounds" integers.

> But copying a marker out of nil seems not logically.

It works just as well as (move-marker m nil) and for the same reasons.
A marker *can* point to "nothing" and it's an important property.


        Stefan




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

end of thread, other threads:[~2018-05-12 22:06 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-05-07  8:19 (copy-marker nil) Andreas Röhler
2018-05-07 13:39 ` John Mastro
2018-05-07 14:23   ` Andreas Röhler
2018-05-07 13:55 ` Noam Postavsky
2018-05-07 14:20   ` Andreas Röhler
2018-05-07 14:26     ` Drew Adams
2018-05-07 17:16       ` Andreas Röhler
2018-05-08  1:46         ` Stefan Monnier
2018-05-08  8:44           ` Andreas Röhler
2018-05-12 22:06             ` Stefan Monnier

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).