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: Alan Mackenzie
Subject: Re: bug#1406: backward-up-list reports scan error incorrectly?
Date: Thu, 27 Nov 2008 22:09:25 +0000
User-agent: Mutt/1.5.9i

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]