all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* display question: should ^N and \NNN widths be fixed?
@ 2002-05-23 21:16 Thien-Thi Nguyen
  2002-05-24 21:14 ` Richard Stallman
  0 siblings, 1 reply; 18+ messages in thread
From: Thien-Thi Nguyen @ 2002-05-23 21:16 UTC (permalink / raw)


in src/indent.c `current_column', ^N and \NNN are presently hard coded
as taking 2 and 4 columns, respectively.  i'd like to propose that these
always be displayed in a fixed-width font, to avoid having to compute
their display widths.  this is not a big deal for ^N, but to compute
width of \NNN efficiently could mean another cache.

from user perspective, it seems to me ^N or \NNN as fixed width makes
reading them easier.

thi

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-23 21:16 display question: should ^N and \NNN widths be fixed? Thien-Thi Nguyen
@ 2002-05-24 21:14 ` Richard Stallman
  2002-05-24 23:20   ` Thien-Thi Nguyen
  0 siblings, 1 reply; 18+ messages in thread
From: Richard Stallman @ 2002-05-24 21:14 UTC (permalink / raw)
  Cc: emacs-devel

    in src/indent.c `current_column', ^N and \NNN are presently hard coded
    as taking 2 and 4 columns, respectively.

Currently the functions in indent.c don't handle variable width fonts at all.
Extending them to do so is an important project.  When that is done, I expect
it won't be too hard to handle these two cases also.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-24 21:14 ` Richard Stallman
@ 2002-05-24 23:20   ` Thien-Thi Nguyen
  2002-05-24 23:34     ` Thien-Thi Nguyen
                       ` (3 more replies)
  0 siblings, 4 replies; 18+ messages in thread
From: Thien-Thi Nguyen @ 2002-05-24 23:20 UTC (permalink / raw)
  Cc: emacs-devel

   From: Richard Stallman <rms@gnu.org>
   Date: Fri, 24 May 2002 15:14:02 -0600 (MDT)

   Currently the functions in indent.c don't handle variable width fonts at all.
   Extending them to do so is an important project.  When that is done, I expect
   it won't be too hard to handle these two cases also.

ok.  here's my proposal for doing this -- i hope everyone picks it apart
and/or lends expertise to fill the gaps so that emacs can have the best
variable-width font support possible:

 - establish iso-type contour
   + make indent.c C column vars float
   + make callers of indent.c C functions cast retval to int
   + make indent.c C getter functions compute and return float
   - make callers of indent.c C functions cast args to float
   - make indent.c C setter functions accept floats
 - selectively expand contour to propagate float usage
   - determine criteria for propagation
   - determine which funcs/vars fit that criteria (maybe all?)
   - do the changes where needed
     - remove casts
     - fix resulting breakage
 - introduce font sensitivity in column computations
   - unify current_column / current_column_1 / string_display_width
   - consult font text-property		<-- potential race condition?
   - (re-)optimize common cases
     - [maybe] extend width-run cache facilities
     - [maybe] do other caching

some of these (sub)tasks can (and probably should) be done concurrently.
that's not noted here explicitly, but should be easy enough to figure
out for anyone who wants to join in.

logistical questions: is it ok to make a branch in cvs?  what should it
be named?  where can we check in this kind of info for future reference?
is it ok to check in the above in etc/TODO?  if no, then where?  (IMHO,
digging through spam-ridden mailing list archives is neither fun nor
effective.)

thi

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-24 23:20   ` Thien-Thi Nguyen
@ 2002-05-24 23:34     ` Thien-Thi Nguyen
  2002-05-25  1:44     ` Miles Bader
                       ` (2 subsequent siblings)
  3 siblings, 0 replies; 18+ messages in thread
From: Thien-Thi Nguyen @ 2002-05-24 23:34 UTC (permalink / raw)


   From: Thien-Thi Nguyen <ttn@giblet.glug.org>
   Date: Fri, 24 May 2002 16:20:39 -0700

   (IMHO, digging through spam-ridden mailing list archives is neither
   fun nor effective.)

although it looks like the amount of spam varies wildly depending on the
archive.  emacs-devel seems to be quite clean, actually...

thi

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-24 23:20   ` Thien-Thi Nguyen
  2002-05-24 23:34     ` Thien-Thi Nguyen
@ 2002-05-25  1:44     ` Miles Bader
  2002-05-25  2:39       ` Thien-Thi Nguyen
  2002-05-26  4:28     ` Richard Stallman
  2002-05-26  5:09     ` Eli Zaretskii
  3 siblings, 1 reply; 18+ messages in thread
From: Miles Bader @ 2002-05-25  1:44 UTC (permalink / raw)
  Cc: rms, emacs-devel

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:
>  - establish iso-type contour

What is an `iso-type contour'?

