bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Dani Moncayo]

From Emacs -Q:

1. Eval: (setq scroll-margin 1)
2. Eval: (info "(emacs) Intro")
3. Type: <backspace>

--> The current line is the last visible one, but that should never
happen, since `scroll-margin' is set to 1.  The current line should be
the penultimate visible one.


In GNU Emacs 24.3.50.1 (i386-mingw-nt6.1.7601)
 of 2012-12-02 on MS-W7-DANI
Bzr revision: 111063 cyd@gnu.org-20121202064122-kozzng5h4m9fw8ey
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src
 -Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/zlib-1.2.5
 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include
 -Ic:/emacs/libs/jpeg-6b-4-lib/include
 -Ic:/emacs/libs/tiff-3.8.2-1-lib/include
 -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include
 -Ic:/emacs/libs/libiconv-1.9.2-1-lib/include'

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252
  default enable-multibyte-characters: t


-- 
Dani Moncayo

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Eli Zaretskii]

> Date: Sun, 2 Dec 2012 17:39:09 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> >From Emacs -Q:
> 
> 1. Eval: (setq scroll-margin 1)
> 2. Eval: (info "(emacs) Intro")
> 3. Type: <backspace>
> 
> --> The current line is the last visible one, but that should never
> happen, since `scroll-margin' is set to 1.  The current line should be
> the penultimate visible one.

Not a bug.  scroll-margin is only in effect when window is _scrolled_
due to cursor motion commands.  In this case, <backspace> causes the
buffer to be emptied, and an entirely different text be inserted into
it.  There's no scrolling here, thus scroll-related variables are
never consulted in this case.

The Emacs User manual clearly starts the section that describes these
variables with this:

  Emacs performs "automatic scrolling" when point moves out of the
  visible portion of the text.

IOW, scroll-margin determines when automatic scrolling is triggered,
but not where point can be legitimately located in a window.

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Dani Moncayo]

> Not a bug.  scroll-margin is only in effect when window is _scrolled_
> due to cursor motion commands.  In this case, <backspace> causes the
> buffer to be emptied, and an entirely different text be inserted into
> it.  There's no scrolling here, thus scroll-related variables are
> never consulted in this case.
>
> The Emacs User manual clearly starts the section that describes these
> variables with this:
>
>   Emacs performs "automatic scrolling" when point moves out of the
>   visible portion of the text.

From an user point of view, the <backspace> key (from Info buffers) is
indeed a movement command.  In this case the movement was from the to
of one info node to the bottom of another one (the previous one).

> IOW, scroll-margin determines when automatic scrolling is triggered,
> but not where point can be legitimately located in a window.

That makes little sense to me, and is not what I interpret from the
documentation:

     The variable `scroll-margin' restricts how close point can come to
  the top or bottom of a window (even if aggressive scrolling specifies a
  fraction F that is larger than the window portion between the top and
  the bottom margins).  Its value is a number of screen lines; if point
  comes within that many lines of the top or bottom of the window, Emacs
  performs automatic scrolling.  By default, `scroll-margin' is 0.

As I see it, this variable guarantees the users to _always_ see some
context lines around point, which is an important feature to me.
Without this feature, I would be sometimes unsure about whether the
current line is the one I am looking for (because I have no context
lines below/above the current one).  That's the very reason I set this
variable in my init file, and it makes no sense to me to honor this
variable in some situations and not in others.

And BTW, one symptom of the abnormal location of the current line in
my recipe is this: just after the last step, if you minimize the Emacs
frame and restore it again, the current line is then centered in the
window.  What sense does that make?  The current line should not
change because of that, definitely.

-- 
Dani Moncayo

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Eli Zaretskii]

> Date: Sun, 2 Dec 2012 22:51:44 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 13055@debbugs.gnu.org
> 
> >From an user point of view, the <backspace> key (from Info buffers) is
> indeed a movement command.  In this case the movement was from the to
> of one info node to the bottom of another one (the previous one).

The crucial difference is that in your case there's nothing in common
between the two texts.  Scroll-related options are there to let you
control how much overlap is kept between successive windows of text.
When there's nothing in common, there can be no overlap, and therefore
these variables make no sense.

> > IOW, scroll-margin determines when automatic scrolling is triggered,
> > but not where point can be legitimately located in a window.
> 
> That makes little sense to me, and is not what I interpret from the
> documentation:
> 
>      The variable `scroll-margin' restricts how close point can come to
>   the top or bottom of a window (even if aggressive scrolling specifies a
>   fraction F that is larger than the window portion between the top and
>   the bottom margins).  Its value is a number of screen lines; if point
>   comes within that many lines of the top or bottom of the window, Emacs
>   performs automatic scrolling.  By default, `scroll-margin' is 0.

