next-line + recenter (- redraw frame)?

next-line + recenter (- redraw frame)?

[Peter Tury]

Hi,

I've created a tiny function for ease reading:

(defun down-center ()
  "Moves point down by one line and then moves the line to the
center of the screen.
Keeps columns as next-line does.
Created for ease reading (of program source codes) (since this
way the user always can see the most lines around)."
  (interactive)       
  (if (eq last-command 'down-center)
      (setq last-command 'next-line))
  (next-line)
  (recenter))

(define-key global-map [M-down] 'down-center)

Please comment it!

I am especially interested in these:

- do you know some builtin function what does the same (=so this function
is totally unnecessary) in emacs 22?

- how could I get rid of setting last-command (it seems to be a quite ugly
solution for me...) (it is necessary if you go through e.g. an empty or too
short line: then, without this last-command setting, the original column is
lost (since next-line (more exactly: line-move-1) uses last-command :-((

- how could I get rid of redrawing the frame? recenter's doc writes: "Just
C-u as prefix means put point in the center of the window
and redisplay normally--don't erase and redraw the frame." -- I would like
to use this. But how to call recenter from elisp "just uing C-u as prefix"?
It seems for me that if I put "(universal-argument)" (what is bound to C-u)
before "(recenter)" it doesn't help.

Thanks,
P

Re: next-line + recenter (- redraw frame)?

[Ralf Angeli]

* Peter Tury (2006-03-03) writes:

> I've created a tiny function for ease reading:
>
> (defun down-center ()
>   "Moves point down by one line and then moves the line to the
> center of the screen.
> Keeps columns as next-line does.
> Created for ease reading (of program source codes) (since this
> way the user always can see the most lines around)."
[...]
> I am especially interested in these:
>
> - do you know some builtin function what does the same (=so this function
> is totally unnecessary) in emacs 22?

You can get a similar functionality with `C-l' followed by `M-x
scroll-lock-mode RET' and using `C-p' and `C-n' for moving around.

-- 
Ralf

Re: next-line + recenter (- redraw frame)?

[Peter Dyballa]

Am 03.03.2006 um 16:54 schrieb Peter Tury:

> Please comment it!

Please compare it to scroll-down-in-place in lisp/term/sun.el by Jeff  
Peck!

(defun scroll-down-in-place (n)
   (interactive "p")
   (previous-line n)
   (scroll-down n))

(defun scroll-up-in-place (n)
   (interactive "p")
   (next-line n)
   (scroll-up n))

--
Greetings

   Pete

 From error to error, one discovers the entire truth.
                                                             -Sigmund  
Freud

Re: next-line + recenter (- redraw frame)?

[Peter Tury]

On Fri, 03 Mar 2006 18:36:30 +0100, Ralf Angeli wrote:

> You can get a similar functionality with `C-l' followed by `M-x
> scroll-lock-mode RET' and using `C-p' and `C-n' for moving around.

Hi,

thanks for the info! I checked this mode now and learned from it. But I
don't plan to use it instead of my code, because you reimplemented some
functionality and thus (e.g.) <down> doesn't work exactly as normally. I
mean e.g. if I go to end of line and then down, then the column is keeped
instead of the end of line (as normally). This solution is equivalently
good also for me but I would like to have only one method... (Moreover:
your minor mode sometimes skips two lines, I don't know why.)

Anyway: thanks a lot,
P

Re: next-line + recenter (- redraw frame)?

[Peter Tury]

On Fri, 3 Mar 2006 23:20:55 +0100, Peter Dyballa wrote:

> Please compare it to scroll-down-in-place in lisp/term/sun.el by Jeff  
> Peck!
> 
> (defun scroll-down-in-place (n)
>    (interactive "p")
>    (previous-line n)
>    (scroll-down n))
> 
> (defun scroll-up-in-place (n)
>    (interactive "p")
>    (next-line n)
>    (scroll-up n))

Hi,

thanks for the info! This is again really almost the same as I wanted.
(Recenter is not so important, maybe scroll- is better.) However this has a
"big" disadvantage: it forgets the correct column always. The problem is in
next-line (more exactly: line-move-1) as I mentioned earlier, I know...

What do you think: is it realistic to modify simple.el "officially" to
eliminate this "bug"? I think we would have a variable
column-keeping-line-moves-list or something similar what would tell what
commands should be treated as now next-line and previous-line. Its default
could be '(next-line previous-line), so we would have backword
compatibility.

After this, if the user adds e.g. scroll-up-in-place to this list, then
scroll-up-in-place would work "correctly" in the above form. (I can imagine
this is not the required functionality for scroll-up-in-place, but it is
just an example here).

What should I do if I want to propose this "officially"? I see that
simple.el's maintainer is FSF...

Br,
P

Re: next-line + recenter (- redraw frame)?

[Ralf Angeli]

* Peter Tury (2006-03-06) writes:

> On Fri, 03 Mar 2006 18:36:30 +0100, Ralf Angeli wrote:
>
>> You can get a similar functionality with `C-l' followed by `M-x
>> scroll-lock-mode RET' and using `C-p' and `C-n' for moving around.
>
> thanks for the info! I checked this mode now and learned from it. But I
> don't plan to use it instead of my code, because you reimplemented some
> functionality and thus (e.g.) <down> doesn't work exactly as normally. I
> mean e.g. if I go to end of line and then down, then the column is keeped
> instead of the end of line (as normally).

I don't understand what you mean.

If there are the lines

1: a
2: ab

in a buffer and point is at the end of the first line, calling either
`next-line' without Scroll Lock mode or `scroll-lock-next-line' will
have the same result, namely that point will be between "a" and "b" in
the second line.  `next-line' does not move point to the end of the
second line as you seem to describe.  But maybe I misunderstood that.

> This solution is equivalently
> good also for me but I would like to have only one method... (Moreover:
> your minor mode sometimes skips two lines, I don't know why.)

If you send a bug report with a minimal example by means of `M-x
emacs-report-bug RET' people would have a chance to debug the problem
and eventually fix it.

-- 
Ralf

Re: next-line + recenter (- redraw frame)?

[Peter Tury]

On Mon, 06 Mar 2006 09:43:32 +0100, Ralf Angeli wrote:

> * Peter Tury (2006-03-06) writes:
>> On Fri, 03 Mar 2006 18:36:30 +0100, Ralf Angeli wrote:
>>
>> (e.g.) <down> doesn't work exactly as normally. I
>> mean e.g. if I go to end of line and then down, then the column is keeped
>> instead of the end of line (as normally).
> 
> I don't understand what you mean.
> 
> If there are the lines
> 
> 1: a
> 2: ab
> 
> in a buffer and point is at the end of the first line, calling either
> `next-line' without Scroll Lock mode or `scroll-lock-next-line' will
> have the same result, namely that point will be between "a" and "b" in
> the second line.  `next-line' does not move point to the end of the
> second line as you seem to describe.  But maybe I misunderstood that.

Sorry, my mistake: it works this way only if I set track-eol to t. (And in
this case the difference is what I described.)

>> your minor mode sometimes skips two lines, I don't know why.)
> 
> If you send a bug report with a minimal example by means of `M-x
> emacs-report-bug RET' people would have a chance to debug the problem
> and eventually fix it.

Thanks for the info! I may do this. Currently I don't see any rule when
this minor mode does this. If I will see the rule, then I will be able to
send a detailed bug report. Maybe the bug is in my (cvs: emacsW32) emacs?
It seems so if you cannot achieve this functionality since I see it many
times...

Br,
P

Re: next-line + recenter (- redraw frame)?

[David Combs]

In article <19aniuq151di2$.1qyujo75j1w3b$.dlg@40tude.net>,
Peter Tury  <tury.peter@gmail.com> wrote:
>On Fri, 3 Mar 2006 23:20:55 +0100, Peter Dyballa wrote:
>
>> Please compare it to scroll-down-in-place in lisp/term/sun.el by Jeff  
>> Peck!
>> 
>> (defun scroll-down-in-place (n)
>>    (interactive "p")
>>    (previous-line n)
>>    (scroll-down n))
>> 
>> (defun scroll-up-in-place (n)
>>    (interactive "p")
>>    (next-line n)
>>    (scroll-up n))
>

Never even knew it was there, sun.el.


Questions:

. What makes sun.el relevant to (only?) Sun computers, or Solaris?

. Is this sun.el so well liked that just about *anyone* running
   emacs on a Sun should put a load-file of it in their .emacs?

Thanks,

David

Re: next-line + recenter (- redraw frame)?

[Peter Dyballa]

Am 26.03.2006 um 04:38 schrieb David Combs:

> . What makes sun.el relevant to (only?) Sun computers, or Solaris?

It has keyboard bindings for old Sun Type 4 (and 3?) keyboards, those  
with extra Left and Right function keys. For recent keyboards and  
environments it's probably neither needed nor useful.

>
> . Is this sun.el so well liked that just about *anyone* running
>    emacs on a Sun should put a load-file of it in their .emacs?

I think it's outdated (Emacstool is the Carbon Emacs for Sunview --  
ever heard of this pre-X11 GUI?). Modern Suns have poor PC like  
keyboards, but some functions are worth being saved -- when still  
working in small windows.

--
Greetings

   Pete

“One cannot live by television, video games, top ten CDs, and dumb  
movies alone”
       (Amiri Baraka 1999)

Re: next-line + recenter (- redraw frame)?

[Kevin Rodgers]

David Combs wrote:
 > Never even knew it was there, sun.el.
 >
 > Questions:
 >
 > . What makes sun.el relevant to (only?) Sun computers, or Solaris?

It is relevant to Sun keyboards.

 > . Is this sun.el so well liked that just about *anyone* running
 >    emacs on a Sun should put a load-file of it in their .emacs?

It should be loaded automatically:

,----[ C-h v term-file-prefix RET ]
| term-file-prefix's value is "term/"
|
| Documentation:
| If non-nil, Emacs startup does (load (concat term-file-prefix (getenv 
"TERM")))
| You may set this variable to nil in your `.emacs' file if you do not wish
| the terminal-initialization file to be loaded.
|
| Defined in `paths.el'.
`----

And from the Emacs manual:

,----
|
| Terminal-specific Initialization
--------------------------------|
|
|    Each terminal type can have a Lisp library to be loaded into Emacs
| when it is run on that type of terminal.  For a terminal type named
| TERMTYPE, the library is called `term/TERMTYPE' and it is found by
| searching the directories `load-path' as usual and trying the suffixes
| `.elc' and `.el'.  Normally it appears in the subdirectory `term' of
| the directory where most Emacs libraries are kept.
|
|    The usual purpose of the terminal-specific library is to map the
| escape sequences used by the terminal's function keys onto more
| meaningful names, using `function-key-map'.  See the file
| `term/lk201.el' for an example of how this is done.  Many function keys
| are mapped automatically according to the information in the Termcap
| data base; the terminal-specific library needs to map only the function
| keys that Termcap does not specify.
|
|    When the terminal type contains a hyphen, only the part of the name
| before the first hyphen is significant in choosing the library name.
| Thus, terminal types `aaa-48' and `aaa-30-rv' both use the library
| `term/aaa'.  The code in the library can use `(getenv "TERM")' to find
| the full terminal type name.
|
|    The library's name is constructed by concatenating the value of the
| variable `term-file-prefix' and the terminal type.  Your `.emacs' file
| can prevent the loading of the terminal-specific library by setting
| `term-file-prefix' to `nil'.
|
|    Emacs runs the hook `term-setup-hook' at the end of initialization,
| after both your `.emacs' file and any terminal-specific library have
| been read in.  Add hook functions to this hook if you wish to override
| part of any of the terminal-specific libraries and to define
| initializations for terminals that do not have a library.  *Note
| Hooks::.
|
`----

-- 
Kevin Rodgers