From: Dmitry Gutov <dgutov@yandex.ru>
To: "Wedler, Christoph" <christoph.wedler@sap.com>,
Stefan Monnier <monnier@iro.umontreal.ca>
Cc: "Fabián E.Gallina" <fabian@anue.biz>,
"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: antlr-mode.el - need some support by python.el
Date: Wed, 18 Feb 2015 17:29:41 +0200 [thread overview]
Message-ID: <54E4AFE5.1070208@yandex.ru> (raw)
In-Reply-To: <F9C2521BBF380A4A97379009991555E685B0697C@DEWDFEMB17C.global.corp.sap>
On 02/18/2015 02:22 PM, Wedler, Christoph wrote:
> Well, if the indentation calculation in python-mode needs some context
> information which might be outside the visible part of the buffer, it
> must call `widen', right? Of course, Python does that inside a
> `save-restriction'.
Well, I say it shouldn't, until we have a better `widen'.
>> And/or someone could try and solve the long-standing problem of
>> separating "visibility" narrowing and "functional" narrowing.
>
> To be honest, I do not fully understand what you mean here, or how it
> would solve the problem.
Some `widen' calls mean `don't go beyond this region', and some mean
`don't show me anything beyond this region'. Indentation code would undo
the latter kind, and the multi-mode code would use first kind.
> Cross-command-wise, there is one narrowing. It is used for restricting
> some editing operations ("functional"?) and the visible part of the
> buffer.
Yes, the problem is it does both.
> If we would have two narrowings, then the "functional" should
> always be a subset of the "visible" narrowing (and the "functional"
> should be made somehow detectable for the user by a different background
> color). Otherwise, things would get very confusing for the user.
>
> Then, for python-mode not to call widen itself, the "functional" region
> must be widened, which would imply a "visible" widen with the condition
> above. In other words, pyhon users could not use narrowing when they
> want to get a correct indentation.
I believe it will be in reverse. Though many editing commands will have
to respect the "visible" narrowing, instead of "functional".
>> LEFTMOST-COL, likewise, can by added by the calling function. No need to
>> make the submode's indentation function be aware of it.
>
> As Stefan has mention, it would first require that the mode not just
> indents the line, but also has a function which returns the correct
> indentation.
Not necessarily: you also can adjust the indentation after the submode
applies it.
> Even if we have this, things are not that easy - we start with the
> non-Python case:
> - some indent calculation return the correct indentation based on the
> indentation of previous lines - here, I won't have to add anything
> (given that I calculate the correct index of the first SUB-line myself,
> which I can do), except sometimes for top-level constructs
> - some indent calculation return the correct indentation based on the
> syntactic context - here, I would have to add LEFTMOST-COL
Currently, I'm using this trick: narrow, then add LEFTMOST-COL at the
beginning of the region. In the end, remove them.
But using `line-indentation-function' would avoid it, too.
next prev parent reply other threads:[~2015-02-18 15:29 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-16 19:50 antlr-mode.el - need some support by python.el Wedler, Christoph
2015-01-16 23:37 ` Stefan Monnier
2015-02-05 11:39 ` Wedler, Christoph
2015-02-05 14:27 ` Stefan Monnier
2015-02-06 15:14 ` Wedler, Christoph
2015-02-06 17:47 ` Stefan Monnier
2015-02-13 10:56 ` Wedler, Christoph
2015-02-13 19:40 ` Stefan Monnier
2015-02-16 14:38 ` Wedler, Christoph
2015-02-16 19:23 ` Stefan Monnier
2015-02-17 10:55 ` Wedler, Christoph
2015-02-18 0:00 ` Stefan Monnier
2015-02-18 14:27 ` Wedler, Christoph
2015-02-18 3:39 ` Dmitry Gutov
2015-02-18 5:48 ` Stefan Monnier
2015-02-18 14:13 ` Wedler, Christoph
2015-02-18 15:13 ` Dmitry Gutov
2015-02-18 15:41 ` Wedler, Christoph
2015-02-18 17:56 ` Stefan Monnier
2015-02-19 2:43 ` Dmitry Gutov
2015-02-19 3:20 ` Stefan Monnier
2015-02-19 3:30 ` Dmitry Gutov
2015-02-19 13:18 ` Stefan Monnier
2015-02-21 22:14 ` Dmitry Gutov
2015-02-25 11:05 ` Wedler, Christoph
2015-03-01 17:04 ` Stefan Monnier
2015-03-01 22:16 ` Dmitry Gutov
2015-03-02 5:23 ` Stefan Monnier
2015-03-02 15:08 ` Dmitry Gutov
2015-03-02 16:48 ` Stefan Monnier
2015-03-02 18:04 ` Dmitry Gutov
2015-03-02 18:51 ` Stefan Monnier
2015-03-02 19:31 ` Dmitry Gutov
2015-03-03 16:32 ` Stefan Monnier
2015-03-04 16:53 ` Wedler, Christoph
2015-03-04 17:20 ` Dmitry Gutov
2015-03-05 9:46 ` Wedler, Christoph
2015-03-05 12:29 ` Dmitry Gutov
2015-03-05 12:43 ` Dmitry Gutov
2015-04-02 14:10 ` Wedler, Christoph
2015-04-07 17:49 ` Stefan Monnier
2015-04-09 14:07 ` Wedler, Christoph
2015-04-09 18:13 ` Stefan Monnier
2015-06-03 14:14 ` Wedler, Christoph
2015-06-03 15:31 ` Stefan Monnier
2015-06-05 14:17 ` Wedler, Christoph
2015-06-05 17:46 ` Dmitry Gutov
2015-06-08 9:12 ` Wedler, Christoph
2015-06-08 13:26 ` Stefan Monnier
2015-06-08 16:02 ` Dmitry Gutov
2015-06-08 20:50 ` Stefan Monnier
2015-06-08 21:33 ` Dmitry Gutov
2015-06-09 9:07 ` Wedler, Christoph
2015-06-09 15:58 ` Stefan Monnier
2015-06-09 19:05 ` Wedler, Christoph
2015-06-15 11:02 ` Dmitry Gutov
2015-06-08 13:18 ` Stefan Monnier
2015-03-04 17:37 ` Dmitry Gutov
2015-03-04 22:26 ` Stefan Monnier
2015-03-04 22:59 ` Dmitry Gutov
2015-03-10 1:16 ` Stefan Monnier
2015-03-21 15:30 ` Dmitry Gutov
2015-03-21 17:08 ` Stefan Monnier
2015-03-21 23:41 ` Dmitry Gutov
2015-03-22 13:54 ` Stefan Monnier
2015-03-22 19:31 ` Dmitry Gutov
2015-03-22 21:59 ` Stefan Monnier
2015-03-23 14:03 ` Dmitry Gutov
2015-03-23 19:25 ` Stefan Monnier
2015-03-04 16:29 ` Wedler, Christoph
2015-03-04 17:16 ` Dmitry Gutov
2015-03-01 22:25 ` Dmitry Gutov
2015-02-18 12:22 ` Wedler, Christoph
2015-02-18 15:29 ` Dmitry Gutov [this message]
2015-02-18 16:10 ` Wedler, Christoph
2015-02-18 22:55 ` Dmitry Gutov
2015-02-25 11:16 ` Wedler, Christoph
2015-02-18 3:15 ` Dmitry Gutov
2015-02-22 7:52 ` Andreas Röhler
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=54E4AFE5.1070208@yandex.ru \
--to=dgutov@yandex.ru \
--cc=christoph.wedler@sap.com \
--cc=emacs-devel@gnu.org \
--cc=fabian@anue.biz \
--cc=monnier@iro.umontreal.ca \
/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).