unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#24721: 25.1; Reverse the order of `isearch-message-prefix' prefixes from function advice property
@ 2016-10-17 22:16 Drew Adams
  2016-10-18 20:23 ` Juri Linkov
  2019-11-11  3:33 ` Stefan Kangas
  0 siblings, 2 replies; 7+ messages in thread
From: Drew Adams @ 2016-10-17 22:16 UTC (permalink / raw)
  To: 24721

When there is multiple advice (from `add-function') of
`isearch-filter-predicate' that has property `isearch-message-prefix',
these prefixes are currently shown left to right in the Isearch prompt,
with the first added being on the left and the last added being on the
right.

I think this is backwards from what a user expects.  I've reversed the
order in my own copy, and I think it is more helpful: The first one you
see is the latest applied.  Entries are added and removed on the left,
not the right.  The most important such prefix is typically the last
one applied, and having it on the left makes it more noticeable (IMO).

If you agree, all that's required is changing, in the
`isearch-message-prefix' code, (concat np prefix) to (concat prefix np).


In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-09-17
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --without-dbus --without-compress-install CFLAGS=-static'





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

* bug#24721: 25.1; Reverse the order of `isearch-message-prefix' prefixes from function advice property
  2016-10-17 22:16 bug#24721: 25.1; Reverse the order of `isearch-message-prefix' prefixes from function advice property Drew Adams
@ 2016-10-18 20:23 ` Juri Linkov
  2016-10-18 20:49   ` Drew Adams
  2019-11-11  3:33 ` Stefan Kangas
  1 sibling, 1 reply; 7+ messages in thread
From: Juri Linkov @ 2016-10-18 20:23 UTC (permalink / raw)
  To: Drew Adams; +Cc: 24721

> When there is multiple advice (from `add-function') of
> `isearch-filter-predicate' that has property `isearch-message-prefix',
> these prefixes are currently shown left to right in the Isearch prompt,
> with the first added being on the left and the last added being on the
> right.
>
> I think this is backwards from what a user expects.  I've reversed the
> order in my own copy, and I think it is more helpful: The first one you
> see is the latest applied.  Entries are added and removed on the left,
> not the right.  The most important such prefix is typically the last
> one applied, and having it on the left makes it more noticeable (IMO).

"Adjectives in English absolutely have to be in this order:
opinion-size-age-shape-colour-origin-material-purpose Noun.
So you can have a lovely little old rectangular green French
silver whittling knife." - an excerpt from a book called
"The Elements of Eloquence" by Mark Forsyth.
http://languagelog.ldc.upenn.edu/nll/?p=27890

Does a similar natural order exist for Isearch, so prefixes
absolutely have to be in the order "overwrapped regexp I-search",
but not "regexp overwrapped I-search"?





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

* bug#24721: 25.1; Reverse the order of `isearch-message-prefix' prefixes from function advice property
  2016-10-18 20:23 ` Juri Linkov
@ 2016-10-18 20:49   ` Drew Adams
  2016-10-18 23:01     ` Clément Pit--Claudel
  0 siblings, 1 reply; 7+ messages in thread
From: Drew Adams @ 2016-10-18 20:49 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 24721

> > When there is multiple advice (from `add-function') of
> > `isearch-filter-predicate' that has property `isearch-message-prefix',
> > these prefixes are currently shown left to right in the Isearch prompt,
> > with the first added being on the left and the last added being on the
> > right.
> >
> > I think this is backwards from what a user expects.  I've reversed the
> > order in my own copy, and I think it is more helpful: The first one you
> > see is the latest applied.  Entries are added and removed on the left,
> > not the right.  The most important such prefix is typically the last
> > one applied, and having it on the left makes it more noticeable (IMO).
> 
> "Adjectives in English absolutely have to be in this order:
> opinion-size-age-shape-colour-origin-material-purpose Noun.
> So you can have a lovely little old rectangular green French
> silver whittling knife." - an excerpt from a book called
> "The Elements of Eloquence" by Mark Forsyth.
> http://languagelog.ldc.upenn.edu/nll/?p=27890

We can discuss whether that is nonsense. ;-)
But it is anyway 100% irrelevant here.

> Does a similar natural order exist for Isearch, so prefixes
> absolutely have to be in the order "overwrapped regexp I-search",
> but not "regexp overwrapped I-search"?

Not IMHO.

And the only order that makes sense for multiple predicate filters
is the order of application.

People can disagree, however, about how the sequence of filter
applications should be shown: left-to-right or right-to-left.

