While looking through the Snap.svg tutorial, I came across the following line of code that made me do a double take:
// Now lets create pattern
var p = s.path("M10-5-10,15M15,0,0,15M0-5-20,15")
What is M10-5-10,15? At first, I thought it may have been some kind of coordinate-range syntax, but that wouldn't really make much sense in this case, and I couldn't find anything remotely close to that in the SVG path spec. I also couldn't find anything of note in the Snap.svg docs.
Interestingly enough, that code does seem to draw the desired pattern...
The simplest answer is often the right one. There is no special syntax - the coordinates are just concatenated together with no white space.
The clue is the command: M is the moveto command, which doesn't normally draw anything. If you look in the spec, however, you'll notice the following:
If a moveto is followed by multiple pairs of coordinates, the
subsequent pairs are treated as implicit lineto commands.
So, a moveto can actually have multiple coordinate pairs, and anything after the first pair is treated as a lineto command. The mystery syntax is, in reality, just a concise (but less readable) way of writing M10,-5 -10,15 M15,0 0,15 M0,-5 -20,15, the hyphens being the negative signs.
Simply looking at the SVG path grammar also shows quite clearly that the arguments to moveto are coordinate-pairs, and coordinates are simple numbers.
I suppose the key thing to take away is that SVG paths don't really need whitespace or commas, unless the numbers would be ambiguous without them.
Related
I have the following function definition:
def test(these, are=0, args=1):
pass
I want to find a quick and intuitive way to hop between each argument.
For example, pressing w/b is too slow because it will hit the commas, but even worse it is it will hit the =. W/B works great except with that first argument because test(these is a "WORD".
Is there an existing way to navigate this list that works the same for all arguments, or is there a common modification to do this? For example, can I redefine what a WORD is and make the (/) break up a WORD? I can't think of a good example of when I would have a legitimate WORD with a paren right in the middle.
The big complication with argument lists is complex expressions and nested function calls (e.g. foo(1, bar(2, 3), 4)). To handle those, at least some basic parsing is necessary; simple pattern matching (as can be done with built-in commands) won't do.
I personally use a combination of basic Vim commands, tailored to the current situation (i.e. w / W / f{char}), and the following plugins:
sideways has mappings to jump to next / previous arguments, to move arguments around, and corresponding text objects
fieldtrip builds on top of sideways and offers a submode, where individual keypresses can then be used to jump / move
Just try using ft f0 or f1 to see if these jumps can help you.
Background
Most style guides recommend keeping line lengths to 79 characters or less. In Haskell, indentation rules mean that expressions frequently need to be broken up with new lines.
Questions:
Within expressions, where is it legal to place a new line?
Is this documented somewhere?
Extended question: I see GHC formatting my code when it reports an error so someone has figured out how to automate the process of breaking long lines. Is there a utility that I can put haskell code into and have it spit that code back nicely formatted?
You can place a newline anywhere between lexical tokens of an expression. However, there are constraints about how much indentation may follow the newline. The easy rule of thumb is to indent the next line to start to the right of the line containing the expression. Beyond that, some style things:
If you are indenting an expression that appears in a definition name = expression, it's good style to indent to the right of the = sign.
If you are indenting an expression that appears on the right-hand side of a do binding or a list comprehension, it's good style to indent to the right of the <- sign.
The authoritative documentation is probably the Haskell 98 Report (Chapter 2 on lexical structure), but personally I don't find this material very easy to read.
Is there a way to assign an individual character, as identified by a height and depth index, to a highlight group? Every match feature I have come across uses a regex pattern as input.
The reason I ask is because I am making a syntax coloring plugin that will make text an increasingly lighter shade of gray with increasing parenthesis depth. If vim has no such feature and another algorithm makes character-by-character highlighting unnecessary, please point me to it!
Vim has a whole set of special regular expression atoms that can specify buffer positions.
For lines, \%23l matches only in line 23. You can also use \%>23l for all lines starting from 23, and concatenate two of those with < and > to specify ranges.
For columns, there are the corresponding \%23c and \%23v. The former uses byte indices (what Vim somewhat confusingly calls "columns"), as returned by functions like col() and getpos(), the latter screen widths (from virtcol()).
By combining those atoms, you can select arbitrary blocks of text, and highlight them, e.g. with :call matchadd(...). See :help /\%l for details on the atoms.
For your plugin implementation, you may be able to get some ideas from the vim js context coloring plugin, which highlights JavaScript code according to its scope.
Is there any standard way to specify the set of characters that vim uses to enumerate lines? For example, instead of numbers in succession, could I use lower-case letters {a, b, ..., aa, ab, ac, ...} (or even better, use only the characters in a keyboard's home row) and still act on specific lines by this new referencing system?
I suppose an escape key of sorts -- perhaps ':' or 'g' -- might be needed, but even so, if anyone has suggestions as to how I could implement this, I'd be quite appreciative.
Thanks.
There's nothing built-in other than absolute and relative line numbers, and it would be difficult to square a different addressing scheme with the numerical [count] prefixes to the Vim motions. However, plugins like EasyMotion and vim-seek implement such, though for motions like the built-in f inside a line.
For implementation tips, have a look at the RltvNmbr.vim plugin; it uses the sign column to emulate the now built-in relative numbering. As the sign column is two characters wide (and can display arbitrary characters), this would be fitting. That would take care of the visualization... you'd then only need a custom mapping to query for the Base26 line number, and translate that back into a jump.
OK, so here's an unusual one. Every time you see an example of Haskell's record syntax, it always looks like
Sphere {center = 0, radius = 2}
or similar. My question is... are those curly brackets actually part of the record syntax? Or are they actually shorthand for layout? In other words, can you actually write something like
Sphere
center = 0
radius = 2
and have it work?
I doubt it would be very useful to do this - it takes up a lot of visual space - but I'm just curious as to whether this is syntactically valid or not.
Layout is an alternative to explicit braces and semicolons.
Record syntax uses explicit braces and commas.
So no, you can't use layout as part of record syntax.
Haskell Report 2010 ยง2.7 Layout:
Haskell permits the omission of the braces and semicolons used in several grammar productions, by using layout to convey the same information.
OK, well I thought I'd put this question here in case anybody was interested. Having consulted the Haskell Report itself, it appears that the braces are literally a formal part of the record construct:
http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-690004.2.1
That means that these tokens actually have two distinct meanings in Haskell - as declaration delimiters when layout is not being used, and as record delimiters. I bet that leads to some interesting parser edge-cases!
(I also note in passing that EmptyDataDecls appears to be on by default in Haskell 2010, which is worth knowing...)
After Sphere, the lexer won't insert a brace. Why should it? You dont expect a brace inserted in code like:
z = x
+ y
either, do you?