From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: Re: A better UI than perform-replace Date: Thu, 19 Nov 2015 14:11:40 -0500 Message-ID: References: <56480D6C.2080408@yandex.ru> <876112xj2i.fsf@gmail.com> <87vb90yum7.fsf@mail.linkov.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bacb8745ae57b0524e987da X-Trace: ger.gmane.org 1447960319 4707 80.91.229.3 (19 Nov 2015 19:11:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Nov 2015 19:11:59 +0000 (UTC) To: John Yates , Juri Linkov , Dmitry Gutov , Oleh Krehel , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 19 20:11:58 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZzUcf-0000tL-Ef for ged-emacs-devel@m.gmane.org; Thu, 19 Nov 2015 20:11:57 +0100 Original-Received: from localhost ([::1]:43665 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzUce-0004vL-Qf for ged-emacs-devel@m.gmane.org; Thu, 19 Nov 2015 14:11:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46545) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzUcQ-0004ty-ES for emacs-devel@gnu.org; Thu, 19 Nov 2015 14:11:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzUcP-0000Pz-Cq for emacs-devel@gnu.org; Thu, 19 Nov 2015 14:11:42 -0500 Original-Received: from mail-pa0-x22a.google.com ([2607:f8b0:400e:c03::22a]:33718) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzUcP-0000Pm-46 for emacs-devel@gnu.org; Thu, 19 Nov 2015 14:11:41 -0500 Original-Received: by pabfh17 with SMTP id fh17so92596014pab.0 for ; Thu, 19 Nov 2015 11:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=8w0os97qk6KXgPWU8PKfRl4kP/59AHP8G4NdV2gyp4s=; b=LyyXqAmE1gsL8LDxeoLDSK6VKVTm8hWToz6q64ByijpeDrk8NgALC2h/zUzuXYWqQG d/GKLTBj1hX/Omn+G86Ips7NZgqKKZ7d4UbmxHDXrbDUCYSp2iNwkK+srgan5Q6mKxHg pXgIcGGWL95SvvTmVHzrXkLzJeT4I6HnHZl1UrE/la03cwp7pT8DVqBWluTTZRpIob24 JDX79a9jl9idbMTqIvfN2CRYaZUPyLPxwN3ZHJgDjiuZ5p1t8orID8JPK28JUy+cEdYD o7CiTVp4r6/nuH5vwfUHCnbcA8+LGj9rlkrpAs5VDp19nTSZymhd2RPXZaLH0eopnKnG quYg== X-Received: by 10.66.153.139 with SMTP id vg11mr13094212pab.118.1447960300411; Thu, 19 Nov 2015 11:11:40 -0800 (PST) Original-Received: by 10.66.84.35 with HTTP; Thu, 19 Nov 2015 11:11:40 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: x8lI61WBGnHK0REnKw-q8z6cIFk X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::22a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194815 Archived-At: --047d7bacb8745ae57b0524e987da Content-Type: text/plain; charset=UTF-8 On Thu, Nov 19, 2015 at 11:31 AM, John Wiegley wrote: > Wanting to use Emacs for other editing, while in the middle of a replace > operation, is fairly expert also. We don't use a separate window with "Find > Next" and "Replace" buttons, as graphical editors do: we use a modal > prompt in > the mini-buffer. Most Emacs users expect this to mean that they must > complete > their operation before Emacs is fully available again. > Disclaimer: my model for the proposed interaction is query-replace. If we are actually contemplating something quite different then perhaps my comments are irrelevant. That said... The usage scenario is not uncommon and is not an instance of wanting to perform arbitrary editing in the middle of a replace operation. Rather it is a question of wanting (or needing) to clean-up alignment _after_ replacing a token with a token of a different length. A very common instance is ensuring that end of line comments start at a specified column. IIUC when prompted as to whether I wish to replace the current token the recursive edit approach requires that I: 1) type C-r to enter a recursive edit 2) adjust whitespace (thereby corrupting the visible alignment around the as yet un-replaced token) hoping that I properly anticipate the whitespace needs that will obtain once the replace actually occurs 3) type C-M-c to exit recursive edit 4) respond to the query-replace prompt Following 4) token replacement occurs and the display updates to the next match. I get no visual feedback as to whether my attempt to adjust alignment was actually correct. This is the antithesis of a satisfactory WYSIWYG experience. I might as well be editing in TECO (which _I_ actually did at the beginning of my career :-) If I am working in an environment that bans hard tabs I just may get it right. Allow hard tabs and I doubt that there is a person on this list who would defend the experience. /john --047d7bacb8745ae57b0524e987da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 19, 2015 at 11:31 AM, John Wiegley <jwiegley@gmail.com> wrote:
Wanting to use Emacs for other editing, whi= le in the middle of a replace
operation, is fairly expert also. We don't use a separate window with &= quot;Find
Next" and "Replace" buttons, as graphical editors do: we use= a modal prompt in
the mini-buffer. Most Emacs users expect this to mean that they must comple= te
their operation before Emacs is fully available again.

Disclaimer: my model for the proposed interaction is query-replace.
If we are actually contemplating something quite different then=
perhaps my comments are irrelevant.=C2=A0 That said...

The usage= scenario is not uncommon and is not an instance of wanting
to perform a= rbitrary editing in the middle of a replace operation.
Rather it is a qu= estion of wanting (or needing) to clean-up alignment
_after_ replacing a= token with a token of a different length.=C2=A0 A very
common instance = is ensuring that end of line comments start at a
specified column.
IIUC when prompted as to whether I wish to replace the current token
the recursive edit approach requires that I:

=C2=A0 1) type C-= r to enter a recursive edit
=C2=A0 2) adjust whitespace (thereby = corrupting the visible alignment
=C2=A0 =C2=A0 =C2=A0around the as yet u= n-replaced token) hoping that I properly
=C2=A0 =C2=A0 =C2=A0anticipate = the whitespace needs that will obtain once the
=C2=A0 =C2=A0 =C2=A0repla= ce actually occurs
=C2=A0 3) type C-M-c to exit recursive edit
=C2=A0= 4) respond to the query-replace prompt

Following 4) token replaceme= nt occurs and the display updates to
the next match.=C2=A0 I get no visu= al feedback as to whether my attempt
to adjust alignment was actually co= rrect.=C2=A0 This is the antithesis
of a satisfactory WYSIWYG experience= .=C2=A0 I might as well be editing
in TECO (which _I_ actually did at th= e beginning of my career :-)

If I am working in an environment that = bans hard tabs I just may
get it right.=C2=A0 Allow hard tabs and I doub= t that there is a person
on this list who would defend the experience.

/john
--047d7bacb8745ae57b0524e987da--