Re: [EMAIL PROTECTED]: Overlay string not displayed on text with `display' property]
> On Sun, 11 Jun 2006 12:06:51 +0200, [EMAIL PROTECTED] (Kim F. Storm) said: > There may be _some_ overlay properties where it could make sense, > e.g. before-string and after-string, but doing a lot of work just to > make those work is not worth the trouble IMO. So I think we should > simply document the current behaviour. I agree with you about not making nontrivial changes before the release. But I don't think that it is not worth the trouble in the long term. First, images are usually displayed using the `display' property, and overlay strings are not shown before them. Second, the `composition' property shows the similar behavior as I mentioned in http://lists.gnu.org/archive/html/emacs-devel/2006-06/msg00119.html. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: startup frame position
> From: Ralf Angeli <[EMAIL PROTECTED]> > Date: Sun, 11 Jun 2006 23:51:02 +0200 > > I suspect that `x_set_offset' is called somewhere with values of 0 > for both offsets Correct. > but I could not find the respective call. You could find that call with a debugger, by setting a breakpoint in x_set_offset. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: startup frame position
* Stephan Hennig (2006-05-24) writes: > Emacs' frame appears in the top left corner of the screen. On Windows OS > this is ok when the OS's symbol panel (Symbolleiste) is located at the > bottom of the screen. If the symbol panel is located at the top of the > screen part of Emacs' frame -- the title panel (Titelleiste) -- gets > hidden behind the symbol panel so that you can't grab and move the frame > on the desktop. FWIW, I find it at least annoying that Emacs under Windows always creates frames in the top left corner. I managed to let Windows position new frames by modifying the calls to `CreateWindow' and `ShowWindow' in `w32_createwindow'. For the `CreateWindow' call I used `CW_USEDEFAULT' instead of `f->left_pos' as third argument and `SW_SHOW' instead of `f->top_pos' as fourth argument. For the `ShowWindow' call I used `SW_SHOW' instead of `SW_HIDE' as second argument. Unfortunately newly created frames don't stay at the position they are created at but instantly move to the top left corner. I could not find out where this happens. I suspect that `x_set_offset' is called somewhere with values of 0 for both offsets, but I could not find the respective call. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [PATCH] Re: redisplay-dont-pause is not mentioned in the Emacs manual
Richard Stallman <[EMAIL PROTECTED]> writes:
> > And how do you decide how fast a remote connection is, nowadays?
>
> Fast! And getting faster!!
>
> That is not always true. I had to use a modem connection twice this
> weekend. Even without dialup involved, international connections can
> be slow.
>
> > We could just treat all terminals as fast unless the user specifies
> > a slower speed.
>
> That's basically what my patch does.
>
> To make that acceptable, we would need to do a lot more to inform
> users of what to do when the connection is not so fast.
>
> Ideally we would tell them to run stty, so that it will affect
> all Emacs sessions during one login session.
>
> The Linux console seems to say its speed is 38400 baud. That is
> rather misleading, since even a typical modem is faster than that.
Here's an idea: adapt to the redisplay performance on the fly...
This could be done by checking for input every 0.10 seconds during
window redisplay (rather than every N lines).
This means that if redisplay is fast enough to complete within 0.10
seconds, it doesn't pre-empt.
This also means that there basically isn't anything for the user to
modify -- expect perhaps an option to choose the pre-emption
delay (default 0.10 seconds).
Here is a patch -- unfortunately, I don't have a slow connection that can
really prove this makes a difference
*** dispnew.c 04 Jun 2006 20:58:14 +0200 1.366
--- dispnew.c 11 Jun 2006 23:43:55 +0200
***
*** 192,197
--- 192,210
int redisplay_dont_pause;
+ #ifdef EMACS_HAS_USECS
+
+ /* If a number (float), check for user input every N seconds. */
+
+ Lisp_Object Vredisplay_preemption_period;
+
+ /* Redisplay preemption timers. */
+
+ static EMACS_TIME preemption_period;
+ static EMACS_TIME preemption_next_check;
+
+ #endif
+
/* Nonzero upon entry to redisplay means do not assume anything about
current contents of actual terminal frame; clear and redraw it. */
***
*** 3820,3825
--- 3833,3854
int paused_p;
struct window *root_window = XWINDOW (f->root_window);
+ #ifdef EMACS_HAS_USECS
+ if (!force_p && NUMBERP (Vredisplay_preemption_period))
+ {
+ EMACS_TIME tm;
+ double p = XFLOATINT (Vredisplay_preemption_period);
+ int sec, usec;
+
+ sec = (int) p;
+ usec = (p - sec) * 100;
+
+ EMACS_GET_TIME (tm);
+ EMACS_SET_SECS_USECS (preemption_period, sec, usec);
+ EMACS_ADD_TIME (preemption_next_check, tm, preemption_period);
+ }
+ #endif
+
if (FRAME_WINDOW_P (f))
{
/* We are working on window matrix basis. All windows whose
***
*** 3952,3957
--- 3981,4002
/* Record that this is not a frame-based redisplay. */
set_frame_matrix_frame (NULL);
+ #ifdef EMACS_HAS_USECS
+ if (!force_p && NUMBERP (Vredisplay_preemption_period))
+ {
+ EMACS_TIME tm;
+ double p = XFLOATINT (Vredisplay_preemption_period);
+ int sec, usec;
+
+ sec = (int) p;
+ usec = (p - sec) * 100;
+
+ EMACS_GET_TIME (tm);
+ EMACS_SET_SECS_USECS (preemption_period, sec, usec);
+ EMACS_ADD_TIME (preemption_next_check, tm, preemption_period);
+ }
+ #endif
+
/* Update W. */
update_begin (f);
update_window (w, force_p);
***
*** 4107,4113
--- 4152,4160
{
struct glyph_matrix *desired_matrix = w->desired_matrix;
int paused_p;
+ #ifndef EMACS_HAS_USECS
int preempt_count = baud_rate / 2400 + 1;
+ #endif
extern int input_pending;
extern Lisp_Object do_mouse_tracking;
#if GLYPH_DEBUG
***
*** 4117,4126
#endif
/* Check pending input the first time so that we can quickly return. */
! if (redisplay_dont_pause)
force_p = 1;
! else
detect_input_pending_ignore_squeezables ();
/* If forced to complete the update, or if no input is pending, do
the update. */
--- 4164,4175
#endif
/* Check pending input the first time so that we can quickly return. */
! if (redisplay_dont_pause || NILP (Vredisplay_preemption_period))
force_p = 1;
! #ifndef EMACS_HAS_USECS
! else if (!force_p)
detect_input_pending_ignore_squeezables ();
+ #endif
/* If forced to complete the update, or if no input is pending, do
the update. */
***
*** 4192,4200
detect_input_pending. If it's done too often,
scrolling large windows with repeated scroll-up
commands will too quickly pause redisplay. */
if (!force_p && ++n_updated % preempt_count == 0)
detect_input_pending_ignore_squeezables ();
!
changed_p |= update_window_line (w, vpos,
&mouse_face_overwritten_p);
--- 4241,4262
detect_input_pending. If it's done
Re: [EMAIL PROTECTED]: Overlay string not displayed on text with `display' property]
There may be _some_ overlay properties where it could make sense, e.g. before-string and after-string, but doing a lot of work just to make those work is not worth the trouble IMO. So I think we should simply document the current behaviour. Ok. Would you please do that? Don't worry about writing style; I'll take care of polishing it up. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [PATCH] Re: redisplay-dont-pause is not mentioned in the Emacs manual
> And how do you decide how fast a remote connection is, nowadays? Fast! And getting faster!! That is not always true. I had to use a modem connection twice this weekend. Even without dialup involved, international connections can be slow. > We could just treat all terminals as fast unless the user specifies > a slower speed. That's basically what my patch does. To make that acceptable, we would need to do a lot more to inform users of what to do when the connection is not so fast. Ideally we would tell them to run stty, so that it will affect all Emacs sessions during one login session. The Linux console seems to say its speed is 38400 baud. That is rather misleading, since even a typical modem is faster than that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: Overlay string not displayed on text with `display' property]
[EMAIL PROTECTED] (Kim F. Storm) writes: > Richard Stallman <[EMAIL PROTECTED]> writes: > >> Would you please DTRT and ack? > > I have tried to find a simple way to fix this (assuming it is a bug), > but it is non-trivial to fix. > > OTOH, it may not be a bug at all -- if we accept that overlays at invisible > buffer positions (e.g. if replaced by a display string), are ignored. Thinking more about the implications of mixing overlay properties and display string properties at the same buffer position, I've mostly convinced myself that the current behaviour is ok, i.e. that we _must_ ignore overlays at buffer positions "hidden by" a display string. IMO, the semantics of mixing overlays and display strings (that may also have properties) is too unclear to be of any real use -- and a big headache to get right. There may be _some_ overlay properties where it could make sense, e.g. before-string and after-string, but doing a lot of work just to make those work is not worth the trouble IMO. So I think we should simply document the current behaviour. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: vertical-motion fails when tab in line
* David Reitter (2006-06-11) writes: > To reproduce, take a scratch buffer, enter a few lines of text wich > will be wrapped and contain one (or more?) tabs. Place cursor near > the end of a wrapped line, but not too far towards the end, and call > M-: (vertical-motion 1). > > Tried this in Aquamacs (based on very recent GNU CVS) and as well > with a vanilla CVS build (Carbon port on OS X) with a fixed-width font. Unreproducible with emacs -Q -eval '(progn (insert "\t" (make-string 50 ?x) "\t" (make-string 50 ?x)) (goto-char 85) (vertical-motion 1))' and a build from today: In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.8.16) of 2006-06-11 on neutrino X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--with-gtk'' Assuming a window width of 80 characters and a fixed-width font (-Bitstream-Terminal-Medium-R-Normal--18-140-100-100-C-110-ISO8859-1 to be precise). After executing the command above, point will be at the end of the line. -- Ralf ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ange-ftp and local file names with spaces - failure
This is a bug on w32. I have not seen any answer to the message below. When I last tested I was using GNU Emacs 22.0.50.1 (i386-mingw-nt5.0.2195) of 2006-05-01. http://lists.gnu.org/archive/html/emacs-devel/2006-05/msg01433.html ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
