August 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: [bug] window-end breakage 24 years, 8 months

Hrvoje Niksic

Andy Piper <andy(a)xemacs.org> writes: > At 10:23 PM 8/29/99 +0200, Hrvoje Niksic wrote: > >Try this: visit a largish file, and evaluate: > > (progn > > (goto-char (point-max)) > > (window-start)) > > > >It returns 1 for me. To make it right, I need this: > > (progn > > (goto-char (point-max)) > > (sit-for 0) > > (window-start)) > > > >...but the forced redisplay slows things down and potentially makes > >them uglier. > > The problem is you have to calculate display lines to get this sort of > result, cf current-pixel-column. Do you mean that `window-start' is in this regard different than `window-end'?

1 participants
0 comments

Re: [bug] window-end breakage 24 years, 8 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > How can you know that? I need it for isearch, which is bound to one > > window. > > Have you tried this? When I open two windows viewing the buffer the > isearch highlighting occurs in both windows. The highlighting is there, but isearch itself always happens in one window. If you try to change the window (or frame or buffer or anything), isearch is done. That's how it's been for ages. For some time I considered "correctly" handling this case by highlighting all visible regions in all windows, but I rejected the idea because it would be too much work for practically no gain. When the isearch is in progress, we tend to look at the window where it happens. When the isearch ends, so does the highlighting. > > Your needs (lazy-shot) are quite different, and harder to meet. > > For me, window-start and window-end really do provide what I want. > > The reason for that is that when you are in isearch you more or less > control the event loop. However I think this a very special > situation. It is; that's why window-end suits me and that's why I reported a bug. > A situation that is also handled by lazy-shot style handling; > Wouldn't love to simply be able to say > > (do-on-demand 'isearch-highlight-other-matches-in-region) > > and have the rest be done for you? Yes, it would be nice, but it's hard to do right. Ideally, you'd want the code to be called after the redisplay has calculated what needs to be done, but before it is actually done. But your code could change the screen layout and thus invalidate the previous calculation. This would require a recalculation, leading to your code being reinvoked, etc. It's very easy to infloop there. You can either do what I do and change things on your own risk, or do what lazy shot does, and enjoy the flicker. For isearch, the two approaches amount to (almost) the same thing, and I believe mine is simpler. Oh, and note that even in the case of isearch the `do-on-demand' code might prove deficient. For the highlighting to be meaningful in all cases, it requires an anchoring point, normally provided by the location of point in isearch. If you just try to find matches beginning with a random point, your code will suffer from the "banana phenomenon"; see my article on comp.editors for details. But none of it is really relevant. Philosophical discussions are nice, but I only really wanted to draw attention to a bug in window-end. > > > I think the non-GUARANTEE values is wrong. > > > > This may be so. However, it's exactly the value I need, > > Why do you care about lines? I do not understand the question. > > You think wrong. > > > > Try this: visit a largish file, and evaluate: > > (progn > > (goto-char (point-max)) > > (window-start)) > > OK, but this isn't really the same problem. Huh? It is quite obvious that lack of redisplay causes window-start to return the wrong value. If my understanding is correct, the GUARANTEE argument was invented *exactly* for that purpose -- to get the correct value without forcing a redisplay. Bugs notwithstanding, it is very strange that window-end is provided a GUARANTEE argument, while window-start is not. > You do not really want to force a redisplay, you want to force the > code that makes sure point always stays visible to be run. That code is buried deep in redisplay. I don't think you can just "force it to be run" without also triggering redisplay. Or, do you mean that the redisplay code should be run, while the redisplay *output* should be suppressed?

1 participants
0 comments

