From: Drew Adams <drew.adams@oracle.com>
To: "Vitalie Spinu" <spinuvit@gmail.com>,
"Andreas Röhler" <andreas.roehler@online.de>
Cc: emacs-devel@gnu.org
Subject: RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality
Date: Wed, 23 Mar 2016 07:29:55 -0700 (PDT) [thread overview]
Message-ID: <78a08f80-30e2-4be1-a5e7-17c1c8fa866d@default> (raw)
In-Reply-To: <877fgtpfrw.fsf@gmail.com>
> > preventing unwanted widen instead seems the way to go.
>
> That's precisely what extra limit do. Prevent unwanted widen. How do you
> propose
> to implement that?
>
> I see 4 ways to go about it:
>
> 1) Add an extra prog-widen and teach all modes out there to use it in
> contexts like syntax-parsing, indentation, font-lock and who know what else. A
> half backed version of this in already part of emacs.
>
> 2) Have low level restrictions directly in `widen` and a macro
> `with-widen-limit` that multi-modes can use. This is the current patch.
>
> 3) Have two types of narrowing (soft and hard). This is harder to
> implement but has the benefit that it can be used in non-transient situations
> like Info mode.
>
> 4) Bring widen to elisp and allow minor modes (and Info mode) advice widen
> in whatever way they see.
>
> I think (1) is a bad idea. (4) is simplest and very general. (3) might be
> useful but it's hard. (2) is implemented to get rid of (1).
>
> I proposed (4) very early in the thread, but didn't hear much support for
> it. There are only three trivial usages of Fwiden in C code. Bringing
> `narrow` to elisp is equally easy.
At least now you're backing up to talk about multiple possible
solutions, instead of digging in deeper in your discussion of a
single implementation (or is it two implementations that you and
Stefan are considering?).
I asked for a clear statement (at least a summary, but preferably a
mini-spec) of the _problem_ you are trying to solve. My request was
ignored. So be it. Continue on, the two of you ... but don't be
surprised if people wonder about your solution after a while.
As for solutions (for what I'm only guessing might be the problem),
I suppose there are additional possibilities, including perhaps a
`with-buffer-limits' macro or perhaps even adapting `point-min' and
`point-max' (e.g. by let-binding global variables that they respond
to - e.g., variables `point-min' and `point-max').
Dunno. It's hard to guess at a solution without understanding the
problem. All I've gathered so far is that you want certain zones
of the buffer to act as if the major mode is this or that, and in
those zones you want some code (which code? all code?) to treat
`point-min' and `point-max' as the zone limits, i.e., to act as if
there is nothing outside of the zone limits.
Just what that means in detail is not clear (not specified).
Something about font-locking ... and some other blah. Not clear.
No, I don't need to understand; I'm just one user, and I probably
have nothing useful to offer as a suggestion. But my guess is
that if more people here had an idea of what problem you are
trying to solve then you might get some useful input. Just a guess.
next prev parent reply other threads:[~2016-03-23 14:29 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160322022539.16038.77264@vcs.savannah.gnu.org>
[not found] ` <E1aiC0q-0004DL-40@vcs.savannah.gnu.org>
2016-03-22 12:08 ` [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality Stefan Monnier
2016-03-22 19:44 ` Vitalie Spinu
2016-03-22 19:56 ` Drew Adams
2016-03-22 22:42 ` Vitalie Spinu
2016-03-23 0:44 ` Drew Adams
2016-03-23 7:16 ` Andreas Röhler
2016-03-23 11:58 ` Vitalie Spinu
2016-03-23 13:02 ` Andreas Röhler
2016-03-23 14:17 ` Vitalie Spinu
2016-03-23 15:34 ` Eli Zaretskii
2016-03-23 17:24 ` Andreas Röhler
2016-03-23 17:55 ` Eli Zaretskii
2016-03-23 18:53 ` Andreas Röhler
2016-03-23 21:57 ` Drew Adams
2016-03-23 22:13 ` Vitalie Spinu
2016-03-23 23:03 ` Drew Adams
2016-03-24 3:38 ` Eli Zaretskii
2016-03-24 12:24 ` Dmitry Gutov
2016-03-24 15:56 ` Eli Zaretskii
2016-03-24 18:55 ` Removing prog-indentation-context (was: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality) Stefan Monnier
2016-03-25 0:53 ` Removing prog-indentation-context Dmitry Gutov
2016-03-25 1:29 ` Dmitry Gutov
2016-03-25 2:09 ` Stefan Monnier
2016-03-25 11:38 ` Dmitry Gutov
2016-03-26 22:29 ` John Wiegley
2016-03-28 1:03 ` Dmitry Gutov
2016-03-25 15:45 ` Vitalie Spinu
2016-03-28 21:37 ` Dmitry Gutov
2016-03-28 22:08 ` Stefan Monnier
2016-03-28 22:55 ` Dmitry Gutov
2016-03-28 23:24 ` Stefan Monnier
2016-03-28 1:03 ` [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality Dmitry Gutov
2016-03-24 3:37 ` Eli Zaretskii
2016-03-23 17:14 ` Andreas Röhler
2016-03-24 0:03 ` Vitalie Spinu
2016-03-24 0:37 ` Drew Adams
2016-03-24 2:36 ` Vitalie Spinu
2016-03-24 13:53 ` Drew Adams
2016-03-24 13:57 ` Dmitry Gutov
2016-03-24 14:31 ` Drew Adams
2016-03-24 14:56 ` Stefan Monnier
2016-03-24 15:13 ` Drew Adams
2016-03-24 15:20 ` Stefan Monnier
2016-03-24 7:00 ` Andreas Röhler
2016-03-23 14:29 ` Drew Adams [this message]
2016-03-23 21:16 ` A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:] Alan Mackenzie
2016-03-23 21:58 ` Vitalie Spinu
2016-03-24 17:44 ` Alan Mackenzie
2016-03-24 20:43 ` Vitalie Spinu
2016-03-23 22:34 ` Dmitry Gutov
2016-03-24 18:38 ` Alan Mackenzie
2016-03-24 20:22 ` Vitalie Spinu
2016-03-25 0:11 ` Dmitry Gutov
2016-03-27 12:09 ` Alan Mackenzie
2016-03-27 22:59 ` Dmitry Gutov
2016-03-29 0:07 ` Alan Mackenzie
2016-04-01 1:15 ` Dmitry Gutov
2016-04-05 16:29 ` Alan Mackenzie
2016-04-05 22:52 ` Dmitry Gutov
2016-04-18 21:32 ` Alan Mackenzie
2016-03-28 13:00 ` Filipp Gunbin
2016-03-25 18:20 ` Phillip Lord
[not found] <<20160322022539.16038.77264@vcs.savannah.gnu.org>
[not found] ` <<E1aiC0q-0004DL-40@vcs.savannah.gnu.org>
[not found] ` <<jwvoaa6u36j.fsf-monnier+emacsdiffs@gnu.org>
[not found] ` <<8737riqouj.fsf@gmail.com>
[not found] ` <<221845e0-b194-433e-bfbc-105272ae5752@default>
[not found] ` <<87twjyp21k.fsf@gmail.com>
[not found] ` <<a15ff45f-aef0-4e89-b428-dd1d58a85960@default>
[not found] ` <<56F242E0.7060004@online.de>
[not found] ` <<877fgtpfrw.fsf@gmail.com>
[not found] ` <<56F293E7.2000703@online.de>
[not found] ` <<87a8lpnusg.fsf@gmail.com>
[not found] ` <<83r3f12oo5.fsf@gnu.org>
[not found] ` <<56F2D156.9040401@online.de>
[not found] ` <<83k2kt2i51.fsf@gnu.org>
[not found] ` <<56F2E643.4060903@online.de>
[not found] ` <<592bbafa-76ae-49d9-b5cd-644b3619a0d8@default>
[not found] ` <<838u1835si.fsf@gnu.org>
2016-03-24 14:41 ` [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality Drew Adams
2016-03-24 16:12 ` Eli Zaretskii
[not found] ` <<83zitn26t0.fsf@gnu.org>
2016-03-24 16:24 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=78a08f80-30e2-4be1-a5e7-17c1c8fa866d@default \
--to=drew.adams@oracle.com \
--cc=andreas.roehler@online.de \
--cc=emacs-devel@gnu.org \
--cc=spinuvit@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).