Consider the following dataset:
<uses-configuration
android:reqFiveWayNav=["true" | "false"]
android:reqHardKeyboard=["true" | "false"]
android:reqKeyboardType=["undefined" | "nokeys" | "qwerty" | "twelvekey"]
android:reqNavigation=["undefined" | "nonav" | "dpad" | "trackball" | "wheel"]
android:reqTouchScreen=["undefined" | "notouch" | "stylus" | "finger"] />
I am trying to select all the values after android:
In order to do this, i am using (a\w+:)(\w+) which does exactly what i want. I know that I can use the search and replace and use$2 to select the second group, but I dont want to replace anythin. I want to select anything the second group matches with alt+enter key press.
Is this possible?
What you really need is a lookaround. I don't believe that vscode supports lookbehinds (see issues: lookbehind support coming). But it does support lookaheads so :
(\w+)(?=\=\[.*\])
should work for you as long as your desired values are followed by "[.*]" and nothing undesired has that pattern. The lookahead part will not be selected by vscode. And then Alt-Enter selects all the matches.
If lookbehind was supported, maybe soon, this would work:
\b(?<=a\w+:)(\w+)\b
Just a note that indeed lookbehinds were implemented in vscode since the question and answer so the lookbehind solution \b(?<=a\w+:)(\w+)\b does work now.
Related
I am currently working with Postgresql and I am facing a problem.
I have two tables "question" and "question_detail" in which there are codes. In "question_detail" are the codes including subcode so e.g. TB01Q07, TB01Q07a, TB01Q08_SQ002. Now I wanted to use the command LIKE to see if the table "question" also contains these records. But in "question.code" there are only codes without the following underscore. This is a table that was given to me, I find this somehow very stupid.
The problem is that when I search with LIKE the value TB01Q07a is listed twice. This is also understandable to me, since searching for TB01Q07% also returns the value TB01Q07a.
Does anyone know of a way to search only for TB01Q07a without it resulting in TB01Q07% as TB01Q07a?
Command
SELECT qd.code, qd.label, q.type
FROM public.question q,
public.question_detail qd
where CASE
WHEN qd.code = q.code THEN qd.code = q.code
ELSE qd.code like CONCAT(q.code,'%')
END;
question
| code | type |
| ---------|-------- |
| TB01Q07 | comment |
| TB01Q07a | comment |
| TB01Q08 | option |
**question_detail**
```none
| code | label |
| -------------- | ------|
| TB01Q07 | AB01 |
| TB01Q07a | AB02 |
| TB01Q08_SQL002 | AB03 |
I ran the SQL and wanted the TB01Q07a value to appear only once and not be listed twice.
I think I have found a solution with distinct on.
SELECT distinct on (qd.code) q.id_question,qd.code, q.question, q.question_type
FROM public.question q, public.question_detail qd
where qd.code like CONCAT(q.code,'%');
like('TB01Q07%') matches both TB01Q07 and TB01Q07a, so you get two rows for TB01Q07 and one row for TB01Q07a.
You need to be more precise and include the underscore. Also make sure it's escaped, _ means any one character in a like.
There is no need for a case, use or. Avoid using multiple from statements, use an explicit join with an explicit on. This is clearer and gives you more control over the join.
select qd.*, q.*
from public.question q
join public.question_detail qd
on qd.code = q.code OR qd.code like q.code || '\_%'
Demonstration.
Note: this problem doesn't exist if you use foreign keys. Assign unique IDs to question and reference them in question_detail. This is faster, shields you from changes to the question code, and ensures the referred to question exists.
How can you add tables with multi-row cells to markdown in Microsoft VSTS?
I have previously used asciidoc for readme files on github as it is both richer and less ambiguous. The company now has projects on VSTS which does not support asciidoc so I need to use markdown instead.
However, it is unclear what flavour of markdown is actually supported
This page says that github flavoured markdown can be used
https://learn.microsoft.com/en-us/vsts/collaborate/markdown-guidance
I found another page saying they use commonmark via the markdown-it library.
Q: Does VS Code support GitHub Flavored Markdown?
A: No, VS Code targets the CommonMark Markdown specification using the
markdown-it library. GitHub is moving toward the CommonMark
specification which you can read about in this update.
I've been using a combination of asciidoctor and pandoc to convert files but nothing gets it quite right.
(Asciidoctor converts to docbook which pandoc can then parse)
asciidoctor -b docbook -v -o "$OUTPUT".xml "$INPUT" &&
pandoc -f docbook -t markdown_github -i "$OUTPUT".xml -o "$OUTPUT"
I have to re-add the title manually.
My current stumbling block is multi-row cells.
Github supports grid tables,
see Newline in markdown table?:
+---------------+---------------+--------------------+
| Fruit | Price | Advantages |
+===============+===============+====================+
| Bananas | first line\ | first line\ |
| | next line | next line |
+---------------+---------------+--------------------+
| Bananas | first line\ | first line\ |
| | next line | next line |
+---------------+---------------+--------------------+
But neither this nor embedded html seem to work in VSTS.
I would be happy to use html readmes instead if that was permitted.
Update 17-Nov-2017:
I found the link to markdown-it and added it above. I've raised an issue there for clarification (or enhancement). Its unclear which version VSTS actually uses under the hood.
I would like to ask the question of Microsoft themselves but their ask a question link goes straight to stack overflow.
The markdown-it library does support the usage suggested by #Waylan:
| Fruit | Price | Advantages |
| ------------- | ----------------------- | ----------------------- |
| Bananas | first line<br>next line | first line<br>next line |
| Bananas | first line<br>next line | first line<br>next line |
See https://github.com/markdown-it/markdown-it/issues/406.
The issue is most likely Microsoft disabling html.
A solution thus waits on a reply to #starian's suggestion: https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/32312290-multi-line-in-the-cell-of-a-table-in-markdown-in-v
In short, each row must be on one line and should use <br> to indicate a line break. Like this:
| Fruit | Price | Advantages |
| ------------- | ----------------------- | ----------------------- |
| Bananas | first line<br>next line | first line<br>next line |
| Bananas | first line<br>next line | first line<br>next line |
Below is an explanation of each tool with an analysis of that tool's documentation:
GitHub
CommonMark is a Markdown variant with a strict spec. GitHub-Flavored Markdown (GFM) is an extension of CommonMark (which adds features to CommonMark such as tables), with its own spec. Therefore, to say that an implementation supports GFM is to say that it supports CommonMark with extensions. Note that GitHub adopted the current spec on March 14, 2017, so any information older that that may not be relevant for the current implementation.
Whether VSTS actually uses a CommonMark/GFM implementation or a close approximation is unclear from the documentation. However, as the documentation clearly states that "GitHub-flavored extensions" are supported, that would indicate to me that the GFM Spec would be a good reference. Regardless, the GFM Spec is the controlling spec for any Markdown rendered on github.com.
The Tables section of the GFM Spec plainly states:
Block-level elements cannot be inserted in a table.
And gives this simple example:
| foo | bar |
| --- | --- |
| baz | bim |
While the spec does not specifically mention multiple line cells, there are no examples with any cells that contain multiple lines. It is my understanding that that is not supported by GFM. Therefore, the only way to include line breaks in GFM Table cells is with the <br> tag, which is not a block-level element.
Pandoc
Pandoc supports multiple different styles of table syntax. If you are passing your Markdown to both Pandoc and GFM, then you need to use Pandoc's table style which most closely matches GFM's style. For example, GFM Tables do not include support for + at the corners. That syntax is specific to Pandoc's Grid Tables. Fortunately, Pandoc's documentation tells us which style most closely matches GFM.
Pandoc has support for various "Markdown Variants", one of which is gfm. The docs have this to stay about that variant:
We also support gfm (GitHub-Flavored Markdown) as a set of
extensions on commonmark:
: pipe_tables, raw_html, fenced_code_blocks, auto_identifiers,
ascii_identifiers, backtick_code_blocks, autolink_bare_uris,
intraword_underscores, strikeout, hard_line_breaks, emoji,
shortcut_reference_links, angle_brackets_escapable.
Note that the gfm variant of Pandoc uses Pipe Tables. It is also noteworthy that the markdown_github variant of Pandoc is deprecated since GitHub adopted Commonmark. But even the markdown_github variant uses Pipe Tables.
Pandocs' documentation for Pipe Tables states (emphasis added):
The cells of pipe tables cannot contain block elements like paragraphs and lists, and cannot span multiple lines.
And gives this example:
| Right | Left | Default | Center |
|------:|:-----|---------|:------:|
| 12 | 12 | 12 | 12 |
| 123 | 123 | 123 | 123 |
| 1 | 1 | 1 | 1 |
That is clearly the same as GFM tables and does not include any support for block level elements or multi-line cells.
VSTS
The VSTS Documentation for Tables closely matches GFM and Pandoc Pipe Tables with this example:
| Heading 1 | Heading 2 | Heading 3 |
|-----------|:---------:|----------:|
| Cell A1 | Cell A2 | Cell A3 |
| Cell B1 | Cell B2 | Cell B3 |
While the the VSTS Documentation makes no specific mention of block-level elements or multiple lines, is seems safe to assume that it is in fact the same style.
We can make that assumption because in all three instances (VSTS, GFM and Pandoc Pipe Tables), the syntax does not provide a divider between individual rows of the table (compare with Pandoc Grid Tables, which supports row dividers). While there is a divider between the header and data rows, with no divider between individual data rows, there is no way to indicate how many lines of text belong to each row. Therefore, each row can only be represented by one line of text.
Conclusion
Given the above, to be parsed properly by VSTS, GFM and Pandoc (gfm variant), your table should be formatted like this:
| Fruit | Price | Advantages |
| ------------- | ----------------------- | ----------------------- |
| Bananas | first line<br>next line | first line<br>next line |
| Bananas | first line<br>next line | first line<br>next line |
And when using Pandoc, be sure to use the gfm format (pandoc -f gfm ...).
It is not supported in markdown of VSTS, I submit a user voice here: multi-line in the cell of a table in markdown in VSTS, you can vote and follow it.
I can't find my way around copying a column, or a series of them, from a table.
The only solution I found so far is to copy the whole table and then delete the columns I don't need.
I suppose there must be another easier way for this. Maybe I am just too tired to realize how to do it.
I think the easiest way would be to take advantage of emacs rectangles
To create your rectangle, put your cursor at one of the corners of the rectangle you want to create.
Use C-SPC, or whatever you have set-mark-command set to.
Place your cursor at the diagonal corner of your rectangle.
Use C-x r rr to copy the rectangle to the register named r
Use C-x r ir to insert the rectangle that is being held in the register named r.
Following this process will copy and insert the columns that you want. You may need to repeat this process if the columns are not adjacent.
NOTE
I am using a bolded r to denote that this is technically a name of the register, and not some special input.
If you specifically want to copy the column(s) into another org table (or indeed back into the original table), there's support for that.
See C-hf org-table-copy-region RET
It works much like the regular rectangle commands, so it's not a better interface for selecting the column; but the associated paste command is smart about what it does with the content.
I you are planning to use emacs rectangle command you avoid the use of registers by using the command copy-rectangle-as-kill bound C-xrM-w, execute the command after selecting a region this will copy the rectangle (see this for an example of how marking rectangles works). Then you can paste the copied retangle by doing C-xry.
UPDATE
The page org-mode hacks describes a way to copy columns using org-table formulas. You will need to name the table.
Here is an example of using table formulas to copy columns from another table
Suppose you have following table named FOO, it is necessary to name the table for referring it from table formulas.
#+TBLNAME: FOO
| 0 | 2 | 1 |
| 1 | 3 | 2 |
| 2 | 4 | 3 |
You want to copy the columns 1 and 3 from table FOO to column 1 and 3 of the following table (lets call it B)
| | 5 | |
| | 6 | |
| | 7 | |
The following formula will do the trick, you will need to copy the formula below the table B and move cursor on the formula and do C-cC-c
#+TBLFM: $1=remote(FOO,###$1)::$2=remote(FOO,###$3)
The table B will be converted to the following
| 0 | 5 | 1 |
| 1 | 6 | 2 |
| 2 | 7 | 3 |
You can read about the syntax of the org table formulas here, basically $N refers to Nth column, #N refers to Nth row. ## and $# can be used instead of N to refer the row and column where the current value goes. remote(table-name, #N$N) refers to the Nth row and Nth column of the table table-name. :: concats multiple formulas.
I too had trouble using the standard rectangle operations. When moving to the next column, all of all of the rows between the point and the mark were highlighted. When I tried copying columns by formula as described above and in the org mode hacks, org threw errors if the column's values were non-numeric with more than one word.
But a good hint about cutting and pasting revealed that the problem is the initial direction of motion of the cursor. Moving first rightward to the next column, then down highlights the correct region. Standard rectangle operations then work correctly.
The "native" way in org mode is already covered in the answer by user2053036; I just wanted to add that in the simpler context, "to copy a column within a table": Let's say you have this table
| hello | world |
| is | good |
And want to repeat column 2 in column 3.
Steps:
Place the cursor after the bottom right | of the table
Open a new column to the right using keys Alt-Shift-<right>
| hello | world | |
| is | good | |
Add the "row copy from" formula (for example by putting cursor to row 1 column 3 and typing =$1 C-c C-c; or just type the TBLFM below the table and jump to step 4)
| hello | world | hello |
| is | good | |
#+TBLFM: $3=$1
Place the cursor on the TBLFM and type C-c C-c
| hello | world | hello |
| is | good | is |
#+TBLFM: $3=$1
That will copy column 1 to column 3.
In this example:
| | num |
|---+-----|
| | 5 |
| | 6 |
| | 4 |
|---+-----|
| # | 15 |
| ^ | sum |
#+TBLFM: $sum=vsum(#2..#-1);
Every time you press "tab" in the sum area or C-c C-c in the table formula area below the table it recalculates the sum area. The problem is after it recalculates this area it adds this new sum to the current sum that's already in the area. (Try it in your emacs).
I've created this basic test to show issues I've encountered in creating complex spreadsheets in org. Until I find a solution I can't trust the sums emacs gives me because I may occasionally press C-c C-c twice and it's inconvenient to have to go and zeo out all sum values in my form every time I recalculate.
If anyone knows a solution, please let me know.
Turns out it was a bug with the Org-mode version I was using:
release 5.23a is from Apr 23 10:17:27 2008
Kudos to Thumper_ in freenode #org-mode for pointing it out.
Be sure to update to the newest version of Org-mode, folks! :)
Maybe it's more clear to use vsum(#I..#II) to indicate the rows between the 2 hlines.
I cannot reproduce your accumulation problem; and just read your answer about the bug!!
So I've been using Sphinx with a rails project lately, I want to provide a list of 'would be' exact matches that would match 100% with a give term. For example something like:
+==================+==========================================================+
| ingredient | exact matches |
+==================+==========================================================+
| cheese, cream | 'cream cheese','philadephia cream cheese','cream chese',|
| | 'creamed cheese' |
+------------------+----------------------------------------------------------+
| Cheese, gruyere | 'gruyere','gruyer cheese','gruyeres cheese' |
| | 'gruyere chese' |
+------------------+----------------------------------------------------------+
| Cheese, blue | 'blue cheese','blu cheese' |
+------------------+----------------------------------------------------------+
So basically the functionality I'm looking for would be that Sphinx would try to do its typical matching on all the records, but if the search term matches exactly with one of the strings in an array in that record that result would have a much higher weight. (like 100x, so it would then be the best match)
Is this possible? It seems like other people would have had this problem before... no?
Update
I suppose the best answer might be to just index the exact matches column and provide a really high weight to the terms.
I'm not sure how I can break up the "array" and see if the search term matches exactly though...
Your should try to play with sphinx search modes. Look at match phrase and match extended2.