> logistical questions: is it ok to make a branch in cvs?

It's probably not necessary.

In general, it's better to make changes in smaller incremental steps
that can be merged into main-line CVS.  You already seem to be thinking
that way.

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-25  1:44     ` Miles Bader
@ 2002-05-25  2:39       ` Thien-Thi Nguyen
  2002-05-25  2:57         ` Miles Bader
                           ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: Thien-Thi Nguyen @ 2002-05-25  2:39 UTC (permalink / raw)
  Cc: rms, emacs-devel

   From: Miles Bader <miles@gnu.org>
   Date: 25 May 2002 10:44:05 +0900

   What is an `iso-type contour'?

this is a term i pulled out the air (perhaps better expressed as
"functional iso-contour"? -- the math heads can jump in here) to
describe a method for identifying what is it that stays the same and
what changes, when using an incremental approach.  iso-contours on
"relief" maps typically keep the altitutde the same while varying the
location.  here, we want to keep the functionality the same (not break
anything) while varying the type.

this allows us to consider adding functionality as an independent task
(so that people who are more comfortable designing/modifying those
next-higher-level algorithms can take a whack at it instead of me :-).
adding functionality can also be done incrementally, in the tradition of
emacs development.

perhaps someone can supply better terminology or metaphor...

does this make sense?

   In general, it's better to make changes in smaller incremental steps
   that can be merged into main-line CVS.  You already seem to be
   thinking that way.

yes, lacking a test suite (which is perhaps untenable for emacs), small
incremental approach is a necessity.  so, i'll post uuencoded diffs for
review, initially, to get feedback and thumbs up from rms.

in the meantime, i hope to find answers to the other logistical
questions.  this command:

  cvs co -d emacs-CVSROOT CVSROOT

reveals emacs-CVSROOT/modules has nothing in it.  anyone mind if i
create a cvs module "notes" (sibling to cvs module "emacs")?  absent
other better places, i would use this to keep notes, detailed TODO (for
this particular initiative), etc.

thi

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-25  2:39       ` Thien-Thi Nguyen
@ 2002-05-25  2:57         ` Miles Bader
  2002-05-26  5:03           ` Eli Zaretskii
  2002-05-25  3:05         ` Miles Bader
  2002-05-25  3:05         ` Miles Bader
  2 siblings, 1 reply; 18+ messages in thread
From: Miles Bader @ 2002-05-25  2:57 UTC (permalink / raw)
  Cc: rms, emacs-devel

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:
> anyone mind if i create a cvs module "notes" (sibling to cvs module
> "emacs")?  absent other better places, i would use this to keep notes,
> detailed TODO (for this particular initiative), etc.

Why not just make a subdirectory called `notes' in the main emacs
module?  I suspect that any notes you add wouldn't be large enough to
cause a problem.  Note that there's already an `admin' directory in CVS
that isn't distributed with emacs tarballs.

-Miles
-- 
"1971 pickup truck; will trade for guns"

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-25  2:39       ` Thien-Thi Nguyen
  2002-05-25  2:57         ` Miles Bader
  2002-05-25  3:05         ` Miles Bader
@ 2002-05-25  3:05         ` Miles Bader
  2002-05-25 22:53           ` Thien-Thi Nguyen
  2 siblings, 1 reply; 18+ messages in thread
From: Miles Bader @ 2002-05-25  3:05 UTC (permalink / raw)
  Cc: rms, emacs-devel

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:
> so, i'll post uuencoded diffs for
> review, initially, to get feedback and thumbs up from rms.

Incidentally, it's a big pain to read uuencoded stuff.  Why not just
post the diffs themselves?

-miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-25  2:39       ` Thien-Thi Nguyen
  2002-05-25  2:57         ` Miles Bader
@ 2002-05-25  3:05         ` Miles Bader
  2002-05-25  3:05         ` Miles Bader
  2 siblings, 0 replies; 18+ messages in thread
From: Miles Bader @ 2002-05-25  3:05 UTC (permalink / raw)
  Cc: rms, emacs-devel

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:
> so, i'll post uuencoded diffs for
> review, initially, to get feedback and thumbs up from rms.

Incidentally, it's a big pain to read uuencoded stuff.  Why not just
post the diffs themselves?

-miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-25  3:05         ` Miles Bader
@ 2002-05-25 22:53           ` Thien-Thi Nguyen
  0 siblings, 0 replies; 18+ messages in thread
From: Thien-Thi Nguyen @ 2002-05-25 22:53 UTC (permalink / raw)
  Cc: rms, emacs-devel

Miles Bader <miles@gnu.org> writes:

   Incidentally, it's a big pain to read uuencoded stuff.  Why not just
   post the diffs themselves?

ok.  i guess uu approach is from old days (when mail readers were prone to
mangle diffs).  that's not an issue if the diff is to be read only (and not
applied).

thi

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-24 23:20   ` Thien-Thi Nguyen
  2002-05-24 23:34     ` Thien-Thi Nguyen
  2002-05-25  1:44     ` Miles Bader
