January 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Didier Verna

Darryl Okahata <darrylo(a)sr.hp.com> wrote: > I also understand the opposing viewpoint (regarding viewports) ... > and I can see the reasoning behind it ... but I don't think that way. ;-) >=20 > If modeline dragging via the mouse is ever allowed, I think we'll > need a config variable to control the movement direction, because there > are too many people in either groups. (Me, I don't care what the > default is, as long as there's a way to change it.) OK. Since I also want it, I propose the following patch. The default behavior is *not* to scroll the modeline, and you have options to scroll it either way. I'm also working in adding scrollbar-like arrows at both ends. 2000-01-07 Didier Verna <didier(a)xemacs.org> * modeline.el (modeline-scrolling-method): new variable. (mouse-drag-modeline): add reference to it in the docstring. (mouse-drag-modeline): handle it. Index: lisp/modeline.el RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/modeline.el,v retrieving revision 1.18.2.3 diff -u -r1.18.2.3 modeline.el --- modeline.el 2000/01/04 08:50:58 1.18.2.3 +++ modeline.el 2000/01/07 12:59:23 ＠＠ -59,11 +59,26 ＠＠ :type 'boolean :group 'modeline) +(defcustom modeline-scrolling-method nil + "*If non-nil, dragging the modeline with the mouse may also scroll its +text horizontally (vertical motion controls window resizing and horizontal +motion controls modeline scrolling). + +With a value of t, the modeline text is scrolled in the same direction as +the mouse motion. With a value of 'scrollbar, the modeline is considered as +a scrollbar for its own text, which then moves in the opposite direction." + :type '(choice (const :tag "none" nil) + (const :tag "text" t) + (const :tag "scrollbar" 'scrollbar)) + :group 'modeline) + (defun mouse-drag-modeline (event) "Resize a window by dragging its modeline. This command should be bound to a button-press event in modeline-map. Holding down a mouse button and moving the mouse up and down will -make the clicked-on window taller or shorter." +make the clicked-on window taller or shorter. + +See also the variable `modeline-scrolling-method'." (interactive "e") (or (button-press-event-p event) (error "%s must be invoked by a mouse-press" this-command)) ＠＠ -79,6 +94,9 ＠＠ (start-event-frame (event-frame event)) (start-event-window (event-window event)) (start-nwindows (count-windows t)) + (hscroll-delta (face-width 'modeline)) + (start-hscroll (modeline-hscroll (event-window event))) + (start-x-pixel (event-x-pixel event)) (last-timestamp 0) default-line-height modeline-height ＠＠ -138,6 +156,9 ＠＠ ;; scroll) nore Y pos (modeline drag) have changed. (and modeline-click-swaps-buffers (=3D depress-line (event-y event)) + (or (not modeline-scrolling-method) + (=3D start-hscroll + (modeline-hscroll start-event-window))) (modeline-swap-buffers event))) ((button-event-p event) (setq done t)) ＠＠ -149,6 +170,14 ＠＠ drag-divider-event-lag) nil) (t + (when modeline-scrolling-method + (let ((delta (/ (- (event-x-pixel event) start-x-pixel) + hscroll-delta))) + (set-modeline-hscroll start-event-window + (if (eq modeline-scrolling-method t) + (- start-hscroll delta) + (+ start-hscroll delta))) + )) (setq last-timestamp (event-timestamp event) y (event-y-pixel event) edges (window-pixel-edges start-event-window) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

1 participants
0 comments

Re: XEmacs patches to custom.el 24 years, 3 months

Hrvoje Niksic

s/xemacs-review/xemacs-beta/ Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > > Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > > > > > (custom-declare-variable): Don't use `push'. > > [...] > > > (custom-declare-group): Use `setq' instead of `pop'. > > > > Why? > > To avoid loading the cl runtime in Emacs 21 (I'm not going to take > that fight), however Dave Love mentioned on the emacs-custom list > that pop and push are now in subr.el, so the change is unnecessary. OK. Most of the time, if you maintain the code, you get to make the rules. In XEmacs, it is perfectly fine to use the CL runtime. But if keeping the versions as close as possible makes your life easier, feel free to de-CL-ize the source. > > XEmacs does not have a problem with backquotes, and this change > > apparently makes the code less readable. > > I agree, and the issue might be void if the file is going to require > cl macros (defun*...) anyway. Before themes custom.el was a small > file which it made sense to put early in the bootstrap sequence. > I'll delay committing until I have heard back from Gerd. It still makes sense for custom.el to be loaded as early as possible, so that other files can use its features. I'm not sure how the bootstrap issues are handled, but Steve Baur (who worked on these things at the time) apparently solved them, for things seem to work.

1 participants
0 comments

[David Hedbor <david@hedbor.org>] Re: mailheader? 24 years, 3 months

Didier Verna

AFAIK, this has not been fixed for us right ? -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

1 participants
0 comments

Re: modeline hscroll 24 years, 3 months

Hrvoje Niksic

Didier Verna <didier(a)xemacs.org> writes: > - the team who sees it as dragging the modeline itself: moving the mouse left > shoud move the text left, > - the team who sees it as dragging the viewport, or giving the direction text > should appear (a la gv): moving the mouse left should move the text > right. The former (dragging the modeline) looks more natural to me, but neither view really satisfies me. The problem with the viewport idea is that viewports normally operate on other screen areas. Here the modeline would be a viewport for itself, which looks and feels weird. So I'd like to resurrect Kyle's proposal, which was: when modeline is too large to be displayed, simply draw an arrow at its right, and have clicking the arrow scroll the modeline by some amount. After the scrolling, a similar arrow on the left side could revert it. I don't see how the arrow thing could cause debates on scrolling direction. An arrow at the right pointing to the right should behave the same way as the one in the buffer when truncate-lines is non-nil.

3 participants
2 comments

[Q] [complex_]vars_of_... 24 years, 3 months

Didier Verna

Can somebody explain to me what is the difference between the functions `vars_of_fubar' and `complex_vars_of_fubar' ? Thanks. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

2 participants
1 comments

Re: Weird themes code in custom.el 24 years, 3 months

Per Abrahamsen

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > > > Ok. What really puzzled me was (is) that it apparently worked. > > Maybe the byte-compiler optimized it away? > > Quite possible. What puzzles me is that there are no warnings when > compiling that file. I thought the compiler was supposed to > bitch&warn on undeclared and unbound variables. Not if it has already optimized them away ;-)

