[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits fu

From: Andreas Röhler
Subject: Re: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality
Date: Wed, 23 Mar 2016 18:24:38 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Icedove/38.5.0

On 23.03.2016 16:34, Eli Zaretskii wrote:
From: Vitalie Spinu <address@hidden>
Date: Wed, 23 Mar 2016 15:17:03 +0100
Cc: address@hidden

Widen doesn't go wrong in itself. It what you do when you widen. In multi-modes
which use narrowing to create a micro-universe for inner modes, inner mode might
widen then compute some stuff on code from other language regions. This leads to
errors of all kind.

For example when multi-mode advices font-lock-default-fontify-region it cannot
control what individual functions in font-lock-keywords are doing. In case of
syntax-propertize-function it's a complete black box. The function can decide to
do whatever there.

Luckily if major-modes doesn't use widen or parse-partial-sexp directly it all
seem to work quite well with proper advice of relevant functions.
Isn't prog-widen the solution to those issues?

Hi Eli,

doku of prog-widen says

"This variable enables the major mode of the
main language to use the indentation engine of the sub-mode"

This also doesn't sound right. A mode should not need to fiddle with other modes. Seems it's time to introduce a true multi-mode, and abandon the notion of a buffers major-mode when multi-mode is on - even if the symbol of a than regional-mode is still called major-mode for legacy reasons.

A multi-mode could keep a register, an index about the modes to employ according to position.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]