@ 2002-05-26  4:28     ` Richard Stallman
  2002-05-27  6:44       ` Thien-Thi Nguyen
  2002-05-26  5:09     ` Eli Zaretskii
  3 siblings, 1 reply; 18+ messages in thread
From: Richard Stallman @ 2002-05-26  4:28 UTC (permalink / raw)
  Cc: emacs-devel

       + make indent.c C column vars float
       + make callers of indent.c C functions cast retval to int
       + make indent.c C getter functions compute and return float
       - make callers of indent.c C functions cast args to float
       - make indent.c C setter functions accept floats

This seems like the right first step.

     - selectively expand contour to propagate float usage
       - determine criteria for propagation
       - determine which funcs/vars fit that criteria (maybe all?)
       - do the changes where needed
	 - remove casts
	 - fix resulting breakage

That seems reasonable too.

     - introduce font sensitivity in column computations
       - unify current_column / current_column_1 / string_display_width
       - consult font text-property		<-- potential race condition?

This code is all serial; it can't have race conditions.  Why did you
think there was one?  Perhaps that is a misunderstanding that is worth
identifying so we can clear it up now.

    logistical questions: is it ok to make a branch in cvs?  what should it
    be named?

Yes.  It could be called float-indent.  Eli can help you set it up.

    is it ok to check in the above in etc/TODO?

There is no need.  You know it.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-25  2:57         ` Miles Bader
@ 2002-05-26  5:03           ` Eli Zaretskii
  2002-05-26  5:11             ` Thien-Thi Nguyen
  0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2002-05-26  5:03 UTC (permalink / raw)
  Cc: ttn, rms, emacs-devel


On 25 May 2002, Miles Bader wrote:

> Why not just make a subdirectory called `notes' in the main emacs
> module?

I'd suggest to make that a subdirectory of `admin'.  Any additional 
directory that is not distributed with the tarball needs attention at 
make-dist time, to make sure it doesn't end up in the tarball.  So I'd 
like to avoid adding more top-level directories like that.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-24 23:20   ` Thien-Thi Nguyen
                       ` (2 preceding siblings ...)
  2002-05-26  4:28     ` Richard Stallman
@ 2002-05-26  5:09     ` Eli Zaretskii
  2002-05-27  6:48       ` Thien-Thi Nguyen
  3 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2002-05-26  5:09 UTC (permalink / raw)
  Cc: rms, emacs-devel


On Fri, 24 May 2002, Thien-Thi Nguyen wrote:

> some of these (sub)tasks can (and probably should) be done concurrently.
> that's not noted here explicitly, but should be easy enough to figure
> out for anyone who wants to join in.

I have one (rather vague and potentially unhelpful ;-) comment: when you 
work on this, please keep in mind that some day Emacs will support 
bidirectional display (for languages that are written right to left), 
where advancing by screen position does not necessarily mean you advance 
by buffer position as well.  That is, if glyph G1 is displayed before 
glyph G2, it does not necessarily mean that the buffer position of the 
character displayed as G1 is before that of G2.

The current code in indent.c assumes that buffer positions increase 
monotonically with screen positions.  I'm not saying that you should do 
my job of lifting that limitation, but please keep this in mind when you 
design and code the new indent.c, so that changing it for bidi Emacs 
would not be harder than it is today.

> logistical questions: is it ok to make a branch in cvs?

I agree with Miles that it is best not to make a branch at all, but 
install your changes in parts, so that each part could be tested without 
breaking the main trunk.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-26  5:03           ` Eli Zaretskii
@ 2002-05-26  5:11             ` Thien-Thi Nguyen
  0 siblings, 0 replies; 18+ messages in thread
From: Thien-Thi Nguyen @ 2002-05-26  5:11 UTC (permalink / raw)
  Cc: miles, rms, emacs-devel

   From: Eli Zaretskii <eliz@is.elta.co.il>
   Date: Sun, 26 May 2002 08:03:00 +0300 (IDT)

   I'd suggest to make that a subdirectory of `admin'.  Any additional 
   directory that is not distributed with the tarball needs attention at 
   make-dist time, to make sure it doesn't end up in the tarball.  So I'd 
   like to avoid adding more top-level directories like that.

looks like i moved too fast.  i will delete the just recently added
top-level notes/ (luckily still empty) and create admin/notes/.