If the documentation leads you to different conclusions, it's
something that should be fixed in the documentation.  E.g.

      The variable `scroll-margin' restricts how close point can come to
   the top or bottom of a window as part of cursor motion commands.
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> As I see it, this variable guarantees the users to _always_ see some
> context lines around point, which is an important feature to me.

No, it doesn't.

> Without this feature, I would be sometimes unsure about whether the
> current line is the one I am looking for (because I have no context
> lines below/above the current one).  That's the very reason I set this
> variable in my init file, and it makes no sense to me to honor this
> variable in some situations and not in others.

It was always that way in Emacs.  What you expect is a feature that
never existed.

> And BTW, one symptom of the abnormal location of the current line in
> my recipe is this: just after the last step, if you minimize the Emacs
> frame and restore it again, the current line is then centered in the
> window.  What sense does that make?  The current line should not
> change because of that, definitely.

I disagree, sorry.

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Dani Moncayo]

>> >From an user point of view, the <backspace> key (from Info buffers) is
>> indeed a movement command.  In this case the movement was from the to
>> of one info node to the bottom of another one (the previous one).
>
> The crucial difference is that in your case there's nothing in common
> between the two texts.  Scroll-related options are there to let you
> control how much overlap is kept between successive windows of text.
> When there's nothing in common, there can be no overlap, and therefore
> these variables make no sense.

IMO, `scroll-margin' clearly makes sense whenever the displayed text
changes, regardless of the relation between the old displayed text and
the new one.

>> > IOW, scroll-margin determines when automatic scrolling is triggered,
>> > but not where point can be legitimately located in a window.
>>
>> That makes little sense to me, and is not what I interpret from the
>> documentation:
>>
>>      The variable `scroll-margin' restricts how close point can come to
>>   the top or bottom of a window (even if aggressive scrolling specifies a
>>   fraction F that is larger than the window portion between the top and
>>   the bottom margins).  Its value is a number of screen lines; if point
>>   comes within that many lines of the top or bottom of the window, Emacs
>>   performs automatic scrolling.  By default, `scroll-margin' is 0.
>
> If the documentation leads you to different conclusions, it's
> something that should be fixed in the documentation.  E.g.
>
>       The variable `scroll-margin' restricts how close point can come to
>    the top or bottom of a window as part of cursor motion commands.
>                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

IMO, the current documentation describes the behavior that makes
sense, and the one I want to have.

>> As I see it, this variable guarantees the users to _always_ see some
>> context lines around point, which is an important feature to me.
>
> No, it doesn't.

It should.  In fact it does; the only exception I've found so far is
the one described in the initial post.

>> Without this feature, I would be sometimes unsure about whether the
>> current line is the one I am looking for (because I have no context
>> lines below/above the current one).  That's the very reason I set this
>> variable in my init file, and it makes no sense to me to honor this
>> variable in some situations and not in others.
>
> It was always that way in Emacs.  What you expect is a feature that
> never existed.

Well, then consider this bug report as a feature request.

>> And BTW, one symptom of the abnormal location of the current line in
>> my recipe is this: just after the last step, if you minimize the Emacs
>> frame and restore it again, the current line is then centered in the
>> window.  What sense does that make?  The current line should not
>> change because of that, definitely.
>
> I disagree, sorry.

Does that behavior (changing the location of the the current line
after minimizing + restoring the Emacs frame) makes sense to anyone?
Come on ...

Please Eli, reconsider this.  The meaning of `scroll-margin' makes
perfectly sense here.

Thanks

-- 
Dani Moncayo

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Juanma Barranquero]

On Mon, Dec 3, 2012 at 8:34 AM, Dani Moncayo <dmoncayo@gmail.com> wrote:

> IMO, `scroll-margin' clearly makes sense whenever the displayed text
> changes, regardless of the relation between the old displayed text and
> the new one.

I agree with Eli that this is a documentation bug. The very name
"scroll-margin" clearly says that its effect is related to scrolling,
and it's in fact so though the docstring might suggest otherwise. It's
true that <backspace> in an Info buffer would be, from a user's POV, a
"motion command", but not scrolling IMO. Do you also expect M-> M-< to
move the point to the second line of the buffer, or to display a
ghostly empty line above 1st line?

> It should.

That's clearly a matter of opinion.

> Does that behavior (changing the location of the the current line
> after minimizing + restoring the Emacs frame) makes sense to anyone?
> Come on ...

On this one I agree with you. After minimize / restore, Emacs
shouldn't recenter the point. But that's unrelated to scrolling; it's
just that Emacs has a definite affinity for recentering whether the
user wants or not.

> Please Eli, reconsider this.  The meaning of `scroll-margin' makes
> perfectly sense here.

