Using proportional (variable-width) fonts in Emacs23
Erin Brinkley
I'm using Emacs 23 now and LOVE using proportional fonts! (AKA variable width fonts.) It FINALLY makes Emacs look beautiful, makes text easy to read.
But I discovered a huge problem: the fill and word wrap commands are hard coded to work for monospaced fonts only! For instance the fill-column is based on monospace fonts: if you use a proportional font and set the fill column to what you think is a reasonable number, you'll soon find out that you are WRONG and you get extra whitespace at the end of a line, and words will wrap! The only way out is to set the fill-column to an insanely low number, and that's not a real solution either!
I saw a copy of the old Emacs 21 manual online where it says that yes, you can use variable width fonts but the fill and wrap commands aren't yet set up for it. Something about how they were working on it. I'm curious how that's been going over the years. Is there any support for these fonts in Emacs now? Anyone know of a hack - kludge - tip - workaround I can try in the meantime? I love how this looks but admit to going crazy here with all my documents having these weird wrap problems.
Appreciate the help everyone!
Eli Zaretskii
> From: Erin Brinkley <erin_b...@yahoo.com>
>
> But I discovered a huge problem: the fill and word wrap commands are hard coded to work for monospaced fonts only! For instance the fill-column is based on monospace fonts: if you use a proportional font and set the fill column to what you think is a reasonable number, you'll soon find out that you are WRONG and you get extra whitespace at the end of a line, and words will wrap! The only way out is to set the fill-column to an insanely low number, and that's not a real solution either!
What do you mean by "word wrap" commands?
The only word wrap described in the Emacs manual is invoked by
"M-x visual-line-mode RET", and that one is _not_ hard coded for
monospaced fonts. Please try it.
The reason filling counts all characters of the same fonts as if they
had the same size is that filling inserts hard newlines, so the result
should work independent of the font. Filling works on the buffer text
level, where character size on screen are not known. By contrast, you
are looking for _display_time_ wrap, so filling is not what you want.
"Word wrap" as implemented as part of Visual Line Mode is designed to
exactly that, and it works on the level where the true size of each
character on display is known.
Tassilo Horn
Hi Erin,
> I'm using Emacs 23 now and LOVE using proportional fonts! (AKA
> variable width fonts.) It FINALLY makes Emacs look beautiful, makes
> text easy to read.
That's a purely subjective feeling. ;-)
> But I discovered a huge problem: the fill and word wrap commands are
> hard coded to work for monospaced fonts only!
They are not hard-coded to specific fonts. `fill-paragraph' (M-q) means
"reformat the current paragraph in such a way that all lines are at most
`fill-column' columns long".
What you seem to expect was something like "fill to pixel width". Of
course, that doesn't make sense with real, physical linebreaks. But
there's `visual-line-mode', which performs line wrapping only on the
display level, without changing the file.
,----[ (info "(emacs)Visual Line Mode") ]
| Another alternative to ordinary line continuation is to use "word
| wrap". Here, each long logical line is divided into two or more screen
| lines, like in ordinary line continuation. However, Emacs attempts to
| wrap the line at word boundaries near the right window edge. This
| makes the text easier to read, as wrapping does not occur in the middle
| of words.
`----
Bye,
Tassilo
Xah Lee
as Eli Z & Tassilo H mentioned, fill-column inserts line break char at
fixed number of chars per line. It's used to reformat computer code or
email that require line breaks. This command isn't designed for visual
wrap as the notion of margin in word processors. What you want is
probably visual-line-mode.
However, i wanted to say that i also use variable-width font all the
time (often even when working in dired or python), and fill-column
still works fine for visual purposes. Not quite sure what you mean
weird wraps...
Xah
Uday Reddy
>> I'm using Emacs 23 now and LOVE using proportional fonts! (AKA
>> variable width fonts.) It FINALLY makes Emacs look beautiful, makes
>> text easy to read.
>
> That's a purely subjective feeling. ;-)
Well, my subjective feeling is that I read better if the text is in
proportional font, and I can write better if it is in monospace. But I
make a lot of typos when I write (usually at the level of words rather
than characters), and I notice those typos only if I read the text back
in proportional font. Go figure.
Probably comes from all those years of reading books type set in awful
proportional fonts ;-)
Cheers,
Uday
rusi
> On 3/28/2011 7:30 PM, Tassilo Horn wrote:
>
> >> I'm using Emacs 23 now and LOVE using proportional fonts! (AKA
> >> variable width fonts.) It FINALLY makes Emacs look beautiful, makes
> >> text easy to read.
>
> > That's a purely subjective feeling. ;-)
>
> Well, my subjective feeling is that I read better if the text is in
> proportional font, and I can write better if it is in monospace.
This is an interesting observation. (Especially the second part)
Do you have a clue why?
> But I
> make a lot of typos when I write (usually at the level of words rather
> than characters), and I notice those typos only if I read the text back
> in proportional font. Go figure.
>
> Probably comes from all those years of reading books type set in awful
> proportional fonts ;-)
Tsk Tsk... Spoilt by these bad habits :-)
Uday Reddy
>> Well, my subjective feeling is that I read better if the text is in
>> proportional font, and I can write better if it is in monospace.
>
> This is an interesting observation. (Especially the second part)
> Do you have a clue why?
It must again be the habit of typing in monospace for years. Your eyes
are looking for text in a particular place but the proportional font
condenses it. On occasion when I have to write documents for Word, I
type it in Emacs first and then cut-and-paste it into Word. I had even
written some Emacs commands for it in the old days. But, now that we
have the visual-line-mode, a straight cut-and-paste will work fine.
Cheers,
Uday
rusi
> rusi wrote:
> >> Well, my subjective feeling is that I read better if the text is in
> >> proportional font, and I can write better if it is in monospace.
>
> > This is an interesting observation. (Especially the second part)
> > Do you have a clue why?
>
> It must again be the habit of typing in monospace for years. Your eyes
> are looking for text in a particular place but the proportional font
> condenses it.
By reducing these questions to habits, the implication is that say for
younger folk who only know 'modern' technology (like Word) things like
emacs will be suboptimal and in fact make no sense.
My own sense is that
- Some habits are suboptimal and worth (trying to) change
- Some are suboptimal but its just too uphill to change (eg qwerty vs
dvorak)
- And some things are just naturally wrong -- eg using a dumbed down
mouse interface rather than the keyboard.
Evidently people may disagree on what is natural: eg Microsoft and
Apple have different view on what font is readable on a screen.
Coming back to the typing question:
For the first hundred years after the invention of the typewriter two
things were inseparably linked:
1 Using a keyboard to type
2 The above resulting in 'typewriter' (monospace) text
Surely separating these should make certain optimizations available
that were not available earlier??
Uday Reddy
> By reducing these questions to habits, the implication is that say for
> younger folk who only know 'modern' technology (like Word) things like
> emacs will be suboptimal and in fact make no sense.
No, I didn't imply that. Monospace may be better for the younger folk
too. Or, maybe it isn't. They will have to try out for themselves and
figure out which works better. I am afraid I don't have a theory of
monospace. You are probably looking for one ;-)
On the other hand, the notion that proportional fonts are easier to read
will have plenty of takers. So, everything Emacs can do to support
proportional fonts will be very welcome.
Cheers,
Uday
Thien-Thi Nguyen
() Mon, 28 Mar 2011 09:22:51 -0700 (PDT)
Anyone know of a hack - kludge - tip - workaround I can try in the
meantime?
Personally, i use this:
--8<---------------cut here---------------start------------->8---
(define-derived-mode thinking-with-another-brain text-mode "TWAB"
"Like Text mode, but with `variable-pitch' face and `visual-line-mode'."
(define-key thinking-with-another-brain-map
"'" (lambda () (interactive) (insert-and-inherit "’"))))
(add-hook 'thinking-with-another-brain-hook
(lambda ()
(auto-fill-mode -1)
(facemenu-set-face 'variable-pitch (point-min) (point-max))
(visual-line-mode 1)
(set (make-variable-buffer-local 'truncate-lines) nil)))
--8<---------------cut here---------------end--------------->8---
It was recently written specifically to read (and correct small spelling and
grammar errors in) Turing Evolved by David Kitson, and so is not (yet) fully
generalized and most likely peculiar to my setup, but you get the idea, i
hope. I found that double spacing the text first greatly helps readability.
I don't know if this qualifies as a hack, kludge, tip or workaround; YMMV.
Pascal J. Bourguignon
Yes, for text.
For programming languages, even if indentation is correctly impleented,
the situation is more difficult.
Program readability is often a 2D affair, where you want things to align
in columns to stress on the homogeneity of the structures.
For example, this first declaration block is more readable (use a
non-proportional font to read my messages!):
var
m: integer;
i: integer;
color: integer;
sizeOfTheBox: cardinal;
than this other one, where I simulate proportional font with a different
number of spaces:
var
m: integer
i: integer;
color: integer;
sizeOfTheBox: cardinal;
Another example:
This is less readable:
doSomething(object1,arg1,arg2forObject,arg3);
doSomething(o2,arg1,a2o2,arg3);
than:
doSomething(object1,arg1,arg2forObject,arg3);
doSomething(o2, arg1,a2o2, arg3);
because in the later we see immediately that only the first and third
arguments change, while in the former, you need to parse it and give it
more attention. Unfortunately, Editors with proportional fonts don't
have indenting and formating algorithms sophisticated enough to render
code like in the later example (that would require even more than
understanding the program!).
So proportional fonts are hoplessly useless for programming.
Now of course, emacs has a sizeable user community amongst the
novelists and literature authors, not counting the technical writers
editing software documentation, for whom proportional font support is
nice.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
rusi
wrote:
So far I am in full agreement
> Unfortunately, Editors with proportional fonts don't
> have indenting and formating algorithms sophisticated enough to render
> code like in the later example (that would require even more than
> understanding the program!).
Well that is (may be?) the current situation. Why cant it change?
>
> So proportional fonts are hoplessly useless for programming.
As of now -- yes.
In eclipse for example the file explorer window uses a narrow
proportional font which saves real estate. Likewise a programmer
using emacs uses a number of readonly buffers eg compilation, messages
buffer etc. All these could conserve real estate with a proportional
font.
>
> Now of course, emacs has a sizeable user community amongst the
> novelists and literature authors, not counting the technical writers
> editing software documentation, for whom proportional font support is
> nice.
Proportional font is good for everyone who has to read though the
details differ across genres and some problems are harder to solve
than others.
A particularly tricky problem is that two of the most popular
languages today -- python and haskell -- are space sensitive by
design. Changing the number of spaces changes the meaning of the
program. This makes a hard problem harder. Still, I dont believe its
unsolvable.
Pascal J. Bourguignon
>> Unfortunately, Editors with proportional fonts don't
>> have indenting and formating algorithms sophisticated enough to render
>> code like in the later example (that would require even more than
>> understanding the program!).
>
> Well that is (may be?) the current situation. Why cant it change?
Because you would need strong AI to do it right, and once you have
strong AI, you won't care reading program codes anymore.
>> So proportional fonts are hoplessly useless for programming.
>
> As of now -- yes.
>
> In eclipse for example the file explorer window uses a narrow
> proportional font which saves real estate. Likewise a programmer
> using emacs uses a number of readonly buffers eg compilation, messages
> buffer etc. All these could conserve real estate with a proportional
That said, it could be argued that manual formating with spaces of
program sources tends to anal retentiveness, and it might be wanted to
just use a proportional font with correct left indenting, and let the
editor format the rest of the line as it wants. After all, spaces are
not significant in sane programming languages. At least, as long as the
programming language is verbose enough, it wouldn't matter for APL for
example.
> A particularly tricky problem is that two of the most popular
> languages today -- python and haskell -- are space sensitive by
> design.
Just say no. There are better alternatives.
Peter Dyballa
Am 30.03.2011 um 15:30 schrieb Pascal J. Bourguignon:
> So proportional fonts are hoplessly useless for programming.
And also in dired-mode! (In one account GNU Emacs 24.0.50 uses a
proportional font for dired buffers!)
--
Greetings
Pete
There's something the technicians need to learn from the artists. If
it isn't aesthetically pleasing, it's probably wrong.
Eli Zaretskii
> Date: Wed, 30 Mar 2011 17:53:02 +0200
>
> rusi <rusto...@gmail.com> writes:
>
> >> Unfortunately, Editors with proportional fonts don't
> >> have indenting and formating algorithms sophisticated enough to render
> >> code like in the later example (that would require even more than
> >> understanding the program!).
> >
> > Well that is (may be?) the current situation. Why cant it change?
>
> Because you would need strong AI to do it right
Not necessarily. In Emacs, we can specify that text be displayed
aligned to a specific width in pixels. See the node "Specified Space"
in the ELisp manual. Perhaps display of programming languages could
use this feature to align program source even with proportional fonts.
PJ Weisberg
>> From: "Pascal J. Bourguignon" <p...@informatimago.com>
>> Date: Wed, 30 Mar 2011 17:53:02 +0200
>>
>>
>> >> Unfortunately, Editors with proportional fonts don't
>> >> have indenting and formating algorithms sophisticated enough to render
>> >> code like in the later example (that would require even more than
>> >> understanding the program!).
>> >
>> > Well that is (may be?) the current situation. Why cant it change?
>>
>
> Not necessarily. In Emacs, we can specify that text be displayed
> aligned to a specific width in pixels. See the node "Specified Space"
> in the ELisp manual. Perhaps display of programming languages could
> use this feature to align program source even with proportional fonts.
Something like the rule "after a string of two or more whitespace
characters, position the next character as if the preceeding text on
that line was monospaced"? It would do a decent job of guessing when
the programmer is trying to align things and put the text in a
standard place. It would take some tuning to avoid making the gaps
excessively large, though. (And I'm sure it would annoy plenty of
people who *expect* all code to be monospaced.)
-PJ
Eli Zaretskii
> From: PJ Weisberg <p...@irregularexpressions.net>
>
> > Not necessarily. In Emacs, we can specify that text be displayed
> > aligned to a specific width in pixels. See the node "Specified Space"
> > in the ELisp manual. Perhaps display of programming languages could
> > use this feature to align program source even with proportional fonts.
>
> Something like the rule "after a string of two or more whitespace
> characters, position the next character as if the preceeding text on
> that line was monospaced"?
Yes, not unlike what we do with font-lock.
Stefan Monnier
> aligned to a specific width in pixels. See the node "Specified Space"
> in the ELisp manual. Perhaps display of programming languages could
> use this feature to align program source even with proportional fonts.
I don't think we have good support for that in the display engine right
now, but we do have some amount of support for it and it's not used for
that purpose, and I think there's a good reason: there is no place to
store the necessary information in the file. So while you might be able
to do align on-demand and even maintain that alignment as the buffer is
edited, it's difficult to infer the needed alignment from the source
file: I think that the information present in the file is sufficient for
90% of the cases, but the remaining 10% is problematic (and even
getting those 90% working might be dependent on the language, i.e. on
the major-mode).
Stefan
Eli Zaretskii
> Date: Thu, 31 Mar 2011 00:58:55 -0400
We do something very similar with fontification. There's no reason,
at least not a-priori, that it won't work with alignment.
Pascal J. Bourguignon
> We do something very similar with fontification. There's no reason,
> at least not a-priori, that it won't work with alignment.
Well, it doesn't work (well at all) for fontification, what makes you
think it'd work better with alignment?
Eli Zaretskii
>
> Eli Zaretskii <el...@gnu.org> writes:
> > We do something very similar with fontification. There's no reason,
> > at least not a-priori, that it won't work with alignment.
>
> Well, it doesn't work (well at all) for fontification
It does for me.
Stefan Monnier
> at least not a-priori, that it won't work with alignment.
There's a good reason: fontification does have all the necessary
information in the source file (it does not always make full use of it
because it requires potentially complex parsing, but the info is there).
Whereas for alignment, the info is only in the original coder's head and
needs to be guessed.
Stefan