thi

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-26  4:28     ` Richard Stallman
@ 2002-05-27  6:44       ` Thien-Thi Nguyen
  2002-05-28  5:15         ` Richard Stallman
  0 siblings, 1 reply; 18+ messages in thread
From: Thien-Thi Nguyen @ 2002-05-27  6:44 UTC (permalink / raw)
  Cc: emacs-devel

Richard Stallman <rms@gnu.org> writes:

	  - consult font text-property		<-- potential race condition?

   This code is all serial; it can't have race conditions.  Why did you
   think there was one?  Perhaps that is a misunderstanding that is worth
   identifying so we can clear it up now.

i know emacs separates the display into its own thread.  the emacs display is
customizable w/ elisp that may eventually lead back to calling current-column.
not knowing the details for text-property access from C, i imagine some lock
that must be manipulated in precise order.  this is because i haven't read
that part of emacs, foolishly trusting my instincts to cover for my ignorance.

in any case, when retooling caching schemes, there is always a possibility of
offloading the task to another thread.  (sometimes i like to think of things
w/ parallel operation in mind, even if not needed immediately -- headed for
that emacs uproc, you know. ;-)

thi

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-26  5:09     ` Eli Zaretskii
@ 2002-05-27  6:48       ` Thien-Thi Nguyen
  2002-05-27  7:33         ` Eli Zaretskii
  0 siblings, 1 reply; 18+ messages in thread
From: Thien-Thi Nguyen @ 2002-05-27  6:48 UTC (permalink / raw)
  Cc: rms, emacs-devel

Eli Zaretskii <eliz@is.elta.co.il> writes:

   Emacs will support bidirectional display [...]

   The current code in indent.c assumes that buffer positions increase 
   monotonically with screen positions.  I'm not saying that you should do 
   my job of lifting that limitation, but please keep this in mind when you 
   design and code the new indent.c, so that changing it for bidi Emacs 
   would not be harder than it is today.

what makes it difficult to support this lifting, today?  what makes supporting
that lifting difficult in general?

thi

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-27  6:48       ` Thien-Thi Nguyen
@ 2002-05-27  7:33         ` Eli Zaretskii
  0 siblings, 0 replies; 18+ messages in thread
From: Eli Zaretskii @ 2002-05-27  7:33 UTC (permalink / raw)
  Cc: emacs-devel


On 27 May 2002, Thien-Thi Nguyen wrote:

>    The current code in indent.c assumes that buffer positions increase 
>    monotonically with screen positions.  I'm not saying that you should do 
>    my job of lifting that limitation, but please keep this in mind when you 
>    design and code the new indent.c, so that changing it for bidi Emacs 
>    would not be harder than it is today.
> 
> what makes it difficult to support this lifting, today?

Just a lot of coding ;-)

The problem is that with bidi display, the relationship between buffer 
positions and screen positions is no longer a simple monotonically 
increasing function.  For example, if the buffer's contents is this:

	abcABCdef

where upper-case letters stand for right-to-left characters, then it is 
displayed as

	abcCBAdef

and thus you cannot simply walk the buffer one character at a time and 
add their display widths to compute the display column.  For example, the 
column of C is 3 (zero-based), not 5.

Again, I'm not saying you should solve this problem when you work on your 
changes.  I'm just asking to keep this at the back of your mind when you 
make design decisions.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: display question: should ^N and \NNN widths be fixed?
  2002-05-27  6:44       ` Thien-Thi Nguyen
@ 2002-05-28  5:15         ` Richard Stallman
  0 siblings, 0 replies; 18+ messages in thread
From: Richard Stallman @ 2002-05-28  5:15 UTC (permalink / raw)
  Cc: emacs-devel

    i know emacs separates the display into its own thread.

No, Emacs does not have multiple threads.
Everything is synchronous.  Anyway, those functions
are reentrant.  In order to use them, you create your own
iterator object and pass it to them.

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2002-05-28  5:15 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-05-23 21:16 display question: should ^N and \NNN widths be fixed? Thien-Thi Nguyen
2002-05-24 21:14 ` Richard Stallman
2002-05-24 23:20   ` Thien-Thi Nguyen
2002-05-24 23:34     ` Thien-Thi Nguyen
2002-05-25  1:44     ` Miles Bader
2002-05-25  2:39       ` Thien-Thi Nguyen
2002-05-25  2:57         ` Miles Bader
2002-05-26  5:03           ` Eli Zaretskii
2002-05-26  5:11             ` Thien-Thi Nguyen
2002-05-25  3:05         ` Miles Bader
2002-05-25  3:05         ` Miles Bader
2002-05-25 22:53           ` Thien-Thi Nguyen
2002-05-26  4:28     ` Richard Stallman
2002-05-27  6:44       ` Thien-Thi Nguyen
2002-05-28  5:15         ` Richard Stallman
2002-05-26  5:09     ` Eli Zaretskii
2002-05-27  6:48       ` Thien-Thi Nguyen
2002-05-27  7:33         ` Eli Zaretskii

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.