1 participants
0 comments

Re: Weird themes code in custom.el 24 years, 3 months

Hrvoje Niksic

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > Ok. What really puzzled me was (is) that it apparently worked. > Maybe the byte-compiler optimized it away? Quite possible. What puzzles me is that there are no warnings when compiling that file. I thought the compiler was supposed to bitch&warn on undeclared and unbound variables.

1 participants
0 comments

Re: Weird themes code in custom.el 24 years, 3 months

Per Abrahamsen

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > > > What is the last line in the following code snip from custom.el > > supposed to mean? > > (while args * etc/custom/example-themes/example-theme.el: > > Garbage... It should just be '(while args'. I am not sure where this > came from (wetware error on my side?). Ok. What really puzzled me was (is) that it apparently worked. Maybe the byte-compiler optimized it away?

1 participants
0 comments

Re: Weird themes code in custom.el 24 years, 3 months

Jan Vroonhof

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > What is the last line in the following code snip from custom.el > supposed to mean? > (while args * etc/custom/example-themes/example-theme.el: Garbage... It should just be '(while args'. I am not sure where this came from (wetware error on my side?). Jan

1 participants
0 comments

Re: [XEmacs] signal vs. error 24 years, 3 months

Hrvoje Niksic

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > > > There is a lot of changes in customize like this: > > > > - (error "Keyword %s is missing an argument" keyword)) > > + (signal 'error (list "Keyword is missing an argument" keyword))) > > > > What is the purpose of that change? > > Providing actual arguments to errors is a good idea, especially in > low-level code. Code that traps the error can in that case get more > context about the error without the need to parse the error message > string. Most errors in XEmacs C code are signaled that way. Also, as Robert reminded me, errors signaled by `signal' are continuable. In XEmacs you can get the same thing by calling `cerror', but I preferred signals for reasons explained above.

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta January 2000