all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tomas Nordin <tomasn@posteo.net>
To: Jean-Christophe Helary <jean.christophe.helary@gmail.com>,
	Help Gnu Emacs mailing list <help-gnu-emacs@gnu.org>
Subject: Re: killing the result of isearch
Date: Thu, 09 Nov 2017 22:38:01 +0100	[thread overview]
Message-ID: <87h8u32kw6.fsf@fliptop> (raw)
In-Reply-To: <4EA90B44-DF92-43C3-B8D0-6C42D1D6F1DA@gmail.com>

Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:

>> On Nov 9, 2017, at 7:24, Tomas Nordin <tomasn@posteo.net> wrote:
>> 
>> Jean-Christophe Helary <jean.christophe.helary@gmail.com> writes:
>> 
>>> No, I am actually talking about expectations from using emacs where regions are highlighted, like what isearch seems like doing. What I am seeing is what looks like a region (and except for the active match, all the others are highlighted exactly as a region would be), but it doesn't act like a region. So there is a UI promise that's broken.
>> 
>> Does this imply that in a read-only buffer, there must be no highlighting of the match for you not to say the UI is broken?
>
> Read my text again, and read your question one more time. You probably have the answer you need by now.
>
>> You cannot act on the text there.
>
> I can certainly M-w on any region I like. A region is a region, regardless of the buffer state, afaiu.

Ok, in a couple of posts it looked like the lack of possibility to just
delete the thing highlighted was the main distraction. I also got the
impression it is the subject of the thread.

>
>> Or, in a read-only buffer, is it good that the match(es) are highlighted? Why?
>
> I may be thick, but it does look like you're trying to make me look like a fool, when it is you who do not seem to properly understand the issue I'm talking about.

I don't want to upset anyone, and I didn't have that intention. My
wording was maybe unnecessarily short.

I was trying to suggest that a highlight might have other meanings than
that it will be altered by next insertion or deletion.

Anyway, I think I was reacting on the UI promise wording. I don't know
there is such promise. There are expectations of course, based on
peoples habits and prior experience. I agree that in most other
applications, a highlighted region will get replaced by the next
character you insert, or deleted if that is the action.

When I started out with Emacs, I already knew that almost everything is
different from what I was used to. So, for example, visit a file is not
done by "ctrl-O" or a search is not started with "ctrl-f". Things like
that. So many things are different so I never even reflected over that
the region is not replaced just by hitting a character.

About the incremental search thing. I agree that it *could* be useful
maybe to add an in-search command like

      Type C-l to toggle isearch-lock-string.
       The current search string is frozen and next self-insert-command
       or DEL will operate in the current buffer. C-l again from this
       state will revert to normal isearch. In this mode you can hit C-s
       again to get at the next mach.

But then again, I don't know it would save so many key-strokes. If I want
to search and delete, I find it rather fast anyway to just hit C-s again
two times to get to the next match.

I was curious on the expectations based on other editors, so I tried
this at work with notepad++. The first thing tried was a ctrl-f for the
search. That brings up a dialog for the search and it was not possible
to just delete the thing found. I checked a little and it turned out
that pressing <f3> (after a search and dialog closed) would "select"
next match (the first was already consumed by the dialog search) and
move point to the end of it. And then, yes, possible to act directly on
that selection, like delete for example.

However, this required that one first do a regular search (ctrl-f),
escape that dialog and then start to press <f3>.

Its one of the many things that is different in Emacs to other editors
but then I think that other editors differ to each-other as well, and
each promise their own things. But I don't agree that Emacs is braking a
UI promise. But for sure it will have a different method for doing
things compared to some other editor.

