bug#5695: 23.1; widget-choose buffer lacking options

bug#5695: 23.1; widget-choose buffer lacking options

[Dani Moncayo]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

Hi there,

Using the customization buffers, i've just seen one behaviour that seems
strange to me:

Withing the buffer [*Customize Group: Killing*], i've changed the value of
the "kill ring max" property. Then, if i click with the mouse on the "State"
button, I see (among others) the option "set for current session". But if I
put the point on that button and push Return, i don't see that option in the
[widget-choose-buffer] buffer.

Why??

[-- Attachment #2: Type: text/html, Size: 556 bytes --]

bug#5697: 23.1; widget-choose buffer lacking options

[Dani Moncayo]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

Hi again,

I've seen this bug on a Ubuntu box, but right now I'm tested it in a Windows
XP box, and the bug doesn't appear here.

May the bug be specific to the GNU/Linux version of Emacs 23.1 ?

On Sun, Mar 7, 2010 at 8:35 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:

> Hi there,
>
> Using the customization buffers, i've just seen one behaviour that seems
> strange to me:
>
> Withing the buffer [*Customize Group: Killing*], i've changed the value of
> the "kill ring max" property. Then, if i click with the mouse on the "State"
> button, I see (among others) the option "set for current session". But if I
> put the point on that button and push Return, i don't see that option in the
> [widget-choose-buffer] buffer.
>
> Why??
>
>

[-- Attachment #2: Type: text/html, Size: 1154 bytes --]

bug#5695: 23.1; widget-choose buffer lacking options

[Dani Moncayo]

[-- Attachment #1: Type: text/plain, Size: 195 bytes --]

Hi again,

I've seen this bug on a Ubuntu box, but right now I'm tested it in a Windows
XP box, and the bug doesn't appear here.

May the bug be specific to the GNU/Linux version of Emacs 23.1 ?

[-- Attachment #2: Type: text/html, Size: 279 bytes --]

bug#5697: 23.1; widget-choose buffer lacking options

[Dani Moncayo]

[-- Attachment #1: Type: text/plain, Size: 161 bytes --]

Sorry, I've created this bug report by mistake.

I wanted to reply to the bug 5695:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5695

So forget about this one.

[-- Attachment #2: Type: text/html, Size: 292 bytes --]

bug#5695: 23.1; widget-choose buffer lacking options

[Dani Moncayo]

[-- Attachment #1: Type: text/plain, Size: 235 bytes --]

More info: The missing menu item "0 = Set for Current Session" is not shown,
but the option is actually available: If I press "0", the status messagge
changes to "SET for current session only".

So the problem seems to be only visual.

[-- Attachment #2: Type: text/html, Size: 320 bytes --]

bug#5695: 23.1; widget-choose buffer lacking options

[Chong Yidong]

> Withing the buffer [*Customize Group: Killing*], i've changed the
> value of the "kill ring max" property. Then, if i click with the mouse
> on the "State" button, I see (among others) the option "set for
> current session". But if I put the point on that button and push
> Return, i don't see that option in the [widget-choose-buffer] buffer.

I assume you're using `emacs -nw' to run Emacs in a terminal.  I haven't
been able to reproduce this in xterm running on GNU/Linux.  Can you
reproduce this with `emacs -Q -nw' to disable customizations?  If so,
could you take a screenshot of the terminal frame when the widget-choose
window is up?

bug#5695: 23.1; widget-choose buffer lacking options

[Dani Moncayo]

[-- Attachment #1.1: Type: text/plain, Size: 1390 bytes --]

Hi Chong,

I've reproduced this bug both in a terminar (starting emacs with -nw) and in
graphical mode. But thanks to your mail I've discovered the root of the
problem:

I've just noticed that the problem arises if (and only if) I start emacs
loading my .emacs file. So, i've been testing a bit and i've discovered that
the line that produces the problem is the one that sets the
next-screen-context-lines variable to 4.

So, now the question is: Is that behaviour correct?

I think it isn't, because i'm not scrolling into the widget-choose window.

I've attached the screenshot that you requested, and also my .emacs file.

Thank you. Dani.

On Sat, Mar 13, 2010 at 9:07 PM, Chong Yidong <cyd@stupidchicken.com> wrote:

> > Withing the buffer [*Customize Group: Killing*], i've changed the
> > value of the "kill ring max" property. Then, if i click with the mouse
> > on the "State" button, I see (among others) the option "set for
> > current session". But if I put the point on that button and push
> > Return, i don't see that option in the [widget-choose-buffer] buffer.
>
> I assume you're using `emacs -nw' to run Emacs in a terminal.  I haven't
> been able to reproduce this in xterm running on GNU/Linux.  Can you
> reproduce this with `emacs -Q -nw' to disable customizations?  If so,
> could you take a screenshot of the terminal frame when the widget-choose
> window is up?
>

[-- Attachment #1.2: Type: text/html, Size: 1868 bytes --]

[-- Attachment #2: screenshot-emacs.png --]
[-- Type: image/png, Size: 62148 bytes --]

[-- Attachment #3: .emacs --]
[-- Type: application/octet-stream, Size: 716 bytes --]


(custom-set-variables
  ;; custom-set-variables was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.
 '(blink-cursor-mode nil)
 '(inhibit-startup-screen t)
 '(make-backup-files nil)
 '(next-screen-context-lines 4)
 '(scroll-down-aggressively 0.3)
 '(scroll-margin 1)
 '(scroll-up-aggressively 0.3)
 '(tool-bar-mode nil))

(custom-set-faces
  ;; custom-set-faces was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.
 )

bug#5695: 23.1; widget-choose buffer lacking options

[Dani Moncayo]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

On Mon, Mar 8, 2010 at 9:44 AM, Dani Moncayo <dmoncayo@gmail.com> wrote:

> Hi again,
>
> I've seen this bug on a Ubuntu box, but right now I'm tested it in a
> Windows
> XP box, and the bug doesn't appear here.
>
> May the bug be specific to the GNU/Linux version of Emacs 23.1 ?
>
>
>
Forget about the abobe post. The bug isn't specific to any particular port.
In Windows XP the contents of the buffer were also shifted. The only
difference was that the shift isn't identical, and the option "0 - Set for
current session" is visible at the top of the window.

Incidentally, is there anyone working on the bug?

[-- Attachment #2: Type: text/html, Size: 1388 bytes --]

bug#5695: 23.1; wid-edit.el problems (was: widget-choose buffer lacking options)

[Jan Djärv]

Dani Moncayo skrev:
> 
> I've just noticed that the problem arises if (and only if) I start emacs
> loading my .emacs file. So, i've been testing a bit and i've discovered that
> the line that produces the problem is the one that sets the
> next-screen-context-lines variable to 4.

Actually, it is the scroll-margin that does it.
When the menu is created, point is at the last line.  Since you have 
scroll-margin set to 1, it scrolls up.  You can't see that because you have no 
indication, but on a graphical terminal you can see that the scroll bar has 
moved a bit.  Unfortunately there is no way to scroll the window, it is either 
select something or C-g.  wid-edit.el tries to set a scroll-other-window 
command, but it somehow fails to work because of the default binding to 
keyboard-quit.  And in any case, IT only scrolls down, not up.

So, the menu created by wid-edit.el should either (or both)

1) place point somewhere else, preferrably at the end of the first line.
2) provide a way to scroll the window. tmm-menubar does this so it can be done.

Someone familiar with wid-edit.el must look at this.

	Jan D.

bug#5695: 23.1; wid-edit.el problems

[Jan Djärv]

One solution would be for widget-choose to use tmm-prompt.  Is that ok?

	Jan D.

Jan Djärv skrev:
> Dani Moncayo skrev:
>>
>> I've just noticed that the problem arises if (and only if) I start emacs
>> loading my .emacs file. So, i've been testing a bit and i've 
>> discovered that
>> the line that produces the problem is the one that sets the
>> next-screen-context-lines variable to 4.
> 
> Actually, it is the scroll-margin that does it.
> When the menu is created, point is at the last line.  Since you have 
> scroll-margin set to 1, it scrolls up.  You can't see that because you 
> have no indication, but on a graphical terminal you can see that the 
> scroll bar has moved a bit.  Unfortunately there is no way to scroll the 
> window, it is either select something or C-g.  wid-edit.el tries to set 
> a scroll-other-window command, but it somehow fails to work because of 
> the default binding to keyboard-quit.  And in any case, IT only scrolls 
> down, not up.
> 
> So, the menu created by wid-edit.el should either (or both)
> 
> 1) place point somewhere else, preferrably at the end of the first line.
> 2) provide a way to scroll the window. tmm-menubar does this so it can 
> be done.
> 
> Someone familiar with wid-edit.el must look at this.
> 
>     Jan D.
> 
> 
> 

bug#5695: 23.1; wid-edit.el problems

[Dani Moncayo]

[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]

From my little experience with GNU Emacs (i'm yet starting to understand
it), i think that the buffer created by tmm-menubar has basically the same
function that the widget-choose buffer: To present a list of options to the
user, and get the chosen one.

So... i agree with you, Jan. Why don't share the same mode for both buffers?
Why to have different modes for each?


On Thu, Apr 1, 2010 at 9:43 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:

> One solution would be for widget-choose to use tmm-prompt.  Is that ok?
>
>        Jan D.
>
> Jan Djärv skrev:
>
>> Dani Moncayo skrev:
>>
>>>
>>> I've just noticed that the problem arises if (and only if) I start emacs
>>> loading my .emacs file. So, i've been testing a bit and i've discovered
>>> that
>>> the line that produces the problem is the one that sets the
>>> next-screen-context-lines variable to 4.
>>>
>>
>> Actually, it is the scroll-margin that does it.
>> When the menu is created, point is at the last line.  Since you have
>> scroll-margin set to 1, it scrolls up.  You can't see that because you have
>> no indication, but on a graphical terminal you can see that the scroll bar
>> has moved a bit.  Unfortunately there is no way to scroll the window, it is
>> either select something or C-g.  wid-edit.el tries to set a
>> scroll-other-window command, but it somehow fails to work because of the
>> default binding to keyboard-quit.  And in any case, IT only scrolls down,
>> not up.
>>
>> So, the menu created by wid-edit.el should either (or both)
>>
>> 1) place point somewhere else, preferrably at the end of the first line.
>> 2) provide a way to scroll the window. tmm-menubar does this so it can be
>> done.
>>
>> Someone familiar with wid-edit.el must look at this.
>>
>>    Jan D.
>>
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 2430 bytes --]

bug#5695: 23.1; wid-edit.el problems

[Jan Djärv]

Hi.

I have checked in a fix in the trunk that puts the cursor on the second line
instead of the last.  That way we at least prevent scrolling.  Problems 
remain, such as not being able to scroll the window.  However, most value 
menus are short, so this won't be needed in most cases.

	Jan D.

bug#5695: 23.1; wid-edit.el problems

[Jan Djärv]

Dani Moncayo skrev:
> 
> On Wed, Apr 7, 2010 at 3:01 PM, Jan Djärv <jan.h.d@swipnet.se 
> <mailto:jan.h.d@swipnet.se>> wrote:
> 
>     Hi.
> 
>     I have checked in a fix in the trunk that puts the cursor on the
>     second line
>     instead of the last.  That way we at least prevent scrolling.
>      Problems remain, such as not being able to scroll the window.
>      However, most value menus are short, so this won't be needed in
>     most cases.
> 
>            Jan D.
> 
> 
> 
> Thank you Jan.
> 
> As you've said, there are remaining problems, but the bug has been closed...
> 

Well, the bug as such (bad scrolling) is solved.

> Nobody else has said nothing about the idea of using here the same 
> procedure of "tmm-menubar" for selecting one option.
> 
> Don't you think it would be one suitable solution?

It can be but requires some work on tmm first (i.e. it hardcodes buffer to 
*Completions*, and strings like "Completions are:").

> Should we create another bug (feature-request) for this?
> 

Yes, please do so.

	Jan D.