display question: should ^N and \NNN widths be fixed?

display question: should ^N and \NNN widths be fixed?

[Thien-Thi Nguyen]

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

Re: display question: should ^N and \NNN widths be fixed?

[Richard Stallman]

    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.

Re: display question: should ^N and \NNN widths be fixed?

[Thien-Thi Nguyen]

   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

Re: display question: should ^N and \NNN widths be fixed?

[Thien-Thi Nguyen]

   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

Re: display question: should ^N and \NNN widths be fixed?

[Miles Bader]

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]

Re: display question: should ^N and \NNN widths be fixed?

[Thien-Thi Nguyen]

   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

Re: display question: should ^N and \NNN widths be fixed?

[Miles Bader]

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"

Re: display question: should ^N and \NNN widths be fixed?

[Eli Zaretskii]

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.

Re: display question: should ^N and \NNN widths be fixed?

[Thien-Thi Nguyen]

   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

Re: display question: should ^N and \NNN widths be fixed?

[Miles Bader]

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'

Re: display question: should ^N and \NNN widths be fixed?

[Thien-Thi Nguyen]

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

Re: display question: should ^N and \NNN widths be fixed?

[Miles Bader]

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'

Re: display question: should ^N and \NNN widths be fixed?

[Richard Stallman]

       + 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.

Re: display question: should ^N and \NNN widths be fixed?

[Thien-Thi Nguyen]

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

Re: display question: should ^N and \NNN widths be fixed?

[Richard Stallman]

    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.

Re: display question: should ^N and \NNN widths be fixed?

[Eli Zaretskii]

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.

Re: display question: should ^N and \NNN widths be fixed?

[Thien-Thi Nguyen]

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

Re: display question: should ^N and \NNN widths be fixed?

[Eli Zaretskii]

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.