Re: Last call for lua-mode contributors

Re: Last call for lua-mode contributors

[Miles Bader]

immerrr again <immerrr+lua@gmail.com> writes:
> As some of you might know, lua-mode, Emacs major mode for editing Lua, is
> undergoing integration to Emacs mainline.

Hopefully lua-mode's bogus handling of symbols vs. words will finally
be fixed as a result.....

[lua-mode redefines "_" as a word-component; it shouldn't, as it
really messes with users' instincts, and makes Emacs commands less
useful.  Historically this was often done by language-modes as an
simple (though misguided) expedient to allow them to safely use "\<"
and \>" in regexps matching keywords, but nowadays they shouldn't do
that, they should leave "_" alone and use "\_<" and "\_>" instead.]

A few years ago (one of the previous times an attempt was being made
to include lua-mode), of the lua-mode authors mentioned he was of the
opinion that the existing lua-mode was such a huge hack that it should
just be rewritten from scratch anyway (and said he planned to, but
never seemed to get the time).

If author-archeology proves sufficiently painful, maybe that would
indeed be the more expedient option (especially as there are more nice
tools in emacs for writing modes these days, e.g., Stefan's
parser-thingy)!

-Miles

-- 
Custard, n. A vile concoction produced by a malevolent conspiracy of the hen,
the cow, and the cook.

Re: Last call for lua-mode contributors

[Ken Raeburn]

On Jan 17, 2012, at 23:32, Miles Bader wrote:
> immerrr again <immerrr+lua@gmail.com> writes:
>> As some of you might know, lua-mode, Emacs major mode for editing Lua, is
>> undergoing integration to Emacs mainline.
> 
> Hopefully lua-mode's bogus handling of symbols vs. words will finally
> be fixed as a result.....
> 
> [lua-mode redefines "_" as a word-component; it shouldn't, as it
> really messes with users' instincts, and makes Emacs commands less
> useful.  Historically this was often done by language-modes as an
> simple (though misguided) expedient to allow them to safely use "\<"
> and \>" in regexps matching keywords, but nowadays they shouldn't do
> that, they should leave "_" alone and use "\_<" and "\_>" instead.]

My "instincts" have long been to interpret "word" as "identifier or keyword" in programming modes, to the point of customizing the syntax tables at startup to make "_" a word component.  Not for regular expressions, but for word-motion commands; I like the fact that I can skip over one identifier with M-f no matter how many underscores it contains -- string_to_widget, stringToWidget, string2widget, and stringtowidget are all treated the same.  It's also more useful in constructing keyboard macros that kill-word identifiers and later yank them from the kill ring; typing in a regexp search would be much more annoying.

I haven't made the customization yet at my new (well, ~2 years) job -- but that's because our coding standards use camelCaseAndNoUnderscores so the word-motion commands already work on identifiers and not on (English) words.  (Though I've been dealing with Linux code lately, so it may be time to make the change.)  If I often wanted to deal with the individual English words making up an identifier, the handling of underscore wouldn't be enough to make Emacs work correctly.

I realize I'm much closer to the power-user end of the spectrum than most typical users, but among those heavily using programming modes, is this such a strange mind-set?

(I have no particular opinion on lua-mode specifically.)

Ken

Underscores and word commands

[Stefan Monnier]

> My "instincts" have long been to interpret "word" as "identifier or keyword"

That's OK.

> in programming modes, to the point of customizing the syntax tables at
> startup to make "_" a word component.  Not for regular expressions, but for

While you're free to do it in your .emacs of course, it's not a good
solution when it makes its way into a package's source code because it
then imposes this conflation of the two concepts on every user (they
can't easily fix it in their .emacs).

C-M-SPC, C-M-f, and C-M-b already jump over symbols in many of the
relevant cases, but we should probably offer, along the lines of
subword-mode, a new minor mode that makes word commands operate on
symbols rather than just words (without messing with syntax tables,
since that can have much further reaching consequences).


        Stefan

Re: Underscores and word commands

[John Yates]

On Thu, Jan 19, 2012 at 1:57 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> ... we should probably offer, along the lines of
> subword-mode, a new minor mode that makes word commands operate on
> symbols rather than just words

Yes! Please do.  24.2?

/john

Re: Underscores and word commands

[Stefan Monnier]

>> ... we should probably offer, along the lines of
>> subword-mode, a new minor mode that makes word commands operate on
>> symbols rather than just words
> Yes! Please do.  24.2?

Thank you for volunteering to code it up ;-)


        Stefan

Re: Last call for lua-mode contributors

[Miles Bader]

2012/1/20 Ken Raeburn <raeburn@raeburn.org>:
> My "instincts" have long been to interpret "word" as "identifier or
> keyword" in programming modes, to the point of customizing the
> syntax tables at startup to make "_" a word component.  Not for
> regular expressions, but for word-motion commands; I like the fact
> that I can skip over one identifier with M-f no matter how many
> underscores it contains -- string_to_widget, stringToWidget,
> string2widget, and stringtowidget are all treated the same.  It's
> also more useful in constructing keyboard macros that kill-word
> identifiers and later yank them from the kill ring; typing in a
> regexp search would be much more annoying.

Emacs contains convenient commands to do exactly those things
regardless of word-syntax:  C-M-f (forward-sexp), C-M-k (kill-sexp)
etc.  Obviously these commands are even _more_ "reliable" in that
sense because they work the same in _all_ programming modes, and don't
depend on user-customization.

So when editing in a programming-mode buffer, one can use whichever
unit is most suited for the job: moving over/killing/etc _symbols_ if
that's what one wants to do, but allowing convenient editing of words
within symbols when _that's_ the goal -- and in my experience, I very
often want to the latter, even when programming (which is why lua-mode
drives me crazy).   One really can have the best of all worlds:
convenience, reliability, consistency, flexibility ... but only if
modes don't randomly screw around with syntax...

For instance, I want to write a new function "mypackage_frob_numnum".
I copy an existing function "mypackage_snort_numnum", and change
"frob" to "snort" ... but in lua-mode the hardwired-into-my-fingers
method of doing this doesn't work, I have to hit C-f a bunch of times
(typically only _after_ trying to use M-f and having it do the wrong
thing)...

> I haven't made the customization yet at my new (well, ~2 years) job
> -- but that's because our coding standards use
> camelCaseAndNoUnderscores so the word-motion commands already work
> on identifiers and not on (English) words.  (Though I've been
> dealing with Linux code lately, so it may be time to make the
> change.)  If I often wanted to deal with the individual English
> words making up an identifier, the handling of underscore wouldn't
> be enough to make Emacs work correctly.

[There are actually modes which make word-commands respect
"STuDlyCapS" though...]

> I realize I'm much closer to the power-user end of the spectrum than
> most typical users, but among those heavily using programming modes,
> is this such a strange mind-set?

Wellllllll.... it does seem like a "power-user," and especially a
programmer, would be most likely to know about and use Emacs'
programming-specialized movement commands ..... :]