I think one exciting thing with Emacs has been the practice that you
never have to use the mouse for anything (if you don't want to). I could
guess that many commands are not even possible to do via the mouse. Then
one could maybe claim that since Emacs often is used a a GUI, its
braking a promise because the mouse cannot be used for this or that
command. But then I wouldn't agree.

As you say, editing in Emacs is done by the lisp interpreter, so almost
any wish for a behavior can be satisfied by some snippets of code, often
provided by the very kind and helpful Emacs help list. Or, if enough
developers agree on a new feature it will even be added into stock
Emacs. To that note by the way, I evaled the code snippets posted by
Stefan and said `M-x delete-selection-mode`, and after that I got a
behavior exactly as I understand you are looking for. Just don't forget
to hit RET before acting on that region. That post also give some
reasons for the current behavior. I am reading my mail in Emacs so that
behavior slided smoothly into my Emacs just as if it would have been a
feature available through an item in a menu.

--
Tomas



  parent reply	other threads:[~2017-11-09 21:38 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-07  2:41 killing the result of isearch Jean-Christophe Helary
2017-11-07  5:34 ` Drew Adams
2017-11-07  6:01   ` Jean-Christophe Helary
2017-11-07  6:25     ` Søren Pilgård
     [not found]     ` <mailman.3103.1510035932.27995.help-gnu-emacs@gnu.org>
2017-11-07  7:07       ` Loris Bennett
2017-11-07  7:49         ` Jean-Christophe Helary
2017-11-07  8:43         ` Jean-Christophe Helary
     [not found]         ` <mailman.3106.1510044223.27995.help-gnu-emacs@gnu.org>
2017-11-07 10:49           ` Loris Bennett
2017-11-07 12:45             ` Jean-Christophe Helary
2017-11-07 15:26               ` Drew Adams
2017-11-07 15:51                 ` Jean-Christophe Helary
2017-11-07 16:46                   ` Drew Adams
2017-11-07 22:38                     ` Jean-Christophe Helary
2017-11-07 16:53                   ` Eric Abrahamsen
2017-11-07 17:24                     ` Drew Adams
2017-11-07 17:45                       ` Eric Abrahamsen
2017-11-08  8:21               ` Thien-Thi Nguyen
2017-11-08 13:47                 ` Emanuel Berg
2017-11-11 15:36                   ` Charles A. Roelli
     [not found]             ` <mailman.3114.1510058721.27995.help-gnu-emacs@gnu.org>
2017-11-07 15:08               ` Loris Bennett
2017-11-07 15:28                 ` Jean-Christophe Helary
2017-11-07 16:24                   ` Drew Adams
2017-11-07 22:34                     ` Jean-Christophe Helary
2017-11-07 22:54                       ` Drew Adams
2017-11-08 22:24                   ` Tomas Nordin
2017-11-08 22:44                     ` Jean-Christophe Helary
2017-11-08 23:07                       ` Emanuel Berg
2017-11-09 21:38                       ` Tomas Nordin [this message]
2017-11-10 13:11                         ` Jean-Christophe Helary
2017-11-10 16:54                           ` Drew Adams
2017-11-07  8:31     ` Marcin Borkowski
2017-11-07 15:26     ` Drew Adams
2017-11-07 20:59     ` Bob Proulx
2017-11-07 22:10       ` Drew Adams
2017-11-07 22:53         ` Bob Proulx
2017-11-07 23:15       ` Jean-Christophe Helary
2017-11-08  4:27         ` Bob Proulx
2017-11-08  5:29           ` Jean-Christophe Helary
2017-11-08 18:50             ` Bob Proulx
2017-11-07 17:53 ` Stefan Monnier
2017-11-07 22:59   ` Jean-Christophe Helary
2017-11-12 20:02     ` Tomas Nordin
2017-11-12 22:13       ` Emanuel Berg
2017-11-13 21:17         ` Tomas Nordin
2017-11-13 22:13           ` Emanuel Berg
2017-11-20  3:24           ` Emanuel Berg
2017-11-15 14:48       ` Emanuel Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h8u32kw6.fsf@fliptop \
    --to=tomasn@posteo.net \
    --cc=help-gnu-emacs@gnu.org \
    --cc=jean.christophe.helary@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.