Activity for Vic
-
Vic modified a comment on ticket #1489
I don't know how to make a patch in git either. On github.com I just know how to make code changes directly in the website (or copy them from a file in my computer), then "commit". There I also can compile online (appveyor.com). If you know a simple way to get the patch in github, please let me know: https://github.com/victorel-petrovich/notepad-plus-plus_vic/commit/0a289fbcdfed89ec82c41f0131145d21ac18c727 I have forked your project here on sourcefourge, but I don't see how to make a patch. By the...
-
I don't know how to make a patch in git either. On github.com I just know how to make code changes directly in the website (or copy them from a file in my computer), then "commit". If you know a simple way to get the patch in github, please let me know: https://github.com/victorel-petrovich/notepad-plus-plus_vic/commit/0a289fbcdfed89ec82c41f0131145d21ac18c727 I have forked your project here on sourcefourge, but I don't see how to make a patch. By the way, how about moving the project to github? :)...
-
I don't know how to make a patch in git either. On github.com I just know how to make code changes directly in the website (or copy them from a file in my computer), then "commit". If you know a simple way to get the patch in github, please let me know: https://github.com/victorel-petrovich/notepad-plus-plus_vic/commit/0a289fbcdfed89ec82c41f0131145d21ac18c727 I have forked your project here on sourcefourge, but I don't see how to make a patch. I probably need to install https://www.mercurial-scm.org/downloads...
-
OK. But it doesn't have to be the other way around, does it? I.e, deselection does not have to imply exiting rectangular mode. Just like when keep Alt+Shift pressed, it's possible to deselect (make selection empty) with the arrows.
-
From what I have found, the changes would be made in Message::LineDelete: in this location: https://sourceforge.net/p/scintilla/code/ci/default/tree/src/Editor.cxx#l4017 Please see the attached the compressed file of Editor.cxx. It's first time for me contributing code to Scintilla. I'm not familiar with Mercurial and how to make a patch... I could learn it next time if needed. Explanation of changes: Replaced the lines 4018-4020 of Message::LineDelete: with lines 4008-4011 Message::LineCut:, to...
-
From what I have found, the changes would be made in Message::LineDelete: in this location: https://sourceforge.net/p/scintilla/code/ci/default/tree/src/Editor.cxx#l4017 Please see the attached the compressed file of Editor.cxx. It's first time for me contributing code to Scintilla. I'm not familiar with Mercurial and how to make a patch... I could learn it next time if needed. Explanation of changes: Replaced the lines 4018-4020 of Message::LineDelete: with lines 4008-4011 Message::LineCut:, to...
-
OK. But it doesn't have to be the other way around, does it? I.e, deselection in principle does not have to imply exiting rectangular mode. Just like when keep Alt+Shift pressed, it's possible to deselect (make selection empty) with the arrows.
-
I understand that Right/Left will deselect, and that can be kept. But what I'm refering to in this Feature is not to destroy / collapse the tall vertical caret (the multiple component carets) when you press the arrow keys.
-
I think it only makes sense to disable it for rect. selections. For non-rectangular, the user will be aware (from experience) what the effect will be. Similarly to how backspace is allowed.
-
(I forgot to type the "carets" in the expected result, they would be at front of line3 and line6)
-
SCI_CLEAR does not delete EOL in multi-edit (multi-caret) mode
-
I found this discussion true multi caret editing, where Neil said: An option to allow left/right with rectangular selection may be reasonable if someone contributes an implementation. That's good. I suppose up/down too? On how the feature would work: I think should allow any kinds of arrow movements that still preserve the vertical allignment, as well as the initial count, of the carets. In a first, simpler implementation , could allow: * Left just till start of lines * Right till EOL of the shortest...
-
I found this discussion true multi caret editing, where Neil said: An option to allow left/right with rectangular selection may be reasonable if someone contributes an implementation. That's good. I suppose up/down too? On how the feature would work: I think should allow any kinds of arrow movements that still preserve the vertical allignment, as well as the initial count, of the carets. In a first, simpler implementation , could allow: * Left just till start of lines * Right till EOL of the shortest...
-
I found this discussion true multi caret editing, where Neil said: An option to allow left/right with rectangular selection may be reasonable if someone contributes an implementation. That's good. I suppose up/down too? On how the feature would work: I think should allow any kinds of arrow movements that still preserve the vertical allignment, as well as the initial count, of the carets. In a first, simpler implementation , could allow: * Left just till start of lines * Right till EOL of the shortest...
-
... just like it's possible in case of multi-editing (multi-caret, with ctrl+click) mode.
-
Moving with arrow keys in column (rectangular) mode editing
-
In rest, it's fine. I exaggerated with "IMO, this would be the minimum style change that the site needs.".
-
Increase line height (spacing) on Scintilla.org
-
even for coding?
-
SCI_LINEDELETE works inconsistently with SCI_LINECOPY and SCI_LINECUT
-
As a simple editor user, I think such features would be very useful, whether they are done in Scintilla or in editors. Perhaps it's possible to meet half way, and just have Scintilla expose some parameters or procedure that would make it easier to implement this feature in application? Refering to what @Robert wrote above: The application (or a plugin) can implement logic to measure the start and end position of the folded region, then pass those values to SCI_SETSELECTION. Could it be that this...
-
I think such features would be very useful, whether they are done in Scintilla or in editors. Perhaps it's possible to meet half way, and just have Scintilla expose some parameters or procedure that would make it easier to implement this feature in application? Refering to what @Robert wrote above: The application (or a plugin) can implement logic to measure the start and end position of the folded region, then pass those values to SCI_SETSELECTION. Could it be that this would be more efficient to...
-
I think such features would be very useful, whether they are done in Scintilla or in editors. Perhaps it's possible to meet half way, and just have Scintilla expose some parameters or procedure that would make it easier to implement this feature in application? Refering to what @Robert wrote above: The application (or a plugin) can implement logic to measure the start and end position of the folded region, then pass those values to SCI_SETSELECTION. Could it be that this would be more efficient to...
-
I'm using 4.2 on Windows.
-
overloading a builtin function
-
I'd like to help update the documentations/sites (reading it now). Let me know how to contribute.
-
Hi! I'm exploring this program, on windows 7. It works :) . By the way, many links in the supplied .html files are obsolete . In particular, in "External links.html", the english pages are all dead, except one - and that with non-working applets.
-
Thanks for the advice. Any modification of the line length can then be done through an API just for that purpose. Would that be a function (message), like SCI_SETFOLDLINELENGTH(<unused>, position len) ?
-
Having the end of the fold line at the vertical guide line (or at a fixed offset before that) would only give a false sense of security regarding whether the hidden lines exceed or not the vertical guide line. What the author should have wished for is that the end position of the fold line be set at end of longest of the hidden lines . (Which would kind of agree with the idea that the fold line represents the hidden lines.)
-
Thanks for the advice. Any modification of the line length can then be done through an API just for that purpose. Would that be a function (message), like SCI_SetFoldLineLen(<unused>, int len) ?
-
Thanks for the advice. Any modification of the line length can then be done through an API just for that purpose. Would that be a function (message), like SCI_SetFoldLineLen(<unused>, int len) ?</unused>
-
Option 1 -- in pictures 1,2,3,4 above; Option 2 -- in pictures 1,2,5 above Both options underline at least the whole span of visible chars in header. But Option-1 does not always add a trailing piece (like Option-2) unless the header text is too short and risks being overlooked (like one or few characters). On the other hand, Option 2 has a more consistent look.
-
Having the end of the fold line at the vertical guide line (or at a fixed offset before that) would only give a false sense of security regarding whether the hidden lines exceed or not the vertical guide line. What the author really should have wished for is that the end position of the fold line be set at end of longest of the hidden lines . (Which agrees with the idea that the fold line could represent the hidden lines.) But to look better, I'd set: - end position of fold line to be = max of (end...
-
Having the end of the fold line at the vertical guide line (or at a fixed offset before that) would only give a false sense of security regarding whether the hidden lines exceed or not the vertical guide line. What the author really should have wished for is that the end position of the fold line be set at longest of the hidden lines . (Which agrees with the idea that the fold line could represent the hidden lines.) But to look better, I'd set: - end position of fold line to be = max of (end position...
-
Drawing some horizontal lines with random length looks ugly for me. The lengths are not random, but are determined by position of last character in the header text line. Just like the position of your ***. In fact, the Option-2 above, with user-chosen fixed length of trailing part of fold-line, is equivalent to the ellipsis, but just with a different looking style. Thanks for the links though, I didn't know that was possible in Scintilla. I think the features I'm suggesting here can complement the...
-
Option 1 -- in pictures 1,2,3,4 above; Option 2 -- in pictures 1,2,5 above Both options underline at least the whole span of visible chars in header. But Option-1 does not always add a trailing piece (like Option-2) unless the header text is too short and risks being overlooked (like one or few characters). So it ensures a certain minLen for fold-line, but which won't affect the display of header texts longer than that minLen. On the other hand, Option 2 has a more consistent look.
-
Having the end of the fold line at the vertical guide line (or at a fixed offset before that) would only give a false sense of security regarding whether the hidden lines exceed or not the vertical guide line. What the author really should have wished for is that the end position of the fold line be set at longest of the hidden lines . Which would agree with the idea that the fold line is representative of the hidden lines. But to look better, I'd set: - end position of fold line to be = max of (end...
-
Having the end of the fold line at the vertical guide line (or at a fixed offset before that) would only give a false sense of security regarding whether the hidden lines exceed or not the vertical guide line. What the author really should have wished for is that the end position of the fold line be set at longest of the hidden lines . Which would agree with the idea that the fold line is representative of the hidden lines. But to look better, I'd set: - end position of fold line to be = max of (end...
-
Having the end of the fold line at the vertical guide line (or at a fixed offset before that) would only give a false sense of security regarding whether the hidden lines exceed or not the vertical guide line. What the author really should have wished for is that the end position of the fold line be set at longest of the hidden lines . (Which would agree with the idea that the fold line is representative of the hidden lines). But to look better, I'd set end of fold line to be = end of longest of...
-
Drawing some horizontal lines with random length looks ugly for me. The lengths are not random, but are determined by position of last visible character in the header text line. Or else, the position of your *** is also "random". In fact, the Option-2 above, with user-chosen fixed length of trailing part of fold-line, is equivalent to the ellipsis, but just with a different looking style. Thanks for the links though, I didn't know that was possible in Scintilla. I think the features I'm suggesting...
-
Drawing some horizontal lines with random length looks ugly for me. The lengths are not random, but are determined by position of last visible character in the header text line. Or else, the position of your *** is also "random". In fact, the Option-2 above, with user-chosen fixed length of trailing fold-line, is equivalent to the ellipsis, but just with a different looking style. Thanks for the links though, I didn't know that was possible in Scintilla. I think the features I'm suggesting here can...
-
In the pictures, it's assumed the user has chosen a fold-line MinimalLength of 25 characters; that's why you see a | indicator in the "before" picture and why in "after_A" and "after_B", the fold line it exceeds a bit the visible part of if (everything_ok()){. EDIT: ignore Option B above; better alternative option in my comment below.
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use a very small fold-line MinimalLength, and with Option A , the fold line will match the header text nicely. While people with the other style, again with Option A, can choose a large MinimalLength , to make the fold line extend as they wish beyond the { . Please see attached more example pictures I have...
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use a very small fold-line MinimalLength, and with Option A , the fold line will match the header text nicely. While people with the other style, again with Option A, can choose a large MinimalLength , to make the fold line extend as they wish beyond the { . Please see attached more example pictures I have...
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use a very small fold-line MinimalLength, and with Option A , the fold line will match the header text nicely. While people with the other style, again with Option A, can choose a large MinimalLength , to make the fold line extend as they wish beyond the { . Please see attached more example pictures I have...
-
In the pictures, it's assumed the user has chosen a DefaultMinimalLength of 25 characters; that's why you see a | indicator in the "before" picture and why in "after_A" and "after_B", the fold line it exceeds a bit the visible part of if (everything_ok()){. EDIT: igore Option B above; better alternative option in my comment below.
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use a very small DefaultMinimalLength, and with Option A , the fold line will match the header text nicely. While people with the other style, again with Option A, can choose a large DefaultMinimalLength, to make the fold line extend as they wish beyond the { . Please see more example pictures I have prepared....
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use a very small DefaultMinimalLength, and with Option A , the fold line will match the header text nicely. While people with the other style, again with Option A, can choose a large DefaultMinimalLength, to make the fold line extend as they wish beyond the { . Please see more example pictures I have prepared....
-
And not to forget: a completely different alternative to a fold-line, but with same end purpose, would be to change the background color of (or draw a box around? ) the header text , and again with same/similar span options as described above.
-
Option 1 -- in pictures 1,2,3,4 above; Option 2 -- in pictures 1,2,5 above Both options underline at least the whole span of visible chars in header. But Option-1 does not always add a trailing piece (like Option-2) unless the header text is too short and risks being overlooked (like one or few characters). So it ensures a certain minLen for fold-line, but which won't affect the display of header texts longer than that minLen. Option 2 's trailing piece makes that header seem more important than...
-
Option 1 -- in pictures 1,2,3,4 above; Option 2 -- in pictures 1,2,5 above Both options underline at least the whole span of visible chars in header. But Option-1 does not always add a trailing piece (like Option-2) unless the header text is too short and risks being overlooked (like one or few characters). So it ensures a certain minLen for fold-line, but which won't affect the display of header texts longer than that minLen. Option 2 's trailing piece makes that header seem more important than...
-
Option 1 -- in pictures 1,2,3,4 above; Option 2 -- in pictures 1,2,5 above Both options underline the whole span of visible chars in header. But Option-1 does not always add a trailing piece (like Option-2) unless the header text is too short and risks being overlooked (like one or few characters). So it ensures a certain minLen for fold-line, but which won't affect the display of header texts longer than that minLen.
-
Option 1 -- in pictures 1,2,3,4 above; Option 2 -- in pictures 1,2,5 above I would choose Option-1, b/c it does not add a redundant trailing piece unless the header text is too short and risks being overlooked (like one or few characters). So it ensures a certain minLen for fold-line, but which won't affect the display of header texts longer than that minLen.
-
Option 1 -- in pictures 1,2,3,4 above; Option 2 -- in pictures 1,2,5 above I would choose Option-1, b/c it does not add a redundant trailing piece unless the header text is too short and risks being overlooked (like one or few characters). So it ensuring a certain minLen for fold-line, but which won't affect the display of header texts longer than that minLen.
-
Option 1 -- in pictures 1,2,3,4 above; Option 2 -- in pictures 1,2,5 above
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use a very small DefaultMinimalLength, and with Option A , the fold line will match the header text nicely. While people with the other style, again with Option A, can choose a large DefaultMinimalLength, to make the fold line extend as they wish beyond the { . Please see more example pictures I have prepared....
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use a very small DefaultMinimalLength, and with Option A , the fold line will match the header text nicely. While people with the other style, again with Option A, can choose a large DefaultMinimalLength, to make the fold line extend as they wish beyond the { . Please see more example pictures I have prepared....
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use a very small DefaultMinimalLength, and with Option A , the fold line will match the header text nicely. While people with the other style, can choose a large DefaultMinimalLength, to make the fold line extend as they wish beyond the { . Please see more example pictures I have prepared. Many people judge...
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use a very small DefaultMinimalLength, and with Option A , the fold line will match the header text nicely. While people with the other style, can choose a large DefaultMinimalLength, to make the fold line extend as they wish beyond the { . Please see more example pictures I have prepared. Many people judge...
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use a very small DefaultMinimalLength, and with Option A , the fold line will match the header text nicely. While people with the other style, can choose a large DefaultMinimalLength, to make the fold line extend as they wish beyond the { . Please see more example pictures I have prepared. Many people judge...
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use a very small DefaultMinimalLength, and with Option A , the fold line will match the header text nicely. While people with the other style, can choose a large DefaultMinimalLength, to make the fold line extend as they wish beyond the { . Please see more example pictures I have prepared. Many people judge...
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use just Option A, so fold line will match the header text nicely. While people with the other style, can choose to make the fold line extend as they wish beyond the { . Please see more example pictures I have prepared. Many people judge the hierarchy structre based on indentation, and this feature will allow...
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use just Option A, so fold line will match the header text nicely. While people with the other style, can choose to make the fold line extend as they wish beyond the { . Please see more example pictures I have prepared. Many people judge the hierarchy structre based on indentation, and this feature will allow...
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use just Option A, so fold line will match the header text nicely. While people with the other style, can choose to make the fold line extend as they wish beyond the { . Please see more example pictures I have prepared. Many people judge the hierarchy structre based on indentation, and this feature will allow...
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use just Option A, so fold line will match the header text nicely. While people with the other style, can choose to make the fold line extend as they wish beyond the { . Please see more example pictures I have prepared. Many people judge the hierarchy structre based on indentation, and this feature will allow...
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use just Option A, so fold line will match the header text nicely. While people with the other style, can choose to make the fold line extend as they wish beyond the { . Please see more example pictures I have prepared. Many people judge the hierarchy structre based on indentation, and this feature will allow...
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use just Option A, so fold line will match the header text nicely. While people with the other style, can choose to make the fold line extend as they wish beyond the { . Please see more example pictures I have prepared. Many people judge the hierarchy structre based on indentation, and this feature will allow...
-
Thanks for the quick reply Both options look substantially worse to me. One detail I missed when making those pictures is that people with style of opening { on same line will probably choose to use just Option A, so fold line will match the header text nicely. While people with the other style, can choose to make the fold line extend as they wish beyond the { . Please see more example pictures I have prepared. Many people judge the hierarchy structre based on indentation, and this feature will allow...
-
In the pictures, it's assumed the user has chosen a DefaultMinimalLength of 25 characters; that's why you see a | indicator in the "before" picture and why in "after_A" and "after_B", the fold line it exceeds a bit the visible part of if (everything_ok()){.
-
In the pictures, it's assumed the user has chosen a DefaultMinimalLength of 25 characters, that's why it exceeds a bit the visible part of if (everything_ok()){. It will also be okay (though suboptimal) if this DefaultMinimalLength were a built-in constant.
-
fold line: restrict it to the header text line span
-
Graphical illustrations Assume the following text, line wrap OFF, where imagine || stands for window margin. Hence, you're only supposed to see the text within the 2 vertical columns of ||: a a ||a a a a a a ||a a a a a a a a ||a a a a a a ||a a a a a a a a ||a a a a a a ||a a a a a a a a a || a a a a a ||a a a a a a a a a a || a a a a ||a a a a a a a a a a a || a a a ||a a a a a a a a a a a a || a a ||a a a a a a a a a a a a a || a ||a a a a a a a a a a a a a a || ||a a a a a a a a a a a a a a a...
-
Graphical illustrations (don't know when Ist reply will get approved; this is shorter version) Assume the following text, line wrap OFF, where imagine || stands for window margin. Hence, you're only supposed to see the text within the 2 vertical columns of ||: a a ||a a a a a a ||a a a a a a a a ||a a a a a a ||a a a a a a a a ||a a a a a a ||a a a a a a a a a || a a a a a ||a a a a a a a a a a || a a a a ||a a a a a a a a a a a || a a a ||a a a a a a a a a a a a With wrap ON, SCI_SETWRAPINDENTMODE(1)...
-
-
deeply nested code should be hard wrapped by hand that's exactly why I suggest this feature: so that we don't have to wrap by hand... Also, you don't know in advance how narrow the window is going to get and when. And when the window is wide, above feature uses all of it, so you don't have to scroll up-down a lot. Thanks for the recommendation of the link, I will post it there too then. But since I've already posted it here, would you please aprove my first reply with examples, to have it complete...
-
deeply nested code should be hard wrapped by hand that's exactly why I suggest this feature: so that we don't have to wrap by hand... Also, you don't know in advance how narrow the window is going to get and when. And when the window is wide, above feature uses all of it, so you don't have to scroll up-down a lot. Thanks for the recommendation of the link, I will post it there too then. But since I've already posted it here, would you please aprove my first reply with examples, to have it complete...
-
wrapping: indentation-aware line-length limit
-
Hi Zufu, I had no idea you have YOUR OWN text editor. I'm just a user
-
Yes, I understand that; (or in other Scintilla-based editors)
-
Ather possible use of a prefix_text variable, at least for itemized lists, is having the editor insert automatically the same prefix for the next line, when pressing enter, if current line has that prefix. If after that press again enter without typing any other characters, then it would erase the prefix and just move to next line, at indent position. I.e, just like in more advanced word processors.
-
I just read a bit from this https://stackoverflow.com/questions/402283/stdwstring-vs-stdstring , and what I got is that std::string could hold all ASCII characters (or at least first 127, not sure IIUC), on any platform, without problems. I looked at https://www.rapidtables.com/code/text/ascii-table.html , and these first 127 characters are what we are using most of the time anyways. So maybe implement just ASCII-based prefixes, for now -- it will still be very useful. The doc can have an explanation...
-
You could bug the SourceForge site admins about that, just like I did
-
Hi Zufu, I did not try the Indent language yet, b/c I'm using Geany (for now). But just in case it helps you: an alternative, in Geany edior, you could make your own filetype/language, using the lexer of python or haskell or coffeescript (which fold based on indentation). It's not hard, that's what I did: https://www.geany.org/manual/current/index.html#creating-a-custom-filetype-from-an-existing-filetype
-
I only know very little of C/C++, but maybe I could help with research/ideas/pseudocode/algorithm/discussion/... . (For any of the feature requests I submit) ... and just convert the whole line to a std::wstring ... Maybe first 50 or 100 characters, after indent position, should suffice; after all, it should be a "prefix". While a whole line can be a whole page and more. If it helps performance. ... "a|b|zz" ... And it's very clear to the end user too.
-
I guess a user preference to choose the characters to break at, in addition to whitespace, would solve this, if it's possible. Eventually making it a per-language option, if that much desired.
-
I only know very little of C/C++, but maybe I could help with research/ideas/pseudocode/algorithm/discussion/... ... and just convert the whole line to a std::wstring ... Maybe first 50 or 100 characters, after indent position, should suffice; after all, it should be a "prefix". While a whole line can be a whole page and more. If it helps performance. ... "a|b|zz" ... And it's very clear to the end user too.
-
Hi Neil, I did not know you are the one who could change those options for "milestone", see the reply I got from creating this ticket https://sourceforge.net/p/forge/feature-requests/667/
-
Thanks for the info, Dave!
-
new milestone options
-
:) the only options I had for Milestone when creating this ticket were: Completed Won't implement Commited Duplicate Maybe it was a joke from those who made that menu :)
-
Colomban Wendling: But in any case, I guess the best solution for all cases would be combining both, e.g. having the lexer able to answer, possibly a property to disable this if wanted, and a mean of adding custom prefixes. I totally agree with this. In addition to tags and keywords, another obvious prefix for lexers is comment symbol(s). The reasons I defend the custom prefixes option are that: It will work when the lexer does not know about the prefixes one needs. Examples: Using bulleted lists...
-
Colomban Wendling: But in any case, I guess the best solution for all cases would be combining both, e.g. having the lexer able to answer, possibly a property to disable this if wanted, and a mean of adding custom prefixes. I totally agree with this. In addition to tags and keywords, another obvious prefix for lexers is comment symbol(s). The reasons I defend the custom prefixes option are that: It will work when the lexer does not know about the prefixes one needs ex: Using bulleted lists inside...
-
Thanks. I don't see that in Geany though...
-
It could be more interesting to have a way of asking the lexer... Not all languages have their own lexer, thus it may not know the prefixes for the new language. For example, I use .txt files with lexer of haskell or python (to get folding based on indentation), and that lexer has no idea of what kind of prefixes I want to use. Also, even for langs with their own lexer, you may want to define your own prefixes and have scintilla wrap nicely.
-
This sounds flexible, but a little tedious on the part of the consumer, as it has to list all possible prefixes. Not that tedious for a language like Markdown and most others; you'd specify at most a dozen kinds of prefixes. For a lang like XML, you'd use ready made list of opening tags and convert to required format. And a user usualy uses at most a few languages on a regular basis. It could be more interesting to have a way of asking the lexer... Not all languages have their own lexer, thus it...
-
One way for faster user- specification of lots of similar prefixes, is making it accept both literal text, and regex patterns (or just regex) Example: (assuming { and } will signify regex) possible_prefix_text=* ;$$ ;{[-]+ };{<[a-zA-Z]+>[ ]*}; The third would cover -, --, --- etc , what Peter Klenner (creator of this ticket) was after. The forth would cover XML/HTML tags
-
I understood one problem is that the set of prefix text (that includes the possible bullets and spacing before main text ) is arbitrary, and you (dev. of scintilla) can't know in advance what prefix an user may need to use, for different languages/ personal styles etc So, let the user define his possible prefix texts that scintilla will have to skip when aligning the wrapped sublines to the text of Ist subline, then also taking into account how much to indent past the indentation of Ist subline....
-
I understood one problem is that the set of prefix text (that includes the possible bullets and spacing before main text ) is arbitrary, and you (dev. of scintilla) can't know in advance what prefix an user may need to use, for different languages/ personal styles etc So, let the user define his possible prefix texts that scintilla will have to skip when aligning the wrapped sublines to the text of Ist subline, then also taking into account how much to indent past the indentation of Ist subline....
1 >