-miles

-- 
Cat is power.  Cat is peace.

Re: Last call for lua-mode contributors

[Ken Raeburn]

On Jan 20, 2012, at 00:12, Miles Bader wrote:
> Emacs contains convenient commands to do exactly those things
> regardless of word-syntax:  C-M-f (forward-sexp), C-M-k (kill-sexp)
> etc.  Obviously these commands are even _more_ "reliable" in that
> sense because they work the same in _all_ programming modes, and don't
> depend on user-customization.

I actually use some of them frequently when dealing with parenthesized lists like argument lists… but I guess for some reason I don't think of them when I'm working with a single identifier or keyword.  Without the parens or some opening delimiter, I guess it just doesn't say "s-expression" to me; time to do some retraining I guess….

It's not immediately obvious looking at the description of forward-sexp, though, that it's really suitable for other modes.  For example, it refers to a "balanced expression (sexp)", which doesn't tell me very well what to expect if the cursor is pointing at "int" or "return" (which aren't expressions) or "sizeof x" (which is an expression only if you include both words).  The help message says it comes out of lisp.el, which is not encouraging if I'm in C mode; I'd half expect it to assume Lisp comment syntax or not work with braces.  (I'm not saying it doesn't work; I know it does.  I'm saying the description could be improved.  But not by me at this hour.)

And now that I'm taking a fresh look at the s-expression bindings I should be using more, I want eval-last-sexp in C mode to evaluate C expressions. :-)

> [There are actually modes which make word-commands respect
> "STuDlyCapS" though…]

If they're minor modes suitable for use in conjunction with programming modes, that might be suitable, yes.

>> I realize I'm much closer to the power-user end of the spectrum than
>> most typical users, but among those heavily using programming modes,
>> is this such a strange mind-set?
> 
> Wellllllll.... it does seem like a "power-user," and especially a
> programmer, would be most likely to know about and use Emacs'
> programming-specialized movement commands ..... :]

*ahem*  Yeah, I guess you got me there… I do use some of them, but after 20+ years I guess I've developed some habits that give me blind spots to some places where I should be using them.  Okay, I'm convinced....

Ken

Re: Last call for lua-mode contributors

[Stefan Monnier]

> [lua-mode redefines "_" as a word-component; it shouldn't, as it
> really messes with users' instincts, and makes Emacs commands less
> useful.  Historically this was often done by language-modes as an

BTW, this reminds me: why do word-based movement commands even care
about the syntax-table?  I understand that it's the way they're
currently implemented, but AFAICT we don't actually want their behavior
to depend on the major mode, do we?


        Stefan

Re: Last call for lua-mode contributors

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> [lua-mode redefines "_" as a word-component; it shouldn't, as it
>> really messes with users' instincts, and makes Emacs commands less
>> useful.  Historically this was often done by language-modes as an
>
> BTW, this reminds me: why do word-based movement commands even care
> about the syntax-table?  I understand that it's the way they're
> currently implemented, but AFAICT we don't actually want their behavior
> to depend on the major mode, do we?

Dunno, I suppose sometimes maybe it is reasonable to allow the details
to be tweaked; it's "consistency of feel" which is the goal, which may
not always entail literal consistency....

For instance:  is a single-quote part of a word?

In text-mode, it is, and that makes some sense, because single-quotes
are mostly followed by a single letter to form a contracted thingie.
Having word commands stop at the single-letter boundary in such cases
would be pretty annoying and not particularly useful, and generally
wouldn't feel "right" (even though there's a visual boundary).

However in some programming language mode that uses single-quotes like
Ada does, as an operator, you really want them to be punctuation,
because they are used to separate independent pieces that are thought of
as independent.

-Miles

-- 
Discriminate, v.i. To note the particulars in which one person or thing is,
if possible, more objectionable than another.