No, you want some new variable (and behavior) `point-margin' or somesuch.

    Juanma

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Dani Moncayo]

>> IMO, `scroll-margin' clearly makes sense whenever the displayed text
>> changes, regardless of the relation between the old displayed text and
>> the new one.
>
> I agree with Eli that this is a documentation bug. The very name
> "scroll-margin" clearly says that its effect is related to scrolling,
> and it's in fact so though the docstring might suggest otherwise. It's
> true that <backspace> in an Info buffer would be, from a user's POV, a
> "motion command", but not scrolling IMO.

What's the point of distinguishing "motion" and "scrolling" here?  IMO
someone who customizes `scroll-margin' is for having (always) some
context lines on both sides of the current line (but I'm repeating
myself).

> Do you also expect M-> M-< to
> move the point to the second line of the buffer, or to display a
> ghostly empty line above 1st line?

For M-> I expect to leave `scroll-margin' lines below the current (last) line.

M-< is an exception, because it makes little sense to show empty lines
before the first one.

IOW: The current behavior of those keys is the right one, IMO.

>> Does that behavior (changing the location of the the current line
>> after minimizing + restoring the Emacs frame) makes sense to anyone?
>> Come on ...
>
> On this one I agree with you. After minimize / restore, Emacs
> shouldn't recenter the point. But that's unrelated to scrolling; it's
> just that Emacs has a definite affinity for recentering whether the
> user wants or not.

Yes, recentering should not happen here, obviously.

>> Please Eli, reconsider this.  The meaning of `scroll-margin' makes
>> perfectly sense here.
>
> No, you want some new variable (and behavior) `point-margin' or somesuch.

I don't think a new variable is needed at all.  Just take care of
`scroll-margin' whenever Emacs decides where to put the current line
in the window; and that includes the case brought up in this report.

-- 
Dani Moncayo

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Juanma Barranquero]

On Mon, Dec 3, 2012 at 4:21 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:

> What's the point of distinguishing "motion" and "scrolling" here?

Not all motions are scrolling. Though, to be fair, Emacs seems to be
treating most of them like scrolls in the sense of honoring
scroll-margin.

> For M-> I expect to leave `scroll-margin' lines below the current (last) line.
>
> M-< is an exception, because it makes little sense to show empty lines
> before the first one.
>
> IOW: The current behavior of those keys is the right one, IMO.

Actually, after

  emacs -Q --eval "(setq scroll-margin 1)"
  C-h N
  >

the point is not in the next-to-last line.

    Juanma

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Dani Moncayo]

> Actually, after
>
>   emacs -Q --eval "(setq scroll-margin 1)"
>   C-h N
>   >
>
> the point is not in the next-to-last line.

Indeed.  I don't know why.  Seems a bug too.

BTW, if you repeat that recipe without setting `scroll-margin' at all,
the result is the same.

-- 
Dani Moncayo

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[martin rudalics]

 >> Does that behavior (changing the location of the the current line
 >> after minimizing + restoring the Emacs frame) makes sense to anyone?
 >> Come on ...
 >
 > On this one I agree with you. After minimize / restore, Emacs
 > shouldn't recenter the point. But that's unrelated to scrolling; it's
 > just that Emacs has a definite affinity for recentering whether the
 > user wants or not.

Do you really mean minimize + restore?  This doesn't recenter `point'
here.

martin

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Eli Zaretskii]

> Date: Mon, 3 Dec 2012 08:34:25 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 13055@debbugs.gnu.org
> 
> IMO, `scroll-margin' clearly makes sense whenever the displayed text
> changes, regardless of the relation between the old displayed text and
> the new one.

You are reading into the variable a meaning it never had.

> >> As I see it, this variable guarantees the users to _always_ see some
> >> context lines around point, which is an important feature to me.
> >
> > No, it doesn't.
> 
> It should.  In fact it does

No, it does not.  I could show you more examples, but I don't think it
will matter.  You won't change your mind.

> Please Eli, reconsider this.  The meaning of `scroll-margin' makes
> perfectly sense here.

It is against my best technical judgment to make changes that spread
the effect of scroll-related options beyond scrolling.  It would be
one more step towards making redisplay_window, which is the main
workhorse of the display engine, an unmaintainable heap of twisty
little passages all alike.  We are already half way there, just take
the hint from the fact that we need to explain in the user manual the
order of priority between 3 options that control scrolling in
contradicting ways.  Or just read the code, if you dare, and then try
writing a coherent description of what it does, and why.  I'm sure we
got there by following exactly this kind of path to creeping
featurism, accompanied all the way by requests like "please,
pretty-please, give me just this one more little feature."

