I have set up auto-pairing for Light Table for the characters "({[ and their counterparts (Important Note: I using the german keyboard layout). This is was done by adding [:app :lt.objs.settings/pair-keymap-diffs] to my user behaviors (does the trick for ") and
[:editor "alt-[" (:editor.open-pair "[")]
[:editor "alt-{" (:editor.open-pair "{")]
[:editor "alt-]" (:editor.close-pair "]")]
[:editor "alt-}" (:editor.close-pair "}")]
to my user keymaps. When I now type a {, into the editor a [] is inserted. How do I set it up properly? Thanks in advance.
The correct answer could be found in this github issue. I removed the above code from my keymaps and instead added the following code to my behaviors:
;; Normal brackets autoclose
[:app :lt.objs.editor/load-addon ["edit/closebrackets.js"]]
[:editor :lt.objs.editor/set-codemirror-flags {:autoCloseBrackets true}]
You might have to remove the lighttable autoclose plugin:
[:editor :-lt.objs.settings/pair-keymap-diffs]
Related
enter image description here
When I use VS Code, a problem notice likes that(in the above image) is printed.
Although I want to fix it and really don't want to see it, I can't find any way to fix.
I am very painful about just seeing that error message all the time.
Please give me some helps.
You opened a { parenthesis at line 2784 and didn't close it. You should close it. --> }
Also, you have an extra comma , at 2793 that you have to remove.
Not use {}, because you may already mess your settings.json before.
so my suggestion as follows:
// in/your/settings.json/file
...
setting0_name:[setting0.0, setting0.1],
seting1_name : settings,
...
Chrome 24 has a new way of outputting objects in console.log().
For example, console.log($("p")); on this jsFiddle example outputs this insanity:
▼[<p>, <p>, <p>, prevObject: jQuery.fn.jQuery.init[1], context: #document, selector: "p"]
► 0: <p>
► 1: <p>
► 2: <p>
► context: #document
length: 3
► prevObject: jQuery.fn.jQuery.init[1]
selector: "p"
► __proto__: Object[0]
I can see that it puts the collection of DOM elements at the beginning. But if you try to expand even a simple <p> tag that is mostly empty, it throws up all over you:
▼ 0: <p>
accessKey: ""
align: ""
► attributes: NamedNodeMap
...
[stopping here for sanity's sake]
So how do I use all this information? My first instinct is to tame it down to how it used to look, but on second thought, there really is a lot of info in there that I might want to have access to. But I'm having a hard time understanding what I'm looking at. Much of it looks like jQuery values. Is this a list of every jQuery value that the object has (or doesn't have)?
Then there's the whole issue of the ► context: thing and the ► __proto__: thing. Once you start drilling down in __proto__ you will never stop. I think it goes infinitely down!
How can I begin to learn how to use this new output?
EDIT:
I actually just realized that I'm still using Chrome 23, this isn't something that was introduced in 24. Someone in this thread said it was a Chrome 24 issue, but maybe it's new in 23? At any rate, I only just recently started noticing this on jQuery objects.
EDIT 2: If you're just looking for how to log the old way, try this: (hat tip)
console.log.apply(console, $("div"));
In your demo fiddle, you are logging NodeLists or HTMLCollections. Each of the elements within a NodeList is represented as a numeric index 0, 1, 2, etc. 0 being the first in the NodeList if any elements exist in it.
When you expand the Elements you see all available properties of an HTML Element as defined in DOM Core 3 specification. Refer here for more information about this http://domenlightenment.com/#3.2 and for a list of all properties and their purposes go here: https://developer.mozilla.org/en-US/docs/DOM/element. None of this is new in Chrome.
What is new in the latest Chrome version is the top level logged object, so if you just opened the console and typed:
console.log(window)
Which for me when I just did it logged a preview of what the expanded window object it provides when logging it. So for example, you should see something like:
Window {is_minor: 5, bmi_ie6: false, careers_adselector: "div.hireme, div#hireme"...}
Other NodeLists properties listed below the Elements of the list:
context - the context of the selection - http://domenlightenment.com/#4.4
length - the number of Elements in the HTMLCollection
selector - the selector used to select the Element or NodeList
__proto__ - An Object's __proto__ property references the same object as its internal [[Prototype]] (often referred to as "the prototype"), which may be an object or null (in the case of Object.prototype.__proto__). For more info on this refer to: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Object/proto
I modified the fiddle slightly and should show the preview of the objects when you view the console http://jsfiddle.net/jaredwilli/H3YWq/2/
You can't really get rid of any of these things either, they're a part of the DOM and will exist always otherwise the NodeType of what you're looking at will be something other than an ElementNode.
I'm just as annoyed as you are with this change. I know this isn't ideal, but it will hopefully help you a little bit.
console.log($('p')[0]);
You may have seen that solution before, and then found it didn't work if you were in a loop for instance:
$('p').each(function(){
console.log($(this)[0]);
});
That doesn't end up giving you the result you were used to either, so I had to use ['context'] instead of [0] like this:
$('p').each(function(){
console.log($(this)['context']);
});
Again, I'm looking for a better solution myself, but I thought I'd share with you what I've found.
You want first element so use [0]
As another option, check out Firebug in Firefox. I know, I love chrome too and use it every day, but Firebug is a great plugin and I've never had an issue with it.
It is looks like W3C's validator return a validation error on prettyPhoto's rel attribute for HTML5 pages. How do I solve this error?
Bad value prettyPhoto[gallery1] for attribute rel on element a: Keyword prettyphoto[gallery1] is not registered.
Many thanks!
Using rel attribute with non-proposed (thus not allowed) values not valid for HTML5 markup. Value prettyPhoto is not in the list of proposed values. So you may face the difficulties with getting your web-page with image gallery passing validation.
A Possible Solution:
Open jquery.prettyPhoto.js (presumably non-minified one) and perform find & replace function of your text-editor: replace all occurrences of attr('rel') with attr('data-gal').
In your gallery code use:data-gal="prettyPhoto[galname]"instead of:
rel="prettyPhoto[galname]"
Initialize your prettyPhoto with:
jQuery("a[data-gal^='prettyPhoto']").prettyPhoto();
And you are on the right way for getting your code valid!
You can also read this article with this possible solution.
You can use the (undocumented) hook setting as mentioned in the comments here.
Specify your links like this: and use $("a[data-gal^='prettyPhoto'").prettyPhoto({hook: 'data-gal'}); to initialize prettyPhoto.
You can also fix it by updating the settings to use the class hook:
s = jQuery.extend({
...
hook: "rel",
animation_speed: "fast",
ajaxcallback: function() {},
slideshow: 5e3,
autoplay_slideshow: false,
opacity: .8,
...
to:
s = jQuery.extend({
...
hook: "class",
...
To set the html of elements on my site, I use mostly
$('elementId').innerHTML = "<p>text</p>";
Looking through the mootools docs, I found this example given:
$('myElement').set('html', '<div></div><p></p>');
Is there any difference between these? Should I go through and change .innerHTML to the mootools method, or doesn't it make a difference?
the reason why the first one works is because - as it stands - a $ selector (document.id) in mootools returns the actual element. this - in normal browsers - is identical to document.getElementById() and the element object exposes any and all of its attributes/properties for you to edit.
the problems with NOT using .set are:
when mootools 2.0 aka MILK gets released, it won't work as it will be wrapped like jQuery and the selector won't return the object (mootools is becoming AMD hence it won't modify native Types - Element, Array, Number, String, Function(maybe!) - prototypes).
you cannot chain this. with set you can: $('someid').set("html", "loading...").highlight();, for example.
set is overloaded - it can set either a single property or multiples by means of passing an object. eg, element.set({html: "hello", href: "#", events: boundObj});
look at https://github.com/mootools/mootools-core/blob/master/Source/Element/Element.js#L936-942 - you can pass an array as an argument and it will join it for you, this makes it easy to work with multi-line strings and ensures performance in IE
edit: the BBT fan has kind of opened a separate topic: should the framework try to block you / prevent you from doing things that break the browser?
if you want to, you can add disallowed elements by changing that setter Element.Properties.html.set = function() { var tag = this.get("tag"); ... check tag }; - isn't mootools great?
mootools - by default - will NOT try to prevent you from doing stupid shit [tm] - that's your responsibility :) try setting height on an element to a negative value in IE, for example. should the Fx class prevent you from doing that? No. Should the setter prevent you? No. The footprint of constant checks to see if you are not breaking means it will slow everything down in performance-critical cases like animations.
I'm using the actionscript-mode-connors.el for indenting Actionscript 3 code in emacs.
I have most things figured out, but one thing bothering me is when I use an inline closure as a function argument, the indentation of the interior of the function is screwed up.
For example:
var foo:int = some_function(
bar,
baz,
function():void {
return qux();
},
zap);
I want return qux() to be a single indent from the function declaration on the previous line, not a single indent from the open paren. The indentation of 'bar' used to be screwed up too but I fixed that with
(add-hook 'actionscript-mode-hook
(lambda ()
(c-set-offset 'arglist-intro '+)
(c-set-offset 'arglist-close 0)))
Typically here I would use C-c C-s to figure out what syntactic symbols I need to change, but the problem on the 'return qux()' line is that the syntax context is
((arglist-cont-nonempty 731 758) (brace-list-intro 731))
where those numbers refer to the 'some_function' line. 'arglist-cont-nonempty' seems like a mistake, and it seems like it should be 'arglist-cont', since there's nothing after the open paren on that line. I can't change the indentation for 'arglist-cont-nonempty' since that would affect the case where the open paren does not end the 'some_function' line as well.
How can I fix this?
I would use espresso-mode for ActionScript. It indents your example correctly.
How about an indirect answer? It seems as though you're relatively comfortable with the C indentation machine. You might want to use advice around 'c-guess-basic-syntax to recognize the particular configuration and modify it to be what you think would make the most sense for that situation.
If you take a look at this answer for an indentation customization for comments, I essentially did the same thing, only at the point of indentation.
Regarding your specifics, I cannot reproduce the same failure you have, my indentation for that chunk of code (in 'actionscript-mode with your two changes) looks like:
var foo:int = some_function(
bar,
baz,
function():void {
return qux();
},
zap);
Also, the syntax for the return qux(); line is: ((brace-list-intro 319)).
It seems that your hunch is correct (that the arglist-cont-nonempty list is the problem), and changing the output of 'c-guess-basic-syntax seems like it would be a viable solution.
Can I also point out the obvious test? Have you started without any customizations and loading just action-script? I did so with the latest action-script and Emacs 23.1 and got the results you see above. Tested with M-x c-version showing both 5.31.3 and 5.31.7 (the later is distributed with Emacs 32.1).