Mine is just one opinion.





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

* bug#24721: 25.1; Reverse the order of `isearch-message-prefix' prefixes from function advice property
  2016-10-18 20:49   ` Drew Adams
@ 2016-10-18 23:01     ` Clément Pit--Claudel
  2016-10-18 23:50       ` Drew Adams
  0 siblings, 1 reply; 7+ messages in thread
From: Clément Pit--Claudel @ 2016-10-18 23:01 UTC (permalink / raw)
  To: 24721


[-- Attachment #1.1: Type: text/plain, Size: 404 bytes --]

On 2016-10-18 16:49, Drew Adams wrote:
> People can disagree, however, about how the sequence of filter
> applications should be shown: left-to-right or right-to-left.

I'd love to have always-visible icons that light up when a feature is activated, just like for read-only status in the mode line.  These icons could be to the right of the search bar, too.  Their order would always be the same.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

* bug#24721: 25.1; Reverse the order of `isearch-message-prefix' prefixes from function advice property
  2016-10-18 23:01     ` Clément Pit--Claudel
@ 2016-10-18 23:50       ` Drew Adams
  0 siblings, 0 replies; 7+ messages in thread
From: Drew Adams @ 2016-10-18 23:50 UTC (permalink / raw)
  To: Clément Pit--Claudel, 24721

> > People can disagree, however, about how the sequence of filter
> > applications should be shown: left-to-right or right-to-left.
> 
> I'd love to have always-visible icons that light up when a feature is
> activated, just like for read-only status in the mode line.  These icons
> could be to the right of the search bar, too.  Their order would always be
> the same.

Interesting suggestion, but different from the subject here.

Your suggestion would probably be more applicable to a fixed set of
icons (representing a fixed set of thingies).





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

* bug#24721: 25.1; Reverse the order of `isearch-message-prefix' prefixes from function advice property
  2016-10-17 22:16 bug#24721: 25.1; Reverse the order of `isearch-message-prefix' prefixes from function advice property Drew Adams
  2016-10-18 20:23 ` Juri Linkov
@ 2019-11-11  3:33 ` Stefan Kangas
  2020-08-20 16:36   ` Lars Ingebrigtsen
  1 sibling, 1 reply; 7+ messages in thread
From: Stefan Kangas @ 2019-11-11  3:33 UTC (permalink / raw)
  To: Drew Adams; +Cc: 24721

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

> When there is multiple advice (from `add-function') of
> `isearch-filter-predicate' that has property `isearch-message-prefix',
> these prefixes are currently shown left to right in the Isearch prompt,
> with the first added being on the left and the last added being on the
> right.
>
> I think this is backwards from what a user expects.  I've reversed the
> order in my own copy, and I think it is more helpful: The first one you
> see is the latest applied.  Entries are added and removed on the left,
> not the right.  The most important such prefix is typically the last
> one applied, and having it on the left makes it more noticeable (IMO).
>
> If you agree, all that's required is changing, in the
> `isearch-message-prefix' code, (concat np prefix) to (concat prefix np).

I think I agree with the reasoning here, and although the issue is
minor, the change also seems easy enough.

My only concern would be that users would find the change confusing or
bothersome, since they are already too used to the current behaviour.
Perhaps the trade-off is worth it.

Does anyone else have an opinion here?

Best regards,
Stefan Kangas





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

* bug#24721: 25.1; Reverse the order of `isearch-message-prefix' prefixes from function advice property
  2019-11-11  3:33 ` Stefan Kangas
@ 2020-08-20 16:36   ` Lars Ingebrigtsen
  0 siblings, 0 replies; 7+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-20 16:36 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 24721

Stefan Kangas <stefan@marxist.se> writes:

> My only concern would be that users would find the change confusing or
> bothersome, since they are already too used to the current behaviour.
> Perhaps the trade-off is worth it.
>
> Does anyone else have an opinion here?

I agree with your concern here -- it sounds like it would be an annoying
change for those that are used to the old behaviour.  So I'm closing
this bug report.

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





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

end of thread, other threads:[~2020-08-20 16:36 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-17 22:16 bug#24721: 25.1; Reverse the order of `isearch-message-prefix' prefixes from function advice property Drew Adams
2016-10-18 20:23 ` Juri Linkov
2016-10-18 20:49   ` Drew Adams
2016-10-18 23:01     ` Clément Pit--Claudel
2016-10-18 23:50       ` Drew Adams
2019-11-11  3:33 ` Stefan Kangas
2020-08-20 16:36   ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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