Anyway, I'm tired of having my arguments heard and discarded.  The
change that will give you what you asked for is below.  I will commit
it -- under protest -- provided that Stefan and/or Chong give their
blessing -- not to the changes, but to the idea of applying
scroll-margin to this unrelated use case, and a marginal one at that.

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2012-11-30 09:23:15 +0000
+++ src/xdisp.c	2012-12-03 17:24:48 +0000
@@ -15717,6 +15717,34 @@ redisplay_window (Lisp_Object window, in
 	     Move it back to a fully-visible line.  */
 	  new_vpos = window_box_height (w);
 	}
+      else if (w->cursor.vpos >=0)
+	{
+	  /* Some people insist on not letting point enter the scroll
+	     margin, even though this part handles windows that didn't
+	     scroll at all.  */
+	  struct frame *f = XFRAME (w->frame);
+	  int margin = min (scroll_margin, WINDOW_TOTAL_LINES (w) / 4);
+	  int pixel_margin = margin * FRAME_LINE_HEIGHT (f);
+
+	  if (w->cursor.vpos < margin)
+	    new_vpos = pixel_margin;
+	  else
+	    {
+	      int window_height = window_box_height (w);
+
+	      if (w->cursor.y >= window_height - pixel_margin)
+		{
+		  /* Note the gotcha: window_box_height returns the
+		     pixel size of the window excluding the header
+		     line, but pixel coordinates, like new_vpos, are
+		     measured from the beginning of the window, and
+		     thus include the header line size.  */
+		  new_vpos = window_height - pixel_margin;
+		  if (WINDOW_WANTS_HEADER_LINE_P (w))
+		    new_vpos += CURRENT_HEADER_LINE_HEIGHT (w);
+		}
+	    }
+	}
 
       /* If we need to move point for either of the above reasons,
 	 now actually do it.  */

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 3 Dec 2012 17:09:28 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, 13055@debbugs.gnu.org
> 
> On Mon, Dec 3, 2012 at 4:21 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
> 
> > What's the point of distinguishing "motion" and "scrolling" here?
> 
> Not all motions are scrolling. Though, to be fair, Emacs seems to be
> treating most of them like scrolls in the sense of honoring
> scroll-margin.

But this one is not motion at all.  Not even remotely.  It discards
previous text and fills the buffer with an entirely new one.

It is immaterial that Backspace is bound to the command called
'Info-scroll-down'.  What that command does is go to the previous node
in the graph structure of the manual.  The "previous" node could be
anywhere in the manual, since an Info manual does not have a flat
linear structure.  You go to a different section, chapter, or even
another manual -- all according to what the author put in the Prev
link.  It's absurd to call this "scrolling".

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Juanma Barranquero]

On Mon, Dec 3, 2012 at 6:46 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> But this one is not motion at all.  Not even remotely.  It discards
> previous text and fills the buffer with an entirely new one.

I agree with you, but I also understand why, for the user, it can
appear as moving to another part of the same document, even if it
really isn't.

> You go to a different section, chapter, or even
> another manual -- all according to what the author put in the Prev
> link.  It's absurd to call this "scrolling".

Agreed.

    Juanma

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Juanma Barranquero]

On Mon, Dec 3, 2012 at 6:42 PM, martin rudalics <rudalics@gmx.at> wrote:

> Do you really mean minimize + restore?  This doesn't recenter `point'
> here.

Not in the general case, but following Dani's recipe:

1. Eval: (setq scroll-margin 1)
2. Eval: (info "(emacs) Intro")
3. Type: <backspace>

then

4. Minimize Emacs
5. Restore

     J

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Stefan Monnier]

> 1. Eval: (setq scroll-margin 1)
> 2. Eval: (info "(emacs) Intro")
> 3. Type: <backspace>

I agree it would be good to extend scroll-margin so it applies in such
cases as well.


        Stefan

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Dani Moncayo]

