unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dani Moncayo <dmoncayo@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 17346@debbugs.gnu.org
Subject: bug#17346: 24.4.50; Why is the goal column limited to C-n and C-p ?
Date: Thu, 9 Oct 2014 22:43:38 +0200	[thread overview]
Message-ID: <CAH8Pv0hgdv-30R4v7oiyCOQj=7V6QEyrCqoBEvkxO6FMQJJAzA@mail.gmail.com> (raw)
In-Reply-To: <jwvh9zdc9jp.fsf-monnier+emacsbugs@gnu.org>

On Thu, Oct 9, 2014 at 6:57 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> We could change that hardcoded list by replacing it with a symbol
>>> property `preserve-temporary-goal-column' and then add that property to
>>> recenter-top-bottom.
>> Sounds right to me.
>
> Patch welcome.

I currently lack the knowledge for making the change myself, sorry.

>> Note also that, as I said before in this thread, any command intended
>> for _vertical_ motion of the cursor (scroll-up-command,
>> scroll-down-command, scroll-bar-toolkit-scroll, mwheel-scroll, ...)
>> should try to preserve the goal column (whether semi-permanet or
>> temporary).
>
> If you want that, just set scroll-preserve-screen-position accordingly.

I don't see how that would solve the problem I'm reporting.  For example:

* emacs -Q
* Visit the COPYING file from the Emacs tree.
* (setq scroll-preserve-screen-position t)
* M-m
* Scroll down with C-v until point falls on an empty line, so that the
  point can't stay at the original column.
* Now try to continue your scrolling down, but now with C-n.

Observe then how the original column is lost, which is IMO an annoying
bug which makes harder for me the analysis of tabulated files.

> I think there's a remaining bug in that the scroll commands will
> use their own "temporary goal-column".  So, for example, if you're on
> column 70, then do C-n to an empty line and then do page-down you'll end
> up in column 0 because page-down did not pay attention to
> temporary-goal-column (and vice-versa when switching from scrolling to
> C-n/C-p).
> Patch welcome to fix this as well.

Exactly.  That is what I'm trying to explain: All commands that move
point *vertically* to another line of text, either directly (like
C-p/C-n) or indirectly as consequence of scrolling the buffer (like
C-v/M-v) should share a single "temporary goal column", which is the
column where point was after the last non-vertical scrolling command.

>> Therefore, `preserve-goal-column' would be a better name for the
>> property, since it would refer to both types of goal columns.
>
> Actually both types are temporary (as opposed to `goal-column' which is
> set typically once and for all by the major mode).

I'm lost here.  I was aware of only these two types of "goal columns":

1. Temporary: Set after every command which moves point, except for
   those commands intended for _vertical_ motion (C-p/C-n/C-v/M-v/...).

2. Semi-permanent: Set with the `set-goal-column' command.  When this
   goal column is defined, it prevails over the temporary one.


-- 
Dani Moncayo





  reply	other threads:[~2014-10-09 20:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-25 11:29 bug#17346: 24.4.50; Why is the goal column limited to C-n and C-p ? Dani Moncayo
2014-04-25 14:43 ` Dani Moncayo
2014-04-25 16:14   ` Stefan Monnier
2014-04-29  6:25     ` Dani Moncayo
2014-04-29 21:54       ` Stefan Monnier
2014-05-29 15:10         ` Dani Moncayo
2014-10-09  7:24           ` Dani Moncayo
2014-10-09 15:44             ` Stefan Monnier
2014-10-09 16:03               ` Dani Moncayo
2014-10-09 16:30                 ` Dani Moncayo
2014-10-09 19:45                   ` Stefan Monnier
2014-10-09 20:43                     ` Dani Moncayo [this message]
2014-10-09 21:12                       ` Stefan Monnier
2014-10-09 21:32                         ` Dani Moncayo
2014-10-10  1:09                           ` Stefan Monnier
2014-10-09 16:57                 ` Stefan Monnier
2022-04-30 15:34                 ` Lars Ingebrigtsen
2022-04-30 16:11                   ` Drew Adams
2022-06-05 19:37                   ` Lars Ingebrigtsen
2022-06-05 22:56                     ` Drew Adams
2014-04-25 16:20 ` Michael Welsh Duggan
2014-04-25 16:49   ` Dani Moncayo

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to='CAH8Pv0hgdv-30R4v7oiyCOQj=7V6QEyrCqoBEvkxO6FMQJJAzA@mail.gmail.com' \
    --to=dmoncayo@gmail.com \
    --cc=17346@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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 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).