Re: [bug] window-end breakage 24 years, 8 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > completely hosed? (`window-end' is extremely useful when you want > > to operate on the visible portion of the window, for whatever > > reason.) > > Personally I think that is generally the wrong way to do this. ? How can you know that? I need it for isearch, which is bound to one window. Your needs (lazy-shot) are quite different, and harder to meet. For me, window-start and window-end really do provide what I want. Lazy shot is a nice idea, but very hard to implement correctly. > > I don't know which of the two is more correct, but I really think > > they should not differ. > > I think the non-GUARANTEE values is wrong. This may be so. However, it's exactly the value I need, and it seems to be consistent with how the rest of XEmacs works, except for the (1+ (point-max)) thing. > > * `window-start' doesn't have a GUARANTEE argument. What use is it to > > be able to find window's end position without forcing a redraw > > without being able to do the same for its start position? > > Because I think the window-start value is always GUARANTEEd. You think wrong. Try this: visit a largish file, and evaluate: (progn (goto-char (point-max)) (window-start)) It returns 1 for me. To make it right, I need this: (progn (goto-char (point-max)) (sit-for 0) (window-start)) ...but the forced redisplay slows things down and potentially makes them uglier.

2 participants
1 comments

Re: The new equivalent of x-get-clipboard? 24 years, 8 months

Hrvoje Niksic

Andy Piper <andy(a)xemacs.org> writes: > At 09:09 PM 8/29/99 +0200, Hrvoje Niksic wrote: > >I noticed a warning in isearch-mode.el, and it lead me to the code > >that uses the old, x-specific, functions. It is easy enough to change > >`x-get-selection' to `get-selection', but what is the equivalent of > >`x-get-clipboard'? Hyper-apropos doesn't seem to yield anything > >usable. > > Hmmn. Well there is x-get-clipboard and mswindows-get-clipboard and > both are different. Maybe some more rationalisation is in order.... I guess we could simply invent a `get-clipboard', and obsolete the old functions.

2 participants
1 comments

Re: [Stainless Steel Rat <ratinox@peorth.gweep.net>] Re: Emacs 20.4 & Pterodactyl & pop3.el 24 years, 8 months

Jan Vroonhof

Andy Piper <andy(a)xemacs.org> writes: > >I find this situation quite embarrassing. Why hasn't the maintainer > >of pop3.el (Rich Pieri) been informed of our changes? > > He has, That changes the matter completely. > I haven't changed the name because its the same package with the same > (extended) functionality and there is precendence for doing this in > XEmacs. I agree with you on this one, see my comments on the ding list. I think that this is necessary is a flaw in elisp but it is not easy to change. Jan

1 participants
0 comments

Re: The gutter thing 24 years, 8 months

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > Andy Piper <andyp(a)san-jose.beasys.com> writes: >> At 05:12 PM 8/27/99 +0200, Hrvoje Niksic wrote: >> >I'm compiling from the latest 21.2 CVS, and I don't see them. That's >> >what made me ask the question in the first place. >> >> You should get them automatically if you built from cvs. > I do build from CVS, but I don't get them automatically. >> Please send me your build configuration. config.h should define >> HAVE_WIDGETS and LWLIB_TABS_LUCID. > HAVE_WIDGETS is not #defined for me. But the fact is, I've always > just typed `make' after the CVS updates. Maybe I should start a > configure;make from scratch? Always rerun configure if you are trying to rebuild from scratch. At a minimum you need to do `cvs update; ./config.status --recheck; make'. The tab thingies should be automatic if you are building properly.

3 participants
3 comments

Re: [bug] window-end breakage 24 years, 8 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > How can you know that? I need it for isearch, which is bound to one > window. Have you tried this? When I open two windows viewing the buffer the isearch highlighting occurs in both windows. Maybe that is wrong. > Your needs (lazy-shot) are quite different, and harder to > meet. For me, window-start and window-end really do provide what I > want. The reason for that is that when you are in isearch you more or less control the event loop. However I think this a very special situation. A situation that is also handled by lazy-shot style handling; Wouldn't love to simply be able to say (do-on-demand 'isearch-highlight-other-matches-in-region) and have the rest be done for you? Do you handle font changes, window resizing etc? You are basically trying to reinvent lazy-lock v1 for your special case. Maybe the problems don't hurt you that much in the special case but it still has a "wrongish" feel to me.. > > I think the non-GUARANTEE values is wrong. > > This may be so. However, it's exactly the value I need, Why do you care about lines? > You think wrong. > > Try this: visit a largish file, and evaluate: > (progn > (goto-char (point-max)) > (window-start)) OK, but this isn't really the same problem. You do not really want to force a redisplay, you want to force the code that makes sure point always stays visible to be run. You have a point in that might be a good thing to add in a `guarantee' argument for site-start. Jan

1 participants
0 comments

[bug] window-end breakage 24 years, 8 months

Hrvoje Niksic

Has anyone noticed that `window-end' and `window-start' are almost completely hosed? (`window-end' is extremely useful when you want to operate on the visible portion of the window, for whatever reason.) Specifically: * (window-end) at the end of buffer returns (1+ (point-max)), which breaks any code that tries to use it sensibly. I now use (min (window-end) (point-max)). * The GUARANTEE argument makes it return a different value. Specifically, (window-end) returns the start position of the line after the clipped (bottom-most) line. OTOH, (window-end nil t) returns the end position of the end of the line *before* the clipped (bottom-most) line. I don't know which of the two is more correct, but I really think they should not differ. * `window-start' doesn't have a GUARANTEE argument. What use is it to be able to find window's end position without forcing a redraw without being able to do the same for its start position? I would really appreciate some help by the redisplay gurus.

2 participants
1 comments

[Stainless Steel Rat <ratinox@peorth.gweep.net>] Re: Emacs 20.4 & Pterodactyl & pop3.el 24 years, 8 months

Hrvoje Niksic

I find this situation quite embarrassing. Why hasn't the maintainer of pop3.el (Rich Pieri) been informed of our changes?

2 participants
1 comments

The new equivalent of x-get-clipboard? 24 years, 8 months

Hrvoje Niksic

I noticed a warning in isearch-mode.el, and it lead me to the code that uses the old, x-specific, functions. It is easy enough to change `x-get-selection' to `get-selection', but what is the equivalent of `x-get-clipboard'? Hyper-apropos doesn't seem to yield anything usable. Andy?

2 participants
1 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 August 1999