bug#10387: CODE wishlist: search-prop.el

bug#10387: CODE wishlist: search-prop.el

[Jari Aalto]

Package: emacs
Version: 23.3
Severity: wishlist

I come accross functions that might be useful to be included in Emacs:

    http://mwolson.org/static/dist/elisp/search-prop.el

    search-property
    search-property-forward (interactive)
    search-property-backward (interactive)

Jari

-- System Information
Debian Release: wheezy/sid
  APT Prefers testing
  APT policy: (500, testing) (990, unstable)
Architecture: i386
Kernel: Linux cante 3.1.0-1-686-pae #1 SMP Sun Dec 11 20:40:16 UTC 2011 i686 GNU/Linux
Locale: LANG=en_US.UTF-8

-- Versions of packages `emacs depends on'.
Depends:
emacs23         23.3+1-4        GNU Emacs is the extensible self-documenting 
emacs23-lucid   23.3+1-4        GNU Emacs is the extensible self-documenting 
emacs23-nox     23.3+1-4        GNU Emacs is the extensible self-documenting 

bug#10387: CODE wishlist: search-prop.el

[Lars Magne Ingebrigtsen]

Jari Aalto <jari.aalto@cante.net> writes:

> I come accross functions that might be useful to be included in Emacs:
>
>     http://mwolson.org/static/dist/elisp/search-prop.el
>
>     search-property
>     search-property-forward (interactive)
>     search-property-backward (interactive)

I like this.  Gnus uses text properties extensively, and searching for
them using the standard functions (`next-property-change' and friends)
is a hassle.

`search-property' looks like what I have needed in the past.

Would it be OK to install this in Emacs?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#10387: CODE wishlist: search-prop.el

[Stefan Monnier]

> I like this.  Gnus uses text properties extensively, and searching for
> them using the standard functions (`next-property-change' and friends)
> is a hassle.
> `search-property' looks like what I have needed in the past.

text-property-any (and t-p-not-all) seems to do the same, except it only
searches forward.  Is there some other difference I'm missing (other
than the `cycle' which doesn't seem tremendously useful)?


        Stefan

bug#10387: CODE wishlist: search-prop.el

[Michael Olson]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

On Thu, Apr 12, 2012 at 2:55 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > I like this.  Gnus uses text properties extensively, and searching for
> > them using the standard functions (`next-property-change' and friends)
> > is a hassle.
> > `search-property' looks like what I have needed in the past.
>
> text-property-any (and t-p-not-all) seems to do the same, except it only
> searches forward.  Is there some other difference I'm missing (other
> than the `cycle' which doesn't seem tremendously useful)?
>

Differences compared to text-property-any:

 - Includes helper functions 'search-property-forward' and
'search-property-backward' which move point and closely match the interface
and behavior of 'search-forward' and 'search-backward'.  (Except for
'count'.)  The interactive use is nice: when you need it, you really need
it.

 - I don't remember what the original use case was for 'cycle'.  Possibly
to emulate the effect of hitting TAB in Emacs Muse to go to the next URL
(behavior that I would remove if I was starting again from scratch).

 - In the initial release of the file to gnu.emacs.sources, I wrote this
blurb.  Maybe there was a related shortcoming in text-property-any at the
time.

Blurb: "It should work perfectly well both in the case where consecutive
characters have the property, and in that where a single character has
the property."

-- 
Michael Olson  |  http://mwolson.org/

[-- Attachment #2: Type: text/html, Size: 2094 bytes --]

bug#10387: CODE wishlist: search-prop.el

[Stefan Monnier]

>> > I like this.  Gnus uses text properties extensively, and searching for
>> > them using the standard functions (`next-property-change' and friends)
>> > is a hassle.
>> > `search-property' looks like what I have needed in the past.
>> text-property-any (and t-p-not-all) seems to do the same, except it only
>> searches forward.  Is there some other difference I'm missing (other
>> than the `cycle' which doesn't seem tremendously useful)?
> Differences compared to text-property-any:
>  - Includes helper functions 'search-property-forward' and
>   'search-property-backward' which move point and closely match the
>   interface and behavior of 'search-forward' and 'search-backward'.
>   (Except for 'count'.)  The interactive use is nice: when you need
>   it, you really need it.

