[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#7604: `loop', PATCH: loop, cl-parse-loop-clause, cl-map-intervals --
bug#7604: `loop', PATCH: loop, cl-parse-loop-clause, cl-map-intervals -- being the intervals of
Fri, 26 Feb 2016 16:57:48 +1030
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)
MON KEY <address@hidden> writes:
> Current through BZR-102620 there is a bug around `loop',
> `cl-parse-loop-clause', and `cl-map-intervals' which put them in
> conflict with the manual (which is unclear w/re intended usage):
> | `for VAR being the intervals [of BUFFER] ...'
> | This clause iterates over all intervals of a buffer with constant
> | text properties. The variable VAR will be bound to conses of
> | start and end positions, where one start position is always equal
> | to the previous end position. The clause allows `of', `from',
> | `to', and `property' terms, where the latter term restricts the
> | search to just the specified property. The `of' term may specify
> | either a buffer or a string.
> There should be an additional infix filler word preceding `property'
> as their is with the hash-table loop clauses, and he right fix IMO
> would be to add a `using' syntax instead of and/or in addition to
> testing for `property' which is pretty clearly (of itself) NTRT.
> Such an addtion would allow for:
> (loop for <VAR> being the intervals in <BUFFER> using property <PROP>
> from <INT> to <INT>
> collecting tp)
> Regardless, the ttached patch is current w/ BZR-102620. It fixes the
> problem and remains backwards compatable with the existing behaviour
> in Emacs 23.
> rgrep says nothing in core uses this loop idiom so it should be a
> fairly clean fix.
Since nothing uses it, and it's a non-standard Emacs extension to loop,
perhaps we should just remove the intervals stuff from cl-loop?
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
|[Prev in Thread]
||[Next in Thread]|
- bug#7604: `loop', PATCH: loop, cl-parse-loop-clause, cl-map-intervals -- being the intervals of,
Lars Ingebrigtsen <=