(copy-marker nil)

(copy-marker nil)

[Andreas Röhler]

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

Re: (copy-marker nil)

[John Mastro]

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

Re: (copy-marker nil)

[Noam Postavsky]

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.

Re: (copy-marker nil)

[Andreas Röhler]

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.

Re: (copy-marker nil)

[Andreas Röhler]

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

RE: (copy-marker nil)

[Drew Adams]

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

Re: (copy-marker nil)

[Andreas Röhler]

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.

Re: (copy-marker nil)

[Stefan Monnier]

> 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

Re: (copy-marker nil)

[Andreas Röhler]

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? ;)

Re: (copy-marker nil)

[Stefan Monnier]

> 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