I can't remember needing such a thing, but maybe it's just because it
didn't occur to me.

>  - I don't remember what the original use case was for 'cycle'.  Possibly
>    to emulate the effect of hitting TAB in Emacs Muse to go to the next URL
>    (behavior that I would remove if I was starting again from scratch).

I guess the cycle makes sense for interactive use, tho it can be
implemented on top of a non-cycling primitive.

So all in all, I think the main points are:
- search backward.
- UI.
- names with "search" and with direction.
I actually like it, so I suggest to provide new functions
(search-text-property-forward START END PROP VALUE &optional OBJECT NOT-EQ)
and search-text-property-backward, implemented in C and then reimplement
text-property-any and text-property-not-all in Elisp on top of them (and
make them obsolete).


        Stefan

bug#10387: CODE wishlist: search-prop.el

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I actually like it, so I suggest to provide new functions
> (search-text-property-forward START END PROP VALUE &optional OBJECT NOT-EQ)
> and search-text-property-backward, implemented in C and then reimplement
> text-property-any and text-property-not-all in Elisp on top of them (and
> make them obsolete).

Yeah, I think that's a good idea.  I'll probably have a go at it
sometime this year...  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#10387: CODE wishlist: search-prop.el

[Drew Adams]

> > I actually like it, so I suggest to provide new functions
> > (search-text-property-forward START END PROP VALUE &optional
> >                               OBJECT NOT-EQ)
> > and search-text-property-backward, implemented in C and then
> > reimplement text-property-any and text-property-not-all in Elisp
> > on top of them (and make them obsolete).
> 
> Yeah, I think that's a good idea.  I'll probably have a go at it
> sometime this year...  :-)

Maybe see also:
http://www.emacswiki.org/emacs/download/isearch-prop.el

bug#10387: CODE wishlist: search-prop.el

