Re: forward-paragraph return value

["Stephen J. Turnbull" <stephen@xemacs.org>]

Andreas Röhler writes:
 > Am 24.08.2010 10:27, schrieb Stephen J. Turnbull:
 > > Andreas Röhler writes:
 > >
 > >   >  Then people may write functions taking already the return
 > >   >  value.
 > > Sure.  But will they?  Show us examples of existing functions
 > > (preferably already in Emacs) that would benefit from this
 > > change.
 > >    
 > 
 > Didn't I point to?
 > 
 > If a look in forward-paragraph doesn't speak to you,

Of course that doesn't speak to me; that's the function you propose to
change.

 > maybe have a look into
 > 
 > bounds-of-thing-at-point .

`forward-paragraph' is a command.  `bounds-of-thing-at-point' is not.
There's a big difference.

 > Forms like
 >          (let
 >            (beg
 >              (progn
 >               (funcall
 >                (or (get thing 'beginning-op)
 >                                (lambda () (forward-thing thing -1))))
 >               (point))))

I doubt that form appears anywhere in Emacs.  The style is nauseating,
not to mention that `progn' is a very unusual choice for a variable
you are let-binding. ;-)  Please give *real* examples, or if you're
going to simplify real code to make your point, say that's what you're
doing.  And do it correctly, even for a fragment like this.

 > Thats bug-sourcing BTW, as it returns point in any case, even if
 > move failed.  Why not make implementation of return value from
 > 
 > search-forward
 > 
 > canonical instead, returning the position if succesful, nil
 > otherwise.

Er, because otherwise `search-forward' does not return nil, but rather
signals an error?  You need to specify additional arguments to get it
to return nil.  There's a reason for this interface, related to the
fact that `search-forward' is a command, as is `forward-paragraph'.

 > The gain will be for newly written code.  For writers first, who
 > must not learn function by function the return value.

A common convention might be a good idea.  It's a better idea for
non-commands than it is for commands, though.

 > In the example above we could write
 > 
 > (let
 >      (beg
 >       (funcall
 >        (or (get thing 'beginning-op)
 >            (lambda () (forward-thing thing -1))))))
 > 
 > Its clean and much more reliable, as beg will be nil, if nothing
 > was found.

Maybe.  But in fact, this is a (broken) copy of (part of) the
implementation of `bounds-of-thing-at-point'.  At least in XEmacs,
that function has *much* bigger problems than the return value of
forward-thing.  Also, since the return value of `forward-thing' is
undocumented (and probably rather unreliable), you could change that,
or define an internal function for the use of functions defun'ed in
thingatpt.el.

The issue with forward-paragraph is quite different, because it is
documented and it is a command.