help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: bug#1406: backward-up-list reports scan error incorrectly?


From: xah lee
Subject: Re: bug#1406: backward-up-list reports scan error incorrectly?
Date: Thu, 27 Nov 2008 14:49:18 -0800

Personally, I like being able to use the list commands inside a comment
or string.

Don't forget that the list commands are also used a lot as
almost-primitive functions in other lisp code (they're certainly used a lot in CC Mode), and redefining these the way you suggest would slow down
other code, possibly by a lot.

I see. great info.

Doh, i thought i was replying to the bug list. My prev post wast intended for the bug list so that that the communication is unbroken there but didn't notice it just went to help.gnu.emacs. but anyway, you probably right.

  Xah
∑ http://xahlee.org/

☄

On Nov 27, 2008, at 2:09 PM, Alan Mackenzie wrote:

Hi, Xah.

On Thu, Nov 27, 2008 at 07:56:17AM -0800, xah lee wrote:
On Nov 27, 4:19 am, Alan Mackenzie <a...@muc.de> wrote:
Hi, Xah!

though, isn't this something easy to fix?
No, because it isn't a bug.  It's the way the function is meant  to
work.  If there is a bug, it's that the doc-string (and maybe the
elisp  manual, I haven't looked) is vague and incomplete.

I've amended the Emacs manual (.../doc/emacs/programs.texi) and  the
doc strings of `backward-up-list' and several similar functions
(.../lisp/emacs-lisp/lisp.el).

If you're interested, have a look at the changes in
<http://cvs.savannah.gnu.org/viewvc/emacs/?root=emacs>.

Thanks Alan.

I'd rather hope for a fix instead of change wording to reflect
current situation.

Again, there isn't a bug, so there's nothing to fix. What I think you're
saying is that you'd prefer C-M-u to do something a bit different; or,
put another way, you want a different function.

Personally, I like being able to use the list commands inside a comment
or string.

Don't forget that the list commands are also used a lot as
almost-primitive functions in other lisp code (they're certainly used a
lot in CC Mode), and redefining these the way you suggest would slow down
other code, possibly by a lot.

You argued in bug list that the issue is not simple essentially due
to the fact that straight quote chars are not matching pairs.

That is true, but i think given today's tech and computing power, we
can over come this. Just assume that double quotes in the source code
are matched, since they are most of the time. In the few cases when
the backward-up-list went to the wrong place due to un-matched double
quote, i think that's ok. (as opposed to, it stops dead and utter a
beep.)

The stopping dead is due to it not finding an enclosing paren.

alternatively, if the cursor is inside double quote, then issue a
warning in the messag area that the result may not be correct.

Why don't you write the function you want?  Then submit it to
emacs-devel@gnu.org, and it could well become an option in Emacs 24.

You have to decide what "inside a string" means.  It could be as simple
as the text at point being fontified with font-lock-string-face.  Or,
maybe you'd want to scan from the beginning of buffer to check this.
`parse-partial-sexp' is your friend here.

Also, since this works in text-mode, so apparently this can work. A
implementation is to temporarily switch to that mode, do the cursor
move, then switch back. Or temp set the syntax table to whatever chat
that made text-mode work and emacs-lisp-mode not work.

That's another way you could do it.  In text mode, I don't think there
are any string characters defined (we're talking about its "syntax table"
here).  So if you did this (switching temporarily to Text Mode) in Elisp
mode, you'd just get a very crude interpretation of parens.  It might be
what you want, it might not.

In general, my feeling is that moving around nested pairs is not a
some insurmountable issue, that given today's technology and
software, it seems wimpy to tell users that backward-up-list won't
work if it's inside double quotes. Much complex problems are solved
today in emacs, in other IDEs, etc.

No, it's certainly surmountable. But first you've got to decide what you
want, then you've got to do the surmounting.

Just my opinions. Thanks.

No problem!

  Xah

--
Alan Mackenzie (Nuremberg, Germany).

☄






reply via email to

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