Is there column based narrowing in emacs.
I tend narrow in one everything between script tags but that still keeps the original indent (space before var).
It would be great if I could actually column narrow to the the beginning of the indent since otherwise the electrict indent tries to bring it to column 0.
<some html></some html>
<script>
var foo = 1;
var bar = 2;
</script>
<some html></some html>
Alternate solution could be to mark the starting indents as uneditable, but I am also not sure how to do this.
P.S.
I am aware of MMM and NXHTML and html-helper-modes, but I am not looking to use them due to complexities.
Can you put { and } around the code within the script tags? It's not ideal but should keep the same semantics for the code and allow for the indenting (assuming you want one level of indent like in the example you gave).
The table.el package might be a solution. I haven't tested it, so can't be sure that it provides the solution you're looking for, but here's a quote from the mailing-list thread rectangle operations - narrowing?:
there's a package, table.el, which does some stuff that's related, though coming from a different direction. it's concerned with rectangular regions that are delineated by particular characters - but it provides for things like auto-fill and motion commands that are constrained to the bounds of those rectangles.
(i mention this in the hopes that there's some unification of effort possible. i am frustrated by the lack of control of the auto-fill in table.el, for instance, and would love to have it and related functionality generalized as you're suggesting, to generic emacs operations confined to rectangular regions. it's too hard to get the current, specialized operations to do what i need.)
And here's a quote from narrow-to-region for a rectangle:
If one is interested in working with rectangles - edit text (with filling, justification, what not), narrow it (and have regexp matchers ^, $ do the expected) then one can look at table.el and extract portions of it to the Emacs "core".
Remember, rectangle is but a table cell (possibly with no "geometric rectangle" surrounding it.)
Related
Prettier (VSCode) does a great job beautifying my code on save.
There is one feature that I consider important in code formatting which I can't find in Prettier.
I want to align chars =, :, =>, etc., in multiple lines like this VSCode plugin does.
The universal answer to questions like "How can I make Prettier format my code in such a way that ...?" is "You can't."
Prettier's purpose is to facilitate collaboration in projects and teams by taking care of code style, not to be a customizable code formatter that does whatever the user wants. In other words, the formatting it produces isn't really customizable, and this is intentional. Read more here. If you need that degree of control over formatting, you're likely not the target audience for Prettier.
This specific code style (alignment) that you want to have is considered diff-unfriendly (e.g., see here or here). Prettier's line breaking algorithm by itself has similar problems (e.g, adding one argument to a call might lead to a multiline diff if the line becomes too long), but they're inevitable, so Prettier's strategy is to compensate for that by avoiding other diff-unfriendly things.
You could always utilise the Alt key or Code Maid to clean up.
If you hold the Alt Key and drag down then you can highlight the spacing to either remove or align your code.
I'm using Emacs 25.1, with the latest stable release of clojure-mode. When clojure-mode (not in other major modes like js2-mode) is turned on, everything is strictly aligned, no extra whitespace is allowed before any forms. For example,
(def
last (fn ^:static last [x]
(if (next x)
(recur (next x))
(first x))))
I can't insert a space (automatically removed after insertion) before the first non-whitespace character on each line. This kind of behavior is just not desirable to me. I tried changing the variables in the Clojure group, but nothing seemed to work. How can I turn this behavior off?
It isn't exactly clear what you mean, but I suspect you are referring to the way
Clojure will align forms in things like let bindings so that all the symbols and
values being bound are aligned i.e.
(let [a-val1 (something-1)
another-val (something-2)
final-col 12]
(do-some-stuff))
rather than
(let [a-val1 (something-1)
another val (something-2)
final-col 12]
(do-some-stuff))
If this is the case, then there are a few things you can try.
Look at the variable clojure-align-forms-automatically
clojure-align-forms-automatically is a variable defined in
‘clojure-mode.el’. Its value is t Original value was nil
This variable is safe as a file local variable if its value
satisfies the predicate ‘booleanp’.
Documentation: If non-nil, vertically align some forms automatically.
Automatically means it is done as part of indenting code. This
applies to binding forms (‘clojure-align-binding-forms’), to cond
forms (‘clojure-align-cond-forms’) and to map literals. For instance,
selecting a map a hitting ‘M-x indent-for-tab-command’ will align the
values like this:
{:some-key 10
:key2 20}
You can customize this variable.
This variable was introduced, or its default value was changed, in
version 5.1 of the clojure-mode package.
The other variable which you might want to look at is clojure-indent-style
clojure-indent-style is a variable defined in ‘clojure-mode.el’. Its
value is ‘:always-align’
This variable is safe as a file local variable if its value
satisfies the predicate ‘keywordp’.
Documentation: Indentation style to use for function forms and macro
forms. There are two cases of interest configured by this variable.
Case (A) is when at least one function argument is on the same line as the function name.
Case (B) is the opposite (no arguments are on the same line as the function name). Note that the body of macros is not affected by
this variable, it is always indented by ‘lisp-body-indent’ (default
2) spaces.
Note that this variable configures the indentation of function forms
(and function-like macros), it does not affect macros that already use
special indentation rules.
The possible values for this variable are keywords indicating how to
indent function forms.
‘:always-align’ - Follow the same rules as ‘lisp-mode’. All
args are vertically aligned with the first arg in case (A),
and vertically aligned with the function name in case (B).
For instance:
(reduce merge
some-coll)
(reduce
merge
some-coll)
‘:always-indent’ - All args are indented like a macro body.
(reduce merge
some-coll)
(reduce
merge
some-coll)
‘:align-arguments’ - Case (A) is indented like ‘lisp’, and
case (B) is indented like a macro body.
(reduce merge
some-coll)
(reduce
merge
some-coll)
You can customize this variable.
This variable was introduced, or its default value was changed, in
version 5.2.0 of the clojure-mode package.
There are some other alignment/indentation variables which you may also want to
check out - try M-x customize-group clojure-mode and M-x customize-group
cider to browse and see if anything is relevant. You might also find
something relevant on the cider documentation site. In particular, look at the
manual section on indentation
UPDATE EDIT: Based on additional information from the OP communicated in comments, I
decided to edit and extend this answer. I've left the original response as I
feel it may be useful to others who search and find the OPs question. However,
with the additional info in the comments, I don't think the answer addresses the
OPs actual issue, so have extended the answer below which I hope will help.
Some Emacs modes are more rigid or enforce code format more strictly than
others. This is particularly the case with vary regular languages like Clojure
(and most lisps generally) whee the syntax is minimal and the rules regarding
code indentation are easier to define and tend to have wide consensus.
The situation for the OP is further complicated because they are using a
pre-defined Emacs configuration - in this case Steve Purcell's emacs.d,
which is one of my favourite pre-defined or canned Emacs configurations. The
one drawback with these pre-defined configurations is that they will turn on and
define many optional features of the Emacs editor which may or may not be
in-line with user personal preferences. Emacs tends to have a vary conservative
position when it comes to new features or enhancements. Often, they are disabled
by default to avoid impacting new users. The cost for this conservative approach
is that over time, Emacs can seem primitive or less feature rich compared to
other editors to new users who expect some of this behaviour to be enabled by
default. By using a canned configuration, you get one person's preferred setup
without having to go through the often long and difficult process of doing it
yourself. The downside is that when it does not match with the user's
expectations, the user does not have the knowledge or understanding to make the
changes and it is difficult to get help because others don't know/understand
what their configuration is already.
As an example how using these pre-defined setups can complicated matters, when I
last looked at the Purcell configuration, it used the ELPA package
aggressive-indent, which enforces more rigid indentation rules and it could
well be this package rather than clojure-mode which is enforcing the rigid
indentation rule.
The OP mentions they are concerned regarding this auto-formatting as it could
cause problems when contributing to other projects and issues with
auto-formatting making the code look like there has been more changes than has
actually occurred due to the version control picking up the whitespace
adjustments. This issue mainly comes up over differences due to the use of tabs
and spaces. to a large extent, such issues are less frequent these days as most
version control systems can be configured to ignore whitespace changes.
In this case, my recommendation is to do nothing for now as there isn't a real
issue yet. Continue to use the canned configuration and continue to ask
questions, but also spend some time trying to learn and understand the
configuration. At some point, once your comfortable with Emacs, you will likely
want to re-configure the system to better meet your own personal taste. By this
time, you will have a better understanding of Emacs, the various options it has
and the way different modes work. When you run into specific real issues which
you cannot solve, then post another question. It is likely at that point, you
will have concrete information and someone will be able to provide specific
help.
How can you work with the two sides of a bilingual/parallel text?
I know how to run diff and ediff on a text to spot little differences, but a bilingual text will have two completely different sides (expect for the paragraphs, number of chapters and other structural elements like notes). End of line and end of paragraph are certainly useful to mark the units of the two sides.
Is it possible to open two buffers, side by side, and tell what matches what?
This is a hard problem but I dug up an old blog post I read awhile ago that is relevant (and even mentions emacs for preprocessing):
https://languagefixation.wordpress.com/2011/02/09/how-to-create-parallel-texts-for-language-learning-part-1/
Especially check out part2
Beyond that, my suggestion is twofold:
1) Operate on small parts at a time (a chapter or less) and not an entire book
2) Utilize alignment tools available to generate metadata which emacs uses to just 'prettify' the buffer
As there's no existing solution (that I know of or can find), you'll have to get dirty with elisp and create a major or minor mode to colorize matching segments and/or navigate segments.
Quick Hack
However, I hacked some elisp together that takes preprocessed text and uses emacs concept of 'paragraph' and 'sentence' to colorize the buffer; it's a little verbose so I stuck it in a gist:
https://gist.github.com/terranpro/3175bb9f3ed00b3a145c
It's pretty ugly but should give you a start; just run it once in each of the text buffers. But be aware that you'll need to have the text already ready in terms of emacs' paragraphs and sentences (two spaces after a period!!). Hope it gives you a decent starting point.
For the past year and a half, I've maintained a monolithic buffer in Org Mode for my engineering notes with my current employer. Despite containing mostly pointers to other documents, this file has become quite large by human standards (48,290 lines of text), while remaining trivially searchable and editable through programmatic means (read: grep and Org Mode tag search).
One thing bothers me, though. When I perform a tag search using Org Mode 6.33x, Org's sparse tree view retains the folded representation of unmatched trees within the buffer (that is, content preceded by a single asterisk, *). This is generally useful for smaller buffers or those better organized into a single tree with multiple branches. However, this doesn't work especially well for documentation where each new tree is generated chronologically, one for each day, as I've been doing.
.
Before I continue, I'll note that my workaround is inherent in what I've just asked, as are the obvious alterations in my documentation habits with this buffer. However, the following questions remain:
1) Why does Org Mode organize trees in this manner when performing sparse tag searching? The technical details are self-evident, the UX decisions less so.
2) If I wished to correct this issue with a script written in Emacs Lisp, what hooks and commands should I explore in more detail to restructure the document view? Writing overrides for the standard commands (for example, org-match-sparse-tree) is already self-evident.
.
Thank you in advance.
As you already noticed the problem only affects the top level headings. The good thing is that in org-mode you can demote easily all headings with simple keystrokes. This way you can avoid the problem. Also cleaning up afterwards are just some simple keystrokes.
Step-by-step instructions:
Mark the full buffer
Call M-right (for outline-demote)
Input * root\n at the beginning of the file
Now, build up your subtree and do what you want with it.
When done you can remove * root\n at the beginning of the file and promote the headings again with M-left
I have got the impression that you can even leave the overall-heading where it is for your application.
I'm producing a function for imenu-create-index-function, to index a source code module, for csharp-mode.el
It works, but delivers completely unacceptable performance. Any tips for fixing this?
The Background
I looked at js.el, which is the rebadged "espresso" now included, since v23.2, into emacs. It indexes Javascript files very nicely, does a good job with anonymous functions and various coding styles and patterns in common use. For example, in javascript one can do:
(function() {
var x = ... ;
function foo() {
if (x == 1) ...
}
})();
...to define a scope where x is "private" or inaccessible from other code. This gets indexed nicely by js.el, using regexps, and it indexes the inner functions (anonymous or not) within that scope also. It works quickly. A big module can be indexed in less than a second.
I tried following a similar approach in csharp-mode, but it's quite a bit more complicated. In Js, everything that gets indexed is a function. So the starting regex is "function" with some elaboration on either end. Once an occurrence of the function keyword is found, then there are 4 - 8 other regexps that get tried via looking-at - the number depends on settings. One nice thing about js mode is that you can turn on or off regexps for various coding styles, to speed things along I suppose. The default "styles" work for most of the code I tried.
This doesn't work in csharp-mode. It works, but it performs poorly enough to make it not very usable. I think the reason for this is that
there is no single marker keyword in C#, as function behaves in javascript. In C# I need to look for namespace, class, struct, interface, enum, and so on.
there's a great deal of flexibility with which csharp constructs can be defined. As one example, a class can define base classes as well as implemented interfaces. Another example: The return type for a method isn't a simple word-like string, but can be something messy like Dictionary<String, List<String>> . The index routine needs to handle all those cases, and capture the matches. This makes it run sloooooowly.
I use a lot of looking-back. The marker I use in the current approach is the open curly brace. Once I find one of those, I use looking-back to determine if the curly is a class, interface, enum, method, etc. I read that looking-back can be slow; I'm not clear on how much slower it is than, say, looking-at.
once I find an open-close pair of curlies, I call narrow-to-region in order to index what's inside. not sure if this is will kill performance or not. I suspect that it is not the main culprit, because the perf problems I see happen in modules with one namespace and 2 or 3 classes, which means narrow gets called 3 or 4 times total.
What's the Question?
My question is: do you have any tips for speeding up imenu-like indexing in a C# buffer?
I'm considering:
avoiding looking-back. I don't know exactly how to do this because when re-search-forward finds, say, the keyword class, the cursor is already in the middle of a class declaration. looking-back seems essential.
instead of using open-curly as the marker, use the keywords like enum, interface, namespace, class
avoid narrow-to-region
any hard advice? Further suggestions?
Something I've tried and I'm not really enthused about re-visiting: building a wisent-based parser for C#, and relying on semantic to do the indexing. I found semantic to be very very very (etc) difficult to use, hard to discover, and problematic. I had semantic working for a while, but then upgraded to v23.2, and it broke, and I never could get it working again. Simple things - like indexing the namespace keyword - took a very long time to solve. I'm very dissatisfied with it and don't want to try again.
I don't really know C# syntax, and without looking at your elisp it's hard to give an answer, but here goes anyway.
looking-back can be deadly slow. It's the first thing I'd experiment with. One thing that helps a lot is using the limit arg to, say, restrict your search to the beginning of the current line. A different approach is when you hit the open curly do backward-char then backward-sexp (or whatever) to get to the front of the previous word, then use looking-at.
Using keywords to search around instead of open curly is probably what I would have done. Maybe something like (re-search-forward "\\(enum\\|interface\\|namespace\\|class\\)[ \t\n]*{" nil t) then using match-string-no-properties on the first capture group to see which of the keywords was found. This might help with the looking-back problem as well.
I don't know how expensive narrow-to-region is, but could be avoided by when you find a open curly do save-excursion forward-sexp and keep point as a limit for the current iteration of your (I assume recursive) searches.