Re: Quieter glyphs than parentheses
From: Pascal Bourguignon (spam_at_thalassa.informatimago.com)
Date: 02/08/04
- Next message: Ari Johnson: "Re: compile"
- Previous message: Joe Marshall: "Re: PLEASE IGNORE THAT ONE! All screwed up, multi-duplicated text, ..."
- In reply to: Steven M. Haflich: "Re: Quieter glyphs than parentheses"
- Next in thread: Tom Lord: "Re: Quieter glyphs than parentheses"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 08 Feb 2004 01:52:54 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
"Steven M. Haflich" <smh_no_spiced_ham@alum.mit.edu> writes:
> To return to the original question, the brittleness of input methods and
> display fonts is one reason I would caution against using characters from
> some obscure font in order to improve visual typography. Few non-ISO-8859
> fonts are standard across many platforms, and someone trying to read this
> code or papers without all the obscure fonts installed (or with his
> system improperly configured) will see garbage instead of the desired
> slender parentheses.
With emacs, this is easily solved with something similar to the
following (which does display a left arrow instead of underline).
(defvar lse-assign-image
(find-image
(list
(list :type 'xbm
:width 7
:height 12
:ascent 91
:background nil
:foreground nil
:data (let* ((lines
(mapcar
(lambda (line)
(let ((vec (make-bool-vector (length line) nil)))
(do* ((bits (mapcar (lambda (char)
(string/= char "."))
(split-string line ""))
(cdr bits))
(bit (car bits) (car bits))
(i 0 (1+ i)))
((null bits) vec)
(aset vec i bit))))
(split-string ".......\n.......\n.......\n..**...\n.**....\n******.\n.**....\n..**...\n.......\n.......\n.......\n.......\n")))
(vec (make-vector (length lines) nil)))
(do ((lines lines (cdr lines))
(line (car lines) (car lines))
(i 0 (1+ i)))
((null lines) vec)
(aset vec i line))))))
"A left arrow glyph.")
(defun lse-underline-to-assign ()
"Replace all occurence of _ into left arrow (to be used once in lse-mode)."
(interactive)
(save-excursion
(save-restriction
(widen)
(goto-char (point-min))
(while (search-forward "_" nil t)
(delete-region (match-beginning 0) (match-end 0))
(insert-image lse-assign-image "_")))))
(defun lse-put-image (image pos &optional string area)
"Put image IMAGE in front of POS in the current buffer.
IMAGE must be an image created with `create-image' or `defimage'.
IMAGE is displayed by putting an overlay into the current buffer with a
`before-string' STRING that has a `display' property whose value is the
image. STRING is defaulted if you omit it.
POS may be an integer or marker.
AREA is where to display the image. AREA nil or omitted means
display it in the text area, a value of `left-margin' means
display it in the left marginal area, a value of `right-margin'
means display it in the right marginal area."
(unless string (setq string "x"))
(let ((buffer (current-buffer)))
(unless (eq (car-safe image) 'image)
(error "Not an image: %s" image))
(unless (or (null area) (memq area '(left-margin right-margin)))
(error "Invalid area %s" area))
(let (overlay
(curpos (point))
(prop (if (null area) image (list (list 'margin area) image))))
(setq string (copy-seq string))
(put-text-property 0 (length string) 'display prop string)
(insert string)
(setq overlay (make-overlay curpos (point) buffer))
(overlay-put overlay 'put-image t)
(overlay-put overlay 'evaporate t)
(overlay-put overlay 'intangible nil)
)))
(defun lse-assign ()
"Insert an assign operator (the ASCII code of the underline)
but adding an overlay on it with the `lse-assign-image' (a left arrow)."
(interactive)
(lse-put-image lse-assign-image (point) "_"))
(define-key lse-mode-map "_" 'lse-assign)
-- __Pascal_Bourguignon__ http://www.informatimago.com/ There is no worse tyranny than to force a man to pay for what he doesn't want merely because you think it would be good for him.--Robert Heinlein http://www.theadvocates.org/
- Next message: Ari Johnson: "Re: compile"
- Previous message: Joe Marshall: "Re: PLEASE IGNORE THAT ONE! All screwed up, multi-duplicated text, ..."
- In reply to: Steven M. Haflich: "Re: Quieter glyphs than parentheses"
- Next in thread: Tom Lord: "Re: Quieter glyphs than parentheses"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]