From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ken Manheimer" Newsgroups: gmane.emacs.devel Subject: Re: need option so line-move-to-column ignores fields, plus patch Date: Sat, 23 Sep 2006 19:29:49 -0400 Message-ID: <2cd46e7f0609231629hf2187cbl7e46507ee6070422@mail.gmail.com> References: <2cd46e7f0608310848l743430e9ia7a1d45e22428083@mail.gmail.com> <2cd46e7f0608312339s16a2a101p8c30840bbdeb0d22@mail.gmail.com> <2cd46e7f0609032143v311b670dra2d2ef679dd936@mail.gmail.com> <2cd46e7f0609041256q73c0c0d3s7631a964ae9a8367@mail.gmail.com> <2cd46e7f0609060952m54601787x8c91412af7fbf69f@mail.gmail.com> <2cd46e7f0609070747o5028d2bewd5a9e79a5afd4a46@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_10593_29970135.1159054189811" X-Trace: sea.gmane.org 1159054219 15385 80.91.229.2 (23 Sep 2006 23:30:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 23 Sep 2006 23:30:19 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 24 01:30:14 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GRGwg-0003GQ-Pi for ged-emacs-devel@m.gmane.org; Sun, 24 Sep 2006 01:30:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GRGwg-00025l-1Y for ged-emacs-devel@m.gmane.org; Sat, 23 Sep 2006 19:30:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GRGwS-00024d-RG for emacs-devel@gnu.org; Sat, 23 Sep 2006 19:29:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GRGwR-00023n-Nz for emacs-devel@gnu.org; Sat, 23 Sep 2006 19:29:52 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GRGwR-00023h-GB for emacs-devel@gnu.org; Sat, 23 Sep 2006 19:29:51 -0400 Original-Received: from [66.249.82.231] (helo=wx-out-0506.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GRH0V-0004VU-3O for emacs-devel@gnu.org; Sat, 23 Sep 2006 19:34:03 -0400 Original-Received: by wx-out-0506.google.com with SMTP id i26so1599561wxd for ; Sat, 23 Sep 2006 16:29:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=jrBWWbk7q8K8CcRelIfewk+X/3u2sN7Q7UJs6ClFt5HxNNclokPHAQuBCHjUWcP3bXDfWUhN8Ti4wwTGWuunNkjSWIoHcjro0UwAoE03ujqjFbK1fLk8uW/W2feSiQ9p6LgDoS8pmL17ij1d9TYSq+/oCuHe/17D4qK3grh58B0= Original-Received: by 10.90.118.12 with SMTP id q12mr1064178agc; Sat, 23 Sep 2006 16:29:49 -0700 (PDT) Original-Received: by 10.90.105.4 with HTTP; Sat, 23 Sep 2006 16:29:49 -0700 (PDT) Original-To: rms@gnu.org In-Reply-To: <2cd46e7f0609070747o5028d2bewd5a9e79a5afd4a46@mail.gmail.com> X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:60151 Archived-At: ------=_Part_10593_29970135.1159054189811 Content-Type: multipart/alternative; boundary="----=_Part_10594_22485154.1159054189811" ------=_Part_10594_22485154.1159054189811 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline i'm still having serious problems with the behavior of line motion vis a vis field boundaries, as of today's CVS. i've created a script that demonstrates the behavior problems and describes as clearly as i can the behaviors i would like. it may be that those behaviors are not generally suitable, in which case the line-move-ignore-fields variable i was initially proposing would be a workable (but a lot less desirable) compromise. i don't think the behaviors i'm seeking are suited uniquely to my outliner situation, but i'm not sure about that one way or the other. i'm hoping that this explicit example will provide a clear template which would help to verify the solution. ken On 9/7/06, Ken Manheimer wrote: > > On 9/7/06, Richard Stallman wrote: > > i would still be worried that the cursor will annoyingly get pushed > > rightwards when moving across content lines, due to traversing > > headlines of deep topics, where the structure portion of the line > > extends further to the right. > > > > That could certainly happen, but why would it be annoying? > > The cursor would come back towards the original column as you move > > onward into lines whose structure portion is shorter. > > that would be good - it's actually the behavior i was hoping but > wasn't expecting would be the case. that would satisfy me. > > > This is like what happens when you start at a high-numbered column > > and move through lines that are too short to reach that column. > > > > this would be mitigated by preserving > > and restoring the displaced leftwards placements, > > > > I don't understand those words. > > i was trying to describe the cursor coming back to the high-numbered > column, exactly as you mentioned above. > > > but the behavior > i'm > > concerned with doesn't obtain for the cases you're considering, so i > > doubt it would be provided for. > > > > Which cases do you mean by "the cases [I'm] considering"? > > I am considering the allout cases you describe. > > the high-column. > > > (i kinda doubt that my description of > > the concern is readily understandable, sigh). > > which it wasn't - sorry. :-) > > > If the "description of the concern" refers to the words I cited > > at the top of this message, I think I understand the behavior, > > but I don't understand why you see it as a problem. > > > > the option simplifies this concern. > > > > That's not enough to make the option _necessary_. > > Remember I want to avoid options when possible. > > If we can get good enough behavior without one, > > then the option isn't needed. > > i think what you're proposing will work for allout mode. > -- > ken > ken.manheimer@gmail.com > http://myriadicity.net > -- ken ken.manheimer@gmail.com http://myriadicity.net ------=_Part_10594_22485154.1159054189811 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline i'm still having serious problems with the behavior of line motion vis a vis field boundaries, as of today's CVS.  i've created a script that demonstrates the behavior problems and describes as clearly as i can the behaviors i would like.

it may be that those behaviors are not generally suitable, in which case the line-move-ignore-fields variable i was initially proposing would be a workable (but a lot less desirable) compromise.

i don't think the behaviors i'm seeking are suited uniquely to my outliner situation, but i'm not sure about that one way or the other.  i'm hoping that this explicit example will provide a clear template which would help to verify the solution.

ken

On 9/7/06, Ken Manheimer <ken.manheimer@gmail.com> wrote:
On 9/7/06, Richard Stallman <rms@gnu.org> wrote:
>     i would still be worried that the cursor will annoyingly get pushed
>     rightwards when moving across content lines, due to traversing
>     headlines of deep topics, where the structure portion of the line
>     extends further to the right.
>
> That could certainly happen, but why would it be annoying?
> The cursor would come back towards the original column as you move
> onward into lines whose structure portion is shorter.

that would be good - it's actually the behavior i was hoping but
wasn't expecting would be the case.  that would satisfy me.

> This is like what happens when you start at a high-numbered column
> and move through lines that are too short to reach that column.
>
>       this would be mitigated by preserving
>     and restoring the displaced leftwards placements,
>
> I don't understand those words.

i was trying to describe the cursor coming back to the high-numbered
column, exactly as you mentioned above.

>                                                       but the behavior i'm
>     concerned with doesn't obtain for the cases you're considering, so i
>     doubt it would be provided for.
>
> Which cases do you mean by "the cases [I'm] considering"?
> I am considering the allout cases you describe.

the high-column.

>       (i kinda doubt that my description of
>     the concern is readily understandable, sigh).

which it wasn't - sorry.  :-)

> If the "description of the concern" refers to the words I cited
> at the top of this message, I think I understand the behavior,
> but I don't understand why you see it as a problem.
>
>     the option simplifies this concern.
>
> That's not enough to make the option _necessary_.
> Remember I want to avoid options when possible.
> If we can get good enough behavior without one,
> then the option isn't needed.

i think what you're proposing will work for allout mode.
--
ken
ken.manheimer@gmail.com
http://myriadicity.net



--
ken
ken.manheimer@gmail.com
http://myriadicity.net ------=_Part_10594_22485154.1159054189811-- ------=_Part_10593_29970135.1159054189811 Content-Type: application/octet-stream; name=linefield-example.el Content-Transfer-Encoding: base64 X-Attachment-Id: f_esgmoghk Content-Disposition: attachment; filename="linefield-example.el" OzsgRXZhbCBvciBsb2FkIHRoaXMgc2NyaXB0IGFuZCBleGVjdXRlIHRoZSBgbGluZWZpZWxkLWV4 YW1wbGUnIGNvbW1hbmQKOzsgZm9yIGRlbW9uc3RyYXRpb24gb2YgdGhlIGZpZWxkIGJvdW5kYXJ5 IG1pc2JlaGF2aW9ycyBpbiBhbiBlbWFjcyAyMiBjdnMKOzsgY2hlY2tvdXQgYXMgb2YgbWlkLWRh eSwgU2VwdGVtYmVyIDIzLCAyMDA2LCBhbmQgZGVzY3JpcHRpb24gb2YgdGhlCjs7IGJlaGF2aW9y cyBpIHdvdWxkIGxpa2UgdG8gc2VlLgoKOzsga2VuCjs7IGtlbi5tYW5oZWltZXJAZ21haWwuY29t Cjs7IGh0dHA6Ly9teXJpYWRpY2l0eS5uZXQKCihkZWZ2YXIgbGluZWZpZWxkLXRleHQKICAiVGhl IGxpbmVzIHdpdGggYSAnfCcgYmFyIGFzIHRoZWlyIGZpcnN0IG5vbi13aGl0ZXNwYWNlCmNoYXJh Y3RlciBhcmUgZGVjb3JhdGVkIHdpdGggJ2ZpZWxkICdib3VuZGFyeSBhbmQgJ2ZhY2UKJ2hpZ2hs aWdodCB0ZXh0IHByb3BlcnRpZXMgZnJvbSB0aGUgbGVmdCBtYXJnaW4gdW50aWwgYW5kCmluY2x1 ZGluZyB0aGUgYmFyLgoKIHwgICAKICB8IDEuIFdpdGggdGhlIGN1cnNvciBhZGphY2VudCB0byB0 aGUgcmlnaHQgb2YgYW55IGJhciwKICAgfCAgIGlmIHlvdSBtb3ZlIGZvcndhcmRzIGEgbGluZSAo Xk4pLCB0aGUgY3Vyc29yIHNsaXBzIHRvIGNvbHVtbiAwLgogICAgfCAyLiBNb3ZpbmcgYmFja3dh cmRzICheUCkgd2l0aCB0aGUgY3Vyc29yIGluIHRoZSBzYW1lIHBsYWNlLCBob3dldmVyLAogICAg IHwgICBkb2Vzbid0IGhhdmUgdGhpcyBwcm9ibGVtIC0gaXQgc3RpY2tzIG5lYXIgdGhlIGJvdW5k YXJ5LgogICAgfCAzLiBNb3ZpbmcgZm9yd2FyZHMgb3IgYmFja3dhcmRzIHdpdGggdGhlIGN1cnNv ciB0byB0aGUgcmlnaHQgb2YgdGhlCiAgIHwgICAgIGJvdW5kYXJ5ICpub3QqIGFkamFjZW50IGRv ZXMgcmVndWxhciBzdGlja3ktY29sdW1uIGJlaGF2aW9yLgogIHwgNC4gRm9yd2FyZHMgd2l0aCB0 aGUgY3Vyc29yIG9uIG9yIHRvIHRoZSBiYXIncyBsZWZ0IGxlYXZlcyBpdCBpbiBjb2x1bW4gMC4K IHwgNS4gQmFja3dhcmRzIGluIHRoZSBzYW1lIHNpdHVhdGlvbiBtb3ZlcyBpdCB0byB0aGUgcmln aHQgb2YgdGhlIGJhci4KNi4gXkEgZnJvbSBhbnl3aGVyZSBiZXlvbmQgdGhlIGltbWVkaWF0ZSBy aWdodCBvZiB0aGUgYm91bmRhcnkgbW92ZXMgdG8KICAgdGhlIGltbWVkaWF0ZSByaWdodCwgYW5k IHN1YnNlcXVlbnRseSBhZHZhbmNlcyB0byB0aGUgZmFyIGxlZnQuCgojMiwgIzMsIGFuZCAjNiBh cmUgbmVhciB3aGF0IGkgd2FudC4gIHRoZSByZXN0IGFyZSBub3QuCgojMiBpcyBhY3R1YWxseSBp bmNvbnNpc3RlbnQgLSBzb21ldGltZXMgdGhlIGN1cnNvciBpcyBrZXB0CmFkamFjZW50IHRvIHRo ZSBib3VuZGFyeSwgc29tZXRpbWVzIChpZiByaWdodC1oYW5kIHBhcnQgaXMgb25seQp3aGl0ZXNw YWNlLCBsaWtlIHRoZSB2ZXJ5IGZpcnN0IGRlY29yYXRlZCBsaW5lLCBhbmQgdGhlbiBpdApkZXBl bmRzIG9uIGhvdyB5b3Ugc3RhcnRlZCEpIHRoZXJlJ3MgYSBjb2x1bW4gbGVmdCBpbiBiZXR3ZWVu Lgp0aGUgaW5jb25zaXN0ZW5jaWVzIGhlcmUgbWFrZSBtZSB3b3JyaWVkIHRoYXQgdGhlIGJlaGF2 aW9ycyBhcmUKbm90IGNvbnZlcmdpbmcgdG8gc29tZXRoaW5nIHJlZ3VsYXIuCgojMSBzaG91bGQg d29yayBsaWtlICMyLCBpbnN0ZWFkIG9mIHNsaXBwaW5nIHRvIGNvbHVtbiAwLiAgaSBkb3VidAp3 aGF0J3MgaGFwcGVuaW5nIG5vdyBpcyB0aGUgaW50ZW5kZWQgYmVoYXZpb3IuCgojNSB0cmVhdHMg c3R1ZmYgdG8gdGhlIGxlZnQgb2YgdGhlIGJvdW5kYXJ5IGFzIGZvcmJpZGRlbiwgYWx3YXlzCnBy b21vdGluZyB0aGUgY3Vyc29yIHRvIHRoZSByaWdodCwgd2hpY2ggaXMgbm90IHdoYXQgaSB3YW50 LgppbnN0ZWFkLCBtb3Rpb24gdG8gdGhlIGxlZnQgb2YgdGhlIGJvdW5kYXJ5IGxpbmUgc2hvdWxk IGJlIHRoZQptaXJyb3IgaW1hZ2Ugb2YgIzIgYW5kICMzIGJlaGF2aW9ycywgb24gdGhlIGxlZnQg aW5zdGVhZCBvZiB0aGUKcmlnaHQuCgojNCBpcyBicm9rZW4gbGlrZSAjMS4KCml0IG1heSBiZSB0 aGF0IHRoZXJlJ3MgYSBkaWZmZXJlbnQgd2F5IHRvIHBhaW50IHRoZSBwcm9wZXJ0aWVzCnRoYXQg Z2V0cyB0aGUgYmVoYXZpb3JzIGkgd2FudCAtIGJ1dCAjNiBpcyBpbXBvcnRhbnQsIGl0J3MgdGhl CnJlYXNvbiBpJ20gbXVja2luZyB3aXRoIHRoZSBmaWVsZCBzdHVmZiBpbiB0aGUgZmlyc3QgcGxh Y2UuICB0aGUKYmVoYXZpb3IgaW4gIzIgd291bGQgYmUgZ29vZCwgaWYgaXQgd2VyZSBjb25zaXN0 ZW50bHkgdGhlcmUsCmZvcndhcmQgYW5kIGJhY2t3YXJkcywgYW5kIHN5bW1ldHJpYyBhY3Jvc3Mg dGhlIGJvdW5kYXJ5LgoiCgogICJUZXh0IGZvciBkZW1vbnN0cmF0aW5nIGxpbmVmaWVsZCBzdGFp cmNhc2UuIikKCihkZWZ1biBsaW5lZmllbGQtZXhhbXBsZSAoKQogICJEZW1vbnN0cmF0ZSBmaWVs ZHRleHQgYm91bmRhcnkgbWlzYmVoYXZpb3IuIgogIChpbnRlcmFjdGl2ZSkKICAobGV0KiAoKGJ1 ZmZlciAoZ2V0LWJ1ZmZlci1jcmVhdGUgImZpZWxkdGV4dC1leGFtcGxlIikpCiAgICAgICAgIGZp cnN0IHNlY29uZCkKICAgIChwb3AtdG8tYnVmZmVyIGJ1ZmZlcikKICAgIChlcmFzZS1idWZmZXIp CiAgICAoaW5zZXJ0IGxpbmVmaWVsZC10ZXh0KQogICAgKGdvdG8tY2hhciAocG9pbnQtbWluKSkK ICAgICh3aGlsZSAocmUtc2VhcmNoLWZvcndhcmQgIl4gK3wiIG5pbCB0KQogICAgICAoY29uZCAo KG5vdCBmaXJzdCkgKHNldHEgZmlyc3QgKHBvaW50KSkpCiAgICAgICAgICAgICgobm90IHNlY29u ZCkgKHNldHEgc2Vjb25kIChwb2ludCkpKSkKICAgICAgKHNldC10ZXh0LXByb3BlcnRpZXMgKG1h dGNoLWJlZ2lubmluZyAwKSAocG9pbnQpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICcoZmll bGQgYm91bmRhcnkgZmFjZSBoaWdobGlnaHQpKSkKICAgIChnb3RvLWNoYXIgc2Vjb25kKSkpCg== ------=_Part_10593_29970135.1159054189811 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ------=_Part_10593_29970135.1159054189811--