[Lars Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>>     search-property
>>     search-property-forward (interactive)
>>     search-property-backward (interactive)
>
> I like this.  Gnus uses text properties extensively, and searching for
> them using the standard functions (`next-property-change' and friends)
> is a hassle.
>
> `search-property' looks like what I have needed in the past.
>
> Would it be OK to install this in Emacs?

(That was seven years ago.)

Instead I implemented different versions of the same concept in Emacs a
few years back, so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#10387: CODE wishlist: search-prop.el

[Drew Adams]

I was not aware of this bug thread - just came across it when scanning
the list of patch bugs that Glenn pointed to in emacs-devel today.

I only skimmed this thread, so ignore if my input is not relevant.

I have a library, with almost the same name, isearch-prop.el, which
lets you isearch zones of text having certain text or overlay
properties.

If useful and appropriate, you can add this code or similar to Emacs.
The code is here:
http://www.emacswiki.org/emacs-en/download/isearch-prop.el.

As I wrote in a mail to Juri a while back:

By default, the zones not being searched are dimmed a bit.
`C-M-~' toggles, to search the zones that do *not* have the
particular property values.  For example, with a command such as
`isearchp-imenu-command', which normally searches Emacs-Lisp
command definitions (after putting a property on them),
`C-M-~' makes it search all text other than command definitions.

bug#10387: CODE wishlist: search-prop.el

[Juri Linkov]

> I was not aware of this bug thread - just came across it when scanning
> the list of patch bugs that Glenn pointed to in emacs-devel today.
>
> I only skimmed this thread, so ignore if my input is not relevant.

I'm not sure whether this feature request was about low-level
search functions or more user-oriented isearch commands.
Both can be easily implemented by using `isearch-filter-predicate'.

But it seems the request has nothing to do with the text search
and asks for a better replacement of `next-property-change'.
Indeed, such functions could provide a similar interface
(function names and argument names) like in isearch functions
and maybe even reuse some code e.g. wrapping, direction, etc.

One idea is to define `isearch-search-fun-function' in such a way
that it will interpret its argument `string' as the name
of the property to search.  Then new isearch sub-mode
will allow searching by property names.

> By default, the zones not being searched are dimmed a bit.
> `C-M-~' toggles, to search the zones that do *not* have the
> particular property values.  For example, with a command such as
> `isearchp-imenu-command', which normally searches Emacs-Lisp
> command definitions (after putting a property on them),
> `C-M-~' makes it search all text other than command definitions.

`C-M-~' is a strange choice and it can't be typed on tty.
There is a special sub-map for filter commands on `M-s f'.

bug#10387: CODE wishlist: search-prop.el

[Drew Adams]

> > By default, the zones not being searched are dimmed a bit.
> > `C-M-~' toggles, to search the zones that do *not* have the
> > particular property values.  For example, with a command such as
> > `isearchp-imenu-command', which normally searches Emacs-Lisp
> > command definitions (after putting a property on them),
> > `C-M-~' makes it search all text other than command definitions.
> 
> `C-M-~' is a strange choice and it can't be typed on tty.

FWIW -

It can be typed on a tty, as `ESC-C-~'.  Admittedly, not as handy
as `C-M-~'.  But no worse than `M-s f ~' etc.

`~' is mnemonic for complementing/negation in some logic notations.

I use `C-M-~' because that is also the key I use for this in
Icicles search (from which this property-searching was taken).

In Icicles, `C-~' is used to complement the current set of
completion candidates, and `M-~' is used to toggle whether to
abbreviate your home directory using `~'.  And of course `~'
self-inserts.

> There is a special sub-map for filter commands on `M-s f'.

I have no objection, if you would like to put this on `M-s f ~',
for example.

bug#10387: CODE wishlist: search-prop.el

[Andreas Schwab]

Drew Adams <drew.adams@oracle.com> writes:

> It can be typed on a tty, as `ESC-C-~'.

C-~ is the same as C-^.

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

bug#10387: CODE wishlist: search-prop.el

[Drew Adams]

> > It can be typed on a tty, as `ESC-C-~'.
> 
> C-~ is the same as C-^.

Not for me it's not.

emacs -Q   ; or emacs -Q -nw

;; Visit a file foo.el.
;; C-h k for each.  Both keys are undefined.

M-x global-set-key C-~ forward-char

C-h w forward-char  ; It is not shown as being on C-^
C-h k C-^           ; It is undefined
C-h k C-~           ; It is bound to `forward-char'

bug#10387: CODE wishlist: search-prop.el

[Andreas Schwab]

Drew Adams <drew.adams@oracle.com> writes:

> M-x global-set-key C-~ forward-char

That binds C-^ in -nw.  C-~ isn't a character.

(characterp ?\C-~) => nil

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

bug#10387: CODE wishlist: search-prop.el

[Drew Adams]

> > M-x global-set-key C-~ forward-char
> 
> That binds C-^ in -nw.  C-~ isn't a character.
> (characterp ?\C-~) => nil

What's your point?

The claim (from Juri) was that `C-M-~' "cannot be typed on tty".

But it can be typed.  And it can be bound to a command.
And typing it invokes the command.  And Emacs recognizes it
as a binding of that command.  And Emacs does not recognize,
just because of that binding, that `C-M-^ is bound to that
command (or is bound at all).

What does this behavior, and the usefulness of this binding,
have to do with the fact that `C-~' or `C-M-~' is not a character?
Or with the fact that `C-^' is a character and `C-~' is not?

In `emacs -Q -nw', `C-down' is bound to `forward-paragraph'.
Yet (characterp [(control down)]) is nil.  So what?  Did those
who defined that default binding for Emacs out of the box make
a mistake?  Was that a no-no?

bug#10387: CODE wishlist: search-prop.el

[Eli Zaretskii]

> Date: Sun, 24 Nov 2013 08:51:26 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 10387@debbugs.gnu.org
> 
> > > M-x global-set-key C-~ forward-char
> > 
> > That binds C-^ in -nw.  C-~ isn't a character.
> > (characterp ?\C-~) => nil
> 
> What's your point?
> 
> The claim (from Juri) was that `C-M-~' "cannot be typed on tty".
> 
> But it can be typed.

No, it can't, not on a Unix text terminal.

> And it can be bound to a command.  And typing it invokes the
> command.  And Emacs recognizes it as a binding of that command.

I'm guessing that you tried this on MS-Windows, where C-M-~ and C-~
are indeed usable in a -nw session.  But not on a Unix TTY.  (The
MS-Windows build of Emacs uses Windows-specific method for reading the
keyboard that is very different from character input on a Posix TTY,
and which supports almost every key combination that the GUI session
does.)

> In `emacs -Q -nw', `C-down' is bound to `forward-paragraph'.
> Yet (characterp [(control down)]) is nil.  So what?  Did those
> who defined that default binding for Emacs out of the box make
> a mistake?  Was that a no-no?

I think Unix TTYs can only read those combinations that are
characters.  MS-Windows is different.

bug#10387: CODE wishlist: search-prop.el

[Stefan Monnier]

> I think Unix TTYs can only read those combinations that are
> characters.  MS-Windows is different.

Actually, POSIX ttys can transmit "any" key combo, including M-C-~, but
for those combos like C-~ which aren't part of ASCII, they need to use
some ad-hoc escape sequence.  By default xterm has no such ad-hoc
sequence for C-~, so it doesn't work.  You can add such an ad-hoc
sequence to xterm and then add the corresponding back-mapping in
lisp/xterm.el, after which C-~ should work just fine as well.


        Stefan

bug#10387: CODE wishlist: search-prop.el

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Actually, POSIX ttys can transmit "any" key combo,

Ttys transmit characters, period.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#10387: CODE wishlist: search-prop.el

[Andreas Schwab]

Drew Adams <drew.adams@oracle.com> writes:

> Yet (characterp [(control down)]) is nil.

Key sequences are never characters.

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

bug#10387: CODE wishlist: search-prop.el

[Stefan Monnier]

> emacs -Q   ; or emacs -Q -nw

The difference is important here.


        Stefan

bug#10387: CODE wishlist: search-prop.el

[Drew Adams]

> > emacs -Q   ; or emacs -Q -nw
> 
> The difference is important here.

What difference?  And what importance?

Use either one in the recipe.
Same effect wrt using `C-M-~', AFAICT.

`emacs -Q -nw' has the behavior I reported, as does
`emacs -Q'.  (At least on MS Windows.)

bug#10387: CODE wishlist: search-prop.el

[Eli Zaretskii]

> Date: Sun, 24 Nov 2013 08:54:06 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 10387@debbugs.gnu.org, Andreas Schwab <schwab@linux-m68k.org>
> 
> > > emacs -Q   ; or emacs -Q -nw
> > 
> > The difference is important here.
> 
> What difference?  And what importance?
> 
> Use either one in the recipe.
> Same effect wrt using `C-M-~', AFAICT.
> 
> `emacs -Q -nw' has the behavior I reported, as does
> `emacs -Q'.  (At least on MS Windows.)
                ^^^^^^^^^^^^^^^^^^^^^^

Actually, _only_ on MS-Windoes.  (Well, on MS-DOS as well, but who
cares?)

bug#10387: CODE wishlist: search-prop.el

[Drew Adams]

> > > > emacs -Q   ; or emacs -Q -nw
> > >
> > > The difference is important here.
> >
> > What difference?  And what importance?
> > Use either one in the recipe.
> > Same effect wrt using `C-M-~', AFAICT.
> > `emacs -Q -nw' has the behavior I reported, as does
> > `emacs -Q'.  (At least on MS Windows.)
>                 ^^^^^^^^^^^^^^^^^^^^^^
> Actually, _only_ on MS-Windoes.  (Well, on MS-DOS as well,
> but who cares?)

Got it.  Thx.  Perhaps I will change that default binding,
with that knowledge.

At any rate, I was explaining why I chose that key sequence.

Which key to use is not really the point of my post about
`isearch-prop.el'.  The toggle key to use is only a bike shed.
Paint it any color you like.