>> IMO, `scroll-margin' clearly makes sense whenever the displayed text
>> changes, regardless of the relation between the old displayed text and
>> the new one.
>
> You are reading into the variable a meaning it never had.

In that case, I'd like you to consider whether that meaning could make
any sense.

>> >> As I see it, this variable guarantees the users to _always_ see some
>> >> context lines around point, which is an important feature to me.
>> >
>> > No, it doesn't.
>>
>> It should.  In fact it does
>
> No, it does not.  I could show you more examples, but I don't think it
> will matter.  You won't change your mind.

I try to be as open as I can to change my mind, whenever I realize I
was wrong somehow.

>> Please Eli, reconsider this.  The meaning of `scroll-margin' makes
>> perfectly sense here.
>
> It is against my best technical judgment to make changes that spread
> the effect of scroll-related options beyond scrolling.  It would be
> one more step towards making redisplay_window, which is the main
> workhorse of the display engine, an unmaintainable heap of twisty
> little passages all alike.  We are already half way there, just take
> the hint from the fact that we need to explain in the user manual the
> order of priority between 3 options that control scrolling in
> contradicting ways.

I agree with you in that the current user-level model for customizing
automatic scrolling is too messy.  IMO, the variables
scroll-up/down-aggressively are misguided and could be obsoleted.  But
that is another story.

>  Or just read the code, if you dare, and then try
> writing a coherent description of what it does, and why.  I'm sure we
> got there by following exactly this kind of path to creeping
> featurism, accompanied all the way by requests like "please,
> pretty-please, give me just this one more little feature."

I don't know anything about how Emacs implements these features.  I
just was trying to explain, as a mere user, how I'd like Emacs to
behave, and why.  If my idea is wrong or misguided, just dismiss it.

> Anyway, I'm tired of having my arguments heard and discarded.

I'm sorry you feel that way.  I don't discard your arguments.  I just
sometimes disagree with them.

> The change that will give you what you asked for is below.  I will commit
> it -- under protest -- provided that Stefan and/or Chong give their
> blessing -- not to the changes, but to the idea of applying
> scroll-margin to this unrelated use case, and a marginal one at that.

I don't pretend to make any pressure.  You decide whether what I
propose is valid or not.

Anyway, thank you again for all the time a energy invested in Emacs;

-- 
Dani Moncayo

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Mon, 03 Dec 2012 13:07:37 -0500
> Cc: 13055@debbugs.gnu.org
> 
> > 1. Eval: (setq scroll-margin 1)
> > 2. Eval: (info "(emacs) Intro")
> > 3. Type: <backspace>
> 
> I agree it would be good to extend scroll-margin so it applies in such
> cases as well.

Committed (as trunk revision 111079) under protest.

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Eli Zaretskii]

> Date: Mon, 3 Dec 2012 20:02:41 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Chong Yidong <cyd@gnu.org>, 13055@debbugs.gnu.org
> 
> >> IMO, `scroll-margin' clearly makes sense whenever the displayed text
> >> changes, regardless of the relation between the old displayed text and
> >> the new one.
> >
> > You are reading into the variable a meaning it never had.
> 
> In that case, I'd like you to consider whether that meaning could make
> any sense.

It does to me, and I already explained why.  Twice.

> > Anyway, I'm tired of having my arguments heard and discarded.
> 
> I'm sorry you feel that way.  I don't discard your arguments.  I just
> sometimes disagree with them.

A constructive disagreement is the one where arguments of your
opponent are accepted, digested, and then countermanded by explaining
_why_ they are incorrect.  Simply reiterating your opinion
disregarding anything I say to back up mine does not make a useful
discussion.

> > The change that will give you what you asked for is below.  I will commit
> > it -- under protest -- provided that Stefan and/or Chong give their
> > blessing -- not to the changes, but to the idea of applying
> > scroll-margin to this unrelated use case, and a marginal one at that.
> 
> I don't pretend to make any pressure.

You could have fooled me.

bug#13055: 24.3.50; `scroll-margin' not always honored in Info buffers

[Dani Moncayo]

>> >> IMO, `scroll-margin' clearly makes sense whenever the displayed text
>> >> changes, regardless of the relation between the old displayed text and
>> >> the new one.
>> >
>> > You are reading into the variable a meaning it never had.
>>
>> In that case, I'd like you to consider whether that meaning could make
>> any sense.
>
> It does to me, and I already explained why.  Twice.

True - you said that I was requesting a new feature.  But I didn't
perceive any intention to change the status-quo  (sorry if I
misinterpreted you).  When I say "consider", I mean "consider the
possibility of revising the current behavior".

>> > Anyway, I'm tired of having my arguments heard and discarded.
>>
>> I'm sorry you feel that way.  I don't discard your arguments.  I just
>> sometimes disagree with them.
>
> A constructive disagreement is the one where arguments of your
> opponent are accepted, digested, and then countermanded by explaining
> _why_ they are incorrect.  Simply reiterating your opinion
> disregarding anything I say to back up mine does not make a useful
> discussion.

Good explanation.  100% agreement.  I'll do my best for being more
constructive next time.


-- 
Dani Moncayo