Eli Zaretskii wrote:
From: Kevin Rodgers <[EMAIL PROTECTED]>
Date: Fri, 08 Apr 2005 09:46:23 -0600
Why can't the overscrolled portion of the window (or any portion beyond
the end of the buffer) be displayed differently? I think the fringe
face would be good for that.
There's already an optional f
Yes,and for Lesstif/Motif. There has been bug reports on this
approach. The main confusion seems to be that when a small buffer is
used (like the three initial lines in the *scratch* buffer), the
scrollbar thumb does not extend to the bottom, since we have added the
fictit
On 4/10/05, Jan D. <[EMAIL PROTECTED]> wrote:
> Yes,and for Lesstif/Motif. There has been bug reports on this
> approach. The main confusion seems to be that when a small buffer is
> used (like the three initial lines in the *scratch* buffer), the
> scrollbar thumb does not extend to the bottom,
It would be absurd to change Emacs's text model to fit the demands of
a GUI toolkit. However, we could consider computing the "total size"
for scrolling to include N fictitious final blank lines, N = window
height.
AFAIK that's what we do for LessTif and Gtk,
Jan, is that what we do for GTK?
> It would be absurd to change Emacs's text model to fit the demands of
> a GUI toolkit. However, we could consider computing the "total size"
> for scrolling to include N fictitious final blank lines, N = window
> height.
AFAIK that's what we do for LessTif and Gtk,
Jan, is
Miles Bader wrote:
On Apr 10, 2005 1:04 AM, Luc Teirlinck <[EMAIL PROTECTED]> wrote:
>default-indicate-unused-lines.
>
> I am always wary about changing default values close before a release,
> but in this case, it would seem completely harmless to enable this by
> default.
On Apr 10, 2005 1:04 AM, Luc Teirlinck <[EMAIL PROTECTED]> wrote:
>default-indicate-unused-lines.
>
> I am always wary about changing default values close before a release,
> but in this case, it would seem completely harmless to enable this by
> default.
I seem to recall a previous flamewar
>From my previous message:
The description of the option in the Emacs manual needs updating
regardless, as it currently uses obsolete variable names.
I have just fixed this, since the required changes were trivial.
Sincerely,
Luc.
___
Emacs-de
Kim Storm wrote:
> From: Kevin Rodgers <[EMAIL PROTECTED]>
> Date: Fri, 08 Apr 2005 09:46:23 -0600
>
> Why can't the overscrolled portion of the window (or any portion beyond
> the end of the buffer) be displayed differently? I think the fringe
> face would be good for that.
> From: Kevin Rodgers <[EMAIL PROTECTED]>
> Date: Fri, 08 Apr 2005 09:46:23 -0600
>
> Why can't the overscrolled portion of the window (or any portion beyond
> the end of the buffer) be displayed differently? I think the fringe
> face would be good for that.
There's already an optional feature t
Stefan Monnier wrote:
As for overscrolling: yes, it has puzzled a few users occasionally, because
it's not obvious where the buffer actually ends. But note that this problem
is not specific to overscrolling since it already appears when viewing
a buffer too small to fill the window.
Why can't the
> It would be absurd to change Emacs's text model to fit the demands of
> a GUI toolkit. However, we could consider computing the "total size"
> for scrolling to include N fictitious final blank lines, N = window
> height.
> With this technique, the slider would not touch the bottom until you
> h
I looked back at the 2003 conversation. Taylor simply refused to
implement behavior that fits logically with Emacs, demanding that we
change Emacs to put actual blank lines in the bottom of the screen.
It would be absurd to change Emacs's text model to fit the demands of
a GUI toolkit. However,
> As it stands now, the scrollbars are jerking around in size, however, and
> when you try to drag the scrollbar, the displayed portion of the buffer will
> jump somewhere unpredictable.
Yes, and these are just plain bugs.
> Anyways, can I as a user please get the freedom to configure whether I l
On 8 Apr 2005, at 13:42, Stefan Monnier wrote:
There's consistency and there's consistency. In my experience, what
people
care about is "in which direction and by how much does my thingy move
when
I click with button X on part Y of the scrollbar" and "does the
slider's
position and size reflect
> Consistency is extremely important.
I think Ralph Waldo Emerson would disagree.
There's consistency and there's consistency. In my experience, what people
care about is "in which direction and by how much does my thingy move when
I click with button X on part Y of the scrollbar" and "does the
On 8 Apr 2005, at 03:05, Miles Bader wrote:
Instead, suffice it to say that it should be up to
the UI layer to implement the exact behavior.
The UI layer should be able to specify defaults; the final decision
should be up to the user.
Either the user choses an environment, i.e. operating system, th
On Apr 8, 2005 4:59 AM, David Reitter <[EMAIL PROTECTED]> wrote:
> Users exert their freedom to chose a particular UI environment. GTK can
> be seen as part of an environment, as it creates compatible behavior
> across applications. As mentioned earlier in this thread, UI is more
> than the pretty
Stefan Monnier <[EMAIL PROTECTED]> writes:
PS: The only problem is that those toolkits have the idiotic
idea to enforce that the bottom of the thumb cannot go further
than the bottom. And they enforce it by hiding the events
corresponding to "user moves the mouse yet-further-down"
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> PS: The only problem is that those toolkits have the idiotic
>> idea to enforce that the bottom of the thumb cannot go further
>> than the bottom. And they enforce it by hiding the events
>> corresponding to "user moves the mouse yet-f
On 7 Apr 2005, at 20:30, David Kastrup wrote:
Stefan Monnier <[EMAIL PROTECTED]> writes:
PS: The only problem is that those toolkits have the idiotic
idea to enforce that the bottom of the thumb cannot go further
than the bottom. And they enforce it by hiding the events
correspondi
PS: The only problem is that those toolkits have the idiotic idea
to enforce
that the bottom of the thumb cannot go further than the bottom.
And they
enforce it by hiding the events corresponding to "user moves the
mouse
yet-further-down".
I can talk with the GTK developers abo
> PS: The only problem is that those toolkits have the idiotic idea to
> enforce that the bottom of the thumb cannot go further than the
> bottom. And they enforce it by hiding the events corresponding to
> "user moves the mouse yet-further-down".
> I can talk with the GTK develop
PS: The only problem is that those toolkits have the idiotic idea to enforce
that the bottom of the thumb cannot go further than the bottom. And they
enforce it by hiding the events corresponding to "user moves the mouse
yet-further-down".
I can talk with the GTK developers about
> I think you are laboring under the delusion that the scroll bar
> actually displays something sensible, namely that mouse-2 exactly at
> the bottom of the slider will take you exactly one page of screen
> material further. I think you'll find that users are much less
> surprised if this goal is
> I'm curious how _any_ program manages to do this calculation in a
> reasonable amount of time; do they really lay-out the _entire_
> document ahead of time?
AFAIK, yes. HTML rendering engines do the rendering "eagerly" as they
receive the HTML data. They typically do it in a separate thread, s
Miles Bader <[EMAIL PROTECTED]> writes:
> On Apr 6, 2005 11:32 PM, David Reitter <[EMAIL PROTECTED]> wrote:
>> that I'd like to implement in order to conform to standards in my
>> environment, the vertical slider size shows a proportion of _ displayed
>> lines_ not document characters or real line
On Apr 6, 2005 11:32 PM, David Reitter <[EMAIL PROTECTED]> wrote:
> that I'd like to implement in order to conform to standards in my
> environment, the vertical slider size shows a proportion of _ displayed
> lines_ not document characters or real lines (those that end with a CR
> or LF). Whether
> I acknowledge your explanations on the other points - thanks. In the UI that
> I'd like to implement in order to conform to standards in my environment,
> the vertical slider size shows a proportion of _ displayed lines_ not
> document characters or real lines (those that end with a CR or LF). Wh
On 6 Apr 2005, at 15:08, Stefan Monnier wrote:
Under OS X, Emacs behaves very strangely with regard to the
scrollbars and
sliders. When you just click on a slider without moving it (after
you've
scrolled to the middle of the document), you will see that the text
scrolls right away, often far beyo
30 matches
Mail list logo
