Commit 8147d939 authored by Eli Zaretskii's avatar Eli Zaretskii

; * etc/TODO: Update.

parent c61bfe0a
Pipeline #3233 passed with stage
in 55 minutes and 8 seconds
......@@ -219,6 +219,54 @@ https://lists.gnu.org/r/emacs-devel/2013-11/msg00515.html
processing. That is why we added text properties and variable
width fonts. However, more features are still needed to achieve this.
** Support ligatures out of the box
For the list of typographical ligatures, see
https://en.wikipedia.org/wiki/Orthographic_ligature#Ligatures_in_Unicode_(Latin_alphabets)
For Text and derived modes, the job is to figure out which ligatures
we want to support, how to let the user customize that, and probably
define a minor mode for automatic ligation (as some contexts might not
want, say, "fi" or "ff" always yield a ligature, and also because it
might slow down redisplay, because character composition goes through
Lisp).
For ligature support in programming language modes, one can look at
the various add-on packages out there that provide the feature via
prettify-symbols-mode. We need to figure out which ligatures are
needed for each programming language, and provide user options to turn
this on and off.
The implementation should use the infrastructure for character
compositions, i.e., we should define appropriate regexp-based rules
for character sequences that need to be composed into ligatures, and
populate composition-function-table with those rules. See
composite.el for examples of this, and also grep lisp/language/*.el
for references to composition-function-table.
The prettify-symbols-mode should be deprecated once ligature support
is in place.
** Support for Stylistic Sets
This will allow using "alternate glyphs" supported by modern fonts.
For an overview of this feature, see
https://www.typography.com/faq/157
https://glyphsapp.com/tutorials/stylistic-sets
HarfBuzz supports this, see this discussion:
https://lists.freedesktop.org/archives/harfbuzz/2019-September/007434.html
One possible way of letting Lisp program support this would be to
introduce a new text property 'stylistic-set' whose value will be the
set name(s), a symbol or a list of symbols. Characters that have this
property should be processed specially by 'get_glyph_face_and_encoding':
instead of calling the 'encode_char' method of the font driver, we
should invoke the 'shape' method. 'hbfont_shape' should be extended
to pass to 'hb_shape_full' the required array of features, as
mentioned in the above HarfBuzz discussion.
** Extend text-properties and overlays
*** Several text-property planes
This would get us rid of font-lock-face property (and I'd be happy to
......@@ -529,10 +577,6 @@ from the emacsclient process.
** Optionally make the cursor a little thinner at the end of a line
or the end of the buffer.
** Port the conservative stack marking code of Emacs's garbage collector
to more systems, so that we can completely get rid of GCPROs. Note
that Boehm garbage collector provides this.
** Reorder defcustom's in each package so that the more important
options come first in the Customize buffers. This could be done by
either rearranging the file (since options are shown in the order
......@@ -1469,17 +1513,25 @@ presence of multi-file documents.
** Replace linum.el with nlinum.el
https://lists.gnu.org/r/emacs-devel/2013-08/msg00379.html
(Since Emacs 26 introduced native line numbers, this item is
probably obsolete.)
** Merge sendmail.el and messages.el.
Probably not a complete merge, but at least arrange for messages.el to be
a derived mode of sendmail.el. Or arrange for messages.el to be split
into a small core and "the rest" so that we use less resources as long as
we stick to the features provided in sendmail.el.
(Probably obsolete, as Emacs 24 switched to message.el as the
default mail composer.)
** Replace gmalloc.c with the modified Doug Lea code from the current
GNU libc so that the special mmapping of buffers can be removed --
that apparently loses under Solaris, at least. [fx has mostly done
this.]
(Obsolete, since gmalloc.c is nowadays only used on MS-DOS.)
** Rewrite make-docfile to be clean and maintainable.
It might be better to replace it with Lisp, using the byte compiler.
https://lists.gnu.org/r/emacs-devel/2012-06/msg00037.html
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment