my code and the terminal .
file = "ex25.py", line 27
words=sort_sentence(sentence)
IndentationError: unindent does not match any other indentation level
The code I wrote in ex25 is:
def print_first_and_last_sorted(sentence):
words =sort_sentence(sentence)
print_first_word(words)
print_last_word(words)
After you define function with the first line, in the second line you need to use proper indentation or spaces. The standard is 4 spaces (4 space keystrokes) or 1 tab.
def print_first_and_last_sorted(sentence):
words =sort_sentence(sentence) # This line and next should be spaced 4 times with
print_first_word(words) # respect to the above one
print_last_word(words)
Your second line is not indented properly. You can compare it with the next lines. They all should be vertically parallel at their start points.
I can't comment but from both the edit and the original post, therefore I can't tell what the indentation actually is.
Python indentation works like blocks of code, similar to other languages except without the curly braces. For example:
def print_first_and_last_sorted(sentence):
words = sort_sentence(sentence)
print_first_word(words)
print_last_word(words)
You may have mixed up spaces & tabs. From this answer, try searching and replacing to replace them with a few spaces.
Related
Trying to create a timestamp snippet in VS Code that produces yyyy-MM-ddThh:mm:ssZ.
Tried so far:
$CURRENT_YEAR-$CURRENT_MONTH-$CURRENT_DATE","T","$CURRENT_HOUR:$CURRENT_MINUTE:$CURRENT_SECOND","Z" but the commas place each section on a new line.
2021-06-27
T
08:57:03
Z
How do I get the "T" and "Z" characters inline here?
You have to do two things:
Put the whole thing on one line - the ,'s are seen as line breaks.
Wrap each variable in ${....} so that they work properly with the other charcters T and Z right next to them. Otherwise the variables cannot be interpreted properly. So:
"${CURRENT_YEAR}-${CURRENT_MONTH}-${CURRENT_DATE}T${CURRENT_HOUR}:${CURRENT_MINUTE}:${CURRENT_SECOND}Z"
I'm writing a text on C++. But often the line breaks after the first "+", so I get C+
+
This is just an example. How can I prevent line breaking of arbitrary parts in my odt doc?
There is no formatting option at the moment
Use the Unicode Character U+2060. Insert it an every point the line breaks, but it shouldn't. It glues two parts together.
Example for "C++" ( | represents the text cursor )
C|++
Press Ctrl+Shift+U
u will appear on the screen
Type in 2060
Press Enter
Now the line won't break between C and +.
Move cursor: C+|+
repeat process
Problem:
In Emacs configuration modes (e.g. conf-xdefaults-mode or conf-space-mode), some special characters are used in unusual ways, for instance when they define keybindings. This messes up the highlighting for the rest of the buffer.
Example:
The ranger rc.conf file uses conf-space-mode which greatly helps its readability. But lines such as:
map # console shell -p%space
map "<any> tag_toggle tag=%any
mess up the highlighting since # usually defines a comment and is followed by font-lock-comment-face until the end of the line and " defines the beginning of a string and is followed by font-lock-string-face until it encounters a closing quote.
Escaping those characters is not an option because it would prevent them from defining the keybindings.
Possible solution:
The best solution I can think of is to fiddle with font lock settings for those configuration modes to remove the highlighting after those special characters. But I will then loose the proper highlighting after those characters when it is suitable.
A compromise could be to keep highlighting after # since this only messes up one line and there are a lot of comments in those configuration files, while removing the highlighting after single and double quotes since those mess up the entire rest of the buffer and strings are not so common in configuration files.
Question:
What is the proper way to deal with these situations?
Is there a way to reset the highlighting at a point in the buffer? or to insert a character which would affect the highlighting (to fix it) without affecting the code? or is there a way to "escape" some characters for the highlighting only without affecting the code?
The easy way
It's probably easiest to just live with it but keep things constrained. Here, I took ranger's default rc.conf and re-arranged some of the font-lock errors.
Let's ignore the blue "map" for now. We have two visible font-lock errors. The map #... is font-locking as a comment, and the map "... font-locking as a string to the end of the buffer. The first error is self-constrained. Comments end at the end of the line. The second error we constrain by adding a comment. (I don't know if ranger would accept comments in the middle of the line, so I'm only using beginning-of-line comments here.)
The second error is now constrained to one line, but a couple more errors have popped up. Quickly adjusting these we get.
This is something that I could live with, as I'm not in conf files all day long (as opposed to say, source code.) It would be even neater if our new "comments" could be included on the same line.
The hard way
You'll want to use Emacs font-lock-add-keywords. Let's get back to that blue map in the first image. It's rendering blue because conf-space-mode thinks that a string, followed by any amount of whitespace, followed by an opening brace should be rendered in font-lock-type-face (the actually regexp that triggers this is ^[_space__tab_]*\\(.+?\\)[_space__tab_\n]*{[^{}]*?$ where _space_ and _tab_ are actual space and tab characters.)
We can override this in a simple fashion by evaluating
(font-lock-remove-keywords
'conf-space-mode
'(("^\\<\\(map\\)\\>" 1 font-lock-variable-name-face)))
and reloading the buffer with C-x C-v RET. Now, every time that the word "map" appears at the beginning of a line it's rendered as font-lock-variable-name-face (yellow in our example.)
You can make this change permanent by adding a hook to your init file.
(add-hook 'conf-space-mode-hook (lambda ()
(font-lock-remove-keywords
nil
'(("^\\<\\(map\\)\\>" 1 font-lock-variable-name-face)))))
This method doesn't appear to work for your comment (#) and string (' ") delimiters as they're defined in the syntax table. Modifying the syntax table to provide special cases is probably more effort than it's worth.
I created a README.md file on GitHub and there are some markdown problems I can't find a solution to.
When I enter this (The dots represent space signs):
Instructions:..
....1. First sentence..
....2. Second sentence..
........This is some code.
....3. Third sentence..
....4. Fourth sentence
It renders to this:
Instructions:
1. First sentence
2. Second sentence
This is some code.
3. Third sentence
4. Fourth sentence
How can I separate the code block from the numbered list?
I would also like to know how I can tell Markdown to ignore Markdown syntax so I don't have to use dots as a representation of space signs.
How about this?
Instructions:
1. First sentence
2. Second sentence
`This is some code.`
3. Third sentence
4. Fourth sentence
It wouldn't indent each point, however your example with the dots doesn't do it either.
If the spacing between Instructions: and the rest is not what you want, you can use the double space after it and on the two following lines.
UPDATE:
After a little fiddling, if you want to keep the numbering of the list and put some code that's relative to a single item on the list you should indent the code block.
Also, have a new line before the first element of the list seems to help.
I've been trying to make use of a cool feature of YASnippet: write snippets containing embedded Emacs Lisp code. There is a snippet for rst-mode that surrounds the entered text with "=" that is as long as the text such as in
====
Text
====
Based on this snippet, I decided to slightly modify it (with Elisp) so that it comments out these three lines depending on the major mode you are in (I thought that such a snippet would be useful to organize the source code). So I wrote this:
${1:`(insert comment-start)`} ${2:$(make-string (string-width text) ?\-)}
$1 ${2:Text}
$1 ${2:$(make-string (string-width text) ?\-)}
$0
This code works relatively well except for one problem: the indentation of these three lines gets mixed up, depending on the major mode I'm in (e.g., in emacs-lisp-mode, the second and the third lines move more to the right than the first line).
I think the source of the problem might have something to do with what comes after the string ${1: on the first line. If I add a character, I have no problem (i.e., all three lines are correctly aligned at the end of the snippet expansion). If I add a single space after this string, the misalignment problem still continues though.
So my question is: do you know of any way of rewriting this snippet so that this misalignment does not arise? Do you know what's the source of this behaviour?
Cheers,
From Writing snippets:
yas/indent-line
The variable yas/indent-line controls the indenting. It is bound to 'auto by default, which causes your snippet to be indented according to the mode of the buffer it was inserted in.
Another variable yas/also-auto-indent-first-line, when non-nil does exactly that :-).
To use the hard-coded indentation in your snippet template, set this variable to fixed.
To control indentation on a per-snippet basis, see also the directive # expand-env: in Writing Snippets.
For backward compatibility with earlier versions of YASnippet, you can also place a $> in your snippet, an (indent-according-to-mode) will be executed there to indent the line. This only takes effect when yas/indent-line is set to something other than 'auto.
for (${int i = 0}; ${i < 10}; ${++i})
{$>
$0$>
}$>